[00:15:38] bug 34466 should be fixed now by r111802 [00:18:09] raindrift: ping [00:18:19] oh. not here. [00:23:32] kaldari: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/mediawiki/mediawiki.user.js?&pathrev=111695&r1=111694&r2=111695 [00:24:40] AaronSchulz: Here's the rev for 34466: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111802 [00:24:46] also has a minor follow-up [00:29:26] hexmode: sorry to keep you waiting. we've been in a bit of a warroom mode in SF trying to get through this list [00:29:46] robla: np [00:30:16] kaldari: the navpopup problem disappeared, then reappeared, then disappeared for me [00:30:22] caching? [00:32:51] kaldari: on the simple_talk page, someone says it has been broken intermittently for "over a year now" [00:33:02] updating bug and removing 1.19 bit [00:33:24] hexmode: before you do that.. [00:33:58] ? [00:34:18] we have a repro here [00:34:46] on 34480? [00:34:55] I did too [00:36:02] but if you have one *now*, maybe you can figure it out :) [00:36:58] oh...nm [00:37:00] carry on [00:37:12] I thought for some reason you were talking about 34409 [00:37:52] :) [00:55:07] hexmode: I guess the best thing to do if you're still around is to copy the etherpad into an email, update based on your understanding, and go ahead and send. we'll update later [00:55:33] robla: will do [12:05:06] anyone know of the status of mwEmbed etc ? [12:05:25] the old version is still hosted on prototype.wikimedia.org, and it doesn't support https... [17:30:51] gwicke: yay, first two commits to VisualEditor seem to went through smoothly \o/ [17:31:11] yay! ;) [17:31:50] I'll have to start to do an occasional svn up now.. [17:33:16] au: I still wonder what the issue with the marker type is [17:33:40] the weird thing is that it only happens after running a lot of tests [17:33:51] it looks like as you said, i.e. pointer inequality after realloc [17:34:45] the marker seems to be static though, so any pointer inequality sounds more like a bug in the V8 GC [17:34:47] since your patch is obvious the Right Thing here I didn't attempt any other workarounds :) [17:35:32] yeah- I didn't invest too much time into it either [17:37:31] another thing to consider is that we are using both the system copy of html5 to parse the expected test case output, and a local, hacked-up copy to build the DOM from tokens [17:38:21] could also be some kind of unsafe optimization that kicks in after a while [17:38:24] you mean FauxHTML5? [17:38:28] *au nods [17:38:58] yes, FauxHTML5- that is a wrapper around the hacked-up copy [17:39:26] btw, I'll go ahead and take out the cloneNode note from https://www.mediawiki.org/wiki/Parsoid#Getting_started if you're OK with it [17:40:14] wouldn't other users still run into it right now? [17:40:41] no... r111836 fixed that [17:41:02] (that was my first commit :)) [17:41:57] oh, a noob question. I see "ckeditor" in extensions/ too [17:42:27] would that be the code wikia.com is using? [17:43:07] au: not sure if they have open-sourced their editor part [17:43:14] it might as well be an unrelated editor [17:43:22] ah, just both based on cke. gotcha. [17:43:22] there are quite a few around afaik [17:43:30] *nod* [17:44:08] au: please go ahead and remove the warning about cloneNode [17:44:26] thanks for working around that ;) [17:44:48] np, I have three working hosts, this saves more time than applying one patch in each host :) [17:46:13] also feel free to tweak the documentation on running the tests etc [17:46:24] should be much quicker with 'make test' [17:47:29] ok, added a sentence on make test. [17:48:50] au: I added some comments to ext.core.ParserFunction.js [17:49:18] quite a few of those are really magic variables, where the challenge is more about getting those values from regular MW [17:49:52] still a few that can be implemented directly [17:50:57] yup [17:51:16] how would we talk with MW, btw? a REST API? some other HTTP-based API? pure PHP calls? [17:51:45] there is an api, but it does not yet deliver everything we need [17:52:07] there is an api function to parse arbitrary wikitext though [17:52:12] (action=parse) [17:52:18] so it's like a fallback [17:52:33] yep, that is the idea to support all the weird stuff [17:52:40] including extensions and so on [17:52:42] would it be acceptable performance-wise to calling it multiple times during one single js parse? [17:52:56] http://etherpad.wikimedia.org/ParserNotesExtensions [17:53:19] got it [17:53:20] if we can avoid that, then I think we should [17:53:31] but there will be cases where it is necessary [17:53:45] nested template expansion can produce multiple calls [17:54:00] *nod* [17:54:21] though, we're in editor [17:54:26] why are we expanding nested templates? [17:54:28] but for anything directly in the top-level page, I think we should get away with a single request of wikitext bits separated by some unique string [17:54:41] wouldn't they be just represented by markers/lozegnes in the DOM? [17:54:47] the expansion is mostly to provide a WYSIWYG experience [17:55:06] and to support some level of inline editing for template arguments [17:55:14] got it. [17:55:27] http://www.mediawiki.org/wiki/Parsoid/HTML5_DOM_with_microdata [17:55:50] there are some details about template expansion and its representation in the DOM in that document [17:56:32] right now expansion works mostly, but marking the expansion up as microdata is not yet implemented [17:57:09] aye. are there tests for the latter? [17:57:12] expanding articles like [[:en:Barack Obama]] still fails [17:57:24] eats 1.7G, then dies.. [17:57:35] cite templates are very hard [17:57:54] au: there are no tests for the HTML5 DOM yet [17:58:04] but there are tests for regular template expansions [17:58:33] many of those already pass, but I think the tests in that area are relatively harmless compared to the Cite template system [17:58:46] ok. [17:58:57] is the template expansion subsystem in effect for Special:VisualEditorSandbox ? [17:59:16] no, the parser is not used for that at all [17:59:17] *au would like to see it _in vivo_ to better understand it [17:59:35] ok. [17:59:56] parsing to WikiDom (the JSON format) worked until two weeks ago or so, but might now be broken [18:00:18] I started to clean up the internal DOM as it is about to replace WikiDom [18:00:49] Roan is working on the direct HTML DOM -> linear model conversion for the editor [18:01:16] so the editor will also be able to edit plain HTML after that change [18:01:16] k. I guess I'll just focus on making more of "make test" pass for the time being :) [18:01:56] au: I think things like #switch would be nice to implement properly [18:02:11] there is no fall-through support right now [18:02:37] ok, will look. [18:02:51] and the cite template stuff likely fails because some parser function is not yet working properly [18:03:46] ok. thanks much again for the detailed overview [18:03:58] . o O { 244 of 677 is 36%, or mid-1981, in xkcd's "Backward in Time" https://www.xkcd.com/1017/ notation } [18:04:11] *au refrains from adding this extra info to "make test" [18:04:30] *gwicke grins [18:05:35] *au have time-traveled from the year 1981 to hack on Parsoid! :D [18:07:07] au: btw- if you have ideas on optimizations for the token stream framework, or generally design questions / ideas- let me know! [18:09:36] gwicke: wilco! [18:09:58] gwicke: btw, how comfortable are you with me writing new code in .coffee and commit both .coffee and .js ? [18:10:11] ("please don't do that" would be a perfectly reasonable answer) [18:10:42] au: I personally wouldn't mind at all- I was playing with coffeescript myself and liked what I saw [18:10:55] yay! [18:11:00] but we should ask the other developers as well [18:11:32] ok. I won't rush to js2coffee any existing code unles other devs are comfortable with it. [18:11:36] the js output looks quite nice though [18:11:49] it's just I'm measurably ~40% more productive in coffee than in js :) [18:12:29] it just hurts much less ;) [18:12:54] amen to that. especially to our poor wrists ;) [18:14:52] definitely more fun for people fond of Python and Haskell [18:15:42] but there is some push-back against introducing too many languages- I doubt it would be realistic to introduce Haskell for example [18:15:53] perl already generates some backlash.. [18:15:56] yeah, the {record, pun} and (if then else) and {destructuring:{binds}} are all straight from Hs [18:16:02] *nod* [18:16:39] js2coffee.org translates bothways though, so we can still get contributions from people of either preference if it's setup. [18:17:09] that would be very interesting to try [18:17:20] at least for me [18:18:18] coffeescript in mediawiki [18:18:19] wah [18:18:43] yuvipanda: is that a positive wah? [18:18:54] very much indeed [18:19:08] *au was glad it's not a "wat" [18:19:34] since the mobile app is almost all js, there's a part of me that wants to just convert that entire thing into coffeescript [18:19:45] let me see if I can do that once 1.1 goes out [18:19:47] *gwicke is happy to discover another person not convinced of JS being the end of language development [18:20:04] wat [18:20:07] wat indeed [18:20:09] js is a happy accident [18:20:15] could've been worse [18:20:20] imagine PHP 3 on the client side [18:20:28] or VB4 [18:20:33] /clear [18:20:36] :D [18:20:45] but it is an accident nonetheless [18:21:03] and I'll gladly take anything I can get over that [18:21:04] *au clears the buffer to expel those perilous thoughts :) [18:22:24] ok, I'll setup js/coffee conversion starting from __patched-html5-parser.coffee and perhaps new modules. [18:22:42] au: do keep the general community posted on how that goes :) [18:22:57] au: I am starting to work on the internal image handler, might try to do that in .coffee too [18:23:29] yuvipanda: sure! do you mean #wikimedia-dev here, or some other pages/modes of communication? [18:23:35] :) [18:23:37] I am also thinking about using the async module in a few places [18:23:40] wikitech-l, perhaps? :) [18:24:07] gwicke: i'm currently using jquery's deferred's, would perhaps want to switch to async (lighter-weight) [18:24:24] all the async token transforms should be simplified by using it [18:25:08] the transform manager itself does something not provided in async, but each transform fits it quite well [18:25:49] yeah. using it for other projects too; it seems to be the lightest weight of the current crop of solutions [18:25:55] IcedCoffeeScript notwithstanding [18:26:15] we are using EventEmitter to communicate between the stages of the parser pipeline, that works quite well too [18:26:41] but we don't yet take much advantage from it [18:27:12] *nod* [18:28:42] so my laptop battery does not last an entire day on the sofa without power plugged in [18:33:37] au: I still miss GHC and Erlang's support for async IO in light-weight user-space threads [18:34:03] gwicke: node 0.6 fibers fills that niche somewhat [18:34:29] au: will check those [18:34:38] but yeah, it may take another couple years or so to be anywhere close to GHC/Erlang... [18:34:59] ...and they are (rather fast) moving targets too. [18:35:15] especially for parallelization [18:35:34] and STM / parallel GC [18:37:03] exactly; v8 happening to run on server side is a happy accident in itself too. [18:37:38] (meaning such use cases was probably not part of its original design criteria.) [18:38:06] witnessed for example by the 1.7G heap limit ;) [18:38:27] absolutely. ;) [18:46:17] I'll grab something to eat, will be back in a bit [18:54:28] enjoy (.coffee->.js makefile rules committed) [19:26:45] Rather than CoffeeScript it would be interesting to see if we could get Traceur in and fit even more es-harmony features into it [19:30:16] Dantman: clojure-script [19:30:52] Haskell can also be compiled to JS ;) [19:31:13] as could both variants of perl ;) [19:31:16] Traceur! [19:31:20] # http://perlcabal.org/~fglock/perlito5.html [19:32:34] Dantman: more seriously though, an inverse function to Traceur (js->js.next) would be highly interesting if it exists [19:33:35] (to save effort from manual conversion of existing js code) [19:33:46] Heh... awesome http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions [19:34:22] pretty nice! [19:34:35] au: I don't see all too much purpose. js.next is js, it's an upgrade not a new language. Unless you're doing something bad in your code all existing js should run in js.next. In other words there is nothing to rewrite. [19:35:18] true, it's more of a style/idiom mixture thing. [19:36:14] *gwicke would like to see a compiler automatically adding traits in a conversion [19:37:27] just a tiny bit of AI needed [19:39:26] Dantman: are you aware of any serious users of Traceur? [19:40:08] ;) It's js+, do you really need prior users? [19:41:17] *yuvipanda hasn't heard of Traceur [19:41:41] some users and an open development model tend to give a project more stability, so your nice an shiny trait-using code does not break at the next iteration [19:42:12] Uhhh... [19:42:26] if the JS output is still readable, then that might not be too much of a risk though [19:43:22] You do remember that Traceur is basically an attempt at bringing es-harmony/js.next to ES3... [19:43:23] but if it is full of gibberish, then I would not like to be the one having to clean it up when something breaks or the project is abandoned in favor of dart or somesuch [19:44:23] You can't change and break the syntax to something different than what the plan for es-harmony is. [19:44:39] In fact Traceur goes in the other direction. [19:45:08] The spec changed, and Traceur keept some syntax it had already implemented around so that existing scripts won't break. [19:45:43] so it is not in fact the playground it claims to be on its project page? [19:47:22] Playground? Are you misreading the "What is Traceur?" section? [19:47:47] Traceur's goal is to inform the design of new JavaScript features which are only valuable if they allow you to write better code. Traceur allows you to try out new and proposed language features today, helping you say what you mean in your code while informing the standards process. [19:48:25] that translates to playground for me- with the added appeal to try out the new shiny toys [19:48:52] there is not much mention about stability or production uses on the front page [19:50:54] maybe one could get away with not using the 'proposed' part of it [19:53:55] No matter what you're still talking about the difference between "We try to implement an partially-finished specification, and pass feedback from you to the specification makers" and "We're writing our own language, feel free to give us input, and we'll make radical changes to the language" [19:54:34] The only thing that's going to change Traceur's end syntax is if a whole committe decides to change the syntax of something they already agreed on the syntax for. [19:55:03] And there are naturally some pieces there that you can expect will never be changed. [19:55:18] things like a different class model can still bite you, even if the syntax remains the same [19:55:33] from the documentation: [19:55:33] eg: There is no way in hell that `var {a, b, c} = x;` is ever going to be changed. [19:55:36] Warning: Our current class implementation has diverged from what was approved for ES6. Watch this bug for changes to the Traceur implementation of classes. [19:55:54] Pft, I didn't care about the class syntax anyways. [19:56:07] I would feel like kicking any developer that used that in MW core anyways. [19:56:13] your written code might still depend on it [19:56:45] No one uses it now, I'm not writing anything to use it, and I intend to kick a dev the moment I see someone use it. [19:56:56] So, I see no dependency there ;). [19:57:23] That's like saying we might depend on with(). [19:57:33] we agree then ;) [19:58:06] an implementation of a stable subset of Harmony features would be more interesting imo [19:58:08] If we dropped Traceur because there were features we didn't want to use, we wouldn't even be using JS in the first place ;). [19:58:33] Lets see, the most interesting things I'm waiting for: [19:58:44] Naturally destructuring syntax. [19:58:54] Perhaps modules too. [19:59:01] The spread and rest operators. [19:59:37] Some of the object literal improvements. [20:00:06] Perhaps some of the new function syntaxes. [20:00:37] I could have sworn I saw an await syntax somewhere but I can't find it. [20:00:50] most of the things I like about coffescript are sadly missing from that list [20:02:50] things like list comprehensions or => for example [20:05:10] Ah it's in http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [20:05:45] The ability to write async code in synchronus style without needing to infinitely nest callbacks [20:06:28] gwicke: list comprehensions? [20:08:20] Dantman: yep, and generator expressions (but those are not in coffeescript afaik) [20:08:44] IIRC there was some development in that direction, not sure how far along that really is [20:10:08] Oh, generators, iterators, generator expressions, and array comphrehensions [20:11:43] Sure, I'm awaiting those, and harmony has those feature... I just didn't list them because I'm not sure how well they can be manipulated to work in ES3. [20:12:18] FF 11 supports list comprehensions [20:12:27] let even = [ x for (x in values([1,2,3,4,5,6])) if (x %2 === 0) ] [20:12:46] no luck in node though [20:13:01] in version 0.6.8 at least [20:13:12] I'm also awaiting getter syntax like `var o = { get foo() { return 'bar'; } };` but ES3 has no getters so I didn't list it either. [20:13:34] SpiderMonkey invented generator and array comprehension syntax in JS. [20:13:53] That stuff was there before it even made it's way into es-harmony. [20:14:04] yeah, and pushed for inclusion into harmony [20:14:12] Heck, I don't even remember if harmony existed back then ;). [20:14:33] there was this aborted, more ambitious project [20:14:39] That was what 1.8, or did some of it make it's way into 1.7. [20:15:05] not sure what it was called [20:15:29] didn't pay a lot of attention to JS then [20:15:54] comprehensions and let were 1.7 [20:16:44] Expression closures and generator expressions where 1.18 [20:16:47] 1.8* [20:17:09] This all dates back to Firefox 3. [20:17:37] ;) And I'm talking even before 3.5, which is the only version of Firefox that old that's even supported anymore. [20:17:42] but still not supported in main-stream V8 [20:17:43] Crap FF11, this has been around for ages. [20:17:49] Yeah, of course. [20:18:33] Harmony isn't quite finished. [20:18:39] Hence Traceur. [20:18:56] Heck, we'd need to use Traceur anyways. [20:18:57] so- do they support list comprehensions despite not listing them? [20:19:12] Listing, where? [20:19:31] http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures [20:20:30] might just be the list of proposals though, excluding 'stable' parts [20:21:02] Not sure... I'm speaking of Traceur in the hypothetical sense of "It's an implementation of es-harmony, if it doesn't support the feature, then we have the right to implement it and have it pushed upstream" [20:21:37] . o O { Projects named "Harmony" seem to appear whenever there's a lot of discord around... } [20:21:37] And array comprehensions are in harmony. [20:21:40] ( GNU Harmony/Qt)???Apache Harmony/Java, ES Harmony/JS, etc. ) [20:21:43] lol [20:21:59] Well, what do you expect after ES6? [20:22:34] ;) And that's probably a good thing, we'd all be writing ActionScript now if that didn't fall appart. [20:22:50] aye aye. [20:22:57] au: the dart memo was interesting in that respect ;) [20:23:07] lol indeed. [20:25:17] http://traceur-compiler.googlecode.com/svn/branches/v0.10/demo/repl.html does not like list comprehensions [20:30:03] Meh... it's syntax sugar, it can be implemented [20:30:56] In fact given that iterators and generators are already implemented, all the hard work is already done. [20:31:21] Generator expressions and array comprehensions are pure syntax on top of iterators and generators. [20:31:33] pure sugar* [20:31:39] but syntax matters a lot [20:32:16] My point is it's easier to update Traceur to support them than it is to implement iterators and generators in the first place. [20:33:09] very likely, but right now that does not seem to be a research / harmony proposal subject for google [20:33:30] huh? [20:34:22] several of the other traceur proposals are not that far away from dart [20:35:19] Traceur proposals? [20:35:31] http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures [20:35:42] You seam to be missunderstanding something. [20:35:44] These features are proposals for ECMAScript Harmony unless otherwise noted. [20:35:53] These are things that google/traceur is proposing for harmony. [20:36:11] These are chunks of es-harmony specs that are in the 'proposal' phase. [20:36:22] yeah, I said as much [20:36:44] There is no final es-harmony spec. [20:36:59] There are strawmen and proposals. [20:37:30] traceur to me seems to be part of google's two-pronged strategy [20:37:31] Proposals are pieces of the spec that so far have gathered a concensus by the standardization body. [20:37:53] They ARE the most reliable parts of the spec. [20:39:37] Most of the harmony "proposals" are likely about as reliable as something in html5. [20:39:48] well- I am not up to date on which proposals have already made it into specs [20:40:00] None. [20:40:11] The point is there is no es-harmony spec yet. [20:40:25] there seems to be something 'approved' for classes for example [20:40:34] Strawmen ideas go up. They get a concensus. They get turned into proposals. [20:40:50] "Our current class implementation has diverged from what was approved for ES6. " [20:40:57] And the proposals only change if there's another concensus that there is a reason to chagnge the proposal. [20:41:50] http://wiki.ecmascript.org/doku.php?id=harmony:classes [20:41:56] Proposal History [20:42:37] It's not that traceur has diverged. [20:43:11] It's that they implemented one version of classes. And then there was a good reason for the proposal to be rewritten. [20:43:43] Classes could be taken as inherently unstable anyways. [20:43:58] It's not like many of the other syntaxes are likely to change. [20:44:25] How many ways can you come up with to implement the spread operator? [20:44:33] I'll follow that process loosely, but in the meantime there seem to be better ways to produce code than chasing unstable proposals [20:46:33] They aren't even as unstable as a proposal. [20:48:12] And the whole class thing is a good example not a bad example. [20:48:27] Traceur implemented something, and it's still around even though the spec got updated. [20:50:18] Hell, when you look at them. It's different, but 98% of the syntax is the same. [20:50:54] Even if you already had a pile of code implemented using the classes, it would only be minor refactoring. [20:51:06] You could probably even automate it with a regexp. [20:52:12] And to top it off. It appears like it's not even a case of a proposal being changed. It's a case of Traceur implementing an unauthorized strawman, and then the final authorized propsal being slightly different. [20:52:20] Dantman: I do not object if you write your next project using Traceur ;) [21:01:30] In fact I double check the table of contents. [21:01:37] "Classes - Strawman" [21:01:46] "These features are proposals for ECMAScript Harmony unless otherwise noted." [21:01:56] ;) It was "otherwise noted" [21:03:25] gwicke: do we care about / tests? [21:03:46] Heh... right `for ( x of array ) { ... }` will be finally possible [21:04:35] au: that is not yet implemented [21:04:38] hmmm... waitasecond [21:04:43] if we do, I can add some code comparing js-object/php-object equivalenc [21:05:02] it's only used for tests to verify earlier phases of processing, afaics. [21:05:41] I think the statictag thing is just a stub parser hook used in tests [21:05:48] yup, ditto [21:05:55] so it exercises the tag hook machinery [21:06:14] we don't have a generic tag hook machinery/ registration yet, so it fails [21:06:57] in the end, we'll need to have a list of all registered tag hooks on the wiki [21:07:18] right. I meant I'd be happy to code up parserPipeline.setHook [21:07:19] some of those can also be implemented locally, but the remaining ones will have to fall back to the action=parse method [21:07:39] just wanted to know it's not a wasted effort to code up setHook('statictag') to make those tests pass [21:07:50] s/it's not/it'll not be/ [21:08:14] the idea so far is to get the list of registered tag hooks from the PHP parser [21:08:25] so we don't have to replicate the registration interface [21:09:02] there is a TokenCollector class that collects all tokens between start / end tag of a given tag name [21:09:21] I see that [21:09:23] and calls a given function with those tokens [21:09:32] so it'll be responsible for dispatching 'pre', 'nowiki', 'gallery', 'html' [21:09:43] (and 'tag' and 'statictag') so we don't have to write setHook ? [21:09:53] nowiki is handled in the tokenizer, as it changes the tokenizer mode [21:10:04] pre the same [21:10:29] but all the generic ones will be collected using the TokenCollector, or a more generic version of it [21:10:50] aha. makes sense. [21:11:10] performance-wise more specific registrations should be better [21:11:37] so maybe the best would be to register a TokenCollector for each entry in the list of parser tag hooks [21:12:31] got it [21:12:33] right now I am using it manually to implement noinclude / includeonly and am just about to use it for wikilink / extlink expansion [21:12:54] what should be the rank of, say, 'gallery' or 'statictag' be? [21:13:01] "anything >0.1 will do"? [21:13:05] *0.01 [21:13:25] there are three phases [21:13:48] [0.1) is synchronous in-order per input [21:14:06] [1,2) is async and out-of order per input [21:14:17] ... and [2,3) in-order on output token str[Deam [21:14:19] got it [21:14:24] yep [21:15:05] the tendency is to move everything after template expansions [21:15:35] so 'gallery' will be something like 2.5? #wildGuess [21:15:48] so something between 1.1 and 1.9 I guess [21:15:55] ah right. [21:16:05] at least if we want it to be processed asynchronously [21:16:16] we don't actually output tags, it's between expansion and output. [21:16:41] cool. this is starting to make more and more sense :) [21:16:52] anything that involves IO should really be in the async part [21:17:17] yup, otherwise it blocks everyone else [21:17:18] including wikilink expansion, which (sadly) still depends on the existence of the target [21:17:23] Oooooooohhhhhhhhh.... [21:17:53] same with arbitrary extensions [21:18:03] *nod* [21:21:41] Dantman: you are ok? [21:21:45] ;) [21:22:05] I was looking through something on Traceur and I spotted something REALLY interesting. [21:22:13] I'm trying to find the actual spec for it. [21:22:23] k [21:23:48] wow, 22:22 already. time to hit the hay... thanks gwicke++ again for the detailed tour-of-codebase [21:24:07] have a good localtime hackers \o [21:24:17] au: sure, have a good nite! [21:28:08] Ahah, found it http://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensions [21:29:13] From what I was reading http://p.defau.lt/?68aBGT2r20ErNwYKUbRR_A [21:30:02] Think of it. Being able to write `Import ES5.Extension;` at the top of your code, and have all the stuff that we won't put on prototypes in case of conflicts available. [21:30:25] All of a sudden .some .each .filter, etc... all become available [21:31:26] sounds like an improvement [21:31:50] `import ES5.Extension; [1,2,3,4,5].map(#(n) { { n: n } });` [21:32:31] some of that could also be the task of type classes or traits [21:32:50] ? [21:33:11] http://en.wikipedia.org/wiki/Type_class [21:33:46] Overriding equality? [21:34:02] defining it for arbitrary types [21:34:35] including your own types [21:34:49] but you can also add a new operation to built-in types [21:35:33] http://book.realworldhaskell.org/read/using-typeclasses.html [21:37:07] C++ traits offer somewhat related functionality [21:39:22] http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies [21:39:32] in Haskell's case, you get the scoping from the module system btw [22:03:47] Dantman: it is a game of catching up ;) [22:04:08] but good to see nevertheless