[04:04:25] https://paste.fedoraproject.org/paste/jKXZFpTqL93seRdEw4-9ng/raw interesting how the number of extension classes greatly varies from wiki to wiki [04:04:59] * Krinkle thought ^D was meant to be an emoji [04:11:14] brion: re: https://gerrit.wikimedia.org/r/#/c/390222/ is there no alternative to commiting binary files? [04:11:48] and how could one verify the wasm file is built from the source? [04:12:03] legoktm: by compiling onesself from source :) [04:12:08] or asking me nicely [04:12:10] since i am upstream ;) [04:12:49] that's an interesting general question though [04:14:13] and probably one that'll increase in frequency as more libraries for fancy stuff rely on compiled tools [04:14:30] I mean, are the wasm files reproducible? like if I build from source, will I get the same exact file that you built? [04:14:48] compilation should be deterministic yeah [04:15:05] though theoretically changes in built environment, phase of the moon, version of the compiler .... [04:15:31] you can also decompile and analyse, of course, just as you can the asm.js versions [04:16:19] legoktm: should we have a wider discussion of source v binary formats for our client-side JS world? [04:16:24] could be something we RFC [04:18:58] an intermediate option is to pull the js and wasm together from npm or another package-managed intermediary [04:19:25] so then we're not checking in the binaries (or the other libarary bits that are source), but we're outsourcing the trust management [04:19:50] a wider discussion might be nice, I think this is the first use of wasm in the MediaWiki world? [04:20:06] first i know of yeah :) [04:20:19] But yeah, I always get skeptical when we start commiting binary files [04:20:30] if concerned, i could swap my temp fix back to a using the .js versions until we've had that discussion [04:20:47] no rush :) [04:21:47] Is wasm a major perfomance improvement over native JS? [04:22:13] right now it loads faster, but runs about the same speed in Apple and Microsoft's VMs as the JS versions. over time that may change [04:22:32] it'll be more of a difference when multithread support comes next year [04:23:16] lemme flip the switch back to JS for now [04:25:16] We've avoided having a build step in MW for quite a while but it really feels like our usage of JS is pushing against the current trend of compilign the source into some other representation of JS [04:33:21] we've definitely got a few things that have their own build process and then feed into mediawiki as libraries... [04:36:33] yeah oojs-ui is probably the best example of that [14:05:56] legoktm, brion: Regarding other projects' having a build step to make minified/obfuscated JS, the current MediaWiki way seems to be to JIT-minify via ResourceLoader. [14:06:36] *nod* unfortunately a C/C++ build step seems bad for JIT ;) [14:07:07] we could ship text format of wasm instead of binary but that'd be a pain in the ass and not really any more readable than decompiling it in the debugger [14:07:08] legoktm: Seems not. lol [14:11:29] I wasn't referring to wasm; this is the first I've heard of that existing. [14:11:54] :) [14:12:29] i'm in ur web platform, sneaking in binaries :D [14:12:48] "WebAssembly is a portable stack machine which is designed to be faster to parse than JavaScript, as well as faster to execute." So, like what Java was supposed to be? [14:15:43] similar in some ways :) main difference is that wasm *aggressively* does not have any API or libraries for the code running inside it [14:15:55] so there's no huge standard library to vet [14:16:22] you have to pass JS functions into it to be able to call out to anything [14:21:48] what???? [14:22:03] * hashar goes reading some WebAssembly article [14:22:49] brion: is that what you did to have some Video codec written in C and injected as javascript? [14:23:04] I remember you had an experiment toward that to support newer codec on old browsers/platforms [14:23:29] hashar: i have two builds of the actual codecs done with emscripten, one to JS (asm.js) and one to WebAssembly (wasm) [14:23:43] get_local 0 [14:23:43] i64.const 0 [14:23:43] i64.eq [14:23:44] both are equivalent, but the wasm one loads faster and, potentially, can be better optimized [14:23:49] yueah hmm that looks like assembly :) [14:23:51] :D [14:24:17] but lego is right we should have a wider discussion of such things, especially as regards maintenance and packaging :D [14:24:57] next step, port it to llvm and generate some binary out of those nodejs apps [14:25:17] hehe [19:19:24] James_F: Does CiteThisPage use release-branch compatibility or does it keep compatibility with old MW in master? [19:21:31] It should be release branch because it's tarball bundled [19:28:25] https://github.com/legoktm/autoload-bench/commit/b154e1c42ff10ec7b29fb36d32e661dbba3c173a <-- potential easy autoloader perf improvement [19:33:57] legoktm: Would you mind jumping into this discussion with an upstream project? https://github.com/JetBrains/phpstorm-stubs/pull/289#discussion_r152361728 [19:34:21] I'm trying to convince the phpstorm-stubs maintainer to make a change that would unbreak our CI but he isn't convinced (yet) [19:38:38] anomie: Just release branch like normal, yes. [20:24:53] RoanKattouw: The JetBrains guys... sometimes can be awesome [20:25:01] Other times, it's like banging your head against the wall [20:37:36] RoanKattouw: looking... [20:41:44] RoanKattouw: just to clarify, the tool that does the warnings is phan. we use the phpstorm-stubs mostly for the extensions, as phan can't figure out function signatures if the extension isn't installed [21:25:30] no_justification: https://gerrit.wikimedia.org/r/#/c/392697/