[15:58:58] Hey Elitre. :-) [15:59:14] About to start the weekly triage meeting. Can't hear James_F or others on Webex though :) [15:59:30] Elitre: We're all muted right now, yes. [16:00:16] Welcome everyone to this week's VE triage meeting. As the topic states, please see https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal for details and link to join the audio portion of the meeting on Webex. [16:00:56] As a reminder, if you don't feel like clicking on the link above :p , this is what's on the agenda: reviews of release criteria, of resolved blockers and of nominated blockers, then a short discussion about other business. [16:02:31] https://phabricator.wikimedia.org/project/profile/1015/ is the link to the criteria. [16:02:59] Anyone wishing to discuss that? If not, let's move on. [16:04:11] Here's the link to the solved blockers bugs: https://phabricator.wikimedia.org/maniphest/query/k2_oebAEjnjt/#R [16:04:22] https://phabricator.wikimedia.org/T91145 was a regression. [16:04:40] https://phabricator.wikimedia.org/T91307 irritating, now fixed. [16:04:56] https://phabricator.wikimedia.org/T91299 was about redlinks. [16:05:14] https://phabricator.wikimedia.org/T88386 and https://phabricator.wikimedia.org/T76523 , also fixed. [16:05:56] The latter means the toolbar is now loaded faster. [16:06:25] https://phabricator.wikimedia.org/T89054 was about the context menu. [16:07:15] https://phabricator.wikimedia.org/T70590 was about the behavior of the link inspector. [16:07:40] https://phabricator.wikimedia.org/T89309 affected Safari users. [16:07:59] https://phabricator.wikimedia.org/T71474 , https://phabricator.wikimedia.org/T89923 also now fixed. [16:08:56] https://phabricator.wikimedia.org/T89878 is about integration with OOjs UI dialog. [16:09:43] I might have missed a few of them. [16:09:58] To follow the discussion about nominated blockers: check out the left column at https://phabricator.wikimedia.org/project/sprint/board/1015/ . [16:10:49] End of quarter in 4 weeks! let's not freak out about that though :) [16:11:53] https://phabricator.wikimedia.org/T85622 is a bug meaning that new internal links, in preview, point to an URL which has /w/ rather than /wiki/ in it, and therefore won't work. [16:12:12] Accepting it as a Polish task, since it's so minor. [16:13:02] https://phabricator.wikimedia.org/T89399 is a dependency of a bug accepted last week. [16:13:27] Also being accepted as such. Relatively irritating and inexplicable. [16:13:32] https://phabricator.wikimedia.org/T90420 meant that after clicking Edit on any wiki in Firefox, although the cursor is correctly at the top of the page, the view will immediately scroll to the bottom. [16:13:45] Accepting it. [16:13:52] https://phabricator.wikimedia.org/T90454 is about loading the "welcome to VE" message earlier than what happens now. [16:14:18] improved perceived speed, therefore, accepting as Polish. [16:14:36] https://phabricator.wikimedia.org/T91245 is a performance issue. [16:15:48] (shout out to Wittylama for showing it to us. Accepting it!) [16:16:28] Trevor suggests moving it to the Polish queue though. [16:16:43] https://phabricator.wikimedia.org/T91248 , another performance issue. [16:17:20] What's all this talk about people from Poland [16:17:38] Queueing and being minors etc. [16:17:47] (aka the chimera bug. difficult to explain, but will be accepted) [16:18:05] marktraceur: we love that community :p [16:18:16] https://phabricator.wikimedia.org/T52227 is also related to design, specifically, to the toolbar appearing on several lines when the window is narrow. (So annoying, IMHO.) [16:19:16] oops, I was looking at another task :) https://phabricator.wikimedia.org/T90815 is an item related to the toolbar's design, accepted anyway. [16:20:00] https://phabricator.wikimedia.org/T51806 is a quite old request to display hidden templates somehow so that the editors are aware of where they are, and can interact with them. (My favourite in this batch. Glad my clever colleague Sherry nominated it.) [16:22:04] Accepted as polish task. [16:22:25] https://phabricator.wikimedia.org/T90673 sub-task of an already accepted task. [16:22:36] therefore, needs to be accepted. [16:23:29] anything you'd like to say? feedback about the meeting(s)? [16:24:39] We'd like to switch to Google Hangouts: any concerns about this? [16:25:20] (looks like there are a couple of people on call in Webex right now though). [16:25:44] (three people calling in via phone currently in that meeting) [16:26:18] They'll probably be able to do the same in Hangouts. [16:28:15] Thanks for coming, you'll find the logs and minutes linked from https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal ASAP. We'll probably be using Hangouts for the next meeting. Get in touch or leave further feedback on that very same page. bye! [17:50:40] Tech talk starting in 10 min [17:58:57] talk starting soon! :) [17:59:48] starting in just a few min [18:00:00] awesome [18:00:01] exciting!!! [18:00:36] for once, I make it to one of these events !! [18:00:41] but why am I the only one in the Tech Talk Hangout? :P [18:00:44] yay, hi thedj! [18:00:51] andre__: what's the URL? [18:01:04] don't know, whatever I found in the "internal" Engineeering calendar [18:01:09] I just click, I don't read. [18:01:20] ah, more people! [18:01:46] i only see the youtube link [18:01:56] ohai [18:02:24] almost there :) [18:03:29] The sixth suggested video by Youtube: Hack Hungry Shark evolution monedas y diamantes infinitos ( NO ROOT ) [18:03:38] 7th actually [18:03:47] whouhou, I amde it. [18:04:15] starting! [18:04:28] let me know when you are watching on youtube [18:04:34] Now [18:04:38] rfarrand: now [18:04:54] ping me with all questions :) [18:04:58] * anomie is watching on youtube [18:05:07] youtube not working for me [18:05:25] try to reload jeremyb2 [18:05:37] rfarrand: i'm watching on youtube as well [18:05:37] youtube working for me [18:06:02] ok, maybe got it now [18:06:22] great [18:06:45] 30 people watching! [18:08:17] HA ! [18:08:25] thedj: :) [18:09:24] var_export never gets any love. [18:09:54] WAT [18:09:59] That's pretty horrible. [18:10:32] (the list thing, not var_export) [18:10:46] ewww, why do these code samples have smart quotes? :-) :-) [18:11:20] <^d> superm401: echo var_export($var, true) [18:12:03] ^d, yep. What about it? [18:12:26] <^d> superm401: I love var_export :) [18:12:27] rfarrand: in the future can we start the stream early (5 or 10 mins ahead?) even if the camera, etc. is not actually turned on. or else google fix whatever the problem is that means I can be early and even leave and come back a few times but still can't manage to get it to start here at the same time you guys started. (so almost guaranteed to miss something) [18:12:32] :) [18:12:45] ^d, you can leave off the echo and true, of course. It outputs to stdout by default. [18:13:13] <^d> echo "foo msg: " + var_export... [18:13:17] rfarrand: (I'm willing to do a bit of testing with you if you want to figure out a way that works well) [18:14:02] jeremyb2: let me think about a good way to address that. That would effect the start of the youtube video which is what most people end up watching over time. I can always invite you directly to the hangout which we start early. [18:14:11] I think there's an implicit "if you have your editor configured to do that" [18:14:34] Yeah, sounds like a really cool feature though. [18:14:41] Presumably there's a command line version too. [18:14:45] rfarrand: which is why we should test with a dummy hangout. IIRC it's not just on or off. [18:16:27] jeremyb2: happy to test ideas out with you [18:16:42] danke :) [18:17:31] Hm.. sounds like Node.js / yield :) [18:17:39] I wonder if we could write a transpiler from Hack to node.js [18:17:40] :P [18:17:53] and mediawiki will run on nodejs, at last [18:18:50] <^d> nodejs would be so much nicer without the js part [18:19:06] ^d: It's event loop has been factored out for a while now [18:19:07] Krinkle: hehe :) [18:19:09] there's lots of binding actually [18:19:11] even php ones [18:19:29] libuv [18:19:31] <^d> srsly? color me surprised [18:19:41] https://github.com/joyent/node/tree/master/deps/uv#readme [18:19:42] * ^d doesn't exactly pay attention though [18:20:02] https://github.com/libuv/libuv * [18:20:09] I guess async functions useful if response involves multiple requests to services [18:20:33] worse, it often DOES io. [18:20:49] I think that's overstating how much Lua we use a bit. [18:20:55] Yeah, it's the best we can do without threading. [18:21:15] <^d> superm401: Well, we use it a ton on-wiki. I don't think the analogy really works [18:22:08] <^d> Although maybe you could async calls to luastandalone [18:22:11] * ^d shrugs [18:22:49] so, async in php basically only works as long as you have lots of other async stuff at the same time right ? [18:22:59] You'd need multiple instances, a single instance isn't thread safe I don't think. [18:23:05] (of Lua) [18:23:07] thedj, in actual PHP, not much async support at all. [18:23:15] <^d> anomie: probably yeah [18:23:26] i meant hack sorry, already mixing stuff up [18:23:58] PHP can use pthread, but it's rare. [18:24:34] pthread + apache doesn't mix too well, IIRC [18:24:42] Sounds like Hack has nice syntax even for linear async dependencies. [18:24:55] Hm.. callback hell or promises are hidden with 'yield' in js though, much like 'await' [18:24:58] But maybe more of a perf win for depending on multiple once at once. [18:25:01] He, he's saying that now. cool [18:25:11] multiple ones. [18:26:56] I wonder what happens if I await a non-async function [18:27:25] runtime error ? or just gets ignored ? [18:28:21] akosiaris, it has a type checker, so maybe it could warn you. [18:28:47] superm401: could be [18:29:27] <^d> maybe you wait until you dieeeeee [18:29:27] Question for later: Would there we a way to do call u->friends() speculatively before you know if it's needed, then only use it sometimes? [18:30:21] doesn't strong typing imply you can't have dynamic dyspatch like $foo->$bar($foo)? B/c I don't see how it is possible to statically check that [18:31:18] SMalyshev: how is that different from $$n ? [18:31:33] SMalyshev, you mean like List? [18:31:35] jeremyb2: not different, really, just one example. [18:31:51] With function append (T obj)? [18:32:13] superm401: happy to ask, how do you verbalize "u->friends()" [18:32:15] heh [18:32:41] superm401: no I do not. I mean dynamic function call which is not known in advance. I heard "if static type checker passes it, type error can not happen at runtime". I don't see how $foo->$bar($foo) can fullfill this promise [18:32:46] I wasn't paying attention, what does the ? mean in the function arguments ? optional ? [18:32:54] rfarrand, "call the friends method on u" should work. Thanks. [18:32:56] SMalyshev: the type checking is optional [18:33:06] thedj: ? means it is "nullable" [18:33:08] thedj: It means the object could be null [18:33:08] thedj: nullable [18:33:13] ah righ [18:33:25] superm401: thanks :) [18:33:30] Oh, that's nice (specifying field and constructor param simultaneously). [18:33:41] k. thx guys. was difficult to hear from the kitchen :) (coder needs coffee) [18:33:44] spagewmf: that doesn't answer the question. Let's say I use that option and all my functions are types. You still don't know statically what $foo->$bar means [18:33:47] Sometimes people in PHP don't even specify the field, making it public, which is not great... [18:34:37] SMalyshev, oh, I missed the $bar before. [18:34:46] Maybe if you use that you're giving up on the static type guarantees. [18:35:25] Hack accepts most PHP (type annotations are optional), but the static typing only applies if you annotate. [18:35:29] superm401: that's not what he said :) he said type error can not happen [18:35:49] SMalyshev, sounds like a question for the end. :) I interpreted it as only if you use the type annotations. [18:35:50] but if you do $foo->$bar it can happen [18:36:24] this list example is really bad example [18:36:26] What about function foo( int|string $x ) ? [18:36:26] who has actually used hack already? [18:36:41] if it's absolutely edge case why harp on it so much? [18:37:10] SMalyshev, he mentioned it twice briefly... [18:37:17] Not async? [18:37:20] nobody sane would do list($a, $b) = "string" anyway [18:37:44] jeremyb2: FB mostly [18:37:50] <^d> SMalyshev: Not on purpose [18:38:05] ^d: how can you accidentally write such code? [18:38:07] thedj: i meant within wikimedia/mediawiki :) [18:38:14] <^d> But the $foo = 'string'; list($a, $b) = $foo [18:38:18] <^d> That's possible by accident [18:38:19] thedj: (even just to play or for 10 minutes) [18:38:29] SMalyshev, you might right list($a, $b, $c) = $threeLetterCode; [18:38:30] ^d: that works as expected. Only literal string doesn't [18:38:49] superm401: s/right/write/ :) [18:38:54] SMalyshev, it's a legit WTF that they work differently with constant strings. [18:39:22] superm401: yes, except that nobody would use literal string in this context, so it's a bad example [18:39:33] SMalyshev, I disagree. You might in a REPL, or in a test. [18:39:50] superm401: why? for what legit purpose such code may be used? [18:39:58] If it works differently for a constant, that's a major pain when trying out code in a PHP shell (REPL). [18:40:12] I might want to use $threeLetterCode for real, but use 'abc' when testing in a PHP shell. [18:40:21] superm401: did you actually try it and it was a major pain for you in REPL? [18:41:56] I'm 99% sure nobody present every tried it in a real context [18:41:59] jeremyb2: some use outside Facebook on their blog, http://hhvm.com/blog/6005/hack-community-roundup-3 [18:42:07] can we switch tomorrow ? it's not the perfect language, but it seems a whole lot of more usable than pure php to me :) [18:43:03] Don't necessarily want to rush to adopt a language controlled only by one company. We saw how that worked with Oracle. [18:43:04] We can't do much experimenting like that if we want to maintain support for Zend PHP. [18:43:18] Luckily, some of this stuff has been adopted by PHP 7. [18:43:36] Does it transpile to PHP 5.3? [18:43:39] thedj: there are at least two hosts and imagescalers still on zend [18:43:45] list() on strings is gone on PHP 7 btw [18:43:49] <^d> anomie: We'll drop 5.3 support soon enough anyway [18:43:56] <^d> 5.6, I believe [18:43:59] there, zend escape hatch built in ! [18:44:02] ^d: halelujah! :) [18:44:09] anomie: "The Hack transpiler (or h2tp) provides a PHP 5.4+ compatibility" [18:44:11] ^d: I've been hearing that for a while :/ [18:44:11] ^d: well, if it transpiles, then maybe not? ;) [18:44:30] <^d> anomie: Get the rest of cluster on zend. [18:44:32] list() on strings?!.... wow >_< [18:45:47] spagewmf: afaik that does not support at least async, so we still could not use all of hack [18:46:07] That's also almost valid E4X. :) [18:46:16] I wonder object of what is xhp? is it DOM? [18:46:35] can I xpath it? [18:46:40] Woah, weird colons all over the place suddenly [18:47:02] DanielK and all: Can I please ask a general question about AuthManager and ContentHandler, since I'm a little unfamiliar with them, and in terms of Wikipedia's 288 languages? How do these work inter-lingually? And in what ways are https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager and https://phabricator.wikimedia.org/T89733 - anticipating adding further languages? Thanks. [18:47:02] Yeah, are those inner classes or a new namespace syntax or what? [18:47:12] <^d> We should use hack in wmf-config shit. Multiversion and CommonSettings and the like. [18:47:36] ^d: Yeah, or an opt-in database sub class [18:47:42] <^d> That too ^ [18:47:48] xhp is it's own thing. https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919?_fb_noscript=1 [18:48:21] Scott_WUaS_, people are watching a tech talk right now. Maybe ask on https://lists.wikimedia.org/mailman/listinfo/wikitech-l or https://lists.wikimedia.org/mailman/listinfo/wikitech-l . [18:48:29] Err, or https://www.mediawiki.org/wiki/Project:Support_desk [18:48:33] Thanks [18:48:33] ^d: also we could use it where we compile into PHP. E.g. lightncandy compiles templates to PHP. It's unclear if we gain much performance [18:48:56] sounds a bit like angular directives [18:49:09] superm401: I think XHP is more like a different kind of quoted string [18:49:27] Yeah, plus it lets you make elements that know how to render to real HTML. [18:50:13] XHP things are actually classes with a parse level syntactic sugar to let you write them like xml fragments [18:51:58] People probably wouldn't inline them all in real life. E.g. the authors would probably be $postAuthors [18:52:04] Some PHP functions take it in either order! [18:52:13] we are going to need to be quick with questions today - sorry - we need to be out of this room exactly on the hour [18:52:16] can't you just use foreach and write in like 2 lines? [18:53:23] I will work with Josh to fine a way for people to ask questions after this.. maybe be email [18:53:31] *by email [18:53:33] Yay, more javascript paradigms [18:53:53] rfarrand: someone can have the speaker look at his laptop in the collab space while we ask questions in this IRC channel [18:54:01] ok, so we've got shorthand lambda syntax [18:54:11] questions? [18:54:17] which also imports whole scope [18:54:29] In fact, Yahoo recognised the similarity with Hack and wrote static type system on top of Javascript. [18:54:38] imports whole scope [citation needed] [18:54:48] http://flowtype.org/ [18:54:52] question: is anyone using the transpiler? [18:54:54] s/Yahoo/Facebook [18:54:58] I believe Erik B told me it adds implicit use statements. [18:55:08] Flow is Hack for JavaScript. [18:55:27] Also, JavaScript does the same thing, but I doubt it actually keeps the whole scope alive in any sane JS VM. [18:55:30] <^d> bd808: Hahaha. I tried to test hack on a mostly-unused filed in wmf-config but this happened: [18:55:36] <^d> 18:54:30 sync-file failed: Command '/usr/bin/php -l /srv/mediawiki-staging/w/query.php' returned non-zero exit status 255 [18:55:51] anyone in the hangout can ask directly [18:56:05] ^d: heh. lint failure [18:56:07] Krinkle: Flow is improved discussion and collaboration for MediaWiki :) [18:56:08] andrewbogott_afk, bd808, ori [18:56:13] ^ [18:56:38] opps, not andrewbogott_afk, i mean andre_ [18:56:43] Hi rfarrand o/ [18:56:49] hi Krinkle :) [18:57:17] last chance for questions! [18:57:28] ping me so I know that you actually want me to ask [18:58:07] superm401: do you still want "Would there we a way to do "call the friends method on u" speculatively before you know if it's needed, then only use it sometimes?? [18:58:14] rfarrand, yes [18:59:05] so...all hooks wouldn't be type checked? [18:59:09] rfarrand: I want to ask about governance and future. Are there any core committers outside Facebook? What's to stop FB from screwing up Hack? [18:59:20] No need for 'do' [18:59:22] question: is there a performance difference between running async code in hhvm in native hack and the same code transpiled to php? [19:00:29] So strict mode is unusable for us. Ok. [19:00:33] basically, to enable strict typing you have to give up the dynamic nature of php [19:00:47] all variable dispatch etc is gone [19:01:32] and if there's no multidispatch in functions is may become a little awkward [19:01:36] anomie: you can still use strict mode for some files [19:01:52] I argue you never need $foo->$bar in serious code. [19:02:02] who is the speaker? [19:02:09] jzerebecki: you can but you lose the strict guarantee (no runtime errors) unless you go total strict [19:02:15] sure [19:02:21] If there's a finite number of options, explicit flow should do. If there's more than a few, the code needs refactoring. [19:02:28] The only way we could really use it would be via libraries that had both a php and a hack version (or a hack and transpiled version) [19:02:32] It's one of those bad parts you can just take out of the language as a user and not use. [19:02:40] spagewmf and anyone else [19:02:43] or in stand alone service things [19:02:44] Josh is still here [19:02:52] want me to set up a hangout [19:02:55] and you can ask questions? [19:03:07] Krinkle: declaring dynamic dispatch a bad part of PHP is going quite far. IMHO it is one of the good parts [19:03:10] rfarrand: we're in IRC, maybe he can join it [19:03:27] ok, he is standing around chatting with people now [19:03:36] I can suggest it afterwards [19:03:37] SMalyshev: dynamic functions and weak typing (e.g. one function can return different types) is good. [19:03:49] But variable function calls is imho just poor application design. [19:03:55] Krinkle: of course it can be done in other means (like multimethods) [19:03:58] There's no need forit. [19:04:05] rfarrand: if he has a laptop, he visits https://meta.wikimedia.org/wiki/IRC_office_hours , clicks #wikimedia-office^connect and is in [19:04:06] Krinkle: no they are not [19:05:02] they allow you to handle dynamic range of options without writing huge switches etc. [19:05:14] Don't need switches either [19:05:38] SMalyshev: Got an example of where a method name is passed as a variable in good code? [19:06:12] Krinkle: that would depend on your definition of good code. Since you predefined all code where it's used to be bad, we have a contradiction here [19:06:51] if you give another definition - sure, I used it many times, but by virtue of that you'd define my code bad. it still worked, was nice, readable and easily extendable [19:07:38] SMalyshev: An example in code you consider good, then. [19:08:02] I'm open to redefining my scope to include it if it seems reasonable to me. [19:09:51] Krinkle: an implementation of Strategy pattern would use it [19:10:05] for example [19:12:06] (of course, you don't have to pass method name - closure would do too) [19:12:23] in general, what PHP calls "callable" [19:13:42] but beyond that, any code that you would implement as multimethod in a language supporting them [19:13:55] bd808: so for library we'd have to figure out how to have hhvm hosts pick the hack version of the library, and zend hosts use the regular (maybe transpiled) version. [19:15:09] what's multimethod? multiple definitions with different signatures? [19:15:15] bd808: I wonder what that gets us? Maybe runtime speedup, and speaker Jeff would say Hack's type checking delivers better library quality [19:15:19] spagewmf: yeah, which would be a configuration time option I think. Two libraries implementing a common interface and you'd use composer or whatever to choose which one to deploy and run [19:15:34] jeremyb2: basically set of methods that have the same name but different arg types [19:16:02] SMalyshev: method overloading does not exist in PHP. [19:16:05] so you can do foo.bar(xyz, baz) and which bar is called depends not only on foo but also on xyz and baz [19:16:05] Nor javascript [19:16:22] Krinkle: that's correct. But you can do the same with dynamic functions [19:16:27] It only has one definition. How is that related to calling a method from a given string? [19:16:32] spagewmf: and possibly features like async. imagine a service pattern where one version used curl/multi-curl and the other used async/await [19:16:52] Krinkle: don't focus on strings, it doesn't have to be a string, any callable [19:17:00] I think we're in a terminology mixup. I'm not familiar with using terms 'multimethod' or 'dynamic functions' by your definition. I probably know them as something else. [19:17:15] SMalyshev: Invoking a callable (e.g. $foo() as opposed to $bar->$foo()) is fine. [19:17:19] but the danger of course is diverging implementations and the php codebase rotting (unless it was transpiled) [19:17:22] And Hack will support that [19:17:31] Krinkle: imagine you have a Printer method than needs to print a number of types. $printer->print($anything) [19:17:54] does phab use hack? are we running on zend or hhvm? [19:17:57] how you make it easy for it to do that without having a huge switch or other uglyness? [19:18:08] Printer class rather [19:18:10] SMalyshev: print is the method name, yes/ [19:18:18] Where is the variable> [19:18:36] Krinkle: yes, for public API but you can have internal implementation. Imagine you have 20 types to print [19:18:52] each type has different printing code [19:19:11] SMalyshev: And so you'd do that. get_type($anything) and call internal $this->print_$type($anything): ? [19:19:13] That'd horrible. [19:19:39] A switch case for type seems quite reasonable there. [19:19:49] Krinkle: that's one way, not get_type() - that's produce "object" - but with $anything->getPrintType() [19:20:03] Krinkle: 20-clause switch? You really think it's better? [19:20:10] SMalyshev: If the anything object has a method then there is no variable. [19:20:29] Krinkle: if each printing method has 20 lines, you've got 400-line function. And god forbid you miss a break; anywhere... [19:20:30] SMalyshev: can you show us example zend php for what you're imagining? [19:20:31] SMalyshev: I think you misunderstood my original premise. Which is that calling a method name on an object with a variable is bad practice. [19:21:08] e.g. $this->$bar($something) where $bar holds a string that is a method name. [19:21:17] jeremyb2: give me 2 mins to sketch it out [19:21:45] Krinkle: but $this->bar($something) is fine, right? [19:22:48] jeremyb2: Yeah, totally. I don't think any sizable program wouldn't have that. [19:22:54] That's the most boring code any PHP program would have. [19:22:56] ok :) [19:22:57] bread and butter [19:23:08] i don't look at php too much :D [19:23:30] * jeremyb2 repeats: does phab use hack? are we running on zend or hhvm? [19:23:41] chasemp: ^ [19:23:41] jeremyb2: something like this: https://gist.github.com/smalyshev/a6528384707ddbfe38e9 [19:23:48] jeremyb2: I think it might run hhvm, but not using Hack internally. [19:23:57] it doesn't [19:24:11] so, zend or hhvm? [19:24:17] It runs on nginx and claims powered by PHP/5.5.9-1ubuntu4.5 [19:24:19] old but http://www.quora.com/Does-Phabricator-run-on-HipHop-for-PHP [19:24:31] afaik evans opinion hasn't changed [19:24:46] Krinkle: that's exactly what I disagree with [19:24:49] hhvm is //possible// maybe even easy but no one is using it that I have seen [19:25:03] chasemp: Hm... I knew Phabricator doesn't use Hack features. But do we not run it on hhvm, like other app servers? [19:25:14] that's correct [19:25:21] I don't think it is a bad practice - actually, I think it's one of a very useful tools in PHP toolkit [19:25:29] Or does this mean this is the only server we have that uses Zend PHP with a version other than 5.3 [19:25:32] ok, so we could do hhvm if we felt like it but essentially only facebook actually does it [19:25:50] there are other zend instances running I believe, thought I cant' remember what [19:26:03] chasemp: on trusty / php 5.5? [19:26:25] the determination to purge standard php from mw is larger than appservers [19:26:26] we outsourced wordpress. we probably have some drupal [19:26:27] trusty PHP 5.5.9 [19:26:36] is fundraising all hhvm? [19:26:46] (and/or civi) [19:27:28] it's a good question for jgreen but I think not [19:27:34] huh, i thought contacts.wm.o was dead. but seems to still be running [19:27:48] Krinkle: wikitech is on trusty / php 5.5 as well [19:28:43] hhvm isn't all sunshine and roses, for performance it's brilliant in some scenarios right but adds complexity and isn't a total win in every case [19:28:52] but then again it's not my call to make [19:29:29] complexity for developer? or you mean precompiling hhbc? [19:29:35] if we were cpu bound for phab and were willing to take on the local mismatch from the canonical instance it would be worth it [19:29:39] jeremyb2: I don't think fundraising is on a branch that supports hhvm yet. Anything from before this past November or so would have various blocker bugs for running on hhvm [19:29:40] complexity for support [19:29:59] bd808: ahh [19:30:42] bd808: remember the great code review marathon of 2014? reviewing stuff that had already been deployed for a while. (I guess self-merges) [19:31:09] SMalyshev: We'll have to disagree to agree ;-). I've seen the concept you mean there but never written like that and not aware of any qualitative or maintainability compromise. And I'm quite strict when it comes to readability and such in code. [19:31:34] jeremyb2: I didn't get roped into that but I did hear about the list that had to be checked out, yeah [19:33:01] Krinkle: so how would you write that code better? e.g. in example on gist, what would you do? [19:35:31] SMalyshev: If you consider a wide range of conceptually similar problems but that e.g. involve something other than a string (or something that would fit within a reasonable method name) or something that isn't returned by a single method, then one woudl also be forced to use a registry, subclasses, switch case or elseif construct. [19:35:33] https://github.com/wikimedia/mediawiki/blob/631186747a9/includes/content/JsonContent.php [19:35:34] for example [19:35:51] or https://github.com/wikimedia/mediawiki/blob/631186747a9/includes/json/FormatJson.php [19:37:32] Krinkle: if you have complex case that you can not reduce to a simple parameter, yes. But most cases can be reduced so, at least within the parameters for task in hand [19:37:37] Krinkle: SMalyshev: why not just have a ->print() instead of a (or in addition to) a ->getPrintType() ? [19:38:29] jeremyb2: because House class doesn't know about how printing is done, it's not its business. It just holds data [19:39:05] jeremyb2: there could be 100 of different printers, we can't put all of them inside House. Of course, if you have only one printer, then you can do it this way [19:39:23] i don't understand [19:39:30] House doesn't have to know how to print everything [19:39:31] jeremyb2: but once you have the second one, you don't want to go and modify all sibject classes, right? [19:39:34] just how to print House [19:39:35] *subject [19:40:03] jeremyb2: but what if you have 10 ways of printing? as HTML, as SVG, as JSON, as PNG, etc. [19:40:25] that's different [19:40:56] jeremyb2: right. so you can do it both ways, depending on which part would be likely to expand most and which part needs to know most [19:41:04] first you print to e.g. XML. or YAML. or just an in memory structure. then something renders it to HTML, SVG, JSON [19:41:17] both ways are valid, in appropriate circumstances, I just describe on of them [19:41:42] jeremyb2: you seek workaround for a fixed design. that's not a point of the exercise - the point is to find better design :) [19:41:56] If every printer needs logic for every type, something is wrong. [19:42:26] Krinkle: every printer always needs the logic for every type, there's no way out of it. The question is *where* this logic is located [19:42:27] And yeah, it seems like a syntactical trick that saves a few lines of code and decreases readability. [19:42:58] If it only contains data, and the data is in a usable format. The printer should be able to deal with it in a generic way. [19:43:17] perhaps baring a small set of exceptions that are generic based on the shape of the data, not a specific type [19:43:19] Krinkle: no it doesn't decrease redability - you can very easily know which code goes where by just looking at the names, and you also have right types [19:43:37] Anyway, that's how I roll. [19:43:37] o/ [19:44:05] maybe the problem is that this is an abstract discussion. SMalyshev can you give some real production code as an example? [19:44:07] Krinkle: you seem to just refuse to consider the case where you can not have generic logic that works for all cases [19:44:18] jeremyb2: real production code of what? [19:44:38] of $$n or $a->$b [19:44:58] that is analogous to your House example [19:45:10] of course it's an abstract discussion. How discussion about abstract design option like "dynamic function are always bad" can't be abstract? [19:45:30] if you show an example that's not bad [19:45:37] SMalyshev: I still think that the only case that warrants such code flow is if you're dealing with data from a foreign source you do not control, and as such can't blame it on one's own design. [19:46:02] jeremyb2: I don't want to gice you my code since it's essentially the same and I don't have code handy right now since I didn't spend last night looking for specific production code example for this :) [19:47:56]