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

2008-10-30:

[8:40] <hannesw> good morning
[8:40] <hannesw> so are we ready for a second 1.6.3 rc?
[8:43] <lehni> hello all
[8:46] <hannesw> hi juerg!
[8:47] <lehni> hi hannes
[8:47] <hannesw> i just applied your hopobject patch, looking at it in context
[8:47] <lehni> good
[8:47] <lehni> what do you think?
[8:47] <lehni> it is a bit weird maybe because it allows hopobject slots the priority over the wrapped node's properties
[8:47] <lehni> i mean, scriptobject slots
[8:48] <lehni> or ScriptableObject, to be correct
[8:49] <hannesw> was on the phone, haven't looked yet
[8:50] <hannesw> i understand what you do conceptually - be more like ScriptableObject i.e. ordinary js object
[8:50] <lehni> yes
[8:50] <hannesw> i just have to look if there are any unwanted side effects
[8:51] <lehni> the downside might be that we have to check for super.has in a few places
[8:51] <hannesw> that shouldn't be a problem, scriptableobject is pretty fast ;-)
[8:52] <hannesw> for 1.6.3 it's too late, but it can make 1.7.0 even cooler
[8:52] <hannesw> :-)
[8:52] <hannesw> sorry, have to leave for another 5 minutes (check ausflug with kindergruppe)
[8:52] <lehni> fine with me
[8:52] <lehni> so far there are no side effecs on my apps
[8:53] <lehni> super.has only returns true if a slot was defined there. and as far as I know that can only happen when using __defineGetter__
[8:54] <lehni> since when setting, node.set gets the priority, and super.put is only used when the slot is already defined
[9:11] <hannesw> one potential problem with delete() is that we probably should do super.delete() _and_ node.unset(), not just either or...
[9:12] <hannesw> or in any case check for the proeprty in node before doing super.delete()
[9:14] <hannesw> ha, wrong. actually it's ok what you do. I was thinking about super in terms of prototype chain, which is wrong of course
[9:16] <hannesw> what i don't understand: why does this work? you're only calling super.put() in put() if the property is already defined (super.has() returns true)
[9:16] <hannesw> so how do you set this the first time?
[9:20] <lehni> __defineGetter__ and __defineSetter__ produce a getterSetter slot
[9:21] <hannesw> i see, i just found that out by myself
[9:21] <hannesw> ok, so this looks really good!
[9:21] <lehni> nice!
[9:21] <lehni> calling delete on such an introduced property removes the property, and frees the underlying node property again
[9:22] <lehni> if i would call unset there too it would be gone
[9:22] <lehni> which would be more normal JS behavior
[9:22] <hannesw> i'll have another review and test and commit it then
[9:22] <hannesw> i see
[9:22] <lehni> pretending that the node's properties and the native js propeties are the same
[9:22] <hannesw> yep
[9:22] <lehni> but that would break my little watch / unwatch hack ;)
[9:23] <lehni> but maybe it's the way to go
[9:23] <hannesw> hmmm
[9:23] <lehni> something else i wanted to ask: right now, the setting and getting of values has a lot of logic in HopObject, not just Node
[9:24] <lehni> e.g. the private getFromNode in HopObject
[9:24] <hannesw> yes
[9:24] <lehni> and all the stuff in put
[9:24] <lehni> i was wondering if this logic could made javascript independent and moved to node.
[9:24] <lehni> so i could to toJava(obj).get / set
[9:24] <lehni> for watching / unwatching of values
[9:25] <lehni> or better, for fetching of underlying 'native' properties
[9:25] <hannesw> or we could make toJava return the HopObject instead of the Node...
[9:25] <lehni> but that's a ScriptableObject, isn't it?
[9:25] <hannesw> I'd rather not shift that much functionality around at this time of the helma 1 lifecycle :-)
[9:26] <lehni> i see
[9:26] <hannesw> yes, but it's the same behaviour as when you call toJava on a native js object
[9:26] <hannesw> you also get the scriptableobject/nativeobject
[9:26] <lehni> ah, ok
[9:26] <lehni> but that might break other things then?
[9:26] <hannesw> yes, i guess so
[9:26] <lehni> people relying on toJava returning a Node
[9:27] <lehni> how many could there be ;
[9:27] <lehni> )
[9:27] <hannesw> between zero and 3
[9:27] <hannesw> :-)
[9:27] <lehni> haha
[9:27] <lehni> one more thing?
[9:28] <hannesw> what is it?
[9:28] <lehni> i looked at __metaobject__
[9:28] <lehni> intersting stuff
[9:28] <hannesw> ah, ok!
[9:28] <hannesw> yes it is
[9:28] <lehni> (i would just call it __meta__ though)
[9:28] <hannesw> agreed
[9:28] <lehni> i wished this kind of stuff could make it into the standard
[9:28] <lehni> imagine that on the browser.
[9:28] <hannesw> yes, would be great
[9:28] <hannesw> we should work something out
[9:29] <lehni> it felt more clean than all the __defineSetter__ __defineGetter__ __lookupGetter__ etc cruft
[9:29] <hannesw> and propose it to the es folks
[9:29] <lehni> who proposed it initially?
[9:29] <lehni> where is it from?
[9:29] <lehni> i found this page here: http://www.bias2build.com/thesis/javascript_mop_expanded.html
[9:29] <hannesw> yes. you know the __defineSetter__ etc stuff is being redesigned for EcmaScript 3.1 and becoming part of the standard?
[9:29] <hannesw> there'll be just one method: Object.defineProperty()
[9:29] <lehni> yes, heard about that
[9:30] <hannesw> Object.defineProperty(obj, prop, { getter: ..., setter: ..., [enumerable: true]})
[9:30] <lehni> what i was wondering with __metaobject__ was why the lookup happens only on the object itself, not its inheritance chain
[9:30] <lehni> imagine being able to set it on prototype objects, and then it would serve all instances of that prototype
[9:30] <hannesw> i think it goes down the proto chain
[9:31] <hannesw> at least that was the behavour of metamethods
[9:31] <lehni> maybe it would need some smart cashing
[9:31] <hannesw> and that's copied from MOP
[9:31] <lehni> caching
[9:31] <lehni> (ooops, crazy delays here in my web based irc client)
[9:31] <hannesw> well i think one thing we could do is to do the meta lookup _after_ the ordinary property lookup
[9:32] <lehni> i am pretty sure it does not
[9:32] <lehni> let me check
[9:32] <hannesw> and/or store the meta object as specialized java field, not as ordinary property
[9:32] <hannesw> that would make the lookup a no-brainer, performance wise
[9:32] <lehni> Object o = this.get("__metaobject__", object, null);
[9:32] <lehni> this does not walk the chain
[9:33] <hannesw> yes, but the ordinary lookup walks the chain... it's in get() so it will be found in the proto chain
[9:33] <lehni> the static ScriptableObject.getProperty does
[9:33] <hannesw> exactly
[9:33] <lehni> which ordinary lookup?
[9:34] <lehni> the thing is, when an instance wants its __metaobject__, it only does a flat lookup, so to speak
[9:34] <hannesw> well, foo.bar in javascript
[9:34] <lehni> so it won't receive the one from it's prototype
[9:34] <lehni> when looking up methods and things
[9:34] <hannesw> yes, but that's the way Scriptable.get() works in general
[9:34] <hannesw> the prototype walk is outside of Scriptable.get()
[9:34] <lehni> i know
[9:35] <lehni> what i am saying is that in getMetaobject, ScriptableObject.getProperty is not used
[9:35] <hannesw> all it means is you can overwrite a meta object getter in the proto chain with an ordinary js property in the object
[9:35] <lehni> so setting the __metaobject__ on prototypes won't have an effect for put and has on instances
[9:35] <hannesw> i think it will!
[9:35] <lehni> no
[9:35] <lehni> i tried
[9:35] <lehni> getting __metaobject__ explicitely from js will return it
[9:36] <hannesw> that would be really really strange. it worked with metamethods ( i think)
[9:36] <hannesw> wait a moment...
[9:36] <lehni> but in all the hidden magic where metamethods are looked up, it won't use it
[9:36] <lehni> i might have done something wrong
[9:36] <hannesw> its strange because as far as i remember, metamethods was functionally identical to MOP/__metaobject__
[9:36] <hannesw> I have to check...
[9:39] <lehni> i think it's the same in jmop
[9:40] <lehni> i was realy interested in this __metaobject__ stuff because it means i could watch helma properties on a level of prototpes, not instances
[9:40] <lehni> hopobject properties i mean
[9:40] <lehni> this would solve one of my bugs: handlers for property changes
[9:41] <lehni> my tests then showed that just like my watch / unwatch stuff, it also only works on instance level.
[9:41] <hannesw> ok, seems like you are right
[9:42] <lehni> changing it to a different lookup will definitelly have an impact on performance though. even now it might slow things down
[9:42] <lehni> but then walking that chain every time might be slow for long inheritance chains (which are to be avoided in js anyhow)
[9:43] <hannesw> no no, that shouldn't be a problem
[9:43] <hannesw> setters defined via __defineSetter__ are inherited, right?
[9:43] <lehni> no
[9:44] <lehni> if you have a field in prototype, and you set the field of the same name in an instance, it's not going to modfify what's there in the prototype already
[9:44] <lehni> it just stores the field in the instance
[9:44] <lehni> which masks out the one in the prototype
[9:44] <hannesw> yes, but I thought it would use the setter...
[9:44] <lehni> deleting the field again on the instance will unmask out what's in the prototype in the next lookup
[9:44] <hannesw> to set it on the top level object
[9:45] <lehni> no, because at this time it does not know if it's a normal property or a getterSetter
[9:45] <lehni> and when setting on an instance it will never set on top level objects
[9:45] <lehni> i think that's js convention
[9:45] <lehni> otherwise prototype objects would get modified all the time
[9:46] <hannesw> ok, setters _are_ inherited!
[9:46] <lehni> sure?
[9:46] <lehni> ah, hang on
[9:46] <hannesw> yes, tested in spidermonkey
[9:46] <lehni> maybe this does not work in hopobject
[9:46] <lehni> or maybe rhino does it differently
[9:47] <lehni> might be a problem of my patch
[9:47] <lehni> i will check how it works with plain objects in rhino
[9:47] <lehni> hang on
[9:47] <hannesw> the reason it works with setters is that has() returns true in the prototype
[9:48] <lehni> (this is all very exciting stuff... js feels so much more powerful with such concepts)
[9:48] <lehni> well
[9:48] <lehni> has will also return true for any normal field defined in the prototype
[9:48] <hannesw> and that's also the reason it doesn't work with generic meta lookups i guess
[9:48] <lehni> still it would not call the prototype's setter
[9:48] <lehni> i tihink it's more complex than that
[9:49] <lehni> let me check some things
[9:52] <hannesw> arg... i'm in patch hell, but I think the metamethods page still has an old/obsolete patch.
[9:52] <lehni> ok, you're right. it works with plain objects
[9:53] <lehni> on rhino, that is
[9:53] <lehni> now trying with hopobjects and my patch
[9:53] <hannesw> doesn't it work with hopobjects? I think it did, at least i thought so when i closed bug 514
[9:53] <hannesw> http://helma.org/bugs/show_bug.cgi?id=514#c2
[9:53] <lehni> well
[9:53] <lehni> hmm
[9:53] <lehni> true
[9:53] <lehni> that does not have anything to do with my patch
[9:54] <lehni> but in the mix it probably does not work: defining a setter on the prototype for node properties
[9:54] <lehni> ok, same behaviour with a bare hopobject
[9:55] <lehni> now let's see with type.properties
[9:56] <lehni> that's what does not work
[9:56] <lehni> i will solve that one now then
[9:57] <hannesw> the problem is with type.properties?
[9:57] <lehni> well
[9:57] <lehni> with node properties
[9:57] <lehni> they seem to get the priority over setters in the prototype
[9:57] <lehni> and getters
[9:57] <lehni> so i will check that now
[9:57] <lehni> i know why!
[9:58] <lehni> the instance returns true for has
[9:58] <hannesw> ok
[9:58] <lehni> so it does not check the prototype
[9:58] <hannesw> yes, that's to be expected.
[9:58] <lehni> tricky
[9:58] <hannesw> that would also happen with plain js objects
[9:59] <hannesw> hopobject.has returns true if the prop is defined in type.properties, even if no prop is set?
[9:59] <lehni> well, this one was set
[9:59] <lehni> since i want to find a way to observer fields...
[9:59] <lehni> on hopobjects
[10:01] <lehni> so it's no bug... makes sense
[10:01] <hannesw> ok, metamethods also works via prototype chain
[10:01] <lehni> for setters?
[10:01] <hannesw> but maybe that's in a second patch I didn't upload to the wiki page, still unsure
[10:01] <hannesw> yes.
[10:01] <lehni> can i get the patch?
[10:01] <lehni> curious to see
[10:02] <hannesw> 1 sec
[10:04] <hannesw> ok, it's the metamethods-2.patch here:
[10:04] <hannesw> http://dev.helma.org/ng/Metamethods/
[10:04] <lehni> oh
[10:04] <lehni> was it too slow?
[10:04] <lehni> i guess all the lookups do it
[10:05] <hannesw> yes, ordinary property lookups for each get/set/has...
[10:05] <hannesw> but storing __meta__ as a java field would solve that problem.
[10:05] <lehni> but that would not work with chains again, right?
[10:05] <lehni> i didn't see metamethods before!
[10:06] <hannesw> yes it would work with proto chains
[10:06] <hannesw> did you follow helma-ng a bit?
[10:07] <lehni> not at all so far!
[10:07] <lehni> was too busy with other stuff
[10:07] <hannesw> i think it's really exciting stuff
[10:07] <lehni> i am sure it is
[10:07] <hannesw> helma without all the burden
[10:07] <lehni> yes
[10:07] <hannesw> and it's 60% javascript, only 40% java ;-)
[10:07] <lehni> i am working on my boots (cms) and bootstrap (js library) stuff again
[10:07] <lehni> it would be great to get it up and running on ng
[10:08] <lehni> i am a bit weary of all the changes though
[10:08] <hannesw> yes! helma-ng is pure javascript, only better because of the modules
[10:08] <lehni> i looked at the core modules yesterday and saw a lot of stuff is added to string
[10:08] <hannesw> modules rock - each js file lives in its own scope
[10:08] <hannesw> you don't have to use it!
[10:08] <lehni> ah!
[10:08] <lehni> wow
[10:09] <lehni> niceness
[10:09] <hannesw> and it's non-enumerable
[10:09] <lehni> ok
[10:09] <hannesw> unless you import it it's not there
[10:09] <lehni> ok
[10:09] <lehni> how does the importing work?
[10:09] <lehni> does it merge scopes?
[10:09] <lehni> i guess i should look at code
[10:09] <hannesw> no, it just evaluates the script to a top level scope and returns that
[10:10] <lehni> ah, ok
[10:10] <hannesw> we're still working on the naming, though ;-)
[10:10] <lehni> naming of what?
[10:10] <hannesw> and there's a nice console with history and auto-completion
[10:10] <lehni> where?
[10:10] <hannesw> and a .deb installer that even works on mac os x
[10:10] <lehni> that i heard
[10:11] <hannesw> java -jar run.jar
[10:11] <hannesw> java -jar run -i apps/demo/main.js
[10:11] <hannesw> you can run an application and use the shell simultanously.
[10:12] <hannesw> sorry, should have been run.jar, not run
[10:12] <lehni> ah, i see
[10:12] <lehni> great!
[10:12] <lehni> i shall check
[10:13] <lehni> is hopobject / db functionality there?
[10:13] <hannesw> you will love it I'm sure
[10:13] <hannesw> only in the beginning
[10:13] <hannesw> i mean: we're just starting with db/persistence
[10:13] <hannesw> there's a hibernate wrapper in the works by robert thunher
[10:14] <hannesw> and i'm working on a simple file store using json
[10:14] <lehni> is that the way things will go?
[10:14] <hannesw> and i also have a simple couchdb wrapper
[10:14] <lehni> relying on 3rd party?
[10:14] <hannesw> not sure, we may also port helma o/r at some point
[10:14] <lehni> will there be an api for all the different wrappers?
[10:14] <lehni> to abstract them
[10:14] <hannesw> that would be ideal
[10:15] <lehni> i would not come too late to the party then
[10:15] <lehni> ;)
[10:15] <hannesw> current api for helma.filestore is really simple and similar to the robi's hibernate wrapper
[10:15] <hannesw> there's a demo app in apps/storage/
[10:16] <hannesw> http://github.com/hns/helma-ng/tree/master/apps/storage/model.js#L36
[10:16] <hannesw> current import function is called require, but we'll switch once again to import()/export()
[10:17] <hannesw> so it's not stable yet
[10:17] <lehni> nice
[10:17] <lehni> so it's using getters and setters to do the magic
[10:17] <lehni> great
[10:17] <lehni> how is performance compared to helma 1?
[10:18] <lehni> since more stuff is in js
[10:18] <hannesw> yes
[10:18] <hannesw> super fast
[10:18] <lehni> haha
[10:18] <hannesw> hannes@hns:~/git/helma-ng$ java -jar run.jar -i apps/storage/main.js
[10:18] <hannesw> 0 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via org.mortbay.log.Slf4jLog
[10:18] <hannesw> 95 [main] INFO org.mortbay.log - jetty-6.1.10
[10:18] <hannesw> 155 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:8080
[10:18] <hannesw> helma> include('model');
[10:18] <hannesw> helma> Book.all();
[10:18] <hannesw> Book{author:{_id:"5", _type:"Author"}, title:"Helma for Dummies"},Book{title:"Wahlverwandschaften", author:{_id:"1", _type:"Author"}},Book{title:"Faust", author:{_id:"1", _type:"Author"}}
[10:18] <hannesw> helma>
[10:18] <lehni> wow
[10:19] <hannesw> well, helma 1 is ok too.
[10:19] <lehni> which one is faster?
[10:19] <lehni> ;)
[10:19] <hannesw> but for the fact that there is more js than java, and every runtime specific feature is js, helma ng is amazingly fast
[10:19] <hannesw> you can't really compare as functionality differs too much i guess
[10:19] <lehni> great
[10:19] <lehni> way to go
[10:20] <lehni> one question:
[10:20] <lehni> store.registerType(Book, {
[10:20] <lehni> oops
[10:20] <lehni> cut off
[10:20] <lehni> title: db.Text(),
[10:20] <hannesw> so a persistent query that goes down to the file system and json decoding each time does about 500 - 1000 reqs per second on my laptop i think
[10:20] <lehni> does db.Text need to know about the field's name?
[10:20] <lehni> and if so, how can it?
[10:20] <hannesw> no, it doesn't need to know
[10:20] <lehni> or does this just produce an abstract description, and the magic happens in registerType
[10:21] <lehni> (probably does)
[10:21] <hannesw> it's always used in context of the property name ... yes, exactly
[10:21] <hannesw> registerType is in modules/helma/filestore.js
[10:22] <lehni> and this api will be standardized, so switching from file storage to hibernate would only require a different store object in the helma code?
[10:22] <hannesw> i can't promise that 100%
[10:23] <hannesw> but it's a goal
[10:23] <lehni> goals are there to be met ;)
[10:23] <lehni> great
[10:23] <hannesw> :-)
[10:23] <lehni> i think it's exciting
[10:23] <lehni> does HopObject still exist?
[10:23] <hannesw> yes, think so too
[10:24] <lehni> only as a compatibility layer i guess
[10:24] <hannesw> nope.
[10:24] <hannesw> helma ng is really far from helma 1, i don't think a compatibilty layer makes a lot of sense
[10:24] <lehni> ok
[10:24] <lehni> bye bye HopObjet
[10:24] <lehni> sniff
[10:25] <hannesw> it'll be more like conceptual compatibility or whatever
[10:25] <lehni> it was fun while it lasted
[10:25] <hannesw> :-)
[10:25] <hannesw> well, not always :-)
[10:25] <lehni> conceptual compatibility. i like that
[10:25] <lehni> indeed!
[10:25] <lehni> hahaha
[10:25] <lehni> you mentioned naming
[10:25] <lehni> do you need advise?
[10:25] <lehni> ;)
[10:26] <lehni> (i am happy to join in on discussions. where do they mostly happen?)
[10:26] <hannesw> http://groups.google.com/group/helma-ng
[10:26] <hannesw> btw, we also moved to google groups for helma 1:
[10:26] <hannesw> http://groups.google.com/group/helma
[10:27] <lehni> if i subscribed to the old groups, am i kept in?
[10:27] <hannesw> nope
[10:27] <lehni> so i need a google account
[10:29] <lehni> so far i stayed away from that, no gmail, etc
[10:29] <hannesw> i see. sorry about that
[10:29] <lehni> haha
[10:30] <lehni> there is no way to simply be subscribed to that list by mail?
[10:31] <hannesw> of course. just create a google account and enter your email address (i think)
[10:31] <hannesw> it's just an ordinary mailing list afaik
[10:32] <lehni> ok
[10:32] <hannesw> i don't think you need a gmail account or any other google service. but I don't know as I already have/had a gmail account
[10:32] <lehni> http://finance.google.com/group/google.finance.709508/topics?hl=en&lnk&pli=1
[10:33] <lehni> haha
[10:33] <hannesw> hehe
[10:36] <lehni> ok, i am there now
[10:36] <hannesw> so did it work without gmail etc?
[10:36] <lehni> yes
[10:36] <lehni> still evil, haha
[10:37] <lehni> ok, time for coffee here
[10:38] <lehni> i will look at metamethods next
[10:38] <hannesw> just dumb, i think. like all big corps :-)
[10:38] <lehni> indee
[10:38] <lehni> sitting on top, you get lazy
[10:38] <hannesw> :-)
[10:38] <lehni> nice catching up!
[11:05] <lehni> are metafunctions much faster?
[11:05] <lehni> still one more lookup each time, right?
[11:19] <hannesw> yes, i'd think they're a bit slower
[11:19] <hannesw> I'd favor the meta method approach
[11:20] <hannesw> metamethods also have a problem when setting them. if you define __set__ before any of the others, it will interfere in weird ways...
[11:26] <lehni> oh
[11:26] <lehni> of course
[11:27] <hannesw> so this is another reason for having these methods bundled in a metaobject
[11:27] <lehni> meta methods have the same 'problem' with inheritance as getters / setters though
[11:27] <lehni> you said you'd favor for the meta method approach
[11:27] <hannesw> you mean if a property is defined in the top level object?
[11:27] <lehni> but you ment meta object, right?
[11:27] <lehni> top level or anywhere else up the chain
[11:27] <hannesw> yes, but that's not a bug/problem imo.
[11:27] <lehni> no, not really
[11:28] <hannesw> maybe it is for your purposes :-)
[11:28] <lehni> but in this particular case (watching properties through the prototype) it is ;)
[11:28] <lehni> and metaobjects solve it
[11:28] <lehni> but they are slow
[11:28] <lehni> i know, this is not an argument for them
[11:29] <lehni> i just realised i could use those and wanted to find out more
[11:31] <lehni> and you favour meta functions, right?
[11:32] <hannesw> i favour the meta object approach now
[11:32] <lehni> ok
[11:32] <lehni> me too
[11:32] <hannesw> but implemented a bit differently
[11:32] <lehni> what i like about it is that it differs more from getter / setter stuff than meta methods, since it's not set on the same object
[11:44] <lehni> it is a more powerful structure in a way
[11:45] <lehni> delegation vs extension
[11:48] <lehni> shall i work on a proposal?
[11:51] <hannesw> one question is: on which object should the functions be called, i.e. what is the this object?
[11:51] <hannesw> I'd say the object which is accessed, not the meta object
[11:52] <lehni> yes
[11:52] <lehni> never the metaobject
[11:52] <lehni> it could be either the object on which __metaobject__ was set
[11:52] <lehni> but i think the access object sounds right
[11:52] <lehni> since we dont want prototype passed as this
[11:55] <hannesw> nope, not the prototype for sure
[11:57] <lehni> so this
[11:57] <lehni> i mean, start
[12:01] <lehni> if (this.has("__metaobject__", object, null))
[12:01] <lehni> Object o = this.get("__metaobject__", object, null);
[12:01] <lehni> this is unnecessary
[12:01] <lehni> that's already two lookups anyway
[12:01] <lehni> why not just get it and see if it's defined
[12:07] <lehni> what is the issue with thread safety?
[12:18] <lehni> now imagine being able to add operators to the meta object
[12:18] <lehni> __meta__['+=']
[12:18] <lehni> haha
[12:42] <hannesw> thread safety: metamethod patch was using a java threadlocal to deactivate metamethods while a metamethod was executing
[12:43] <hannesw> i think that's the way to go unless you want to run into problems later on
[12:45] <lehni> ok
[12:45] <lehni> is that much slower?
[12:45] <hannesw> shouldn't be too bad.
[12:46] <hannesw> to start it only applies if a meta object is defined.
[12:46] <lehni> what if we made a special getter / setter for __meta__ to cache the value in java and then even would cache all the functions?
[12:46] <hannesw> so the most important factor (because it affects each and every property access) is to move that into a java field lookup
[12:47] <lehni> when setting __meta__, instead of just setting the object it could produce a special type meta object and copy over all the fields.
[12:47] <hannesw> yes, that's what I'm talking about all along: meta object must be stored as java field, not as js property
[12:47] <lehni> so later setting of functions could be detected and references to all the methods could be stored in java
[12:47] <lehni> for performance increase
[12:47] <hannesw> there's no need to copy anything, just store the meta object as java field
[12:48] <hannesw> the critical test is: is there a meta object or not.
[12:48] <hannesw> in 99% or cases there is none, so this is what we have to optimize
[12:48] <hannesw> -- off for lunch
[12:48] <lehni> the problem is that if __meta__ is set, the function lookup is still slow
[12:48] <lehni> that's why i thought there could be fields for these too
[12:49] <lehni> i agree though about the main optimisation
[12:49] <lehni> i will make some tests
[14:12] <lehni> i did some tests now with caching of meta objects
[14:12] <lehni> the slow down is still 50% due to the walking up the hierarchy chain
[14:13] <lehni> depends on the situation of course
[14:14] <lehni> but this is doing some basic operations with objects that have a bit of inheritance
[14:17] <lehni> ok, wrong measurement. the slow down came mostly from calls to nanoTime
[14:18] <lehni> the slow down is only 18%, due to these lookups up the chain for __meta__ (which is cached on each level)
[14:21] <lehni> and if not walking up the chain, the slowdown is 10%
[14:22] <lehni> 11, actually
[14:22] <lehni> so not too bad
[14:23] <lehni> i am sure more optimisations can be done
[14:30] <lehni> it appears that most of the slow down stems from the use of ThreadLocal
[14:33] <lehni> just using a boolean instead (and breaking thread safety) leads to only a 8% decrease when using the full inheritance chain
[14:42] <lehni> hannes?
[14:43] <lehni> i have it down to a 12% decrease
[14:52] <hannesw> jürg: you shouldn't do a prototype walk in the lookup for __meta__
[14:52] <hannesw> ScriptableObject.getProperty() will do that for you
[14:53] <lehni> i know
[14:53] <lehni> you'll see why i do it myself
[14:53] <lehni> i'm not using getProperty
[14:54] <hannesw> can you post your patch somewhere?
[14:54] <lehni> right now i only look at parents that are instances of ScriptableObject, and then i directly check their cached metaObject field
[14:54] <lehni> not yet
[14:54] <lehni> almost done
[14:55] <lehni> is there anything against making disableMop static?
[14:56] <hannesw> yes - if it was static, mop lookups on other objects wouldn't work while one was in executing
[14:56] <lehni> ah, ok
[14:56] <lehni> true
[14:56] <lehni> hah
[14:57] <lehni> that's what really makes it slower
[14:57] <lehni> anything else is actually not so bad
[14:57] <lehni> everything i mean
[14:57] <lehni> but you would have the same issue with metamethods
[14:58] <hannesw> you could use an ordinary boolean flag in 99% of cases which don't need thread safety
[14:58] <hannesw> unfortunately helma is in the 1% pool :-)
[14:58] <lehni> indeed
[14:59] <hannesw> hey let's just serialize request processing in helma
[14:59] <mib_f4gtrc> oops
[15:00] <lehni> haha
[15:00] <lehni> good idea
[15:00] <hannesw> does your irc client use random handles by default? mib_f4gtrc?
[15:00] <lehni> the trade off in my test is around 18%
[15:00] <lehni> mibbit.com does
[15:00] <lehni> how bad would that be?
[15:01] <hannesw> hm... but the 18% are just for the case where a __meta__ object is defined, right?
[15:01] <lehni> no, when it's not defined
[15:01] <lehni> just due to the lookups and mopDisabled checks
[15:02] <hannesw> then you're doing something wrong.
[15:02] <lehni> disableMop i mean
[15:02] <hannesw> you don't need a mopDisabled lookup if no meta object is defined
[15:02] <lehni> it still needs to walk the chain
[15:02] <lehni> if we want to support that
[15:02] <hannesw> no! why?
[15:02] <lehni> because of what we said earlier
[15:03] <hannesw> that was a misunderstanding then
[15:03] <lehni> if that's not done, it doesn't find meta methods defined in a parent's __meta__ object
[15:03] <lehni> i can give you a little test case
[15:05] <hannesw> well walking the proto chain is not an option imo
[15:05] <lehni> because getProperty is only called when i explicitly ask for obj.__meta__. wen I just access a property on obj, the internal getMetaObject so far did not walk up the chain
[15:05] <lehni> i understand
[15:05] <lehni> i just wanted to see what the impact would be
[15:06] <hannesw> i just checked and it did inherit meta methods from prototype - just not if the property in question was defined in the object itself
[15:07] <lehni> are we talking meta methods or meta object now?
[15:09] <hannesw> does it make a difference?
[15:09] <lehni> yes
[15:10] <hannesw> why?
[15:10] <lehni> http://www.scratchdisk.com/static/metaTest.js
[15:10] <lehni> here a little test
[15:11] <lehni> this only works with my new patch since i change naming and also removed the object parameter from the handler, as this is already the object
[15:11] <lehni> but with inheritance enabled i get:
[15:11] <lehni> set value to 10
[15:11] <lehni> get value
[15:11] <lehni> 10
[15:11] <lehni> set value to 20
[15:11] <lehni> get value
[15:11] <lehni> 20
[15:12] <lehni> as expected
[15:12] <lehni> without it, i just get
[15:12] <lehni> 10
[15:12] <lehni> 20
[15:12] <lehni> if i then set __meta__ on the object itself, it works
[15:13] <lehni> http://www.scratchdisk.com/static/metaobject-new.patch
[15:13] <lehni> here the patch
[15:13] <lehni> hackish...
[15:14] <hannesw> wait
[15:19] <hannesw> *sigh*
[15:20] <lehni> was denn
[15:27] <lehni> weirdly the slowdown does not even come from the chain walking, but from the ThreadLocal stuff
[15:27] <lehni> mostly
[15:27] <lehni> i leave it at that for now
[15:28] <lehni> not sure what to think of it
[15:32] <hannesw> ok, you are right about the prototype thing. but i could have sworn that it worked with metamethods.
[15:32] <hannesw> still have to dig into that
[15:40] <zumbrunn> hannesw, what's the deal with these bugs:
[15:41] <zumbrunn> http://helma.org/bugs/buglist.cgi?target_milestone=1.6.3&bug_status=NEW&bug_status=ASSIGNED
[15:41] <zumbrunn> they currently have a 1.6.3 target milestone
[15:41] <zumbrunn> will they change to 1.7?
[15:59] <hannesw> chris: I'd say they are not likely to be fixed
[19:26] <Helma0> does java have a fast String.replace (no regexp awareness reqd)?

 

 

In the channel now:

Logs by date: