[00:03:33] Weekly newsletter: Help us choose focus languages for improvements to the lexicographic extension of Wikidata and Abstract Wikipedia https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-03-03 [00:03:43] Now that is something we have been discussing here a few times :) [00:07:54] Those are some great criteria! (So much better than my own initial thoughts on the Phab ticket.) [00:22:42] i would probably recommend doing some data type enforcement at the wikifunction call level even for pure functions, for consistency. i'm not sure if, say, a JS Symbol or other complex object should survive transfer as a reference [00:23:07] if that works for pure functions but not for impure ones that could be weird when changing language boundaries [00:23:41] but for, say a node tree of JS objects with a bunch of strings on them? no need to serialize strings even if you copy, if they're running in the same scripting engine <3 [00:23:54] just have to copy the array or property storage and reuse the immutable strings [00:24:02] binary data is harder (thanks JS) [00:24:19] there does not appear to be an immutable ArrayBuffer variant or freezing method that works [00:26:08] might be worth devising an API type for binary buffers that can be read in slices [00:26:25] pass the reference around cheap (like a JS string) and copy only what you need [00:27:07] worst case an ad-hoc protocol can export a reader callback that returns an ArrayBuffer which gets copied over the boundary, but only the part you read is copied [00:53:31] Thanks! We had the advantage of having read your criteria. But in the end it depends who will apply. If you could get a seed up for Bengali, that would be awesome! (re @mahir256: Those are some great criteria! (So much better than my own initial thoughts on the Phab ticket.)) [00:55:48] @brion: There's a lot of optimization going on already! :D Eventually, you are totally right, particularly given that we want to create whole Wikipedia articles, which will be a lot of string copying, but I hope that we can do these improvements all behind the scenes, without having them be visible to the average contributor [00:57:04] We expect all types to be defined (and enforced!) in the common wiki, and have our own type system - but convert it to native types then for computation in the given language [00:58:25] <3 excellent [00:59:51] yeah i'm getting excited about the more stuff we can stuff into one virtual machine, the less data has to be copied, and the faster calls are going to be [01:01:08] Even if we go with some of the Jupyter infrastructure it might be worth it to have our own JS kernel that's able to do these specific module-level optimizations [01:01:30] and then we have to decide if we can build that on V8 or need a custom runtime :D [01:01:44] hehe [01:02:20] but your comments are extremely timely! we just started working on the executor engine [01:02:28] yay! perfect timing [01:02:37] very much so [01:02:55] you should meet with Cory, who's been leading that effort [01:03:06] we have a meeting scheduled for monday :D [01:26:30] perfect! [07:16:12] Ok, this has been done! (re @vrandecic: Thanks! We had the advantage of having read your criteria. But in the end it depends who will apply. If you could get a seed up for Bengali, that would be awesome!) [14:02:29] Yay! Thank you! (re @mahir256: Ok, this has been done!)