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

2008-05-01:

[5:55] <zumbrunn> dannyp, yt?
[5:56] <zumbrunn> you probably saw my reply regarding axiomstack in the hopbot log that bslivka pointed you to?
[5:58] <zumbrunn> if that isn't enough info, just say so and I'll be glad to fill in more details
[7:04] <bslivka> Hello
[7:56] <zumbrunn> bslivka, pong
[8:24] <zumbrunn> hi zefredz
[8:25] <zumbrunn> it's your first time here, right?
[8:28] <zefredz> hello zumbrunn
[8:28] <zefredz> yes
[8:28] <zumbrunn> just discovered helma?
[8:29] <zefredz> yeah
[8:29] <zumbrunn> :-)
[8:31] <zefredz> I've just finished the addressbook tutorial ;)
[8:42] <zefredz> I have a question
[8:42] <zefredz> Is there a place to put css files in a helma application or do i have to add a static repository to the application ?
[8:45] <zumbrunn> if the css file your want to serve is static, you would put it in an area of the file system for which you define a static mountpoint
[8:45] <zumbrunn> http://helma.zumbrunn.com/intro/staticfiles
[8:45] <zefredz> ok
[8:45] <zumbrunn> if it is dynamic, you could define an action called foo_css_action
[8:47] <zumbrunn> which would become accessible as foo.css on those objects, for which you define it for
[8:48] <zefredz> thanks
[8:48] <zumbrunn> (helma substitutes the period with an underscore)
[8:49] <zumbrunn> you could also define a file called "foo.css.hac" or "foo_css.hac" to get the same result
[8:50] <zumbrunn> and if you do it dynamically, you would need to set the content type appropriately
[8:51] <zumbrunn> http://helma.zumbrunn.com/reference/res.html#res.contenttype
[13:58] <midnightmonster> I assume this-thing.hac would make /this-thing work... is there a way to do it in the function this_thing_action() style?
[13:59] <zumbrunn> yes, it's the same as any other action
[13:59] <midnightmonster> but the dash?
[13:59] <midnightmonster> can't use those in function names
[14:00] <zumbrunn> Root.prototype['this-thing_action'] might work
[14:01] <zumbrunn> Root.prototype['this-thing_action'] = function(){}
[14:01] <midnightmonster> probably
[14:58] <midnightmonster> I'm doing my first non-tutorial rdbms-backed helma app, and it looks like helma (1) doesn't use DB transactions and (2) doesn't necessarily commit inserts in order, potentially (and in my case actually) violating foreign key constraints.
[15:03] <zumbrunn> if you have this in a reproducible form, it's best to file a bug and attach a test app
[15:20] <midnightmonster> :-/ it's definitely reproducible, but it's with the client's proprietary data. so I'll have to come up with something else.
[15:22] <midnightmonster> I imagine 1 isn't a bug so much as a feature request. I found a list message from 2001 talking about maybe supporting transactions--wasn't done yet at the time b/c MySQL didn't do transactions then. MySQL didn't do foreign key constraints until more recently either, so it may be that that wasn't considered as an issue in the design either.
[15:24] <zumbrunn> does that thread mention postgresql?
[15:25] <zumbrunn> I thought to remember that something was actually done about that
[15:25] <zumbrunn> but I might remember wrong
[15:25] <zumbrunn> if the thread you found talked about postgresql then we probably talk about the same thread
[15:38] <midnightmonster> it did, but I didn't read the whole thread
[15:40] <midnightmonster> hm. thread ends with hannes offering to enable db transactions and someone voting for an optional db flag to use transactions with default no
[15:50] <midnightmonster> In https://dev.helma.org/trac/helma/browser/helma/helma/tags/helma_1_6_2/src/helma/objectmodel/db/Transactor.java , it appears that the list of "dirty" nodes (created/updated/deleted) for a Helma transaction if kept in a HashMap, which of course means that the order is not guaranteed when you get the out.
[15:59] <midnightmonster> so it's by design
[15:59] <midnightmonster> or at least, the design that's there could not be hoped to produce any other result
[16:00] <midnightmonster> ?and searching trac for transaction comes up with 24 hits all about helma's internal transactions
[16:37] <midnightmonster> posted to the user list... and with a solution for the insertion order issue, I think
[17:49] <midnightmonster> I have an type representing a product. a typical value for its accessname is half a UPC, that is, some numbers with a dash. but the source data isn't perfect, and sometimes it's just some numbers. as best as I can tell, that means that I can't use mfgProducts.get(halfUPC), because sometimes the value for halfUPC is just a number-as-a-string, which switches HopObject.get()'s behavior
[17:49] <midnightmonster> any way around?
[17:50] <midnightmonster> there'd be the same kind of problem for zipcodes... seems like there ought to be a way to beat this
[17:51] <zumbrunn> mfgProducts.get(String(halfUPC)) ?
[17:51] <zumbrunn> or mfgProducts.get(''+halfUPC)
[17:52] <zumbrunn> in other words, is halfUPC really a string or do you get a number from your source
[17:53] <midnightmonster> it's really a string. which happens to consist of numbers.
[17:53] <midnightmonster> sometimes
[17:54] <midnightmonster> according to the docs, hop.get() does different things depending on if it's given a number, a string, or a string that looks like a number
[17:54] <midnightmonster> and in this case I want the string behavior even when the string looks like a number
[17:54] <zumbrunn> yep, just went to check the docs myself
[17:56] <zumbrunn> hmm
[17:57] <midnightmonster> also, I can't find the source for HopObject in the source
[17:57] <midnightmonster> (like, browsing svn)
[17:59] <zumbrunn> https://dev.helma.org/trac/helma/browser/helma/helma/trunk/src/helma/scripting/rhino/HopObject.java
[18:01] <midnightmonster> thanks. I have learned and forgotten that location several times
[18:02] <zumbrunn> me too
[18:02] <midnightmonster> now the weird thing: there are only two code paths in public Object jsFunction_get(Object id)
[18:02] <midnightmonster> not three
[18:02] <midnightmonster> ah wait...
[18:02] <zumbrunn> the way I read the code, it shouldn't be converting it to a number
[18:02] <zumbrunn> am I reading the code wrong?
[18:04] <zumbrunn> oh, that might be due to rhino's "super smart" auto-conversion
[18:06] <midnightmonster> no... HopObject only has two code paths, and numeric strings won't turn into numbers there. but in the case of a string, it gets passed on to Node.getChildElement, and somewhere in there must be the other fork
[18:09] <zumbrunn> http://grazia.helma.at/pipermail/helma-dev/2003-August/000369.html
[18:11] <midnightmonster> oh--lol. so the documentation is just wrong and has been for 5 years?
[18:12] <zumbrunn> how does it behave, though?
[18:13] <midnightmonster> dunno. gonna test in a secong
[18:13] <zumbrunn> did you actually bump into this problem or did you just notice it in the docs?
[18:13] <midnightmonster> just saw it coming from the documentation. ?but with the context of that message, my gut says the docs are wrong.
[18:24] <midnightmonster> alas, the documentation is *not* wrong
[18:25] <zumbrunn> then Jürg must have been talking about ids that are not numbers
[18:25] <midnightmonster> helma totally barfs on those
[18:25] <midnightmonster> well, it can read them. but try to write one and it goes kablooie
[18:26] <zumbrunn> I guess we need a HopObject.getByName() ?
[18:26] <midnightmonster> hm... but yeah that must be what he meant
[18:27] <midnightmonster> yeah
[18:27] <zumbrunn> because I'm assuming HopObject.get() can't be changed due to backwards compatibility
[18:43] <midnightmonster> ever used helma.Aspects ?
[18:44] <zumbrunn> yes, back when we added it
[18:44] <zumbrunn> but I'm not currently using it in production anywhere
[18:46] <midnightmonster> when it says you need an onCodeUpdate method... does that mean all calls to helma.Aspect.whatever should be in onCodeUpdate or what?
[19:01] <zumbrunn> the problem is that when a code file changes, all the code is recompiled
[19:01] <zumbrunn> so the aspect that was wrapped around a method gets overwritten again
[19:01] <midnightmonster> right. so how does one actually use it?
[19:02] <zumbrunn> I guess if one would use it in the global scope, it works fine
[19:02] <zumbrunn> since that runs every time the code is recompiled
[19:03] <zumbrunn> but if you really add aspects dynamically at runtime
[19:03] <zumbrunn> then you need to take care of "maintaining" those aspects using onCodeUpdate
[19:04] <zumbrunn> meaning onCodeUpdate would need to redo anything that you've dynamically added during runtime
[19:05] <zumbrunn> anything = any aspects
[19:08] <zumbrunn> and with "global" I didn't mean inside the Global directory, but just outside of functions
[19:12] <midnightmonster> so what if I want to add an aspect to a method of every instance of one of my types?
[19:13] <midnightmonster> helma.Aspects.addBefore(this,'methodName',myfun) ?
[19:14] <midnightmonster> in the js somewhere (not in a function) for that type?
[19:14] <zumbrunn> yes
[19:15] <zumbrunn> hmm, is that true?
[19:15] <zumbrunn> is "this" the prototype object?
[19:15] <zumbrunn> not sure
[19:16] <midnightmonster> not sure either
[19:17] <zumbrunn> otherwise helma.Aspects.addBefore(Foo.prototype,'methodName',myfun)
[19:42] <midnightmonster> unrelated to that, I'm getting:
[19:42] <midnightmonster> Wrapped java.lang.RuntimeException: An object named "00034-6" is already contained in the collection
[19:43] <midnightmonster> and it's true there are two, but my code looks like this:
[19:43] <midnightmonster> if(!(p = u.get(line['Item UPC']))) {
[19:43] <midnightmonster> p = new Product(u,line['Item UPC']);
[19:43] <midnightmonster> u.add(p);
[19:43] <midnightmonster> }
[19:45] <midnightmonster> so I don't understand how the second time it gets by the ?f(!(p = u.get(line['Item UPC'])))
[20:21] <midnightmonster> I'm getting bogus SQL logged in the console that looks like this: [2008/05/01 16:21:33] [INFO] SQL SELECT_BYRELATION PRODUCTS 1: SELECT PRODUCTS.* FROM PRODUCTS WHERE PRODUCTS.PRODUPC = 'org.mozilla.javascript.Arguments@1c46bab' AND PRODUCTS.UPCID = 21
[20:43] <midnightmonster> the documentation for helma.Aspects.addBefore needs all the information from the docs for addAfter about what kind of parameters it receives
[20:45] <midnightmonster> that being missing and me reversing my logic in one place collectively have kept me busy for the last hour and a half
[20:59] <midnightmonster> and.... I'm now not sure about my original statement that the docs were right. I mistook the meaning of a result I was getting
[21:05] <midnightmonster> dang. I am racking up huge, huge idiot points today
[21:06] <midnightmonster> documentation of HopObject.get() is incorrect. if there's an accessname set on the collection, strings are always matched against the accessname, even if they are numeric

 

 

In the channel now:

Logs by date: