Hopbot log for 2009-04-28 - Helma IRC channel: #helma on irc.freenode.net

2009-04-28:

[8:08] <simono> hi hannesw, i was wondering if you had time to look into the genericrefs issue?
[8:09] <hannesw> simono: yes, will do it today!
[8:18] <simono> ok, s?nks
[13:27] <hannesw> simono: generic refs on transient objects should be working now.
[14:42] <hannesw> simono: can you post the code you have in the root main action of the generic ref demo app?
[14:42] <hannesw> you're using another code path than me, so I want to make sure it works now
[14:45] <simono> sure, one moment
[14:46] <hannesw> the question is only, do you also set the reference in the child?
[14:47] <simono> okay, i modified the demo.. so can't easily send you the action only
[14:47] <simono> do you mean i should set the parent in the child?
[14:47] <simono> i don't do that
[14:48] <hannesw> ok... can you still post the action code?
[14:48] <hannesw> ?
[14:48] <simono> http://helma.pastebin.com/m1b784988
[14:49] <simono> i added an audio reference to the image-prototype, just to check if normal refs work
[14:49] <simono> line 22 i just added, doesn't make a difference
[14:49] <simono> it works for you?
[15:11] <hannesw> simono: the fix for transient hopobjects itself is trivial. The trickier part is to transfer the node structure into a persistent structure.
[15:12] <hannesw> but I think i just fixed it now.
[15:12] <hannesw> can you check?
[15:13] <simono> yes, updating..
[15:15] <simono> hannesw, looks good. works for me with demo app... trying with our bigapp
[15:16] <hannesw> ok. are you persisting the objects later on or are they just transient?
[15:18] <simono> i'm persisting them later on
[15:18] <simono> i'll try if this fixes the problem in big-app, where a lot more goes on.. this can take a while, i'll have to remove workarounds
[15:19] <simono> @your explanation: Node is a big file, i don't understand half of what goes on in there - in time :)
[15:23] <hannesw> it should work now. the only caveat is that you probably have to also set the reverse reference
[15:23] <hannesw> i.e. parent.add(child); child.parent = parent;
[15:24] <simono> no, same error. i'm setting child.parent before parent.add (tried other way round, doesn't make diff)
[15:25] <simono> i'll get robert to check if he sees smth wrong with my code / type.properties
[15:29] <hannesw> simono: can you post the stack trace again?
[15:32] <simono> hu, ugly trace.. http://helma.pastebin.com/m19ef345d
[15:32] <simono> hold on, it's because i catch it... i'll post again
[15:33] <simono> thats better: http://helma.pastebin.com/m492a7b40 (updated)
[15:34] <simono> differences i see between demo app and v2: in v2 the two objects are in parent-child relation. that's not the case in demoapp
[15:38] <hannesw> what does the subnode mapping look like in the collection you add to?
[15:39] <simono> like so http://helma.pastebin.com/m6b2f161c
[15:40] <simono> problem with the filter?
[15:42] <hannesw> hm, but the children definition is not generic?
[15:42] <hannesw> shouldn't it have a constraint for the prototype?
[15:42] <hannesw> ah, i see, you have it in the filter...
[15:42] <simono> yes
[15:43] <simono> i'll try with local/foreign instead of filter
[15:43] <hannesw> yes, that should work.
[15:43] <hannesw> however, i want this code to work too...
[15:44] <hannesw> have to think some more about it
[15:44] <simono> that did it
[15:45] <simono> nice :) thanks... if it works otherway as well, even better
[15:45] <hannesw> it's just a matter of how audacious a change I'm going to make...
[15:46] <simono> keep it simple, you can always update the docs to fit the bugs :)
[17:42] <liamMT_> hannesw: don't suppose there's any chance you had a moment to look at that relative module loading issue?
[17:59] <hannesw> liamMT_: yes, i can look at it
[18:01] <liamMT_> that would be great - I'm pretty sure RhinoEngine.findResource() is not working quite right in the case where it checks: else if (localRoot != null && path.startsWith("."))
[18:01] <liamMT_> the way it creates the path to be passed back into the same method won't resolve quite right
[18:02] <liamMT_> but I'm not sure where the best spot to make changes would be, not being more familiar with the code :)
[18:03] <hannesw> one question: do you run the script that calls require('../x') as command line script?
[18:04] <hannesw> because that would explain it.
[18:07] <hannesw> because the parent directory of the command line script is added as first module root implicitly, so importing '../anything' will currently cause a nullpointer exception
[18:09] <hannesw> liamMT_, are you still there?
[18:09] <liamMT_> no - I'm doing that from within a module that gets loaded in normal use
[18:10] <liamMT_> so I run java -jar run.jar ../path/to/my/tests/all.js and from within there I load a test module which then tries to include('../anothermodule')
[18:11] <hannesw> ok - where is that test module? anything below ../path/to/my/tests/ will throw a nullpointer exception
[18:12] <liamMT_> in that path it would be in the 'my' directory. in 'tests' I have all.js and test_mymodule.js - all.js is getting run as main, loads test_mymodule which tries to load ../mymodule in the directory above
[18:13] <hannesw> ok, that currently just won't work.
[18:13] <liamMT_> by design?
[18:13] <hannesw> you can't go beneath your main script file
[18:13] <hannesw> yes, although the nullpointer exception is not by design
[18:14] <hannesw> it's a consequence of two choices:
[18:14] <liamMT_> hm - so I'm confused. 'mymodule' is above all.js - I don't think I'm accessing anything beneath it
[18:14] <hannesw> 1) adding the main script directory as module root implicitly
[18:14] <liamMT_> unless we're confused on our definitions of above and beneath :)
[18:15] <hannesw> 2) preventing modules to be loaded from beneath the repository roots
[18:15] <hannesw> yes, not sure what to call it. is the shorter path upwards or downwards?
[18:15] <liamMT_> shorter path is upwards for me
[18:16] <hannesw> ok
[18:16] <hannesw> so yes, this is kind of by design, although the nullpointer exception is not really what it should be
[18:17] <liamMT_> I see - so that error should really be something like 'tried to load module from out of app scope' or something
[18:18] <liamMT_> so in that case, what would be my best option for this kind of operation? have a test runner at the top level of my module so the app root is placed at that level?
[18:19] <hannesw> yes, that's what i would suggest
[18:19] <liamMT_> ok - I can live with that :)
[18:19] <hannesw> of course, we could change one of the two choices i listed above
[18:20] <hannesw> but i actually think they're good ones.
[18:20] <hannesw> ok, sorry it took me so long to understand.,
[18:20] <liamMT_> yeah - I think they're ok too. plus this kind of use is more the exception than the rule - running a test suite, as opposed to running an app, which will almost always have its main.js at the top level
[18:20] <liamMT_> np :)
[18:21] <liamMT_> I have one other question about module loading, though - can cyclic references be resolved?
[18:21] <liamMT_> if 2 modules try to load each other?
[18:22] <hannesw> yes, unless both modules try to make use of the other one immediately (i.e. in top evaluation scope)
[18:22] <liamMT_> I just remember that issue I came across where I couldn't load the logging module before the system module
[18:23] <hannesw> if one module uses the other in its top scope, then it will only work if that module is loaded first.
[18:23] <liamMT_> ah, and what happens in that case? explosions?
[18:23] <hannesw> unless the other module loads the first one after it has provided what the other one needs...
[18:23] <hannesw> complicated stuff :-)
[18:23] <hannesw> nope, the stuff expected to be there will just not be there.
[18:24] <liamMT_> heh - ok
[18:24] <liamMT_> well I'll leave that one until it bites me again :)
[18:24] <hannesw> i used to have a cyclic dependency between helma/logging and helma/system, and occasionally it blew up, so i just removed one of the dependencies.
[18:25] <liamMT_> gotchya

 

 

In the channel now:

Logs by date: