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

2007-11-06:

[1:38] <BSlivka_> Weird, a bunch of the helma.File methods keep failing to work, returning false.
[1:38] <BSlivka_> but error() returns nothing to enlighten me as to what's going on.
[3:34] <BSlivka_> hrmn this is odd http://helma.pastebin.com/m66f1a2ac
[3:35] <BSlivka_> If the file doesn't exist, it creates a new java "FileWriter"
[3:35] <BSlivka_> but if it does exist already, it creates a new FileReader
[3:36] <BSlivka_> so in essense, with helma.File, you can't add to a file which already exists
[3:36] <BSlivka_> you have to delete it and rewrite it every time.
[3:37] <BSlivka_> readAll is a bit funny too. It only works if the file is not opened.
[3:39] <BSlivka_> Doesn't seem quite right to me.
[6:42] <zumbrunn> BSlivka_, helma.File was implemented to be backwards compatible with the old built-in File object, including any of its strange behaviors
[6:43] <zumbrunn> which doesn't mean that it couldn't be evolved from here
[6:43] <BSlivka_> So I presume that these are known issues?
[6:44] <zumbrunn> http://helma.zumbrunn.net/hopbot/2007-07-18
[6:47] <zumbrunn> I believe I talked to tobi about this afterwards (he wrote helma.File)
[6:47] <zumbrunn> it is a known issue
[6:48] <zumbrunn> and he thinks also that helma.File should be improved
[6:48] <zumbrunn> he just intentionally mirrored the old File object behavior back then as a first step
[6:50] <BSlivka_> Fair enough. What do you think is the best way forward? Add new functions?
[6:50] <BSlivka_> with correct behavior
[6:50] <BSlivka_> depreciate the existing ones with faulty behavior?
[6:51] <zumbrunn> not sure...
[6:51] <zumbrunn> depending on how the behavior changes, we might be able to get away with just changing existing ones
[6:51] <zumbrunn> it would just need to be proposed on helma-user
[6:52] <zumbrunn> if there are no objections, we could co forward and commit the changes
[6:52] <zumbrunn> go forward
[6:52] <BSlivka_> the problem is that if the file exists, it is not writable.
[6:52] <BSlivka_> what if there was another function along the lines of file.makewritable()
[6:53] <BSlivka_> if there are any existing applications that depend on the read only behavior that would save them..
[6:53] <BSlivka_> But it depends on if there are any existing applications that depend on that.
[6:53] <zumbrunn> the write method could internally check and work around that
[6:54] <zumbrunn> but, yes, that could break old apps
[6:54] <zumbrunn> again, that's still possible, if it has been discussed on helma-user first
[6:55] <BSlivka_> Okay I'm going to have to get into helma-user since this is the second strange helma behavior I've encountered
[6:56] <BSlivka_> *gets serious*
[6:56] <zumbrunn> :-)
[6:56] <BSlivka_> The other one of course, being a strange way that helma interacts with ID's in the database.
[6:57] <BSlivka_> Helma seems to require ID's to be integers for writing, but not for reading.
[7:13] <BSlivka_> Okay now, the big one. How shall I diagnose a java.lang.stackoverflow error
[7:14] <zumbrunn> the rhino debugger doesn't help?
[7:14] <zumbrunn> do you get a stack trace in the log file?
[7:15] <zumbrunn> does it always happen at a specific point in the app?
[7:16] <zumbrunn> (or just after the app has been running for some time)
[7:22] <BSlivka_> Its ah... Okay this is going to sound stupid
[7:23] <BSlivka_> I don't know what the rhino debugger is.
[7:23] <zumbrunn> http://helma.zumbrunn.net/tools/debugger
[7:23] <BSlivka_> the stack overflow happens when I call a specific function from within the shell
[7:23] <BSlivka_> and as such probably happens within the program
[7:25] <zumbrunn> do you have any loops within that function?
[7:25] <zumbrunn> you probably have an endless loop somewhere
[7:25] <BSlivka_> yep
[7:26] <BSlivka_> hrmn yeah.
[7:26] <BSlivka_> tricky to diagnose, since it also calls functions that themselves have loops
[7:26] <BSlivka_> nah it's probably not the main loop here since it's a for in
[7:27] <BSlivka_> but maybe in one of the other functions it calls..
[7:31] <BSlivka_> hrmn stack trace blames this line
[7:31] <BSlivka_> this.search = this.ctx.search(
[7:31] <BSlivka_> where ctx is actually an LDAP context
[7:32] <BSlivka_> a javascript object
[7:32] <zumbrunn> so, a rhino regex bug?
[7:32] <BSlivka_> err rather, a JAVA object
[7:32] <BSlivka_> ahem
[7:32] <zumbrunn> aha
[7:32] <BSlivka_> so ctx.search is calling a JAVA function
[7:32] <zumbrunn> ok, not rhino's fault then
[7:34] <zumbrunn> maybe you need to allocate more memory
[7:34] <BSlivka_> Perhaps. Is that done in app.properties?
[7:35] <BSlivka_> Maybe I just need to optimise the thing so it uses less memory to begin with!
[7:35] <BSlivka_> hrmn
[7:36] <BSlivka_> Oh, I think I know what I did wrong here...
[7:36] <BSlivka_> just a guess, but it might have something to do with the way I set it up to connect to the LDAP server.
[7:37] <BSlivka_> if it fails, the function calls itself to try again
[7:37] <BSlivka_> or something along those lines
[7:37] <BSlivka_> so when there's some networking problem, the stack would suddenly get huge
[7:38] <BSlivka_> *slaps self*
[7:48] <zumbrunn> aha, so it's a good old fashion loop after all
[7:48] <zumbrunn> regarding the memory settings.... just for the record...
[7:48] <zumbrunn> you would usually do that in start.sh by setting the JAVA_OPTIONS
[7:49] <zumbrunn> Xms and Xmx
[7:49] <zumbrunn> http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html
[7:49] <zumbrunn> for example:
[7:49] <zumbrunn> JAVA_OPTIONS=-server -Xms64m -Xmx128m
[7:51] <BSlivka_> ah thanks
[19:30] <peter_12> #trac
[22:22] <BSlivka_> Related to yesterday's conversation
[22:23] <BSlivka_> is there anything like a wait instruction, or a settimeout that would let me kind of put a delay between reconnect attempts?
[23:08] <BSlivka_> And I suppose a different question, which I haven't been able to verify. Do the javascript try/catch statements catch errors thrown by java classes?
[23:09] <BSlivka_> I'm guessing they do, but I don't have any proper evidence

 

 

In the channel now:

Logs by date: