2007-08-08:
[11:02] <midnightmonster> Helma stores lastModified and created timestamps for all the objects in the internal db. can I get at those values?[12:06] <midnightmonster> looks like no. did I read something about there being magic property names that would get Helma to handle setting those for you, though?[13:07] <zumbrunn> midnightmonster, the inspector managed to get at those dates[13:08] <zumbrunn> so, looking at the inspector source code should lift that mistery[13:08] <zumbrunn> it both reads and sets them[13:09] <zumbrunn> http://helma.zumbrunn.net/tools/about_inspector[13:10] <zumbrunn> http://adele.helma.org/source/viewcvs.cgi/helmaTools/Global/helma.Inspector.js?rev=1.6&content-type=text/vnd.viewcvs-markup[13:14] <zumbrunn> scratch that...[13:14] <zumbrunn> the inspector doesn't see the built-in ones either[14:01] <midnightmonster> (i looked at the java source for hopobject and it looked like no love)[18:57] <p3k> midnightmonster: did you already try HopObject.prototype.__lastModified__?[19:00] <midnightmonster> calling it on the prototype shouldn't help (since there's no this) even if it does exist[19:01] <zumbrunn> damn! how can something like this be a secret![19:01] <zumbrunn> this.__lastModified__[19:01] <zumbrunn> thanks Tobi![19:01] <midnightmonster> nice[19:03] <p3k> sorry, by using prototype i just wanted to be sure that it's a property of an instance, normally i just would have written HopObject.__lastModified__[19:03] <p3k> but i am glad that it's still available[19:04] <zumbrunn> yep, it's working perfectly[19:04] <zumbrunn> I'll add it to the reference docs (along with hobj.__created__)[19:04] <p3k> ok[19:05] <midnightmonster> alas, you can't use it for getOrderedView, which was what I needed it for[19:07] <zumbrunn> do these work for hop objects that are mapped to a relational db as well?[19:07] <zumbrunn> or is this embedded db only?[19:07] <p3k> i don't think so[19:07] <p3k> there needed to be a default database mapping for such information[19:08] <midnightmonster> I could have sworn I saw something somewhere that if you gave your columns magic names or something, Helma would update them for you[19:08] <zumbrunn> hmm[19:08] <p3k> i am using such an approach in rabbit[19:08] <p3k> but not that i know about such magic built-in helma[19:13] <zumbrunn> there are more of these...[19:13] <zumbrunn> hobj.__prototype__[19:13] <zumbrunn> hobj.__name__[19:13] <zumbrunn> hobj.__id__[19:13] <p3k> hobj.__prototype__ === hobj._prototype[19:14] <p3k> hobj.__id__ === hobj._id[19:14] <p3k> afaik[19:14] <zumbrunn> yes[19:15] <p3k> btw. where did you find them. __lastModified__ i remembered from a code snippet, but i did not find it in helma's source code[19:16] <zumbrunn> I just tried ;-)[19:17] <zumbrunn> (in the hop shell)[19:17] <zumbrunn> these prototype properties are strings of the clean prototype names, which is cool![19:17] <zumbrunn> because I can get rid of some ugly string parsing in places[19:18] <midnightmonster> http://adele.helma.org/source/viewcvs.cgi/helma/src/helma/scripting/rhino/HopObject.java?rev=1.74&cvsroot=hop&content-type=text/vnd.viewcvs-markup about 80% down[19:18] <p3k> uh, i think i remember: in the code they must be getter methods - works like beans[19:18] <midnightmonster> private Object getInternalProperty(String name) ... then a bunch of if's[19:18] <p3k> yes, that's even better :)[19:20] <zumbrunn> interesting stuff![19:21] <midnightmonster> (I found this before but didn'[19:21] <midnightmonster> t grok it)[19:21] <zumbrunn> this.__node__ == this[19:24] <p3k> but this.__node__._parent !== this._parent :)[19:27] <zumbrunn> this.__node__._parent == undefined[19:27] <zumbrunn> this.__node__.__parent__ == '[object GlobalObject]'[19:27] <zumbrunn> but this.__node__.__parent__ != global[19:28] <p3k> undefined only if you have no type mappings[19:28] <p3k> i tested it with a persistent object[19:28] <zumbrunn> ok[19:30] <p3k> but shouldn't this._parent === this.__parent__?[19:30] <p3k> in the code it says:[19:30] <p3k> if ("__parent__".equals(name) || "_parent".equals(name)) {[19:30] <p3k> return core.getNodeWrapper(node.getParent());[19:30] <p3k> }[19:31] <p3k> confusing[19:31] <zumbrunn> yep[19:32] <p3k> using my persistent hopobject it is not...[19:33] <zumbrunn> here not either[19:33] <zumbrunn> (a hop object in the embedded db)[19:34] <p3k> ok at least it's not my fault :)[19:35] <p3k> dang confusing internal __properties__[21:48] <luke-jr> is Helma the same as Rhino?[21:48] <midnightmonster> helam uses rhino[21:48] <midnightmonster> helma[21:49] <luke-jr> i c[21:49] <luke-jr> are you a developer?[21:49] <midnightmonster> using helma, not of helma[21:50] <luke-jr> E4X?[21:50] <midnightmonster> I'm an e4x enthusiast and I'm using it[21:51] <luke-jr> any hints on how to use it? ;)[21:51] <luke-jr> ReferenceError: "XML" is not defined.[21:51] <luke-jr> :/[21:51] <midnightmonster> sounds like you're using an old Helma[21:52] <midnightmonster> you need 1.6, and you actually need an updated Rhino.jar to use with Helma since rhino had an important e4x bug at the time Helma shipped 1.6[21:53] <luke-jr> I'm not using Helma[21:53] <luke-jr> something else that uses Rhino[21:53] <midnightmonster> ok, and old rhino then.[21:54] <luke-jr> 1.6.2?[21:54] <midnightmonster> the last released version of rhino, if it supports e4x at all, requires an extra jar to support e4x.[21:54] <midnightmonster> xbean.jar from apache iirc[21:55] <midnightmonster> helma uses a nightly which has e4x natively[21:56] <luke-jr> got that[21:57] <midnightmonster> I have a binary of the patched nightly--in which I've found only one very non-serious bug since I've been using it a couple weeks. http://letterblock.com/rhino.jar[21:57] <luke-jr> I can't change the Java end of stuff really :/[21:57] <luke-jr> other than adding dependencies[21:57] <midnightmonster> ok. then go look for xbean[21:58] <luke-jr> have it[21:58] <luke-jr> how do I activate it? :p[21:58] <midnightmonster> what do you get when you cross an elephant with a rhino?[21:59] <midnightmonster> 'El'-if-I-know[21:59] <midnightmonster> it has to be in your classpath[22:00] <midnightmonster> but actually I don't think it will work in 1.6.2 at all. that[22:00] <midnightmonster> 's almost 2 years old[22:01] <luke-jr> it is??[22:01] <midnightmonster> (nope--I'm wrong. it is almost 2 years old, but apparently they do implement it if you have xbean.jar properly)[22:01] <midnightmonster> http://developer.mozilla.org/en/docs/Rhino_downloads_archive 2005-09-19[22:02] <luke-jr> Rhino 1.6R5 is 2006-11-19...[22:02] <midnightmonster> r6 is 07-07-30[22:02] <luke-jr> R6 doesn't exist as far as http://www.mozilla.org/rhino/download.html[22:03] <midnightmonster> http://developer.mozilla.org/en/docs/Rhino_downloads[22:03] <midnightmonster> (see the large "this page is obsolete" banner atop your link)[22:04] <luke-jr> eck[22:05] <midnightmonster> zumbrunn, I didn't notice till now that rhino 1.6r6 had come out. I wonder if the released version will drop in to Helma.[22:12] <luke-jr> R1 supposedly does E4X[22:13] <midnightmonster> yeah--corrected myself about that above. afaik you just need xbean in your classpath, but I'm not much of a java guru (read: not at all)[22:42] <zumbrunn> midnightmonster, there is a newer build, based on the R6 release plus the Helma patches[22:42] <zumbrunn> http://helma.zumbrunn.net/downloads/rhino16r6patched/rhino.jar[22:43] <midnightmonster> ooo fun[22:44] <zumbrunn> a R7 release is already being prepared, containing a bug fix that didn't surface during the R6 release candidate phase[22:44] <midnightmonster> what's the bug about?[22:46] <zumbrunn> Jürg Lehni discovered that one...[22:46] <zumbrunn> http://www.nabble.com/VMBridge_jdk15-is-used-for-JDK-1.4--tf4224500.html#a12054633[22:47] <midnightmonster> spiffy[22:47] <midnightmonster> (but unlikely to affect me, so no reason not to go to 1.6r6)[22:48] <zumbrunn> that bug is in the version you've currently got, anyway[22:48] <zumbrunn> like the E4X bug, it's probably been in there for a while[22:49] <midnightmonster> I figured. I'm on jdk 1.6 anyway
In the channel now:
Logs by date: