[00:16:12] had to set up new vagrant installation because of those php error 503 problems and now, when i try to upload a stl file, it says: Unknown error: "unknown". in uploadwizard [00:16:19] very descriptie error [00:27:32] Apr 8 00:25:47 mediawiki-vagrant apache2[1486]: [proxy_fcgi:error] [pid 1486] [client 10.0.2.2:52451] AH01079: failed to make connection to backend: 127.0.0.1, referer: http://dev.wiki.local.wmftest.net:8080/wiki/Special:UploadWizard [00:28:16] Harri: hmmm.. your apache and hhvm fcgi container aren't playing nice together? [00:28:24] was it a big file upload? [00:28:41] I wonder if apache timed out waiting for hhvm to respond? [00:30:37] James_F: What kind of code review do we want before we merge that first commit so there is a "base" to work on? [00:31:17] Harri: actually, have you checked that hhvm is running inside your vm? something like `sudo service hhvm status` would tell you [00:32:01] the file was the same i uploaded previously [00:32:49] what i noticed was, when i accidentally imported the outdate version of my extension, the page loaded (but the upload said unknown error unknown) [00:33:12] and with the uptodate version, it says 503 service unavailable [00:33:31] can i possibly screw it up from my extension files? [00:34:12] 503 is service unavailable which would match with the proxy_fcgi error [00:34:22] yeah [00:34:32] that error part i copied from logs [00:35:04] but why would hhvm not be running [00:35:24] crash? config problem? [00:36:25] i mean, everything sshould be as before [00:36:35] where exactly do i run the sudo [00:36:42] not running on unix so [00:37:11] inside the VM, so `vagrant ssh` first and then `sudo service hhvm status` once you are logged into the VM [00:37:55] "hhvm stop/waiting [00:37:55] " [00:38:03] ah ha [00:38:08] so hhvm is off [00:38:15] started it [00:38:20] fingers crossed [00:38:25] probably it fails again [00:39:15] its fine again. the unknown error was probably caused by it too [00:43:43] on every vagrant reload it falls down again though... [00:55:18] so, it looks like my module loads at the bottom of the page (which is default way, i understand), but i need it before [00:56:29] also, from the source code i can see, it loads (or, tries to load using mw.loader.load) but the console getstate says its only registered [01:06:04] okay, i just had to define the position. now it loads on top, but it still says my function call is not defined [01:10:54] so it seems to me it down want to load the included scripts from my module [01:11:00] doesnt* [01:20:13] is it possible that it has something to do with globals [01:20:41] my function is defined as "function initScene(file) {" [01:25:28] hmm, that seemed to do the trick, on page load it still says function is not defined, but when i insert the same call to console, it loads [01:27:19] so, it seems it doesnt like $out->addHtml(ResourceLoader::makeInlineScript(Xml::encodeJsCall [11:44:20] Can I know how much data is currently on wikiservers? [11:48:54] biscuit: That's quite a vague question [11:50:25] size of all the data of wikipedia [11:51:16] all deleted articles [11:51:31] all revisions [11:51:51] Everything [12:10:25] * Coren attemps to figure out wth composer-validate wants, then fails. [12:15:49] I don't get it. composer-validate is demanding that my composer.json include name and description properties but afaict no other extension has them. [12:16:07] Hm. [12:16:11] Warnings only? [12:17:21] Ah, indeed. [13:09:44] how would i generate an iterable of wikidata items in lua? [13:51:04] * Coren pretends he's not annoyed at the number of noise files needed to satisfy CI about testing all the javascript that does not exist. [14:19:52] Coren: So, review for TemplateStyles… [14:20:31] Coren: If the code goes through WMF-production-like code review from the start it makes the security review a lot (lot) faster for actual production deployment. [14:20:48] That is what I expect is best. [14:21:12] Coren: OTOH, it makes things slower (and you'll need to find a collaborator; maybe b.d808 given his code review already, maybe T.imStarling given his interest, etc. [14:21:19] OK. [14:21:55] The alternative seems like a desperately bad idea if the extension works out. [14:22:25] Yes, unless the objective now is to get it prototyped enough to have a conversation. [14:22:41] But AFAICT it's more in the "let's do this" phase. [14:23:17] I think so. Everyone agrees on the approach, the only question atm is implementation. [14:24:57] Kk. [14:36:23] Ima need someone used to our CI anyways; I've no idea how we normally do unit testing. [14:41:17] Probably want to get that first revision in now that it passes the tests. Having every fix/change/addition live in the one commit is evil at best. [14:59:29] James_F: ^^. What's my next step? Corner someone to review so we can submit this version and start testing 'for realz'? [15:04:20] Coren: Yes. [16:40:51] I can presume mbstring, yes? [18:24:04] Coren: Ha. Yes, but see the current RfC. [18:40:01] James_F: ... sorry, lost context because reboot. What is that refering to? [18:41:14] mbstring [18:42:02] Oh, right. [18:42:15] Turns out I found a better solution that doesn't need it anyways. [18:50:41] Also, I really really should have switched to lxc for vagrant earlier. :-) [19:08:12] OK. :-) [19:31:25] Coren: so LXC is working better for you? [19:31:47] A full order of magnitude faster, if not "better". [19:31:53] nice [19:49:34] brion: Interesting question; if there is a forbidden functional property in a declration, do we elide it or the entire declaration? [19:50:27] Coren: i think i'd remove the rule, as with unrecognized stuff [19:55:35] well shit, my linode seems to have just gone down [19:55:36] brion: e.g., encountering "background: #FFF url(foo);" remove entirely versus reduce to "background: #FFF"? [19:55:40] right when i was testing crap [19:56:04] Helpful. [19:56:06] Coren: yeah just erase the whole rule like if it was "background: #FFF neverheardof(foo);" [19:57:22] Ima whitelist function-like props anyways. Afaict, only rgb() is undagerous. :-) [19:59:13] hm i think it's not just me, i can't get at their shell bouncer in fremont ca [19:59:39] status page says opeartional though [20:01:54] Are we okay with the elvis operator in our codebase? [20:03:36] Coren: Yes?: [20:05:52] hah [20:06:43] ok looks like some network "fun" between linode's fremont DC and me (and ashburn) [20:09:24] oh nice they updated their status page and tweeted me back :D [20:21:34] I'm putting checks against property whitelists when rendering, not saving. That seems to be to be the expected behaviour if someone changes the setting - styles get the new setting on a purge of the page rather than by having to edit the template again. [20:24:59] Or at least, that makes sense to me. [20:29:45] yeah [20:29:58] sounds riht :D [20:30:00] "elvis operator" TIL