2008-06-25:
[2:05] <groovah> anyone know the default password for a fresh install of antville?[3:14] <midnightmonster> finally read the article you linked earlier, zumbrunn. nice little article, and he actually articulates the Helma difference really well[3:14] <midnightmonster> (in his follow-up comment)[18:15] <decke> has anyone plans for an Helma IDE?[18:19] <zumbrunn> it has come up several times[18:19] <zumbrunn> of course, there is interest[18:19] <zumbrunn> but nobody has actually takled it, I believe[18:20] <zumbrunn> hannes once wrote a plug-in for jedit[18:22] <decke> because i Eclipse Dynamic Language Toolkit which is yet another eclipse project[18:22] <decke> +discovered[18:22] <zumbrunn> decke, what would you want the IDE to do[18:22] <zumbrunn> (that is helma specific) ?[18:23] <decke> that is exactly my question...[18:23] <decke> because actually JSEclipse is unsupported afaik[18:23] <zumbrunn> one obvious bit is code completion for the various helma host objects and methods[18:24] <decke> that would be one part of cause[18:24] <decke> but i don't want to start such a project... i think that would need to much time that i don't have at the moment[18:25] <decke> but the eclipse framework DLTK seems to actually work on an JS ide[18:25] <decke> that would be a very good starting point for an helma ide[18:26] <zumbrunn> ok, never looked at that yet[18:26] <zumbrunn> I think integrating helma specific functionality into firebug would yield more interesting possibilities than the editor side of things[18:26] <decke> i don't know firebug...[18:26] <zumbrunn> the firebug plug-in for firefox[18:27] <zumbrunn> http://getfirebug.com/[18:27] <decke> interesting idea... but is that useable too?[18:28] <zumbrunn> sure, why not?[18:29] <zumbrunn> it would be more a debugger and shell[18:29] <zumbrunn> less an editor[18:29] <decke> okay then it's not what i expect from an IDE[18:30] <zumbrunn> but even editing ca[pabilities would be possible with a matching framework on the server-side[18:31] <decke> the code completion, highlighting and editing part should not be a real problem when i see the DLTK examples...[18:31] <decke> they documented it very well.. http://wiki.eclipse.org/A_guide_to_building_a_DLTK-based_language_IDE[18:32] <decke> and as i said there is an JavaScript IDE plugin on top of DLTK that just needs a few patches and should do very well for helma[18:32] <decke> but the debugging stuff could be a bit more complicated[18:32] <zumbrunn> yes, on the server-side, a good helma IDE would probably need to sit in-between rhino and the rhino debugger[18:33] <decke> there is a rhino debugger?[18:33] <zumbrunn> if I remember correctly, there is work being done on rhino to make exactly that kind of thing easier to implement[18:33] <zumbrunn> yes, sure[18:34] <zumbrunn> http://helma.zumbrunn.com/tools/debugger is what I mean[18:34] <decke> oh cute... i never knew about that one[18:36] <decke> how is that launched?[18:36] <decke> is that a java applet?[18:38] <zumbrunn> yeah, it only works locally, not when developing on a remote server[18:40] <decke> that could be solved with X11 forwarding[18:40] <decke> or an port forwarding if the debugger connects to an socket[18:41] <zumbrunn> I don't know how it works internally[18:43] <decke> so if someone steps up and want's to work on an Helma IDE there are quite a few interesting things to learn...[18:48] <decke> with the helma port for freebsd i stumbled across a few problems...[18:49] <decke> the bigest one was the dependency on jetty 5.x that is outdated and there is only jetty 6.x in the freebsd ports[18:49] <zumbrunn> hmm[18:49] <zumbrunn> does it make sense to pick things apart like this?[18:50] <zumbrunn> should the bits that are part of the helma repository come from there[18:50] <zumbrunn> instead of other ports?[18:50] <decke> i only tried to build helma like every other port in FreeBSD - by source[18:50] <decke> and with the ant buildscript[18:50] <decke> but there is no jetty.jar in the source because its an external dependency[18:51] <zumbrunn> huh?[18:51] <zumbrunn> checking...[18:51] <decke> the jetty.jar is only in the precompiled helma zips[18:52] <zumbrunn> that's not what I see[18:53] <zumbrunn> https://dev.helma.org/trac/helma/browser/helma/helma/trunk/lib[18:53] <decke> take a look at the helma-1.6.2-src.tar.gz[18:53] <decke> there is only apache-dom.jar and jimi.jar in the "lib" directory[18:54] <decke> you are right in the helma-1.6.2.tar.gz there is everything you need - the jetty.jar and all the others[18:55] <decke> that is where i stopped and i am not sure how to proceed... taking the source and all dependencies and compile it myself is the FreeBSD way[18:55] * zumbrunn thinks that's a mistake[18:55] <decke> taking the precompiled package and just unpack and move the files where they belong to is much easier but that's not the BSD way[18:56] <zumbrunn> of course[18:58] <zumbrunn> just tried... and like I thought, helma-1.6.2-src.tar.gz doesn't build since the jars are missing[18:59] <decke> yes exactly what i stumbled across too[19:00] <decke> and the problem is now how to interpret the situation...[19:00] <decke> if the missing jars are some kind of "external dependencies"[19:00] <decke> then helma should be comfortable with nearly whatever version of them is out there[19:01] <zumbrunn> the src packages for the 1.6.2 release are borked, that's the situation[19:01] <decke> but with an jetty 5.x dependency that is very hard to follow from the freebsd ports situation[19:01] <zumbrunn> and nobody noticed/tested until now[19:02] <decke> that would be my preferred solution ;o)[19:02] <zumbrunn> I'm guilty of only having tested helma-1.6.2.tar.gz myself[19:02] <zumbrunn> didn't test the src one[19:03] <decke> so helma does not have any external dependencies on any library?[19:03] <decke> or "should have"[19:03] <decke> rhino might be such a candidate...[19:04] <zumbrunn> yes it does have subversion dependencies, but they would be resolved when checking out from subversion[19:04] <zumbrunn> and they are for the modules, helmatools, jala etc[19:04] <zumbrunn> nothing with the jars[19:05] <zumbrunn> the src.tar.gz file I guess wouldn't have any dependencies at all anymore[19:05] <zumbrunn> (which is also one reason why it doesn't make for a very interesting freebsd port)[19:06] <zumbrunn> (since the install location doesn't matter and there are no dependencies)[19:07] <zumbrunn> the only interesting bit where the port could integrate helma better with freebsd is in connection with init.d, maybe[19:07] <decke> that's for sure but it would better integrate into the SystemV startup scripts[19:08] <zumbrunn> is that new in 7?[19:08] <decke> you mean rc.d?[19:08] <zumbrunn> yes[19:09] <decke> no that's at least since FreeBSD 4.x[19:09] <zumbrunn> hmm, haven't stumbled across that[19:10] <decke> erm... there is no init.d - never been[19:10] <decke> they use rc.d and if i remember correctly that's called System V ....[19:11] <decke> you know that for sure... everytime you look into /etc/rc.conf and /etc/rc.d/ or /usr/local/etc/rc.d/[19:12] <zumbrunn> I meant inetd[19:13] <decke> isn't inetd outdated? nowadays everything runs as a daemon by itself[19:14] <zumbrunn> quite possible, it wasn't (at least not completely) with freebsd 6[19:20] <decke> okay then i build an fixed helma-1.6.2-src.tar.gz by myself to complete the port and wait for 1.6.3 until the packages are fixed then[19:21] <decke> should i file a bug for that too?[19:22] <zumbrunn> it doesn't hurt, of course[19:22] <zumbrunn> you don't need to, though[19:22] <zumbrunn> I'll talk to hannes about it and see what we want to do[19:22] <midnightmonster> *catching up* we definitely wouldn't want to be integrated with inetd--antithetical to the way helma runs[19:22] <zumbrunn> maybe we just fix the 1.6.2-src packages[19:23] <decke> okay then i don't file one... i won't forget though[19:23] <midnightmonster> and for IDE, Aptana's JS editor seems better than the JSEclipse one[19:23] <midnightmonster> but it doesn't yet have full language support--nothing free/open source does.[19:24] <decke> yeah but aptana is bloated and i don't know what the future will be....[19:24] <midnightmonster> in what sense is it bloated that Eclipse in general isn't?[19:24] <zumbrunn> plus aptana is now gpl[19:24] <midnightmonster> and it's open source[19:24] * zumbrunn doesn't like the gpl[19:25] <decke> i will have a closer look at the Eclipse DLTK JavaScript IDE[19:25] <midnightmonster> but we're only talking about tools, here. it doesn't become part of your app, so it hardly matters whether it's GPL or BSD or what[19:25] <zumbrunn> sure, still, I just don't like it :-)[19:25] <decke> that sounds quite interesting but it's very new[19:26] <decke> sure they are all just "tools"[19:26] <decke> KDE is also an tool - one which i hate of course[19:26] <midnightmonster> AFAIK, Steve Yegge's JS2 emacs mode has the best language support for JS in the free world.[19:27] <midnightmonster> (KDE is the whole friggin desktop and gui kit, and it's always been ugly as sin)[19:27] <decke> and GNOME is bloated as hell - that's why i am an Xfce user[19:28] <midnightmonster> *Still trying to fathom how you find eclipse acceptable*[19:28] <midnightmonster> (I find it acceptable, but I'm content to use gnome)[19:28] <decke> that's a compromise... you can't win all the time...[19:29] <decke> but that is why i use Eclipse with JSEclipse and not aptana[19:29] <decke> that helps a lot[19:29] <midnightmonster> your experience doesn't match mine at all. aptana for me is no slower than Eclipse in general[19:30] <decke> nowadays that does not matter that much ... but until about 6 months ago i worked on an VIA EPIA 1Ghz[19:30] <midnightmonster> (and last time I tried jseclipse, it just didn't work well--hardly an advantage to run badly faster)[19:30] <decke> there you really have to be carefully with what app you use[19:30] <midnightmonster> I bet. I can't imagine how you lived with eclipse[19:30] <midnightmonster> I'd have had to learn emacs[19:30] <zumbrunn> specially the js editor in aptana is slower than jseclipse, not aptana in general as much[19:30] <decke> exactly...[19:31] <midnightmonster> (which I sure wish I could get around to doing)[19:31] <decke> and the aptana complection code is slow as hell[19:31] <zumbrunn> yep[19:31] <midnightmonster> hm. I guess I'll have to try jseclipse again[19:31] <decke> and it does some very intensive things at startup that locks up eclipse for quite a few seconds[19:32] <midnightmonster> (after all the seconds you spend "loading workbench" :-)[19:32] <decke> the sad thing about jseclipse is that it has been aquired by Adobe[19:32] <midnightmonster> interesting![19:32] <midnightmonster> hadn't heard about that[19:33] <decke> and they do their best to make it stink like all their other products[19:33] <midnightmonster> adobe: where good apps go to die[19:33] <zumbrunn> yeah, it hasn't really evolved since then[19:33] <zumbrunn> decke, are you saying they made it worse?[19:33] <midnightmonster> just brought up the site... "Update: JSEclipse prerelease 2 released on April 2, 2007"[19:33] <midnightmonster> jeeze[19:34] <decke> no because they simply haven't updated it since then[19:34] <decke> but i have seen a newer version number somewhere[19:34] <zumbrunn> they didn't really do anything to it[19:34] <decke> just could not download it or something like that[19:34] <zumbrunn> right, ok[19:35] <decke> http://labs.adobe.com/technologies/jseclipse/[19:35] <decke> you have to have an adobe account for downloading... which i have created if i remember correctly[19:36] <decke> but something was totally wrong with that[19:36] <decke> if someone wants to try it i can provide the the plugin[19:37] <midnightmonster> I have an adobe account[19:37] <midnightmonster> (and I <3 FIOS)[19:37] <decke> that's really strange...[19:38] <midnightmonster> (FIOS = brand name of fiber-optic broadband service in the US)[19:38] <decke> they have an installation notes file for JSEclipse that requires me to donwload Flash[19:38] <decke> are they kind of totally stupid ?[19:38] <zumbrunn> hehe[19:39] <decke> i am not sure if i want to try that plugin on my machine...[19:39] <zumbrunn> still using jseclipse 1.5.5 myself[19:39] <decke> yeah that version rocks...[19:39] <decke> good that i have an ubuntu system where i could play with that strange stuff...[19:40] <midnightmonster> (so why is "not knowing about the future" favoring a product that died in the bowels of adobe a year ago over one that's actively developed?)[19:40] <zumbrunn> "not knowing about the future"?[19:41] <decke> the same with cars... you have one that is not that pretty and big - but it works and there is no need to change it... although it might break in the future....[19:41] <decke> but why buy an big SUV if you like small cars?[19:42] <decke> i better use JSEclipse 1.5.5 until the eclipse api changes break it...[19:43] <decke> and maybe the Eclipse JavaScript IDE improves fast enough to be competitive with aptana[19:44] <zumbrunn> just checked, the version currently available from adobe's site is still 1.5.5[19:44] <zumbrunn> (jseclipse_plugin_040207.zip)[19:45] <zumbrunn> unless they changed something without changing the version number[19:45] <decke> oh that was the problem then[19:45] <decke> JSEclipse prerelease 2 released on April 2, 2007[19:45] <decke> yeah they gave them a new "version number" Prerelease 2[19:46] <decke> and never updated it since then...[19:48] <zumbrunn> goofy[19:57] <zumbrunn> decke, I just checked older helma release src packages and the jars seem to always have been missing[19:58] <zumbrunn> can't the port fetch directly from the subversion repository?[19:59] <decke> if i patch the build.xml it should be possible[19:59] <zumbrunn> no, I don't mean just the jars[19:59] <decke> i think ant has an svn plugin that should be what i need[19:59] <zumbrunn> I mean getting the source from the repository instead of the src.tar.gz file[20:00] <decke> oh no downloading everything from svn would not be a good idea i think... that way the port would never build if the svn repository migrates is down or whatever[20:00] <zumbrunn> ok[20:01] <decke> but i could download both archives[20:03] <decke> but then i don't know what the src part is really good for...[20:04] <decke> because java bytecode is java bytecode... and will not get better, different or worse if i compile it myself in the port[20:04] <decke> or just take the helma.jar from the binary package[20:07] <decke> but on the other hand if i would need to patch the helma code anywhere... because of an bug in BSD or whatever ... i have to compile it in the port[20:07] <decke> thats a good reason to not use the binary packages[20:08] <decke> i will try to discuss that on ##freebsd[20:15] <decke> off topic: now where is that Telekom Austria commercial that they are responsible for sending the UEFA Euro 2008 to all of us?[20:15] <decke> because their satellite transponder is dead *g*[20:59] <midnightmonster> is there a way to get a list of Hop prototypes defined in an application?[21:26] <midnightmonster> that'd be app.getPrototypes()
In the channel now:
Logs by date: