Logs for the RingoJS IRC channel, as logged by ringostarr.


[09:32] <hannesw> good morning

[09:33] <hannesw> fascinating how productive a 2x4 hour train trip can be:

[09:33] <hannesw> http://wiki.github.com/hns/rhino-8/

[09:34] <hannesw> i wrote the native-callsites code on the way to vienna

[09:34] <hannesw> and the non-object-this branch on the way back

[09:45] <oberhamsi> sweet. train coding for the win! ;)

[10:01] <hannesw> earl: rhino-mirror is missing the latest commit again

[10:13] <hannesw> going to run v8 benchmark today with rewritten String and Array classes

[10:14] <hannesw> these should be the two ones with the largest impact

[13:06] <earl> hannesw: updated rhino-mirror

[13:06] <hannesw> thanks earl!

[13:29] <cefn> I would like to propose that the rhino templating engine uses (optionally) XML processing instruction syntax <? ?> instead of its current percent syntax. It would substantially improve compliance with tools to manipulate xhtml. What do you think?

[13:32] <cefn> There's probably a good argument for replacing it as the default. I've run into this problem with other toolkits where the choice of these characters actually prevents any XML editors or tools from processing the documents (e.g. Plain Old Webserver).

[13:45] <cefn> ringo not rhino, I keep making that mistake!

[13:59] <hannesw> cefn sounds like a reasonable idea

[13:59] <hannesw> i think we should consider that

[14:01] <cefn> I've added it into the issue tracker on github. Would make a big difference for me. Without it I'll have to write routines to round-trip from any of my mainstream XHTML manipulation tools, through the ringo templating format and back again - nasty!

[14:03] <hannesw> are there other templating engines using <? ?>?

[14:12] <cefn> I think the use of XML PIs is endemic, but I don't know what examples I can give. This article discusses it. http://www.xml.com/pub/a/2000/09/13/xslt/index.html It's a bit like asking are people using XML attributes :) They certainly are, but it's such a core capability of the XML infoset that no-one would necessarily document it as such.

[14:16] <cefn> http://teng.sourceforge.net/?page=manual#SEC4 uses PIs, dug from http://wiki.python.org/moin/Templating (heading: Engines with Annotated Templates)

[14:16] <oberhamsi> genshi from trac fame is xml based

[14:17] <oberhamsi> oh that's not the question. they don't use <? ?> the just expect xml

[14:18] <cefn> The same point is mentioned on this page, arguing for the use of PHP as a templating engine, because it uses PIs. http://www.bigsmoke.us/php-templates/smarter-sans-smarty

[14:22] <oberhamsi> haha i like the last article. so that adds php itself to the list of <? ?> template-langs

[14:23] <cefn> Several times in recent projects using JSPs we've run into a dead end because of this issue. Is there some argument in favour of <% %> ?

[14:27] <cefn> I'd be tempted to drop the conformance with 'app prefix' PI markup though, as that will get very boring to look at <?ringo name ?> <?ringo subskin myskin ?> ringo ringo ringo. Perhaps support it but don't require it.

[14:28] <earl> only problem with PIs is, that syntactically correct xml requires that there be no space between the <? and the nam

[14:28] <earl> name

[14:30] <earl> i think there's no intention of ringo skins being valid xml, but actually forcing them to be _invalid_ xml is certainly an issue

[14:31] <earl> so it would make sense to drop the <%%> and use something like {{{/}}} per default, while also making the delimiters configurable

[14:43] <cefn> Most tools will ignore PIs content I think. If <? ?> was the default, then on the rare occasion that stricter compliance was needed then the configurability you suggest, and maybe a failover parsing rule in SkinParser would allow people to use <?ringo ?>. However, if it's XML I'm happy.

[14:53] <earl> unfortunately, <? foo ?> is neither a PI nor well-formed XML

[14:53] <earl> in any case, i think the short-term solution is configurability of the skin delimiters

[14:55] <earl> as far as i know, hannes wants to re-write the skin parser in js anyway. this rewrite may be a good opportunity to take this into account

[14:56] <earl> i'll have a look at the current skin parser later this evening. if there's an easy way to add configurable delimiters right away, i'll give it a go

[15:05] <cefn> earl: Thanks. Yes I've found that the Xerces parser and Xpath processing does indeed fail on base.html using <? title ?> in my test application, owing to the extra space. Wasn't expecting that. Is there any need to have the space? It accepted <?title?> which might be an acceptable convention unless the space is meaningful for ringo. The tools REALLY didn't like anything based on <% %> though, reporting that the elements in the

[15:05] <cefn> document weren't well formed and refusing to do anything at all with or without spaces.

[15:07] <earl> cefn: there's no technical reason for the space. but skins are written by humans, and most of the skins currently in use in ringo webapps use spaces

[15:08] <earl> i'm just trying to point out that it's not simply a matter of switching from <%%> to <??>, as that alone won't improve well-formedness for most current skins

[15:09] <earl> for writing _new_ skins, configurable delimiters should give those who need it the tools necessary to write skins to be well-formed xml

[16:11] <cefn> Configurability would be great, definitely, and it wasn't as simple as I thought. Another issue is that <?for name in <?names ?> render hello ?> would break XML since the first ?> would close the PI. How should I understand the role of <% %> embedded inside <% %>. Is that recursive expansion?

[16:16] <cefn> Is something PHPish possible instead of the ringo-specific language constructs - just using javascript as the templating language directly, with delimiters used mostly to eliminate escaping problems?

[17:41] <earl> cefn: ringo is not tied to its own templating engine. must templating engines avail for javascript will work fine with ringo, so you should be able to find something that fits your need

[17:43] <hannesw> that's also true of course

[17:43] <hannesw> but i like <? ?>

[17:43] <earl> visually?

[18:02] <hannesw> I've got a new jline with CTRL-R history search

[18:02] <hannesw> not sure everything is working

[18:02] <hannesw> should i just check it in?

[18:03] <hannesw> or does somebody want to test it before?

[18:05] <earl> is it a manually patched jline? or just an update?

[18:06] <earl> ah, patched it seems

[18:07] <hannesw> it's a patch from mikiobraun

[18:07] <hannesw> http://github.com/mikiobraun/jline-fork

[18:07] <hannesw> but i only took the first two patches and then fixed the rest myself

[18:08] <hannesw> because i think he did a lot of refactoring and cleanup, and i don't want to go too far from mainline jline

[18:09] <hannesw> earl: as heavy ctrl-r user you'll surely find any oddities and bugs

[18:09] <earl> i think my C-r usage is rather basic

[18:09] <earl> well, as we're running with a patched jline already, i'd say just go ahead and push it to ringo

[18:10] <earl> you can also push it to hns first and i'll give it a quick try :)

[18:16] <hannesw> ok, pushed it to hns/master

[18:19] <cefn> earl: http://github.com/ringo/ringojs/issues/#issue/52 has the SkinParser syntax issue documented rather one-sidedly. Don't know if you get notifications of this and how issue notification across forks works through github, but hope it's a useful reference.

[18:36] <earl> hannesw: looks good

[18:36] <hannesw> great!

[18:36] <earl> cursor positioning in reverse-i-search is somewhat weird, but it's a good start

[18:37] <hannesw> yes i know. should i mirror exactly readline behaviour?

[18:37] <earl> well, putting the cursor at the start of the match makes sense in any case, i guess

[18:38] <hannesw> ok

[18:39] <earl> not that it's an important issue

[18:39] <earl> having C-r working at all is far more important :)

[18:39] <earl> and C-g and C-u seem to also work nicely within C-r

[18:39] <earl> (as does ESC)

[18:39] <earl> (and C-d)

[18:39] <earl> well, looks great

[18:40] <earl> cefn: thanks, i saw the issue

[18:47] <hannesw> i fixed that cursor thing too

[18:47] <hannesw> pushed to ringo/master

[18:47] <hannesw> earl: i force-overwrote the previous commit to hns/master

[18:48] <hannesw> hope that's ok for you, didn't want to have two commits for such a minor change

[19:18] <earl> sure, sure

[19:18] <earl> actually, that's just what i would've done :)

[19:19] <earl> ah, looks great