[00:00:22] hashar: it stops and following extensions no longer can run on the hook [00:00:36] wonderful [00:00:42] :p [00:00:56] *hashar looks at Hooks::run() [00:01:11] at the time of writing I didn't realise that [00:01:18] (writing the function) [00:01:45] yeah we are doing a nice foreach of all events [00:01:45] which might be several years ago [00:02:01] maybe we should run all hooks [00:02:09] and then && all the boolean results [00:02:13] not get out of that foreach [00:02:27] hashar: so maybe you could deploy the revision :D the fix is quite straightforward [00:02:35] I could [00:02:46] but it is 1am there and I am on vacation [00:02:50] so I don't want to take any risk [00:03:03] ok, sure [00:03:03] since I will probably disconnect soon [00:03:05] lol [00:03:06] sorry :-( [00:03:25] but I do validate your change. So that is a progress! [00:03:45] no problem, thanks [00:04:29] + I can't deploy [00:04:34] :) [00:06:26] I thought you could.. I see you in the server admin log [00:07:26] I will anyway [00:11:16] SPQRobin: deployed [00:12:06] awesome, thanks hashar :) [00:12:20] can you please test on incubator ? :) [00:12:29] en.wikipedia.org still works somehow :-D [00:12:46] already tested [00:12:56] everything works, including moodbar [00:13:26] enjoy spreading the Wikilove so! [00:13:27] no disasters happened :p [12:35:39] hey, WRT http://strategy.wikimedia.org/wiki/Proposal:Etherpad-based_editing, I'm really eager to know how much work has been done on this, if any [12:39:34] probably less than what has been spent writing that page [12:40:41] Nikerabbit, i see, any potential for a GSOC project next year? [12:41:41] like it says in potential costs: "Low end: Mentor a student for a Google Summer of Code project, or hope that someone in either the Google Wave or Mediawiki communities runs with this idea [12:42:22] yes thats exactly what I wanted to discuss about [12:43:57] ashish_d: are you interested in working on this? [12:44:24] Nikerabbit, yes, I'm really interested in working on this, as much as I can [12:44:42] that's awesome [12:44:58] ashish_d: do you know about the visual editor project? [12:45:43] Nikerabbit, is this http://www.mediawiki.org/wiki/Visual_editor ? [12:45:58] yes, I've been told that it has been built in a way that should make it easier to integrate etherpad like functionality [12:47:11] Nikerabbit, so it should mainly revolve around tweaking it to bring up some etherpad like editing, right? [12:49:02] ashish_d: well yeah there are ddifferent ways to approach it, one would be to replace the edit box with etherpad like thingie, and other would be to implement etherpad like functionality on top of that editor [12:49:19] Nikerabbit, also, I think making it to be GSoC projects it has to be on WMF's priority projects, should this stand a chance considering the fact that its mentioned in the strategy doc [12:50:04] I see no reason why it couldn't be a gsoc project next year [12:50:24] yeah, same here [12:50:40] is it mentioned in the strategy doc? [12:50:51] Neil did some preliminary work on etherpad integration and works on the visual editor, so he should be able to get you started [12:51:21] Nemo_bis, http://strategy.wikimedia.org/wiki/Proposal:Etherpad-based_editing [12:51:29] ashish_d, that's only a proposal [12:51:47] gwicke, the current Etherpad or Etherpad Lite (or whatever the name of the PHP version) [12:51:59] I think he looked at both [12:52:09] ok [12:52:14] but you should try to contact him directly [12:52:26] gwicke, does he hang around in here? [12:52:26] he should be around later [12:52:35] yes, but he's in SF [12:52:52] alright, i may catch up later with him [13:22:06] ashish_d, I find it unlikely that it will be accepted for GSoC [13:22:26] MaxSem, and it is why? [13:22:49] it's hard and the possibility that it will not be completed is rather hard [13:23:02] *rather high [13:24:39] MaxSem, I understand, but what if the proposer can show that it can be done within the timeline, I mean you know figuring out the key complications which can be obviously discussed earlier [13:25:16] MaxSem, ofcourse leaving the complications that come while working on it aside [13:25:22] I would suggest thinking of a good project plan that is doable, it doesn't need to produce perfect, ready to deploy feature [13:26:07] the student will need to demonstrate both stellar JS skills and knowledge of MediaWiki [13:27:01] wish we could apply that hack with Nikerabbit participating in SoC again ;) [13:27:46] MaxSem: technically we could have done it this year [13:28:02] yeah, you became a contractor later [13:28:12] and I'm still a student [13:28:35] so why not? [13:29:01] I'm not a student any longer when the program ends [13:32:22] MaxSem, so, the chances are not completely thin, right? [13:32:51] depands on the student, really [13:33:16] MaxSem, alright, got you [13:33:31] anyway, such important stuff deserves to be done by WMF [13:34:20] MaxSem, thats right, I just thought would be helpful to start talking to dev [13:36:34] well, Neil is currently asleep (I hope) [18:46:55] neilk_, ping [18:47:09] ashish_d: pong [18:47:37] neilk_, hey, WRT http://strategy.wikimedia.org/wiki/Proposal:Etherpad-based_editing, I've been told earlier here that you've done some work on this, have you? [18:47:49] yes [18:47:56] I got a demo working with a fork of Etherpad [18:48:17] I got bogged down trying to truly integrate it into WikiEditor (the existing editor) [18:48:42] johnduhart did something similar with etherpad-lite [18:49:01] but, the advantage of what I did is that it exports your Wikipedia username into Etherpad [18:50:32] neilk_, like using Wikepedia usernames while live editing? [18:51:02] yes -- as you know Etherpad tracks which user added what, and also has a chat on the side. [18:51:11] right [18:51:31] you can enable this on mediawiki.org right now [18:51:34] I think [18:52:20] neilk_, how do I get to it? [18:52:20] hm, or actually not [18:52:30] you need to have our fork of etherpad installed and active [18:52:31] anyway [18:52:59] neilk_, I see [18:53:08] http://www.mediawiki.org/wiki/User:NeilK/vector.js [18:53:18] that will make a new edit tab with "Hackpad" in the title [18:54:25] any major tweak with your etherpad fork? [18:55:01] but, you also need an extension installed in your local MediaWiki, and then you need to be running etherpad (https://github.com/hackpad/pad-mediawiki). I can give you instructions. [18:55:18] it's under "hackpad" because we worked with them as consultants [18:55:54] been kind of dead since May 2011, though. [18:56:02] oh wait, I've heard that on the net while googling ;) [18:56:03] hi ashish_d -- have we met? [18:56:55] sumanah, Most probably not, first time I'm roaming around here [18:57:16] svn+ssh://neilk@svn.wikimedia.org/svnroot/mediawiki/branches/extensions-realtime/IdentityApi <-- that's the extension [18:57:45] welcome, ashish_d [18:58:02] or, if you're not a committer, the SVN url would be http://svn.wikimedia.org/... I think. [18:58:25] sumanah, Thanks :) [18:58:26] sorry it's all in bits and pieces right now [18:58:39] ashish_d: are you by any chance either in San Francisco or New York City? [18:59:01] ashish_d: you should also know that we might be trying to add this directly to VisualEditor soonish, non-Etherpad based sessions. [18:59:30] neilk_, I'm not a committer. I was just eager to know about this project, as I see this good for a GSoC project next year [18:59:45] sumanah, Neither, I'm in India [18:59:50] I'm not sure I would wait until GSoC [19:00:06] the main reason to do it with etherpad at this point is to gather data about what people would do with this [19:00:17] ashish_d: oh, did you & I perhaps meet at the Mumbai hackathon? [19:00:24] and then, if the experiment works out, we could maybe fold that into the new VisualEditor [19:01:11] sumanah, I'll definitely try to make it there as I really want to [19:02:03] ashish_d: the Mumbai hackathon already happened, but we are holding a Pune hackathon in February [19:02:12] ashish_d: you can register now https://www.mediawiki.org/wiki/Pune_Hackathon_Feb_2012 [19:02:16] neilk_, I see, so why not a GSoC project for rumbling the stuff into the VisualEditor [19:02:27] ashish_d: yeah! [19:02:39] sumanah, Yeah, I meant Pune :P [19:03:12] great, ashish_d -- there, you'll be able to meet at least one previous MediaWiki GSoC student [19:03:37] sumanah, that would be a great opportunity [19:04:08] neilk_, so does this stand a chance for GSoC? [19:04:12] ashish_d: you may be interested to read some recent blog entries about our GSoC students -- https://blog.wikimedia.org/c/technology/mediawiki/summer-of-code/ [19:07:08] ashish_d: I think I'd like to see someone work on it sooner than that. VisualEditor stuff will be moving fast -- I'm not sure what it will look like in April or May. I mean, Trevor asserted that he was going to try to add a simple version of this over the holidays, to VisualEditor. [19:07:51] I'm not trying to discourage you, but by the time GSoC rolls around I wouldn't be surprised if there are already more complete implentations, either etherpad, etherpad-lite, or VisualEditor-based. [19:08:38] Should we really be focusing on an etherpad(-lite) extension with VisualEditor coming soon? [19:08:40] however, there will probably still be big things to do there. It might even be more ideal for a GSoC project as we will have a clearer idea of the architecture. [19:08:58] It'd be a cool GSoC project though [19:09:30] johnduhart: yeah, well, the not-so-secret plan behind making undo/redo work was to use the model that Etherpad/Wave uses, so if we did one, we'd get the other. [19:10:04] that is -- we made undo/redo work, and for free, we should get concurrent editing if we add an undo/transform/redo protocol for incoming edits. [19:10:15] ashish_d: here's my thinking: if you get involved now in MediaWiki development (testing, writing little patches, etc.), then by March you'll know what a good proposal would be for the summer [19:11:04] sumanah, I see [19:11:17] johnduhart, ashish_d: I know one thing we'll really need is some sort of server we can deploy to host editing sessions. Maybe that will be etherpad based but more likely written from scratch, maybe in something like node. [19:11:58] neilk_, why not node? [19:12:06] johnduhart, ashish_d: and something we'd really like to do is chat for wikipedia, which is a perennial project -- raindrift and I worked on that a bit over the summer. With labs someone can *really* do this correctly. [19:12:23] ashish_d: you've heard of Wikimedia Labs? [19:12:37] ashish_d: I said it probably would be node :) [19:12:47] sumanah, yes [19:13:03] ashish_d: you can get an account, just ask Ryan_Lane [19:13:04] yay node [19:13:19] yeah, so we keep thinking about adding non-PHP services to the mix here, now we can do that stuff with labs [19:13:19] sumanah: I thought you had to be a developer first [19:13:32] johnduhart: I think if someone intends to develop for MediaWiki that's good enough [19:14:46] johnduhart, neilk_: Aaron Halfaker (EpochFail)'s group at the University of Minnesota is working on the chat project now. [19:15:02] raindrift: oh yeah, I forgot, sorry about that. [19:15:08] raindrift: cool, do you know where I should look for status updates on that? [19:16:38] sumanah: I don't??? I've been keeping up with him via email/skype. I'll ask him if they're maintaining a blog or a wikipage about it someplace, though. [19:17:07] raindrift: yes, please, I would very much like to put this info out to wikitech-l et al. [19:17:17] sounds like it's accidentally closed-source :) [19:18:19] sorta??? there's a lot of design work happening on-wiki now. fetching links. one moment. [19:21:42] initial chat system proposal: http://www.mediawiki.org/wiki/Live_Chat_System [19:22:04] live help mockups (this is the direction we're investigating first): http://www.mediawiki.org/wiki/Live_Chat_System/Help [19:23:11] it sounds like they've focused in on the push+poll+group chat idea as being best. check out the mockups there (http://www.mediawiki.org/wiki/Live_Chat_System/Help#Push_notification_.2B_Poll_list_.2B_Group_chat) for what they're currently working on implementing [19:24:12] raindrift: ok, you know way more about this than me, could I ask you to write a superquick roundup and toss it to wikitech-l? [19:25:01] i can do that, but i'll check with Aaron and see if he wants to do it first. i'd rather have the folks doing the work also do the communication, since it keeps them more engaged. if they're too busy, though, i'll handle it. [19:25:14] thanks raindrift [19:25:23] np. good idea. :) [19:25:30] :) [19:25:40] so, ashish_d, I hope we haven't scared you off [19:26:43] sumanah, No, I was looking at the etherpad fork :) [19:27:30] oh good :) so, ashish_d, I sense that you are resourceful, enthusiastic, and a pretty good self-starter, but we're also here anytime you want advice or guidance or resources regarding Wikimedia, MediaWiki, or GSoC [19:28:03] "with a focus on English Wikipedia" boo boo [19:28:17] MaxSem: where's that from? [19:28:25] sumanah, thank you! [19:28:32] ashish_d: are you already subscribed to wikitext-l? [19:28:32] live chat system [19:28:46] sumanah, No, how do I get there? [19:28:47] MaxSem, doesn't that apply to everything? [19:29:04] ashish_d: it's pretty low-traffic, and it's worth following if you're interested in the parser & VE projects. https://lists.wikimedia.org/mailman/listinfo/wikitext-l [19:29:29] ashish_d: in general, you can get to any of our mailing lists via https://lists.wikimedia.org (they usually end in "-l") [19:29:29] sumanah, alright, thanks thats valuable [19:29:54] ashish_d: very glad to help. And do you have a user login on mediawiki.org ? if you do, there are a few pages you might want to put on your watchlist [19:31:00] sumanah, no, I don't have one yet [19:31:35] ashish_d: go ahead & sign up, it's free of course :) and then put https://www.mediawiki.org/wiki/Future/Real-time_collaboration on your watchlist by clicking the star [19:31:49] ashish_d: or you can subscribe to RSS feeds for individual pages to know when they change [19:32:11] sumanah, thanks for the info [19:32:46] ashish_d: it might also be interesting for you to skim the past few engineering reports https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/November (but there's a lot of info there, feel free to only zoom in on the stuff that interests you, like the Visual Editor and other stuff that gets you thinking about GSoC ideas) [19:33:54] ashish_d: sorry to bombard you, but I figure that it can be a little frustrating to only find out a month into one's investigation, "oh hey, there's this comprehensive report I didn't know about!" and so on [19:35:14] sumanah, that report could be helpful, thanks :) [19:37:41] sumanah: okay, emailed aaron, but also just remembered that those school people are on break. don't necessarily expect anything for the next week or two, but i'll keep on this and make sure it happens. [19:38:13] ashish_d: sadly it looks like I'm not going to be in Pune in February. But you can email me at sumanah at wikimedia dot org if you need assistance & people in IRC are not helping. :) [19:38:20] raindrift: thanks superlatively! [19:38:57] ashish_d: (I am the Wikimedia Foundation's volunteer development coordinator, and the administrator for MediaWiki's participation in Google Summer of Code.) [19:40:10] sumanah, sure and nice to meet you [19:40:20] You as well. [20:36:39] Platonides: Around? Are you interested in expanding/improving the monuments api? [20:37:26] I was thinking about tracking images in a table so we could easily use the api to get one or more images of a certain monument [21:56:44] brion: do you remember whether you wanted to encourage MrBlueSky to apply for commit access? [21:57:20] i'm pretty happy with the overall of his patches yeah [21:57:26] some details on some need some work, but that's all part of the process :D [21:57:36] he's been great about responding to feedback [21:57:48] and actually is pushing for more review/merging of some of his patches, i need to catch up :) [22:05:58] brion: ok, so, should I encourage now, or wait till 1 more round of revisions, or say "apply for ext now and then request core in a month or two"...? [22:07:02] start with ext unless y'all feel happy with core, i don't mind either way :D [22:14:05] with increased number of reviewers, should it really matter? [22:16:00] MaxSem: could you elaborate on that? [22:17:02] everyone makes mistakes first [22:18:42] access was originally separated to ease giving out extension commit rights [22:19:34] however, it quickly switched to "what if they break core?" overcautiousness [22:19:36] IMHO [22:21:37] *MaxSem falls asleep [22:31:30] neilk_: are you around? [22:31:46] gwicke: hey [22:32:17] hey, just thought it might be a good idea to talk about all the refactoring going on a bit [22:32:23] sure [22:32:33] which parts are you planning to attack? [22:32:50] I'm currently rewriting the middle part between the tokenizer and the tree builder [22:32:57] well, I want to get things to the point where you can say "parser = new mediawiki.parser()" [22:33:06] rather than 100 lines located in the test file [22:33:25] ok, so just wrapping up a standard incantation [22:33:32] that also implies that objects get created in a referentially transparent way [22:33:57] i.e. you initialized the tokenizer by poking the PEG src into the tokenizer namespace -- that should just be an argument of the object IMO. [22:34:28] that part is just left over from what the PEG parser already had [22:34:32] this might be premature, but I would really like to get something that I can plug into the visualeditor, even in a primitive way. I don't think these changes will be too bad [22:34:57] keep in mind that the middle part will be a pluggable thing [22:35:02] yes [22:35:11] so you will set up different transformations depending on the circumstances [22:35:18] yes [22:35:22] especially rendering for the editor vs. view [22:35:27] that's what I'm trying to do, to make it less hard-coded [22:36:22] do you think things will break in the meantime? [22:36:27] but, if you think I should stop until you finish your refactor, I will. But I think I can catch up to you in a way that will be okay [22:36:49] I'm pretty sure I can make it work with the system as it exists now [22:36:53] I'm happy if can continue to use parserTests somehow [22:37:10] and as long as the different phases can be called separately [22:37:17] yes [22:37:18] and configured etc [22:37:22] that's exactly what I'm going for [22:37:53] also, the refactoring i'm working on will make things more asynchronous [22:37:57] hmmm [22:38:01] what do you mean by that [22:38:03] so there won't be a complete token list etc [22:38:07] just a stream [22:38:41] so the tokenizer will emit chunks (actually top-level blocks worth) of tokens [22:39:00] which will then be asynchronously transformed by the middle part I'm working on [22:39:19] and emitted as soon as possible to the tree builder [22:39:41] again in a chunked fashion [22:39:47] I don't know what to say [22:39:59] https://www.mediawiki.org/wiki/Future/Parser_development/Token_stream_transformations [22:40:21] okay, well, could we agree on an approach [22:40:46] the parser is composed of components, that are individually configured, and then composed together. [22:41:10] I think it is a very good idea to rip that stuff out of parsertests [22:41:20] right, I saw your note [22:41:32] and to clean up the tokenizer setup a bit [22:41:55] it should not matter whether the objects collaborate closely or what. At least, I don't think so, for now. [22:41:59] but maybe it is a bit too early to refactor too much on the individual stages [22:42:56] especially the middle part, as I'm just about to change that a bit [22:42:57] ok, why don't you let me try, and if you hate it we just roll back [22:43:24] k, just go ahead [22:44:26] I don't want to trap you into an interface you don't want, but what the VisualEditor needs is super-simple [22:44:32] like wikitext in -> wikidom out [22:44:46] as long as that interface stays we could be doing useful things, maybe [22:45:34] all the extension and config registration etc also needs to happen somewhere [22:45:50] that's all in the middle part though [22:47:45] right now I'm trying to get template expansion working [22:48:02] oh, I was thinking of working on that too [22:48:08] in a way that mostly reproduces the MW output and passes parser tests [22:48:19] right so you need your parser env idea [22:48:26] that's what the token stream transform stuff is about [22:48:34] so that can be done async [22:48:35] I see [22:48:50] but the tokens have to arrive in order [22:48:59] (I assume?) [22:49:12] yes, input and output in-order [22:49:18] with an out-of-order phase in between [22:49:21] sounds like a case for using a 'deferred' framework [22:49:47] deferreds are just a minor convenience for some applications [22:49:57] in this case it's more about buffering imo [22:50:11] k [22:50:19] at least the twisted python deferreds I am used to [22:50:40] didn't use the JS port yet [22:50:43] yeah, now that I think about it, those are about blocking until all callbacks have returned. [22:50:53] what you want is to block until the next token is ready. [22:51:13] hmm [22:51:22] no, it is blocking until all children are expanded [22:51:35] but at the same time, return a chunk as soon as possible [22:51:40] well yes [22:51:42] but keep working on later, linked chunks [22:51:58] I think I described it somewhat comprehensible in the wiki page [22:52:37] it ends up as a kind of callback tree [22:52:56] with subtrees managing their own buffering and completion barriers [22:54:52] gwicke: just reread it [22:55:12] gwicke: perhaps I am not expressing it properly but I was trying to agree :) [22:55:32] cool ;) [22:56:08] I did not have a very good feeling about that design so far, am especially scared about templates [22:56:36] really? [22:56:51] I have been doing limited template parsing with the jQueryMsg thing for a long time now [22:57:06] are you scared because it will require db lookups? [22:57:11] and be slow and evil? [22:57:12] just hope that tables and lists are the only main structure commonly broken up into multiple templates [22:57:17] right [22:57:39] because a lot of other things won't be possible with that architecture [22:57:59] well [22:58:34] I think it may be unrealistic to expect that we'll support every possible use of wikitext [22:58:43] https://meta.wikimedia.org/wiki/Help:Advanced_templates should work though [22:58:59] but perhaps we could survey existing templates on wikipedia to find out how many of them have unbalanced HTML tags. [22:59:35] anything that constructs wikitext at a finer level than tokens will fail [22:59:49] unbalanced html tags are not an issue really [23:00:03] html tags in general just pass through [23:00:53] comments inside tokens will similarly fail [23:01:11] [[A link]] [23:04:46] neilk_: I think you are using EventEmitter in the editor, is that the node.js one? [23:05:00] it's similar to the node.js one [23:05:20] the tree builder is using the node one [23:05:22] I think Trevor wrote it from scratch though [23:05:33] ok [23:05:34] I'm not contemplating merging them yet [23:05:57] I just want a service that I can call from an API, or make a socket oriented service where I throw in wikitext and get wikidom out of it. [23:06:16] I was thinking about which interface to use between tokenizer, transforms and tree builder [23:06:28] ? [23:06:42] direct callbacks or events [23:07:11] I would go evented, personally [23:07:25] more flexible in the end [23:07:37] easier to debug/monitor [23:07:39] yeah, easier to add another listener etc [23:08:32] I wish you hadn't shown me this advanced usage of templates page. [23:08:40] https://meta.wikimedia.org/wiki/Help:Array <-- abandon all hope [23:09:16] yeah, that's what scares me at night ;) [23:09:39] you need to involve [[user:Patrick]] [23:09:47] he knows all the edge-cases :) [23:09:56] hahahaha [23:10:10] Nemo_bis: that is very good to know! [23:10:13] well just a little while ago we were terrified of unbalanced-html-producing-templates, and we seem to have an idea about handling them now. [23:10:26] so, i say we will be victorious [23:10:28] somehow [23:10:49] I'm also cautiously optimistic [23:10:51] Patrick is wonderful, he maintains an amazing documentation on Meta-Wiki [23:11:36] Nemo_bis: I'll contact him [23:11:39] :) [23:11:50] thanks for the tip! [23:11:52] http://en.wikipedia.org/w/index.php?title=Template:Substr_any&action=edit [23:12:00] stuff like this needs to killed with fire [23:12:04] *to be [23:12:58] the templates it calls are even more precious.... [23:13:11] Myyyy precious [23:13:25] erik's comparison of templates with brainfuck was quite spot-on [23:13:32] no [23:13:36] yeah. need mount doom for these templates. [23:13:39] templates are referentially transparent brainfuck [23:13:54] modulo timestamps etc [23:14:00] ugh oh yeah [23:14:17] the thing about magic words that start with "CURRENT" being special cased is scary [23:16:01] I like how mediawiki does ensure halting though [23:16:16] provide no looping constructs except for inclusion, then a maximum size on the program [23:16:18] voila! [23:17:07] maybe soon no longer ;) [23:17:39] jit-optimized endless loops [23:17:48] infinite even [23:20:59] neilk_: when you are at it, would you like to tie together the tokenizer, token transforms and tree builder using events? [23:21:12] ok, I could give that a whirl [23:21:18] just a single event with the full token list would be fine for now [23:21:26] coolio [23:21:34] then we can reduce the granularity to chunks step-by-step [23:21:55] i'll stop staring into the abyss now and get back to work [23:22:35] neilk_: have a nice christmas! [23:22:42] you too! [23:22:48] I won't be online very much in the next 2-3 days [23:23:00] but hope to get some hacking done on the train [23:23:04] heh [23:23:15] I'm not travelling, so I might be hacking too [23:25:57] my stuff will all be internal to the TokenStreamDispatcher, so it should't be hard to re-integrate when we both emerge again [23:27:30] if you'd like to make the tokenizer more async, then that should be doable in the toplevelblock production [23:27:47] I'm trying not to change anything ATM [23:28:00] just cleanly separate test & parser [23:28:15] this may require inserting some eventable things though [23:28:45] ok, but that change should be quite simple [23:29:19] you could emit an event with the current result in toplevelblock [23:29:55] and return an empty list to the parent instead [23:30:04] that should do block-level chunks [23:31:00] the actual parser result can then be thrown away [23:32:28] gwicke: ok, noted, but I think I need to understand the code more [23:33:01] np [23:34:05] much of the code in mediawiki.tokenizer.peg.js is currently dead [23:34:30] only the tokenize method is used [23:35:47] so don't be surprised if the remaining methods don't make sense with tokens ;) [23:36:36] ok good to know [23:37:03] I did look at it and it seemed outdated to me too :) Didn't want to say :) [23:37:38] Do you think we're not going to use peg as much after all? [23:38:09] the tokenizer itself is all peg [23:38:22] yes [23:38:31] oh I see what you mean [23:39:00] but could perhaps also be done in bison, but that would be less comfortable [23:39:36] much less comfortable really [23:39:54] but fast.. [23:41:48] the nice thing about peg is basically unlimited backtracking and ordered alternatives [23:55:01] is there a standard template that just echoes its first argument back? [23:55:28] trying to construct an example of problematic template use for Patrick [23:56:12] something like {{echo|[}}{{echo|[}}Testlink]] [23:56:57] You mean {{{{1}}}} ? [23:57:03] er I mean {{{{{1}}}}} [23:57:55] {{{1}}} afaik [23:58:05] aha: http://en.wikipedia.org/w/index.php?title=Template:Echo&action=edit [23:59:06] ah, it works differently on meta: https://meta.wikimedia.org/w/index.php?title=Template:Echo&action=edit [23:59:55] yeah I just noticed that too