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

2007-07-12:

[1:36] <midnightmonster> total helma n00b here. trying to instantiate Java classes from JARs. I've gotten built-in Java classes (e.g., Date) to work, but not any from other JARs. can someone point me to or fill me in on the basics?
[6:49] <zumbrunn_> hi midnightmonster
[6:49] <zumbrunn_> it's working for me
[6:49] <zumbrunn_> not sure what you are doing differently
[6:50] <zumbrunn_> any particular jar you are attempting this with?
[6:51] <zumbrunn_> jackrabbit? (I saw the mailing list posting that asks about this in regard to jackrabbit)
[6:54] <zumbrunn_> is the class you are attempting to instantiate public or private?
[6:54] <zumbrunn_> are you doing this with a Helma 1.5.x or a Helma 1.6.x build?
[8:05] <zumbrunn_> regarding jackrabbit:
[8:05] <zumbrunn_> http://grazia.helma.at/pipermail/helma-user/2007-July/007075.html
[10:42] <midnightmonster> 1.6 rc3
[10:44] <midnightmonster> I'll see what I can do with the mailing list message (a bit later) and let you all know how it goes.
[18:53] <midnightmonster> is there a way to know if app.addRepository() worked? I seem to be able to call it with arbitrary string arguments without generating an error
[18:54] <zumbrunn> I never tried it with arbitrary string arguments ;-)
[18:55] <midnightmonster> I was looking for an error message b/c I was trying to figure out what path it worked relative to
[18:55] <zumbrunn> of course, you should be able to check whether the expected objects are there after you call it
[18:56] <zumbrunn> I'm not sure why it doesn't cause an error
[18:56] <midnightmonster> right--that makes sense. if I use a relative path, where does it work from?
[18:56] <zumbrunn> the helma home directory
[18:57] <zumbrunn> modules/core/String.js for example
[18:57] <midnightmonster> ok. I saw in the provided modules that was what it was doing, but didn't know if it made a difference if it were called from files inside my app directory instead
[18:58] <zumbrunn> nope, shouldn't make a difference
[18:58] <midnightmonster> the sample jackrabbit code stefan provided on the list... think it would make most sense for that to run onStart with my app?
[18:59] <zumbrunn> yes, I think that would be the right place
[18:59] <zumbrunn> unless you only need it under certain circumstances...
[19:00] <midnightmonster> nope--I should need it for everything
[19:00] <zumbrunn> then it might make more sense to check at that point whether you already have a connection in place and otherwise create one
[19:01] <zumbrunn> but if you use the class.properties approach, you'll most likely want it to always be there
[19:01] <zumbrunn> so, onStart is what I would go for
[19:06] <midnightmonster> (filed my first bug report--about addRepository not indicating failure)
[19:07] <zumbrunn> :-)
[19:11] <midnightmonster> if I want to make my session available to the rest of my application, where should I store a reference to it?
[19:11] <midnightmonster> (jackrabbit session)
[19:11] <midnightmonster> there seem to be at least three such places besides just a global var
[19:12] <zumbrunn> if you do it with a global var you need to use defineLibraryScope
[19:13] <zumbrunn> app.data.jackrabbitsession ?
[19:14] <midnightmonster> ok, sounds reasonable
[19:14] <midnightmonster> but re definelibraryscope, per your email it doesn't seem like that would be necessary if I'm doing it onstart?
[19:14] <zumbrunn> right
[19:15] <midnightmonster> ok. but globals suck, so app.data it is
[19:28] <zumbrunn> (actually, code inside of onStart isn't in "the global code", but it should be treated as a special case and still not require the defineLibraryScope call)
[19:28] <zumbrunn> "global code" is probably not the right term for what I was trying to describe
[19:29] <midnightmonster> (well, right--but I would define the global outside the function, because to do otherwise is Wrong)
[19:30] <zumbrunn> right :-)
[19:35] <midnightmonster> (I'm fairly competent with JavaScript--it's only Java and Helma that I'm still an idiot about. I just don't think I can take anymore PHP, so I'm going through the pain of switching to Helma so I can write in a language with some *gasp* expressive power and get access to all the work that much more patient people than I have already done implementing practically anything anyone could want in Java.)
[19:36] <zumbrunn> I hope others will join that club :-)
[19:37] <midnightmonster> I did a little toy algorithmic-type thing recently... <http://codekata.pragprog.com/2007/01/kata_six_anagra.html>
[19:38] <midnightmonster> using the sample ~400kB data file, I wrote a PHP script and a JavaScript via Helma to solve it
[19:38] <midnightmonster> same algorithm in both (and almost the same as the smalltalk one listed in the comments, but slightly better)
[19:39] <midnightmonster> on the plus side, the JavaScript one required only about 60% the lines of the PHP
[19:39] <midnightmonster> on the downside, on my machine, the PHP ran in ~0.93 sec and the JavaScript in ~3.16
[19:42] <zumbrunn> I have no PHP background myself... so tips on how to make Helma easier to grasp for people that come from PHP will be very much appreciated
[19:43] <zumbrunn> Maks is starting to write stuff for people that come from the Java side...
[19:44] <zumbrunn> http://manichord.com/blog/2007/07/simplicity-aka-makss-guide-to.html
[19:44] <midnightmonster> I will certainly be working on helping folks make that transition. soon as I get my helma and jackrabbit powered blog running :-)
[19:45] <zumbrunn> just don't forget where you got stuck along the way
[19:46] <zumbrunn> you can't repeat that experience afterwards :-)
[19:48] <midnightmonster> there's basically nothing at all in common between the essential models of PHP and Helma. PHP works just like basic CGI scripts--you can usually switch between the cgi interface of php and the apache module with no code changes, because nothing is maintained between requests and there is no framework at all--you just get some variables populated with the request parameters
[19:49] <midnightmonster> (on the performance of the anagram scripts, IO seems to be tremendously slower in JavaScript. Reading especially--I assume b/c it has to get read line by line in Java and then get converted into JavaScript's double-byte characters, whereas PHP can memory map the file right into a string in one go. writing to output is slower in JavaScript but not as bad.)
[19:51] <zumbrunn> you could post the code you used to load the file on the mailing list and ask whether there is a faster way to do this
[19:55] <midnightmonster> will do
[19:57] <midnightmonster> (one problem was getting helma apps serving through virtual hosting on apache 2.2. It turns out to be beautifully powerful and easy, but the helma docs don't cover it. I found the clues digging around the jetty docs.)
[20:04] <zumbrunn> do you remember what exactly you got stuck on?
[20:04] <zumbrunn> (which bit did you need the jetty docs for?)
[20:05] <midnightmonster> apache 2.2 has a new proxy module which supersedes the one documented on helma.org
[20:05] <midnightmonster> (it's better, too)
[20:06] <midnightmonster> my apache-foo is strong, but only for things I've had to do to this point, and until recently I had never needed to do anything with proxies, so I didn't know that
[20:07] <zumbrunn> what are you using now? mod_jk and mod_proxy?
[20:08] <zumbrunn> and the problem was that the docs were for mod_jk and mod_rewrite?
[20:08] <midnightmonster> you don't even need mod_jk
[20:08] <zumbrunn> yes, sorry...
[20:08] <zumbrunn> mod_proxy instead of mod_jk and mod_rewrite
[20:09] <midnightmonster> right. and i was simply unaware of the existence and adequacy to the task of mod_proxy. and it came as a huge relief, b/c installing mod_jk is a huge pain
[20:10] <midnightmonster> (at least according to all tutorials about it I found--I never got through it. something in my "there has to be a better way" sense clicked and I looked around)
[20:12] <midnightmonster> e.g., this is really nice:
[20:12] <midnightmonster> <VirtualHost 192.168.1.11>
[20:12] <midnightmonster> ServerName manage.papercrown.test
[20:12] <midnightmonster> ServerAdmin joshua@papercrown.test
[20:12] <midnightmonster> ProxyPass / ajp://localhost:8009/manage/
[20:12] <midnightmonster> </VirtualHost>
[20:12] <zumbrunn> I think the problem is that the mod_jk instructions are for apache 1.x, not 2.x
[20:13] <midnightmonster> I found some for 2.0, I think... mod_proxy isn't fully supported until 2.2
[20:13] <zumbrunn> but those for probably for mod_jk2
[20:13] <zumbrunn> (and that project died)
[20:14] <zumbrunn> anyway... thanks for pointing that out!
[20:14] <midnightmonster> yeah, something like that. anyway, it looked bleak. so I was glad to find mod_proxy
[20:14] <zumbrunn> we need docs for the mod_proxy setup
[20:15] <midnightmonster> how do I get a login on the wiki? I could possibly write it up myself
[20:16] <zumbrunn> http://helma.org/pipermail/helma-user/2004-March/005689.html
[20:16] <zumbrunn> you should be able to just register
[20:16] <zumbrunn> doesn't work?
[20:17] <zumbrunn> click login and then "Register new User"
[20:18] <midnightmonster> yup--worked fine
[20:18] <zumbrunn> a separate register link would probably be a good idea
[20:19] <midnightmonster> additionally b/c the login link is non-obvious. people who use it know where it is, of course, but it's out of the way
[20:40] <midnightmonster> mysteriously, my helma anagrams code is running in ~2.85 sec today
[20:40] <midnightmonster> (about 10% better than initially)
[20:50] <midnightmonster> btw, this is how you'd do hannes' config to skip proxying of static files:
[20:51] <midnightmonster> ProxyRequests Off
[20:51] <midnightmonster> ProxyPass /foo/static !
[20:51] <midnightmonster> ProxyPass /foo http://localhost:8080/foo
[20:51] <midnightmonster> ProxyPassReverse /foo http://localhost:8080/foo
[20:52] <midnightmonster> though that may not have been available in 2004
[20:55] <midnightmonster> also, (I just noticed the difference) in 2004 you had to go over http. ajp is now an option in Apache 2.2

 

 

In the channel now:

Logs by date: