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

2008-12-02:

[8:27] <mcarter_> hello
[8:34] <zumbrunn> hi mcarter_
[9:28] <Tyro7> hi hannesw, are you around?
[9:35] <Tyro7> couple of qs: are you working on a couchdb implementation of a filestore? ... and does intellij idea include a js debugger?
[9:43] <hannesw> Hi Tyro7
[9:43] <hannesw> I have a minimal couchdb module for helma-ng
[9:43] <hannesw> but no relations/collections yet
[9:45] <anton_> hello everyone!
[9:46] <anton_> is someone listening?
[9:55] * zumbrunn was listening at the time
[9:56] <mcarter_> hey again
[9:56] <anton_> hey.
[9:57] <anton_> oh. (i am still not very familiar with the irc stuff)
[9:57] <mcarter_> i'm looking through helma documentation right now -- i had some idea in my head that there was some built-in hibernate integration in helma, but i'm not so sure thats the case
[9:58] <anton_> robert thurnher has written a hibernate module for helma-ng.
[9:58] <anton_> is this what you are looking for?
[10:00] <Tyro7> http://github.com/robi42/dbstore/tree/master
[10:01] <mcarter> neat
[10:01] <mcarter> so does helma have any comet support?
[10:02] <Tyro7> yes, look up continuations
[10:02] <Tyro7> at least in helmang its under apps/demo/main.js
[10:03] <mcarter> I know Jetty has comet support
[10:03] <mcarter> I'm just curious if there was any work done to expose it with a js api in helma
[10:05] <Tyro7> Im not sure, doesnt look like it, better ask zumbrunn :)
[10:05] <Tyro7> hi hannesw
[10:06] <hannesw> regarding intellij: I haven't tried the javascript debugger yet
[10:06] <hannesw> hi
[10:06] <Tyro7> but its there? thats neat ..
[10:06] <hannesw> yes, i think it's new in version 8
[10:06] <Tyro7> nice
[10:06] <hannesw> i'm still using version 7.x though because of a bug with ubuntu 8.10
[10:06] <Tyro7> Ill have to give it a go
[10:07] <Tyro7> do you know anything about comet support in ng? mcarter was asking about it
[10:07] <hannesw> great, let us know how it goes.
[10:07] <Tyro7> will do
[10:08] <hannesw> nope, i've thought about doing comet stuff
[10:08] <hannesw> but haven't yet
[10:08] <Tyro7> should put that on the todo list :)
[10:08] <Tyro7> Im about as far as you on the couchdb side of things, by the sound of things
[10:09] <hannesw> yep, it would be obvious to do, since we already have jetty.
[10:09] <Tyro7> might make sense to collaborate on that
[10:09] <hannesw> i just converted the bundled javascript file to work in ng
[10:09] <hannesw> replace the XmlHTTPRequest stuff with helma.httpclient and stuff
[10:10] <Tyro7> same here
[10:10] <Tyro7> my version handles associations, but Im still testing it
[10:11] <Tyro7> having some weird issues with utf8 characters causing errors as well ..
[10:12] <mcarter> anton_, do you know if this orm module uses the normal hibernate xml worksheets, or has its own js-centric mapping like jp moresmau's work? (http://jpmoresmau.blogspot.com/2007/05/javascript-and-hibernate-hand-in-hand.html)
[10:12] <Tyro7> hannes: http://helma.pastebin.com/m496d0bf9
[10:12] <Tyro7> its a little messy and untested, but there you go
[10:12] <Tyro7> still has the filestore transaction stuff in it as well
[10:13] <hannesw> thanks, tyro7. I'll have a look
[10:13] <Tyro7> can I keep updating that same url with pastebin?
[10:14] <hannesw> yes, i think so
[10:14] <Tyro7> cool, could use that as a poor mans svn
[10:14] <Tyro7> one point about hibernate integration: wouldnt it better to wrap around JPA rather than hibernate
[10:15] <Tyro7> hibernate is a JPA provider, but then so are other libs which dont rely on JDBC
[10:15] <hannesw> actually looks quite a bit more advanced than my version, which is here: http://helma.pastebin.com/m332a3c45
[10:16] <Tyro7> so by supporting JPA (which is similar to hibernate), would be possible to support all those other libs in one go as well
[10:16] <Tyro7> for example the sesame RDF store has a JPA interface etc.
[10:17] <Tyro7> hannesw: thanks, Ill take a look
[10:17] <hannesw> might be. I haven't looked at JPA. If we don't lose any important features, and don't add complexity, going through JPA would sure make sense
[10:18] <mcarter> i don't suppose anyone has seen any work done that exposes network IO to javascript, like maybe nio or at the very least sockets
[10:18] <hannesw> mccarter: not that I'm aware of.
[10:19] <Tyro7> hannesw: I left the transaction stuff in cus it might be useful for batch PUTs
[10:20] <Tyro7> here's a link to some good docs on JPA: http://www.hibernate.org/hib_docs/entitymanager/reference/en/html_single/
[10:20] <Tyro7> ironically enough theyre on the hibernate site
[10:22] <hannesw> thanks. was just reading the ones on java.sun.com..
[10:22] <Tyro7> also for completeness, here's the link to the openrdf jpa integration stuff: http://www.openrdf.org/doc/elmo/1.3/user-guide/x841.html
[10:23] <mcarter> i think it would be pretty neat to be able to write an app in pure-javascript, and run the "server" component in the browser right next to the client-side stuff, and do all the development in a single browser, and just move the server-side js to the server for deployment
[10:23] <Tyro7> take a look at appjet.com
[10:24] <Tyro7> I think it would be worth reimplementing some of their stuff in helmang
[10:24] <Tyro7> cus although theyve been talking about open sourcing their code, they havent done it yet
[10:24] <Tyro7> depsite the fact that theyre running on helma :)
[10:25] <mcarter> are they really running on helma?
[10:25] <Tyro7> the editor bit is done: http://marijn.haverbeke.nl/codemirror/jstest.html
[10:25] <Tyro7> yes
[10:25] <mcarter> i didn't know that
[10:25] <mcarter> I've seen their stuff
[10:25] <Tyro7> now, what the appjet guys have is: comet support and nio which you just mentioned
[10:25] <Tyro7> + rhino sandboxing
[10:25] <mcarter> what is rhino sandboxing?
[10:26] <Tyro7> so that theres a resource quota per app
[10:26] <Tyro7> ie a rogue script cant crash the whole system
[10:26] <mcarter> gotcha
[10:26] <hannesw> I thought the appjet guys weren't using helma for the appjet thing itself
[10:27] <hannesw> just their website. but i could be wrong
[10:27] <Tyro7> youre right
[10:27] <mcarter> to tell you the truth, i am not a fan of the apis appjet exposes -- now, let me say that i'm not terribly familiar with those apis, but i tried going through their "learn to program using appjet" and was not impressed
[10:27] <hannesw> sandboxing is an interesting topic
[10:27] <Tyro7> I guess I wasnt being clear
[10:27] <Tyro7> the libs are effectively helma ng modules
[10:28] <Tyro7> I think it would be very easy to port them over
[10:28] <Tyro7> now, the way they render html is pretty nasty
[10:28] <Tyro7> would much rather have the mvc separation
[10:28] <Tyro7> but for little apps which dont need much html, or produce some other markup, appjet is great
[10:28] <hannesw> well, they have this all-in-one file concept, which is nice for small projects
[10:29] <Tyro7> yeah, theyre moving away from that though, or so it appears from their last blog post
[10:30] <mcarter> so is the helma orm written in java or javscript?
[10:30] <Tyro7> I decompiled the appjet jar they released
[10:30] <Tyro7> and it has apache derby classes
[10:30] <Tyro7> so I guess its a thin layer on top of that
[10:31] <Tyro7> oh sorry, I thought we were still talking about appjet :)
[10:31] <hannesw> just catching up on appjet blog, interesting stuff
[10:31] <hannesw> helma 1 orm is written in java.
[10:31] <Tyro7> helma ng doesnt have an orm per say yet ;)
[10:32] <Tyro7> but its all in javascript
[10:32] <hannesw> helma-ng orm doesn't exist yet, there is a hibernate module which is written in js
[10:32] <Tyro7> one other neat thing, before I forget ... ;)
[10:32] <Tyro7> have you guys looked at trimpath junction?
[10:32] <mcarter> i guess i don't understand what ng means. whats the difference between helma ng and helma?
[10:32] <Tyro7> http://dev.helma.org/wiki/Helma+NG/
[10:33] <Tyro7> junction runs on top of helma(1), but it has this neat feature where the orm can run client side and store data in the browser if google gears is present
[10:33] <Tyro7> and then theres simple calls for syncing it with the servers orm
[10:34] <Tyro7> looks very neat, very gwt style
[10:34] <mcarter> thats exactly the kind of orm i'm looking for
[10:35] <Tyro7> then trimpath junction is your friend
[10:35] <Tyro7> would be great if you ported it to ng :)
[10:36] <mcarter> what is ng?
[10:37] <Tyro7> a rewrite of helma with better separation of code using modules (which doesnt pollute the global namespace) and more functionality implemented in javascript (as opposed to javascript)
[10:37] <mcarter> wow, look at this idiotic blog post someone made: http://weblogs.asp.net/rosherove/archive/2007/06/04/is-google-gears-a-disaster-waiting-to-happen.aspx
[10:38] <Tyro7> there needs to be some big notice somewhere that javascript != dom implementation
[10:39] <Tyro7> and a link to this book: http://oreilly.com/catalog/9780596517748/
[10:40] <mcarter> Tyro7, did you run across any pages that elucidated the trimpath orm well?
[10:40] <Tyro7> http://code.google.com/p/trimpath/wiki/TrimJunction
[10:40] <Tyro7> http://trimpath.googlecode.com/svn/trunk/junction_docs/files/junction_doc_about-txt.html
[10:41] <mcarter> what all of these server-side js frameworks should be doing, in my opinion, is implementing almost everything in native javascript for portability, and then re-implementing very specific components for performance
[10:41] <mcarter> so then you could share libraries a lot easier
[10:41] <Tyro7> absolutely
[10:42] <Tyro7> it would be quite neat to write an appjet lib->helma module converter
[10:42] <Tyro7> shouldnt be too difficult
[10:42] <mcarter> it seems like appjet would be hugely in favor of that not existing
[10:42] <Tyro7> hannesw, zumbrunn: would anyone object to me putting up a wiki page under helma-ng with a wishlist of sorts listing the things we discussed here?
[10:43] <hannesw> tyro7: sure, go ahead!
[10:43] <mcarter> any idea where these appjet guys are located anyway?
[10:43] <Tyro7> mcarter: Im not so sure, if you follow them on their forums, they seem to be pretty open about things
[10:43] <Tyro7> I could have a chat with them about it
[10:43] <Tyro7> theyre part of ycombinator, and I knew a few people there
[10:44] <Tyro7> from what I gather they just havent figured out how to make money with their business, and have wasted quite a bit of time trying to create a PHP version of appjet
[10:44] <hannesw> yes, i haven't had much contact with the appjet guys, but they sure seem like friendly and open folks
[10:44] <mcarter> http://jazzrecord.org/ -- anyone seen this?
[10:45] <hannesw> aaron iba is in the helma-ng google group also
[10:45] <Tyro7> mcarter: nope, looks neat
[10:46] <Tyro7> will take a look
[10:46] <Tyro7> one thing I dont like about activerecord (and clones) is that it forces you to think in terms of tables, rather than objects
[10:46] <Tyro7> Id much rather have a proper ORM, which translates objects to whatever representation you want
[10:47] <mcarter> i thought in activerecord that you don't have to define tables
[10:47] <mcarter> Tyro7, i'm the exact opposite -- i love sqlalchemy (python orm) because it doesn't try to hide tables from you and lets you really embrace them
[10:48] <Tyro7> I was very much of that opinion myself, until I got excited about document dbs (couchdb) and column oriented databases (bigtable, hbase)
[10:49] <Tyro7> which store objects
[10:49] <Tyro7> all of a sudden an abstract orm starts to make a lot of sense
[10:49] <Tyro7> well bigtable doesnt store objects, its a multidimensional distributed map
[10:49] <Tyro7> but still its a lot easier to map an object to that, than a relational db
[10:50] <Tyro7> that being said, theres a disconnect when it comes to running queries
[10:50] <Tyro7> rather than having sql like queries, one has to run map/reduce jobs
[10:51] <mcarter> Tyro7, i've had some pretty amazing and arbitrary sql -> object mappings using sqlalchemy that made me a believer of ORMs
[10:51] <mcarter> Tyro7, i haven't yet jumped on this couchdb, and in general document database systems, because I think its very difficult to model data on those systems
[10:51] <mcarter> they just don't seem mature enough or something... maybe I just haven't gotten to thinking about it right
[10:52] <Tyro7> well, hannesw and I will have to prove you wrong :)
[10:53] <Tyro7> I agree about couchdb, but its moving along very quickly
[10:53] <Tyro7> hbase is mature imo, but its kind of low level, one would need to do some work to write an orm on top of it
[10:53] <Tyro7> since you have to write all the code for indexing etc. yourself
[10:54] <Tyro7> sparse, column oriented tables are the future though, imo :)
[10:54] <mcarter> it does seem like they are better for sheer scalability
[10:55] <mcarter> but i just can't seem to grasp how to model my data on that type of db in a way to make it easy to construct queries that i'm sure i'll want some time in the future
[11:02] <Tyro7> is there a page desciring the dev.helm.org wiki syntax somwhere?
[11:02] <Tyro7> or is it only html .. ?
[11:07] <hannesw> it's a gobi site: http://gobi.helma.at/Documentation/Wiki+Features/
[11:14] <Tyro7> http://dev.helma.org/ng/helma-ng+wishlist/
[11:14] <Tyro7> added a couple of other ideas related to grails
[11:15] <Tyro7> btw, how easy would it be to port over the helma swarm stuff over to helma ng?
[11:17] <hannesw> tyro7: helma ng uses standard servlet sessions, whereas helma 1.* implemented its own session layer.
[11:17] <mcarter> well i'm off to bed, thanks for the conversation
[11:17] <Tyro7> so basically, its just a case of changing jetty.xml
[11:17] <hannesw> so i guess you could just use standard servlet/hibernate/whatever clusterware for helma ng
[11:18] <Tyro7> thanks, gnite ;)
[11:18] <Tyro7> nice
[11:18] <Tyro7> might be worth putting some scripts in place for packing things up as a war as well then
[12:13] <Tyro7> hmm, realized a wishlist page already exists, should checked more carefully
[12:13] <Tyro7> will move my stuff over there ..
[12:49] <Tyro7> question: I want to run eval inside a function, so that it would use the scripts top level context, any ideas how to do that?
[12:50] <Tyro7> eval(null, "...") doesnt work
[14:02] <hannesw> in helma ng? evaluate() in helma.system should do that.
[14:03] <hannesw> it takes a module name and evaluates it in the current scope, or a scope passed as optional second argument.
[20:12] <Tyro7> played around with intellij idea, doesnt look like there's an easy way to debug server sode js in it
[20:24] <Tyro7> hannesw: I noticed a while ago, you got the rhino debugger working with helma: did that prove useful? how would I go about getting it to work with ng
[20:33] <hannesw> there's an extended rhino debugger in helma 1.
[20:34] <hannesw> i haven't ported it to helma ng yet
[20:35] <hannesw> by extended i mean it has an additional tree view showing the app's script files.
[20:48] <Tyro7> where can I download it from?
[20:48] <Tyro7> or is it in the svn?
[20:48] <Tyro7> hannesw: btw played around with intellij idea, doesnt look like there's an easy way to debug server side js in it
[20:49] <hannesw> the debugger is part of helma 1
[20:49] <hannesw> re intellij, yes, i thought so
[20:50] <hannesw> it's pretty much geared towards browser development
[22:55] <zumbrunn> Tyro7: see http://helma.zumbrunn.com/tools/debugger regarding the rhino debugger for helma 1
[23:22] <Tyro7> nice, thanks

 

 

In the channel now:

Logs by date: