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

2008-11-06:

[11:18] <hannesw> chris: sorry about the one more bug in 1.6.3 :-)
[11:19] <hannesw> unfortunately i think it's an important one
[11:25] <zumbrunn> no problem, that's what release candidates are there for
[12:14] <lehni> hannes, have you seen this rhino patch?
[12:14] <lehni> https://bugzilla.mozilla.org/show_bug.cgi?id=462827
[12:14] <lehni> small change allows for great things
[12:16] <lehni> e.g. http://helma.pastebin.com/d567737b6
[12:17] <lehni> (a wrapper for objects that adds an onChange handler on the object itself and any of its child-objects, arbitrary levels deep)
[14:09] <rindolf> Hi all.
[14:09] <rindolf> I added Helma to the CMS Wikia - http://cms.wikia.com/wiki/Helma
[14:10] <rindolf> Feel free to add more content.
[14:11] <zumbrunn> thanks rindolf
[14:11] <rindolf> zumbrunn: you're welcome.
[14:11] <zumbrunn> I hope that won't go down the road of helma's wikipedia entry :-)
[14:12] <zumbrunn> http://en.wikipedia.org/wiki/Helma_Object_Publisher
[14:13] <zumbrunn> http://deletionpedia.dbatley.com/w/index.php?title=Helma_Object_Publisher
[14:14] <zumbrunn> given what happend on wikipedia, I probably should not recommend to take any of the text there as an example ;-)
[14:14] <rindolf> zumbrunn: I have yet to delete a page from cms.wikia.com
[14:15] <rindolf> zumbrunn: possibly excluding spam.
[14:15] <zumbrunn> :-)
[14:15] <rindolf> zumbrunn: and I want cms.wikia.com to be as comprehensive as possible.
[14:15] <rindolf> Covering even very obscure stuff.
[14:16] <rindolf> And I hate deletionists.
[15:00] <hannesw> juerg:
[15:00] <hannesw> nein, noch nicht gesehen
[15:00] <hannesw> will look into it
[15:00] <lehni> super. der code im pastebin sollte es ein wenig illustrieren
[15:00] <hannesw> wow
[15:00] <lehni> ;)
[15:00] <hannesw> ok, i get it
[15:00] <lehni> works like a charm!
[15:00] <hannesw> wow
[15:00] <hannesw> really smart
[15:01] <hannesw> really really smart
[15:01] <lehni> hahah
[15:01] <lehni> danke
[15:01] <lehni> in verbindung mit getter / setter stuff auf HopObject prototypes kann ich damit fake properties erzeugen, die dann z.b. ein objekt in der datenbank als json speichern, und die direkt ?nderungen entdecken, und per onCommit hook updates erzeugen
[15:02] <lehni> somit siehst du wie alles zusammenh?ngt
[15:02] <lehni> oops, sorry, wrong language
[15:02] <zumbrunn> lol
[15:02] <lehni> there is similar code for wrapping xml objects too
[15:02] <lehni> lemme see
[15:03] <lehni> http://helma.pastebin.com/dad2831
[15:04] <lehni> i was amazed how little change was needed in rhinop
[15:04] <lehni> rhino
[15:04] <lehni> and there is no downside to it, afaik
[15:05] <lehni> so maybe to translate what i said above: the code lets me wrap plain / xml objects in a wrapper that pretends to just be that, but that intercepts changes on the object. since any of the returned children are wrapped as well, changes can be detected any level down the hierarchy. this is only one example of usage of that feature of course
[15:07] <lehni> i use it to produce fake properties on hopobjcet prototypes that return xml / object data, which internally is stored as strings (xml / json). changes on these properties are detected, any level down (e.g. delete obj.foo.bar; obj.some.value = 10; ...), and the string value in the database is updated accordingly.
[15:07] <lehni> that's what i need the onCommit hook (or onBeforeCommit hook) for
[15:09] <hannesw> checking this again: http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/browse_frm/thread/1a9ab69548fba98/6d9a64518a6586ff?lnk=gst&q=456546#6d9a64518a6586ff
[15:10] <lehni> haha
[15:10] <lehni> i did not see that
[15:10] <lehni> quite close
[15:10] <hannesw> i posted it here some time ago
[15:11] <lehni> so does my proposition fix that?
[15:11] <lehni> proposal
[15:17] <hannesw> so this makes the whole meta method/object thing obsolete, right?
[15:17] <hannesw> in a rather elegant way too
[15:18] <lehni> yes, no need for it on my side
[15:18] <lehni> but it's not the same object. it's a wrapped object
[15:18] <hannesw> hm - it's a custom subclass of nativeobject, or whatever you use as base class
[15:19] <lehni> yes
[15:19] <lehni> ScriptableObject i use
[15:19] <lehni> and for xml i use XMLObject
[15:19] <hannesw> well basically it spares you the extra java trickery in my code
[15:19] <lehni> so that my wrapped object works with all the e4x stuff
[15:19] <lehni> i tested that, works like a charm
[15:19] <hannesw> ok, i really like it. but of course we have to look very good for possible side effects
[15:19] <lehni> well
[15:20] <lehni> i dont think people ever use JavaAdapter to extend Scriptable so far
[15:20] <lehni> so i cannot see any
[15:20] <lehni> in worst case, it's just one of the little patches needed for rhino on helma
[15:20] <lehni> (glad you like it!)
[15:21] <hannesw> and the resulting object has its __proto__ set correctly?
[15:23] <lehni> yes
[15:23] <lehni> ?hm
[15:23] <lehni> i think so
[15:23] <lehni> i mean, in my example code i set it after
[15:24] <lehni> would you like me to check what it's set to before that?
[15:24] <lehni> i need to set it so it inherits all the fields
[15:24] <lehni> for xml that would not be needed actually
[15:36] <hannesw> juerg: what is toJava()? is that a helma 1 function?
[15:36] <lehni> yes
[15:37] <hannesw> hmmm
[15:37] <lehni> i am doing that so i can access the scriptable object's native functions
[15:37] <hannesw> what i like in the code i posted is that i'm able to call this.super$put()
[15:37] <hannesw> that doesn't work with your patch
[15:37] <hannesw> not sure why
[15:39] <lehni> well, i am wrapping an existing object by subclassing another type
[15:39] <lehni> they are two different things...
[15:39] <lehni> i haven't tried calling super$ stuff since i did not need to
[15:40] <lehni> it should work though
[15:40] <hannesw> nope, it doesn't. don't know why
[15:40] <lehni> ok
[15:40] <lehni> hmmm
[15:40] <lehni> i can look into it
[15:40] <lehni> i also need to check your code properly
[15:40] <lehni> not sure i understand it all
[15:41] <lehni> i guess it does the same thing though...
[15:49] <hannesw> yes, basically. it creates a javaadapter (wrapped in NativeJavaObject) and then unwraps it and sets the prototype
[15:49] <hannesw> so it's basically the same, but super$put works...
[15:50] <hannesw> hrmpf
[16:33] <hannesw> hey juerg, i found the problem
[16:33] <hannesw> look at JavaAdapter, line 205...
[16:34] <hannesw> this is where the constructor gets called, which results in createAdapterWrapper to be invoked.
[16:34] <hannesw> but what is returned is the value of field "self" of the adapter (next statement)
[16:34] <hannesw> which is actually different than the adapter...
[16:34] <hannesw> major voodoo going on here
[16:35] <lehni> yes, i saw the voodoo
[16:35] <hannesw> well ok the value of field "self" which is returned is not the adapter, but it also is an instance of NativeJavaObject
[16:35] <lehni> i know, self is the wrapper that it produces...
[16:35] <lehni> but if we already produce a scriptable, my patch does not wrap that again
[16:35] <lehni> instead, it just uses the produced object
[16:35] <hannesw> hmmmmm probably the constructor does something to self after it is created
[16:36] <lehni> like what?
[16:36] <lehni> i guess it should be possible to read the produced byte code
[16:36] <lehni> i mean, the way it produces it
[16:37] <hannesw> i don't know!
[16:37] <hannesw> got to decode the constructor (<init>) bytecode to find out ...
[16:38] <lehni> oh dera
[16:38] <lehni> dear
[16:39] <hannesw> hm... the constructur only stores the result of createAdapterWrapper in the "self" field... but obviously the difference is that self needs to contain the wrapped object in order to be able to invoke super methods...
[16:39] <hannesw> ok
[16:39] <hannesw> mystery solved
[16:40] <hannesw> the problem is just that the best occasion to unwrap is where you're doing it
[16:42] <hannesw> so the question is... should this be exposed as NativeJavaObject in method calls
[16:42] <hannesw> or as javascript object...
[16:42] <lehni> you mean 'this'?
[16:43] <hannesw> yes.
[16:43] <lehni> what do you think?
[16:43] <lehni> I guess NativeJava then
[16:43] <lehni> in that sense
[16:43] <hannesw> i think it would be nice to have it as wrapped java object
[16:43] <hannesw> in order to have super$ methods...
[16:43] <lehni> yes
[16:43] <lehni> make sense
[16:44] <hannesw> it's just not so easy to implement...
[16:44] <lehni> do you know how to do that?
[16:44] <lehni> ;)
[16:44] <hannesw> nope
[16:44] <lehni> but then, it only needs to do it if a scriptable object instance is returned, right?
[16:44] <hannesw> :-(
[16:44] <lehni> no, not instance
[16:44] <lehni> i mean, if JavaAdapter is asked to extend a Scriptable class
[16:45] <hannesw> nope, the self field always holds a NativeJavaObject wrapper
[16:45] <lehni> oh, i see
[16:45] <hannesw> only to the script it is exposed unwrapped
[16:45] <hannesw> although that's weird, because from the outside the object looks differently than from the inside....
[16:45] <lehni> so you want to keep holding a NativeJavaWrapper, but get the constructor return it unwrapped if it wraps a Scriptable instance
[16:45] <hannesw> but that's the price you pay for a feature like that i guess
[16:46] <hannesw> exactly
[16:46] <lehni> ok
[16:46] <lehni> i can look into it
[16:46] <hannesw> that would allow you to use super$foo from within the foo
[16:46] <lehni> indeed
[16:46] <lehni> great
[16:51] <hannesw> ok, i got that working (bit of a hack)
[16:51] <hannesw> http://helma.pastebin.com/m6a126edc
[16:51] <lehni> return (NativeJavaObject) self.get(adapter);
[16:51] <lehni> is this conversion needed'
[16:51] <lehni> ?
[16:52] <lehni> ah, ok
[16:52] <lehni> i see it
[16:52] <hannesw> well self is a generic field, so get() returns a java.lang.Object
[16:52] <lehni> yes
[16:52] <lehni> looking good
[16:52] <hannesw> basically you must take care self always contains a NativeJavaObject
[16:52] <hannesw> might change the class generation to declare it as such
[16:52] <lehni> exactly
[16:53] <lehni> do you think the rhino guys would accept this?
[16:53] <lehni> i mean, you're one of them ;)
[16:53] <lehni> "them"
[16:53] <hannesw> yes, i sure think so ... this is minimally invasive
[16:53] <hannesw> and it makes lots of sense
[16:53] <lehni> and massively useful
[16:54] <hannesw> and JavaAdapterr is already a rhino extension, so we might as well make it more useful
[16:54] <lehni> great!
[16:54] <lehni> glad i could add to that
[16:54] <lehni> it just came from my __meta__ experiments
[16:56] <hannesw> oops... last patch doesn't work
[16:56] <lehni> oh
[16:56] <hannesw> well actually lets just leave the definition of the self field as it is ...
[16:57] <lehni> ah, i see
[16:57] <lehni> can't tell what's better
[16:57] <hannesw> there's also a "serial" constructor which would have to change signature...
[16:57] <lehni> did you mess around with the byte code generation
[16:57] <hannesw> yes, and everythign came tumbling down :-)
[16:58] <lehni> haha
[16:58] <lehni> dont touch this
[16:58] <lehni> (by mc hammer)
[16:58] <hannesw> :-) unless you really have to
[16:58] <lehni> that's not how i remember the lyrics ;)
[16:59] <hannesw> hehe
[16:59] <hannesw> actually the whole casting is just to save coding... i'll do it the proper way then (two instanceofs)
[16:59] <lehni> cfw.addField("self", "Lorg/mozilla/javascript/Scriptable;", (short) (ClassFileWriter.ACC_PUBLIC | ClassFileWriter.ACC_FINAL));
[16:59] <lehni> this one here, right?
[17:01] <hannesw> there are several places you'd have to change
[17:04] <hannesw> ok new patch:
[17:04] <hannesw> http://helma.pastebin.com/m4a19e72a
[17:04] <hannesw> although there are two instancofs, i like this better
[17:05] <lehni> why not check for instanceof Wrapper then?
[17:05] <lehni> instead of NativeJavaObject?
[17:05] <lehni> since all you use is unwrap, which is defined in Wrapper
[17:05] <lehni> and then, it would need a short explaining comment i guess
[17:05] <hannesw> ok, you're right
[17:05] <lehni> i agree this is better
[17:06] <lehni> instanceofs
[17:06] <lehni> i like that plural ;)
[17:07] <hannesw> http://helma.pastebin.com/m1540e153
[17:08] <lehni> sweet!
[17:08] <hannesw> so your example can use this.super$get() instead of toJava(obj).get()
[17:08] <hannesw> which is an improvement i think, as toJava isn't standard rhino
[17:08] <hannesw> yeah!
[17:08] <hannesw> gonna post this to your bug report
[17:08] <lehni> well
[17:08] <lehni> no!
[17:08] <hannesw> and then post to rhino group
[17:08] <hannesw> why not?
[17:09] <lehni> because obj is just a wrapped object
[17:09] <lehni> not the super class
[17:09] <lehni> it's an instance
[17:09] <lehni> i am wrapping
[17:09] <hannesw> yes, ok
[17:09] <lehni> but that's fine
[17:09] <lehni> still nice to be able to do this
[17:09] <hannesw> i think the effect is the same actually
[17:09] <lehni> let i try
[17:31] <lehni> "Landing Steve Yegge's new Abstract Syntax Tree (AST) API changes."
[17:31] <lehni> have you seen this?
[17:31] <lehni> Token.java
[17:31] <hannesw> yes i have
[17:31] <lehni> does your token patch still work?
[17:32] <hannesw> aw, don't know
[17:32] <hannesw> doesn't matter, does it
[17:32] <lehni> why not?
[17:32] <hannesw> it's helma 1
[17:32] <lehni> and that's where i am ;)
[17:34] <hannesw> looking at the changes, the patch should still work
[17:35] <hannesw> it might
[17:35] <lehni> trying now
[17:42] <hannesw> let me know how it works!
[17:43] <lehni> i am making a new patch
[17:43] <lehni> for token
[20:02] <decke> zumbrunn: just wanted to let you know that 1.6.3-rc2 works fine for me on FreeBSD
[21:10] <zumbrunn> decke: ok, thanks!
[21:11] <zumbrunn> I was going to ask you about that :-)

 

 

In the channel now:

Logs by date: