Hopbot log for 2008-01-11 - Helma IRC channel: #helma on irc.freenode.net

2008-01-11:

[7:29] <bard> benchmarking my template engine, and spidermonkey appears 10+ times faster than rhino, even at -opt 9 and after vm has optimized :-(
[9:08] <zumbrunn> bard, how is your template engine implemented now?
[9:09] <zumbrunn> basically, a js function to which you pass a e4x object and get a modified e4x object back?
[9:11] <bard> it's a function that compiles e4x down to closures
[9:11] <zumbrunn> what do you mean by "compiling down to closures"?
[9:12] <bard> e.g. var render = compile(<div h:content='foo'/>); render({foo: 'bar'}) -> <div>bar</div>
[9:12] <bard> and does so recursively
[9:14] * zumbrunn still doesn't get what you mean by "closures" in this context
[9:14] <bard> return function(env) { ... } :-)
[9:14] <bard> I'm uploading it, just a sec
[9:15] <zumbrunn> are we talking about normal, standard, typical, the only sort I know of a kind type of js closure?
[9:15] <zumbrunn> apparently we are
[9:15] <bard> I think so
[9:15] <bard> http://dev.hyperstruct.net/tmp/seethrough_helma.js
[9:16] <bard> (scroll down to the profile() function for the example)
[9:23] <zumbrunn> do you already know where rhino is getting slow?
[9:23] <zumbrunn> the walkthrough of the elements tree?
[9:24] <zumbrunn> or the use of arrays, perhaps?
[9:25] <bard> I didn't find any spot in particular (but I'm still trying). it may be that spidermonkey e4x implementation is in C while rhino's is in java
[9:26] <zumbrunn> yes, but when it is 10 times slower, it's usually something particular that makes the difference
[9:27] <zumbrunn> and maybe you can go around it if you know what you would need to go around
[9:28] <bard> I'll keep searching
[9:28] <zumbrunn> for example using java instead of js arrays
[9:28] <zumbrunn> or replacing js strings with java stringbuffers
[9:31] <bard> hmm, only use of arrays in the generated closures is a iterating on an existing array
[9:31] * bard checks for strings
[9:36] <bard> (by the way, looks like adele.helma.org is not responding)
[9:37] <zumbrunn> works for me
[9:37] <bard> must be my provider then, it wouldn't be the first time
[9:38] <zumbrunn> you can get to dev.helma.org but not adele?
[9:39] <zumbrunn> a dns problem, perhaps?
[9:39] <zumbrunn> then it might be just coincidence that it's working for me
[9:41] <bard> no it's ok, I can reach both from my server, while I can resolve but not ping adele from here
[9:41] <bard> so it seems a local issue
[9:43] <zumbrunn> adele resolves to 194.232.104.95 for me, for what it's worth
[9:44] <bard> me too
[9:44] <zumbrunn> ok
[9:44] <bard> (by the way, thanks for your patience about my noob ramblings)
[9:44] <zumbrunn> I didn't need any so far
[9:45] <bard> :-)
[10:01] <bard> I've gone down to benchmarking only e4x object creation... I hope I'm doing something wrong: http://pastebin.ca/850635
[10:08] <zumbrunn> the second numbers are spidermonkey?
[10:08] <zumbrunn> bard, I get numbers that are about 10 times lower than what you got
[10:09] <zumbrunn> (but that's still infinitely higher than 0, of course)
[10:09] <bard> the second numbers are spidermonkey, yes
[10:11] <bard> yeah, a benchmark which outputs zero isn't the smartest thing in the world :-/ I've increased "runs" to 1000, I get ~3500msecs with rhino and ~34-40 with spidermonkey
[10:11] <bard> do you get the same ratio?
[10:13] <zumbrunn> I get about 650ms in the web-based helma shell
[10:15] <bard> 1000 runs?
[10:15] <zumbrunn> yes
[10:16] <bard> I get ~5000
[10:16] <bard> (I'm not on a very fast machine, clearly :-))
[10:17] <bard> what do you get in spidermonkey?
[10:23] <zumbrunn> between 30 and 50 with 10'000 runs
[10:23] <hypersmil> bard: when i run your benchmark i get 200-300 with -Djava.compiler=NONE, but 60-190 ms without this option
[10:24] * zumbrunn wonders what happens with the xmlbean.jar in the classpath
[10:24] <bard> hypersmil: I set that to prevent the jitter from skewing results while I was looking for the bottleneck
[10:25] <bard> zumbrunn: I've tried removing that already and using mozilla implementation, same thing
[10:25] <bard> (I mean a fresh checkout of rhino1.7 without the xmlbeans dir)
[10:31] <bard> maybe in rhino the e4x object is re-parsed at runtime each time it is met, while spidermonkey only parses it at compile time and then duplicates the structure (just shooting in the dark)
[11:47] <bard> posted to rhino ng: http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/browse_thread/thread/1d2324f5c5c0ac81#43f7e21e2a808bab
[12:20] <bard> zumbrunn: regarding the var x = 'foo'; new XML('<a>{x}</a>') -> <a>{x}</a> issue, it works like this in spidermonkey too, I guess that's intended (otherwise, now that I think of it, there wouldn't be a way of writing the "{" and "}" characters in e4x...)
[13:18] <zumbrunn> bard, escaping it with <a>{'{x}'}</a> would work
[13:26] <bard> ah, cool
[14:19] <bard> there's hope :-) https://bugzilla.mozilla.org/show_bug.cgi?id=411895
[14:21] <zumbrunn> yep, I've seen David's reply to your message on the rhino mailing list :-)
[14:23] <bard> I really hope it gets fixed, the engine is coming along nicely and I'd hate to throw it away
[14:53] <midnightmonste1> bard, you around?
[14:53] <bard> yes
[14:53] <bard> joshua?
[14:53] <midnightmonste1> yup
[14:54] <bard> hi :-)
[14:54] <midnightmonste1> hey. just sent you a couple emails--second one more interesting
[14:54] <midnightmonste1> what os/box specs/jvm were you using for the rhino test in the bug you mentioned?
[14:55] <bard> linux x86 2.6.22 on a 1.1ghz intel centrino
[14:55] <bard> same tests on a dual opteron gave similar results (in proportion)
[14:56] <bard> hmm, I'm reading your mail now
[14:56] <midnightmonste1> our laptops and our servers have very similar specs :-)
[14:56] <bard> so this might be a problem in linux implementation of jvm
[14:57] <bard> did you turn off the jitter too?
[14:57] <midnightmonste1> if you haven't installed your own jvm, it's very very likely
[14:57] <midnightmonste1> turn off the jitter?
[14:58] <bard> I'm running sun-java6
[14:58] <midnightmonste1> weirds
[14:59] <bard> yeah, sun jvm optimizes code which is run more frequently, my tests were done with jit disabled
[14:59] <midnightmonste1> right. why do that?
[14:59] <midnightmonste1> I thought that was what I saw in your command line
[15:00] <midnightmonste1> but I'm not much of a java guy--I really only use it through Helma--so I wasn't sure.
[15:00] <bard> to get a more reliable figure about rhino, without jvm implementation kicking in
[15:00] <bard> me neither :-)
[15:00] <bard> I'm just getting closer to the jvm cause this is forcing me to
[15:00] <midnightmonste1> rhino is made to run on a good jvm. everything in java is slow as hell without a jit
[15:01] <bard> I'll give you my figures with jit turned on, just a sec
[15:02] <midnightmonste1> the long-running JVM thing makes a difference, too.
[15:02] <bard> ok, given the subject at hand that might be a bit more than a sec :-)
[15:03] <bard> I have fourth run at 9437msecs
[15:05] <bard> so your runs at 4837 were with jit right?
[15:05] <bard> btw command-line spidermonkey is faster than the one in firefox, which may explain why you got higher figures there
[15:06] <bard> ha! we just got +23% according to bugzilla. :-)
[15:07] <midnightmonste1> right
[15:07] <midnightmonste1> what about +23%?
[15:07] <midnightmonste1> right==right, I used JIT
[15:08] <bard> https://bugzilla.mozilla.org/show_bug.cgi?id=411895
[15:08] <midnightmonste1> ah--sweet!
[15:08] <bard> looks like my hunch was right, rhino is creating a parser every time
[15:09] <bard> anyway I'm impressed, I wonder whether rhino folks are always so responsive
[15:14] <midnightmonste1> I don't see a quick way to run command line spider monkey under windows, so I can't test that yet.
[15:15] <midnightmonste1> I don't see why it should be that much faster, though
[15:16] <bard> just updated rhino from cvs, fourth run is at 3211msecs (vs 4837)
[15:16] <bard> yeah indeed, *that* much faster isn't accounted
[15:18] <midnightmonste1> that's about 30
[15:18] <midnightmonste1> % faster, but different machines :-)
[15:18] <bard> oh right, I quoted yours
[15:18] <bard> mine with jit was similar though
[15:19] <midnightmonste1> last you said here, you had only got down to 9400
[15:19] <bard> with jit?
[15:19] <midnightmonste1> yeah
[15:19] <bard> my god, I'm getting mixed up in figures
[15:19] <bard> wait
[15:20] * bard flushes shell and does it again
[15:20] <bard> yes indeed
[15:21] <bard> ah crap I overwrote rhino cvs
[15:21] <bard> I'm comparing rhino as distributed with helma with rhino cvs, not very smart
[15:21] <midnightmonste1> helma rhino is basically just a recentish cvs checkout
[15:22] <midnightmonste1> they have maybe one patch that they put on it
[15:22] <bard> not that I despise ~9000 vs ~3000
[15:22] <bard> oh
[15:22] <bard> so it may be more than 23% :-)
[15:22] <midnightmonste1> yup
[15:23] <bard> let's try against the figures I posted, without jit...
[15:23] <bard> hmm, definitely
[15:24] <bard> ~5000 vs ~8000
[15:24] <bard> pardon
[15:24] <bard> ~50000 vs ~8000
[15:47] <midnightmonste1> about e4x templates, though, my approach is different from yours (or at least different from anything you were doing in erlang). I'm not using templates in the traditional sense at all. every object has several methods to render its own html for its various contexts. whatever function is using the results sticks them together. the action for the request does the almost-final assembly and puts e4x objects into res.data.wha
[15:48] <midnightmonste1> (that was supposed to end with "web use." let me know if part got cut off)
[15:49] <midnightmonste1> (looks like it may have)
[15:49] <bard> I got it till "...and puts e4x objects into res.data.wha"
[15:49] <midnightmonste1> ...puts e4x objects into res.data.whatever. typically I just use res.data.body and res.data.title. there's a global helper object that you can call methods on to insert scripts or stylesheets or whatever into the <head> of the final document, and when you're ready to output you call Xpage(this.html) where Xpage is the global helper and html is a method defined on the HopObject prototype...
[15:49] <midnightmonste1> ...and overriden is necessary that incorporates the stuff stuck in res.data into the basic shell of the site (which is also defined in this.html). Xpage then does some general stuff with the result to insert the <head> items, build-in XSS protection, and tweak the resulting XML string for web use.
[15:51] <bard> indeed, what we're doing is as similar as day & night. :-)
[15:51] <bard> mine look like this now (skin & action): http://dev.hyperstruct.net/tmp/main.txt http://dev.hyperstruct.net/tmp/main.js
[15:53] <midnightmonste1> what do you do when you have several pages with different content but the same header, footer, etc.?
[15:53] <midnightmonste1> looks like you have to repeat those in every skin
[15:53] <bard> I plan to use template inclusion
[15:54] <bard> I have this in the erlang version but haven't ported yet
[15:55] <bard> might look like:
[15:55] <bard> this.render('layout', {
[15:55] <bard> title: 'foo',
[15:55] <bard> content: this.render('signup', {
[15:55] <bard> username: 'bar'
[15:55] <bard> })
[15:55] <bard> });
[15:56] <midnightmonste1> I've been doing the moral equivalent of what you're doing in PHP for some time. (*very* similar, in fact--using PHPTAL, which adds several namespaced attributes to XHTML to do looks, variable interpolation, etc.) it seems to be the way templates are usually done.
[15:57] <midnightmonste1> looks==loops
[15:57] <bard> indeed when I was doing that in Erlang a colleague pointed out ZPT and I got much of the rest from there
[15:58] <midnightmonste1> yeah--basically the same
[15:58] <bard> *but* in the helma implementation tags and attributes can be added freely
[15:59] <bard> the tags implementation for that example is just a hash with the special tag and attribute names as properties
[15:59] <midnightmonste1> as in, make up your own functions or hack back into your generated HTML later?
[15:59] <bard> the former
[15:59] <midnightmonste1> (whereas I'm making a lot of the latter)
[16:00] <bard> that is the night & day part. :-)
[16:00] <midnightmonste1> (which couldn't be done efficiently in PHP)
[16:02] <midnightmonste1> I decided the whole let-designers-edit-the-template thing was silly, because I'm usually the designer, too, and when I'm not I still can't trust the designer to provide HTML I can use exactly as is.
[16:02] <bard> it's hard to argue with that :-)
[16:03] <midnightmonste1> that argument gone, there wasn't any reason to keep passing my data through little labelled slots and trying to build loop and conditional constructs onto a document markup language
[16:05] <midnightmonste1> and I think it makes a lot more sense to have every object responsible for its own representation(s). esp when the using method can tweak it later if needed
[16:05] <bard> me, I usually get crazy after few minutes if I can't edit xml in nxml-mode, nor can I visualize the result if I'm not looking at a xml-looking source, so count that as personal limitation-driven design :-)
[16:05] <midnightmonste1> (on larger templates, the switching back and forth ends up being a significant mental load, even remembering the names of all the little labelled slots
[16:06] <bard> are you familiar with Naked Objects? your approach reminds me a bit of that
[16:06] <midnightmonste1> better xml editing would be nice. but the XML is XML right in the middle of my JS source with e4x
[16:10] <midnightmonste1> if you mean this http://www.nakedobjects.org/home/index.shtml , my objects have to say how they'll be rendered--there's no automagic appearances available
[16:11] <bard> right
[16:13] <midnightmonste1> I use eclipse, and really I'm used to many of my editing "modes" offering no better than syntax highlighting at best, so I'm not too bothered by the lack of complete editor support
[16:13] <midnightmonste1> (the CSS mode I have is good, and the plain XML one isn't bad, but it's not that great either. js and php are disasters)
[16:17] <zumbrunn> midnightmoste1, do you use or have you tried JSEclipse?
[16:17] <midnightmonste1> I've tried it at some point. maybe not recently
[16:18] <midnightmonste1> afaik there isn't any js editor on any platform that understands e4x
[16:18] <zumbrunn> right
[16:18] <zumbrunn> JSEclipse doesn't either yet
[16:19] <midnightmonste1> but I haven't seen any that really understand what functions are defined by what names in what scopes, either
[16:19] <midnightmonste1> which would be a big improvement even without e4x
[16:33] <bard> hmm, is there any snippet/example around about user management in helma?
[16:35] <zumbrunn> not the straight forward simple type your looking for
[16:35] <zumbrunn> that needs to be written
[16:35] <zumbrunn> if you use the built-in helma user logic, you create new users with app.registerUser(username, password)
[16:36] <zumbrunn> then log them in using session.login()
[16:36] <zumbrunn> then session.user is the currently logged in user
[16:36] <bard> yes, I was thinking of those
[16:38] <zumbrunn> http://helma.zumbrunn.com/reference/app.html#app.registerUser
[16:38] <zumbrunn> http://helma.zumbrunn.com/reference/session.html#session.login
[16:38] <bard> I'd like to end up with urls like /users/1, I suppose I can create a Users hopobject and attach it to Root so as to have root.users, then attach User objects to Users, right?
[16:39] <zumbrunn> yes, except that you wouldn't want root.users to be a user object itself
[16:39] <zumbrunn> rather just another hopobject, probably
[16:40] <zumbrunn> alternatively, you could also use a mountpoint mapping
[16:41] <bard> ok
[16:41] <bard> still making acquaintance with building blocks
[16:42] <zumbrunn> http://helma.org/docs/guide/mapping/mountpoint/
[16:42] <bard> yep, thanks
[16:43] <bard> I'll go the Users object route for now as I think I'll make some action of it the endpoint of POST requests
[17:02] <midnightmonster> bard, is sameplace yours?
[17:02] <bard> yes
[17:02] <midnightmonster> is it doing multi-protocol through jabber only, or through libpurple or something?
[17:03] <bard> through jabber and something. :-) devel version has a connector infrastructure and a twitter-to-xmpp connector
[17:04] <bard> msn/aim is done through jabber instead
[17:04] <midnightmonster> aim via jabber has not worked reliably for me in the past. but that was probably more than a year ago. is it better now?
[17:05] <bard> no idea, I don't have an aim account
[17:14] <midnightmonster> no relation to anything, but I like shirt.woot.com today.
[18:04] <bard> zumbrunn: is there a way to iterate on collections with something like "for each(var x in hopobject)" (short of upgrading rhino and writing a js1.7 generator)?
[18:04] <midnightmonster> yeah
[18:05] <midnightmonster> well, you can use forEach(function)
[18:05] <midnightmonster> which is how I like to do it
[18:05] <bard> it's different :-) I need generic iteration
[18:06] <midnightmonster> then no, not with js 1.7, which is being worked on but isn't here.
[18:07] <bard> I think I read that rhino with js1.7 is available in head
[18:07] <midnightmonster> but what can you not do with forEach or one of the functional-type things?
[18:07] <midnightmonster> head of rhino or of helma?
[18:07] <bard> to use forEach, the object must implement it
[18:07] <bard> head of helma
[18:07] <midnightmonster> but you can implement it on HopObject, and then everything uses it
[18:08] <midnightmonster> well, every hopobject
[18:08] <midnightmonster> and descendants
[18:08] <bard> yeah, I'd rather not be limited to that
[18:09] <midnightmonster> collections behave sort-of like arrays. arrays and collections both can have forEach. e4x cannot be extended, forEach doesn't make sense over name/value pairs of object properties. what other kinds of things do you want to iterate over?
[18:10] <midnightmonster> 'cause all Helma Object collections, including the types you make up extend HopObject
[18:11] <bard> for each can iterate on arrays, xml list, and generators.
[18:12] <midnightmonster> (I didn't realize there was any version of rhino working that had generators, though--that's pretty exciting and I might just go bleeding edge for it)
[18:14] <bard> I read it here: http://www.langreiter.com/space/helma-notes-js-1.7
[18:16] <midnightmonster> wow
[18:16] <midnightmonster> are we sure 1.6.1 doesn't have it?
[18:17] <midnightmonster> helma 1.6.1
[18:17] <midnightmonster> ('cause that suggests getting helma's nightly from the 1.6 branch on the 2nd)
[18:17] <bard> I tried setting that flag, but at least "let" doesn't work in the shell
[18:18] <bard> just downloaded the file and rhino.jar is 40kb larger, so I think it's not in 1.6.1
[18:18] <midnightmonster> ok
[18:19] <bard> yeah, package works. :-)
[18:27] <zumbrunn> helma 1.6.1 includes rhino 1.6R7, I believe
[18:27] <zumbrunn> not rhino 1.7
[18:27] <zumbrunn> but you can replace the rhino jar file
[18:27] <bard> yes, done :-)
[18:27] <bard> ah, the joy of controlling the runtime!
[18:27] <zumbrunn> and then helma.jar that is included with helma 1.6.1 supports js 1.7
[18:28] <zumbrunn> if the rhino.languageVersion flag is set to 170
[18:28] <bard> uhm
[18:28] <bard> I think I tried that with no luck
[18:28] <bard> will retry
[18:31] <bard> hmm, no luck, "let (a=1) a" -> SyntaxError: missing ; before statement
[18:31] <bard> (in the shell)
[18:43] <midnightmonster> so what's the deal? where does one set the rhino.languageVersion flag, and can I do it with Helma 1.6.1? if not, which rhino.jar should I get?
[18:43] <midnightmonster> (ok, I see where to set it)
[18:46] <zumbrunn> I'm rebuilding both rhino and helma right now
[18:46] <zumbrunn> rhino with the JMOP patches
[18:46] <midnightmonster> cool.
[18:46] <bard> woa
[18:47] <midnightmonster> JMOP = JOMP?
[18:47] <zumbrunn> and helma with an experimental change I just made to allow for more file suffixes
[18:47] <bard> !
[18:47] <midnightmonster> (what's the use case for more file suffixes?)
[18:47] <zumbrunn> yep, that's what I meant
[18:48] <zumbrunn> well, I'm just experimenting with it right now
[18:48] <zumbrunn> for example, foo.json becomes a js object at this.foo_json
[18:49] <zumbrunn> foo.e4x becomes an xml object property at this.foo_xml
[18:50] <zumbrunn> eh... this.foo_e4x, of course
[18:50] <midnightmonster> ok, good
[18:50] <midnightmonster> I was about to comment
[18:50] <midnightmonster> interesting idea
[18:51] <zumbrunn> also, foo.put becomes this.foo_action_put
[18:51] <midnightmonster> would let me stick an XML document in type directory and have it automatically be an e4x doc.
[18:51] <zumbrunn> right
[18:51] <midnightmonster> bard, that solves a little of your problem
[18:51] <zumbrunn> why?
[18:52] <midnightmonster> one he mentioned way earlier about liking to edit his xml with his emacs xml mode
[18:52] <zumbrunn> right, yes
[18:52] <bard> midnightmonster, I'm doing that already :-)
[18:53] <midnightmonster> but presumably you have to have some code that picks up the file, no?>
[18:53] <bard> yep, the template compiler
[18:54] <midnightmonster> just skips a step for you, gives you a convention to use. might be more useful for my way of working.
[18:55] <bard> indeed, I still have to invoke the template compiler but I can pass it the e4x instead of calling new XML(this.renderToSkin('name')), it actually skips two steps
[19:01] <bard> where can I place a function so that it's available as a global function, rather than as a method of the hopobject?
[19:01] <midnightmonster> appdir/Global
[19:01] <midnightmonster> /whatever.js
[19:01] * bard feels stupid
[19:01] <bard> thx
[19:01] <midnightmonster> np
[19:03] <zumbrunn> is it just me or does the current rhino HEAD fail to build
[19:03] <zumbrunn> ?
[19:03] <midnightmonster> (I'm still useless on building anything that doesn't build with ./configure; make; make install)
[19:04] <bard> I'll try a clean build
[19:04] <bard> worksforme
[19:05] <zumbrunn> hmm, ok
[19:05] <zumbrunn> thanks
[19:08] <midnightmonster> so if I just want javascript 1.7, is there a prebuild rhino.jar somewhere I should grab?
[19:08] <zumbrunn> I'll upload the one I have already
[19:08] <zumbrunn> just a sec
[19:11] <midnightmonster> random: sometimes there's nothing like hanging out on the mailing list to turn you off to a technology. since I've been subscribed to the h2 list for a while, I definitely haven't felt as comfortable using it for anything.
[19:11] <zumbrunn> http://helma.zumbrunn.com/downloads/anteportas/rhino.jar
[19:12] <midnightmonster> I wish I could wave a magic wand and get sqlite for java
[19:12] <midnightmonster> I <3 sqlite
[19:16] <midnightmonster> more general question, where would I have to hang out to keep on top of what's upcoming in helma world? I just today on here learned about three or four things I had never heard of before.
[19:17] <midnightmonster> (also, I want to send cookies to whoever it was that did the type.MyTypeName bug and patch. what a simple, obvious, huge improvement that somehow we missed till now.)
[19:19] <zumbrunn> you mean MyTypeName.properties ?
[19:20] <zumbrunn> credits for that go to tobi
[19:20] <zumbrunn> officially, the "place to hang out" is the helma-dev mailing list
[19:22] <zumbrunn> but lately, watching the helma wiki for changes would seem like a good idea as well
[19:23] <zumbrunn> what *should* happen is that proposals are published on the wiki and then announced on the mailing list
[19:23] <zumbrunn> and commit messages you get when you subscribe to helma-cvs
[19:23] <zumbrunn> (the helma-cvs mailing list)
[19:24] <zumbrunn> but there as well, commit notifications for anything interesting should be posted on the helma-dev mailing list
[19:25] <zumbrunn> I'm sure, the best place to hang out would be in Hannes' head
[19:30] <midnightmonster> (Yeah, MyTypeName.properties)
[19:30] <zumbrunn> the experimental helma.jar that supports additional file suffixes there now as well
[19:30] <zumbrunn> http://helma.zumbrunn.com/downloads/anteportas/helma.jar
[19:31] <zumbrunn> and my current code to leverage it:
[19:31] <zumbrunn> http://helma.zumbrunn.com/downloads/anteportas/e4xd-0.1.js
[19:31] <zumbrunn> (together with the JOMP patch in the rhino.jar)
[19:32] <midnightmonster> only thing I don't like about the file suffixes thing is that sticking the file format into the variable name seems awakward
[19:33] <zumbrunn> yes
[19:33] <midnightmonster> it's semi-consistent with the .hac convention, though
[19:33] <zumbrunn> but it would be more inline with the existing "helma way" and has advantages as well
[19:33] <zumbrunn> right
[19:34] <zumbrunn> for which you could then use .action, btw
[19:34] <midnightmonster> yeah, it would be nice to make it completely consistent
[19:34] <midnightmonster> except it wouldn't be still
[19:34] <zumbrunn> why?
[19:35] <midnightmonster> foo_put.action -> foo_action_put, but foo.json -> foo_json
[19:36] <midnightmonster> err...
[19:36] <zumbrunn> it's foo.put actually
[19:36] <midnightmonster> right. I just saw that
[19:36] <zumbrunn> but yeah, that would just be a "shortcut"
[19:37] <midnightmonster> yeah, and at least the file extension is getting stuck on the end
[19:37] <midnightmonster> that
[19:37] <midnightmonster> 's better than I was thinking
[19:38] <midnightmonster> and foo.action -> foo_action, so that's cool
[19:38] <midnightmonster> yeah, I think it works
[19:38] <zumbrunn> and foo.macro --> foo_macro
[19:39] <midnightmonster> I don't think macros map onto my perspective on skins/templates. Could be wrong.
[19:39] <midnightmonster> did you already implement all of that in the test builds?
[19:40] <zumbrunn> (and foo.control --> this.foo_control)
[19:40] <zumbrunn> which test builds?
[19:40] <zumbrunn> eh... yeah
[19:40] <midnightmonster> or build singular. of helma.jar that you linked above
[19:40] <zumbrunn> yes
[19:40] <midnightmonster> what's a foo_control ?
[19:41] <midnightmonster> haven't seen that before
[19:41] <zumbrunn> it's what I use in the e4xd file
[19:41] <zumbrunn> a function that controls a skin/view
[19:42] <midnightmonster> ***brain hurts
[19:42] <zumbrunn> e4xd makes the foo.skin/foo.view files available as e4x objects at this.views.foo
[19:42] <midnightmonster> what's a view?
[19:42] <midnightmonster> ==skin with with MVC naming, or something else?
[19:43] <zumbrunn> if there is a foo.control, then the skin/view is passed to the control function and that function can decide what to do with it
[19:43] <zumbrunn> yes skin==view
[19:44] <midnightmonster> when does foo.control get called?
[19:44] <zumbrunn> when you access this.view.foo
[19:44] <zumbrunn> this.views.foo
[19:44] <midnightmonster> ohigetit
[19:45] <zumbrunn> what you get is an e4x object
[19:45] <zumbrunn> but it's been passed through this.controls.foo
[19:45] <midnightmonster> and it's JOMP that's making this possible for you, right? cause we were talking on here at some point about how this couldn't be done in straight js
[19:45] <zumbrunn> yes, exactly
[19:49] <zumbrunn> plus e4xd also provides the soft-coding functionality that openmocha was all about
[19:49] <zumbrunn> which means the object will inherit from it's path in addition to its prototype
[19:50] <zumbrunn> very little code, but it does everything important that openmocha did already
[19:50] <zumbrunn> (and much nicer)
[19:57] <midnightmonster> news (on helma.org) from hannes says he checked in jsadapter. did he later decide on JOMP instead or are both there?
[19:59] <zumbrunn> like I said, both the helma.jar and rhino.jar are totally experimental
[20:00] <midnightmonster> so if I want to avoid having stuff I'm playing with go away next release, I should just use the js 1.7 stuff?
[20:00] <zumbrunn> yes, for sure
[20:02] <zumbrunn> I discussed the idea of adding support for additional file suffixes with Hannes a long time ago
[20:03] <zumbrunn> he even did it quickly for the .macro suffix, but then never committed it
[20:04] <zumbrunn> so, maybe there is a good reason not to go in that direction
[20:04] <zumbrunn> we'll have to discuss it on the helma mailing list
[20:04] <zumbrunn> certainly, I'll propose it for helma 1.7, though
[20:29] <bard> out.@foo = 'bar' -> ok; out['@foo'] = 'bar' -> NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
[20:29] <bard> :-/
[20:29] <bard> are there other ways to set attributes?
[20:30] <bard> (this normally works. I can't find what makes it crash in this case and it's difficult to extract a test case)
[20:39] <midnightmonster> that is weird.
[20:39] <midnightmonster> I haven't had any trouble with it
[20:40] <bard> ah, got it! out.@['foo'] = 'bar'
[20:40] <midnightmonster> oh
[20:40] <midnightmonster> I guess that's what I actually did before
[20:40] <bard> pure luck. never saw that before
[20:42] <bard> I can finally get some sleep now. see you tomorrow!
[20:43] <midnightmonster> cya
[21:05] <midnightmonster> interesting (to me) thing: with bard's e4x issue, if you change it so there's just the single e4x statement in the loop instead of running a function with a single e4x statement in the loop, it improves rhino's speed perhaps 20%. but if you do the same for spidermonkey, which is already 100x faster, it gets something like 50x faster again
[21:46] <zumbrunn> midnightmonster, I noticed that too before, but the difference wasn't that big for me
[21:46] <zumbrunn> (both for rhino and spidermonkey)
[21:47] <midnightmonster> my numbers may be off for spidermonkey--I had to up it to 100k iterations to get non-zero times
[21:47] <midnightmonster> with the function call removed
[21:50] <zumbrunn> with spidermonkey it's "only" three times or so faster for me with the one function level removed
[21:52] <zumbrunn> (130ms vs 400ms at 100'000 iterations)
[22:06] <midnightmonster> "only" 20 times faster now that I'm paying more attention
[22:06] <midnightmonster> 344ms vs 16ms
[22:06] <midnightmonster> but I wonder if we're making the same change
[22:07] <zumbrunn> total = bm(function(){<test/>}, times);
[22:08] <midnightmonster> that's what the original code looked like to me
[22:09] <zumbrunn> wasn't the original...
[22:09] <zumbrunn> total = bm(function(){ (function(env){<test/>})() }, times);
[22:09] <zumbrunn> ?
[22:09] <midnightmonster> not in the stuff I saw
[22:09] <zumbrunn> ok, that explains the difference then, I guess
[22:10] <midnightmonster> I changed function bm so that the business part:
[22:10] <midnightmonster> for(var i=0;i<times;i++) fn();
[22:10] <midnightmonster> was this instead:
[22:10] <midnightmonster> for(var i=0;i<times;i++) <test/>;
[22:11] <midnightmonster> that made the running time essentially nothing in spidermonkey, but only cut 20% off the time for rhino
[22:12] <zumbrunn> yes, that way I get 6ms in spidermonkey
[22:13] <midnightmonster> that's consistent with the other numbers--your spidermonkey is 2-3 times faster than mine
[22:13] <midnightmonster> but I'm running mine in firebug, so that may be it
[22:14] <zumbrunn> and virtually no diff in rhino
[22:15] <midnightmonster> in rhino, I get these results:
[22:15] <midnightmonster> times per run: 1000 (function)
[22:15] <midnightmonster> run #0 total time: 313
[22:15] <midnightmonster> run #1 total time: 297
[22:15] <midnightmonster> run #2 total time: 281
[22:15] <midnightmonster> run #3 total time: 313
[22:15] <midnightmonster> times per run: 1000 (no function)
[22:15] <midnightmonster> run #0 total time: 297
[22:15] <midnightmonster> run #1 total time: 281
[22:15] <midnightmonster> run #2 total time: 281
[22:15] <midnightmonster> run #3 total time: 281
[22:15] <zumbrunn> that makes sense though, since in rhino the overhead is in the e4x xml stuff
[22:15] <zumbrunn> while in spidermonkey it ends up being somewhere else
[22:16] <zumbrunn> overhead == bottleneck
[22:16] <midnightmonster> well, it's pdq in spidermonkey. even at 100k runs I don't always get a non-zero time
[22:17] <zumbrunn> yeah, but your not running it 100k times in rhino
[22:17] <midnightmonster> I know.
[22:18] <midnightmonster> take too long. I'm just showing it doesn't make much dif, like you said
[22:18] <zumbrunn> if you would, it would take so long, you wouldn't notice the few hundred milliseconds difference you gain/loose from the additional function
[22:19] <zumbrunn> in spidermonkey you notice it, because you don't have the e4x bottleneck
[22:19] <midnightmonster> so apparently it's the function call that's essentially all the time spent in spidermonkey and the XML is a non-issue. there must be some room for improvement on spidermonkey there
[22:23] <zumbrunn> well, if I up it to 1'000'000 and replace the <test/> with an empty string, I get 350ms in rhino, 70ms in spidermonkey
[22:24] <zumbrunn> so, spidermonkey is still 5 times faster
[22:29] <midnightmonster> right. 5-10 times faster I expect for this kind of stuff
[22:30] <midnightmonster> I do sometimes wonder about this stuff, though. I mean, javascript comes out at the flat bottom of the language shootout most of the time. and here I am writing for an implementation that's 5x slower
[22:31] <midnightmonster> I wonder if it really is that much slower for more real-world stuff, though
[22:31] <zumbrunn> yeah, well... in reality the bottleneck is most often elsewhere completely
[22:32] <midnightmonster> right
[22:32] <midnightmonster> and preachingtheword.net is the fastest-feeling site I've ever done, I think
[22:32] <zumbrunn> :-)
[22:33] <midnightmonster> partly, I suspect, b/c the 500 object cache actually covers [all but?] every single object in the site. So data access is all in memory
[22:35] <zumbrunn> which would be perfect proof that the bottleneck isn't js but the data backend
[22:35] <midnightmonster> indeed.

 

 

In the channel now:

Logs by date: