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

2008-06-30:

[1:52] <mindlike> anyone know how tough it'd be to embed helma or helma-ng into a browser?
[2:34] <midnightmonster> in what way?
[2:34] <midnightmonster> if the user's supposed to download it, it'd be pretty darn slow
[2:36] <midnightmonster> and applets don't get filesystem access, and I don't think they can listen even on unpriviledged ports without big scary warnings and confirmations, so even if you reworked it for the limitations of being an applet (And I don't know what that would involve, but it wouldn't be easy), the experience would suck
[2:38] <midnightmonster> but I'm not sure in what sense you're talking about embedding
[2:40] <midnightmonster> practically, it would be super lame to run helma as an applet, if it's even possible. If you're distributing an app with a browser all in a bundle, e.g., to run off a local install, it probably wouldn't be too hard
[2:40] <midnightmonster> if you're talking about porting the framework to browser javascript, most of it doesn't make a lot of sense in that context, and even for porting the object extensions there's a huge obstacle:
[2:43] <midnightmonster> helma does a rhino-based dontEnum() javascript object extension, e.g., so you can have Object.toJSON() but still use objects as hash tables without toJSON coming up when you iterate
[2:43] <midnightmonster> that's not possible in browser javascript
[3:13] <mindlike> yeah basically all I meant by embed was auto-install from browser
[3:13] <mindlike> essentially you can just download a zip file and unzip then run a start file and you have a server running, thats pretty turnkey
[3:14] <mindlike> just wondered how hard it'd be to do that from a browser user an applet to bootstrap it
[3:15] <mindlike> thanks for that response though midnight
[5:45] <zumbrunn> mindlike, the most streamlined approach that comes to mind, would be to embed helma in a firefox extension
[5:46] <zumbrunn> midnightmonster, actually, tobi once went a long way, porting the framework to browser javascript
[5:46] <zumbrunn> that's basically what the chopper project is
[5:46] <zumbrunn> http://blog.p3k.org/stories/3143/
[6:50] <mindlike> so in helma-ng hopobjects no longer exist?
[6:57] <zumbrunn> mindlike: they are not part of the java-based helma core, anyway
[6:57] <zumbrunn> but they can be added to the helma-ng core using javascript
[6:58] <zumbrunn> hmm...
[6:58] * zumbrunn wonders whether rewriting chopper for server-side use in helma-ng is an interesting thought
[6:59] <zumbrunn> but there already is a beginning for a helma 1.x compatibility module
[7:00] <zumbrunn> https://dev.helma.org/trac/helma/browser/helma-ng/trunk/modules/helma/helma1.js
[7:07] <mindlike> so chopper is just an emulator not actually a real or partial java on client implementation
[7:07] <mindlike> or is it
[7:08] <zumbrunn> it's just javascript, no java
[7:08] <mindlike> or better yet a clerver implementation of it
[8:54] <Raimi> hello
[8:54] <zumbrunn> hi
[8:54] <Raimi> mocha of mozilla told me it might be ok to ask rhino questions here
[8:54] <zumbrunn> yes, mocha == zumbrunn
[8:54] <Raimi> obviously
[8:54] <Raimi> :)
[8:55] <zumbrunn> just because it's on topic here, doesn't mean you'll get an answer, though
[8:56] <Raimi> hm... i might be in the right spot
[8:56] <Raimi> i develop a webapp (java) that uses rhino on the server side
[8:56] <Raimi> to allow business logic scripting
[8:56] <zumbrunn> cool
[8:57] <Raimi> works like a charme so far. now: i need to do some file operations. some globbing, iterating etc
[8:57] <Raimi> things that are trivial in any shell
[8:58] <Raimi> as far as i can tell, there is nothing in Rhino ... and working with Packages.java.io.File will be PITA
[8:58] <Raimi> i'm looking for a library :)
[8:59] <zumbrunn> http://helma.zumbrunn.com/reference/helma.File.html
[9:01] <zumbrunn> https://dev.helma.org/trac/helma/browser/apps/modules/trunk/helma/File.js
[9:02] <zumbrunn> basically, that just wraps different java.io classes
[9:08] <zumbrunn> actually, this version is newer:
[9:08] <zumbrunn> https://dev.helma.org/trac/helma/browser/helma-ng/trunk/modules/helma/file.js
[9:08] <Raimi> i'm reading ..
[9:08] <zumbrunn> don't remember if it is different in any way
[9:09] <zumbrunn> but that's the one for use with helma-ng
[9:14] <Raimi> it's an interesting project you have, guys
[9:14] <Raimi> keep it up
[9:15] <zumbrunn> so, what's your goal for your rhino server-side app?
[9:16] <zumbrunn> will you release it in some form?
[9:22] <Raimi> well, no. it's a commercial app. and the rhino part is rather small
[9:22] <Raimi> the application does things and we use rhino to make it more flexible
[9:23] <Raimi> i've never heard of helma... seems pretty mature
[9:23] <Raimi> zumbrunn: i think your File class inspired me
[9:23] <zumbrunn> it's been around for almost ten years
[9:23] <zumbrunn> open source since 2001
[9:26] <Raimi> which js language impl are you using? rhino or that other one?
[9:26] <zumbrunn> yes, rhino
[9:56] <Raimi> sorry that i dont chat much... cow-orkers push me to work :)
[13:48] <lapusta> hello. i have some questions about Helma NG. is it ready for usage? i know it's in development and i want to know the status of main components - templates, orm...
[13:50] <zumbrunn> hi lapusta, I would say helma-ng is at a very experimental stage
[13:50] <zumbrunn> so, it's ready for usage if you want to experiment ;-)
[13:50] <lapusta> =) that's what i wanted to hear
[13:51] <zumbrunn> everything may still change, and you'll have to live with that
[13:52] <lapusta> can I ask a personal question? i know you are the author of helma, but i didn't find your name in helma-ng dev list? are you going to participate?
[13:52] <zumbrunn> something might not be working, and you'll have to live with that
[13:53] <zumbrunn> or many bits do not exist yet - and you'll have to help implement them if you do not want to wait until someone else does
[13:53] <zumbrunn> in other words, it's alpha
[13:54] <zumbrunn> hannes is the author of helma, not me
[13:54] <zumbrunn> but yes, of course I will participate
[13:54] <zumbrunn> I'm subscribed
[13:56] <lapusta> and the last question - are there any plans about ecma4?
[13:57] <zumbrunn> sure, by way of ES4 being implemented in rhino
[13:58] <zumbrunn> some things that will be part of ES4 and ES3.1 are already in today's rhino version
[13:59] <lapusta> that's nice. i think my web-framework search is over)
[14:00] <zumbrunn> like always, when which feature will be added mainly depends on whether somebody needs it and is willing to do the work to implement it
[14:02] <lapusta> i understand all of this, so i hope our start-up and helma would evolve together)
[14:03] <zumbrunn> as far as es4 support in rhino is concerned, it looks like much of that work will come from google people
[14:07] <lapusta> yes, i've heard about it in atilla's interview on infoq
[16:24] <midnightmonster> btw: I'm told ECMA doesn't do "point" releases--i.e., there will never be an ecmascript 3.1. talking as though that's what they want is ignorance or a trick on the part of the "little language" advocates--if a rec is released along Crockford's lines, it would end up being ES4, derailing the whole process
[16:42] <zumbrunn> yeah, but theoretically that shouldn't be able to happen, since the majority of TC-39/TG1 is behind ES4, and not the ES3.1 proposal
[16:42] <zumbrunn> (and they don't need consensus)
[16:43] <zumbrunn> I don't know if they could do ES4 and ES5 simultaneously
[16:44] <zumbrunn> meaning the 3.1 proposal would become ES4 and the ES4 proposal would become ES5
[16:55] <zumbrunn> hey, decke, if you don't mind sharing the patch you implemented in order to get Helma 1.x working with Jetty 7, it might save Hannes some time when he gets around to make that step
[16:56] <zumbrunn> (I know you said you still had some bugs, but it might be anyway helpful)
[16:58] <zumbrunn> and regarding the -src.tar.gz packages, they apparently are intended to be installed over the binary package, not on their own
[17:04] <decke> yeah should not be a problem
[17:04] <decke> okay so extracting both (src and binary) over another should give me what i have to start compiling with?
[17:05] <zumbrunn> right
[17:06] <decke> that is very helpful ...
[17:07] <decke> okay then i will try to fix that experimental jetty patch a bit and forward it to the helma bugtracker
[17:09] <decke> so is hannes working on an jetty update for helma 1.x?
[17:10] <zumbrunn> not at the moment
[17:11] <midnightmonster> did we ever get slides for hannes' helma ng presentation? did I already read them and forget?
[17:11] <zumbrunn> slides we got, yes
[17:11] <midnightmonster> location?
[17:12] <midnightmonster> (in English?)
[17:12] <zumbrunn> but I never made a video available, since it was german and not combined with the slides
[17:12] <zumbrunn> looking...
[17:13] <midnightmonster> http://www.henso.com/files/helma-ng-presentation/
[17:13] <zumbrunn> yep
[17:14] <midnightmonster> I'm on slide 4 about scope in ng and I'm lost. help?
[17:15] <zumbrunn> well, Helma 1.x was "prototype centric"
[17:15] <midnightmonster> sure
[17:16] <zumbrunn> helma-ng is "scope centric" in that sense
[17:16] <zumbrunn> so, mentioning how scopes are related to each other is important in the context of helma-ng
[17:17] <zumbrunn> where that was an implementation detail in the background with helma 1.x, that could pretty much be ignored
[17:17] <zumbrunn> in helma-ng, modules have their own scope
[17:17] <zumbrunn> which inherit from the global scope
[17:18] <zumbrunn> (their prototype property points to the global scope)
[17:18] <zumbrunn> "shared global scope" that is
[17:18] <midnightmonster> can you give me an example of something that means I now can or can't do that I couldn't or could do with helma 1.x?
[17:19] <zumbrunn> you don't have to worry about var name collisions in modules
[17:19] <zumbrunn> they act like namespaces
[17:19] <midnightmonster> what're modules?
[17:20] <midnightmonster> in helma ng
[17:20] <zumbrunn> any js file (or group of files) that is loaded using importModule
[17:21] <zumbrunn> plus, their scopes are private, kind of like closures
[17:22] <midnightmonster> but presumably you can purposely expose parts?
[17:22] <midnightmonster> how is that done?
[17:22] <zumbrunn> right
[17:25] <zumbrunn> it's the other way around
[17:26] <zumbrunn> what you define in there is public by default
[17:26] <zumbrunn> and you can hide it in a closure if you want it to be private
[17:26] <zumbrunn> so, no surprise there
[17:27] <midnightmonster> ok... so in what sense are their scopes private?
[17:28] <zumbrunn> yeah, scratch that
[17:28] <zumbrunn> but they have their own namespace
[17:28] <midnightmonster> so here <http://helma.pastebin.com/m4e50c862> is the current version of my simple CSVReader wrapper. what would I change to make it a helma ng module?
[17:30] <zumbrunn> I believe that basically would work like you have it
[17:30] <midnightmonster> since this is only one function, I'm guessing we'll have to stick it in a parent object, so instead of CSVReader('myfile') it'll be CSVReader.open('myfile'), with the upside that when someone imports it, they can call it whatever they like instead of CSVReader?
[17:32] <zumbrunn> yes, or if you put it into a file named foo.js as it is, you would need to call it as foo.CSVReader.open('myfile') after doing importModule('foo')
[17:33] <midnightmonster> oh, ok
[17:33] <midnightmonster> that makes sense!
[17:33] <midnightmonster> (makes me a little nervous about performance, since historically you pay for every .)
[17:33] <zumbrunn> or you could do importFromModule('goo','CSVReader') and then call it using CSVReader.open('myfile')
[17:34] <zumbrunn> ehhh, foo
[17:34] <zumbrunn> not goo
[17:34] <decke> "BUILD SUCCESSFUL" works like a charm compiling helma with a port ;o)
[17:34] <zumbrunn> :-)
[17:35] <midnightmonster> or I could not change it at all and importFromModule('foo','CSVReader') and then use it as it is already with CSVReader('myfile') ?
[17:35] <decke> extracting them over another did the trick
[17:35] <zumbrunn> that's what I meant, yes
[17:40] <midnightmonster> ok, neat. so I see the modules thing as an improvement that won't create a significant burden.
[17:41] <midnightmonster> I don't think I understand how that applies when you're adapting an existing object, e.g., as is presumably the case still with core.string (to take an example from this slide)
[17:43] <zumbrunn> https://dev.helma.org/trac/helma/browser/helma-ng/trunk/modules/core/string.js
[17:44] <zumbrunn> one important bit there is the __shared__ = true; line
[17:45] <zumbrunn> which makes that the module is compiled once and shared between all requests, if I understand it correctly
[17:45] <midnightmonster> but for that line this looks just like I remember the old one looking
[17:46] <midnightmonster> and one would hope that modules weren't getting recompiled every request anyway, right?
[17:47] <zumbrunn> I believe right now they are, but I'm not sure
[17:47] <zumbrunn> not sure what the plan is
[17:48] <midnightmonster> that seems odd, since in helma 1.x my code doesn't get recompiled unless it changes, right?
[17:48] <Raimi> zumbrunn: sorry to interrupt again. do you have a proper sprintf() implementation? my one seems to b0rk at %-128s
[17:49] <midnightmonster> does helma-ng get discussed on helma dev? I keep meaning to subscribe to that and forgetting
[17:49] <zumbrunn> don't know Raimi
[17:50] <zumbrunn> helma-ng has its own list
[17:50] <zumbrunn> helma-dev is basically discontinued
[17:50] <midnightmonster> well I guess I won't subscribe to that one, then
[17:51] <zumbrunn> don't ask me to explain why
[17:51] <zumbrunn> I tried to argue against it :-)
[17:51] <midnightmonster> I wasn't going to until you said don't...
[17:51] <zumbrunn> ;-)
[17:52] <midnightmonster> http://dev.helma.org/mailing+lists/ still lists only user/dev/cvs. how can I join the top-secret cadre of ng-dev mailers?
[17:52] <zumbrunn> hmm, sorry, need to fix that...
[17:52] <midnightmonster> found it
[17:53] <zumbrunn> http://helma.org/mailman/listinfo
[17:56] <zumbrunn> and yes, helma 1.x only recompiles if the source files changed
[17:57] <zumbrunn> maybe helma-ng already does this too, not sure
[17:57] <midnightmonster> that would seem like an important feature parity thing
[18:15] <decke> has hannes explained why helma 1.x uses an old jetty up to now?
[19:59] <zumbrunn> decke, I didn't ask him directly like that
[20:00] <zumbrunn> between the lines, I think it's just that there was no need/benefit to upgrade and take the risk of instability or introducing new problems
[22:47] <jkridner|work> I'm struggling with a basic concept that I hope you can help me with.
[22:47] <jkridner|work> I'm trying to create a simple database...
[22:48] <jkridner|work> and I want all of my objects inherit from a parent object type.
[22:48] <jkridner|work> the problem I find is in the URL construction and initialization.
[22:49] <jkridner|work> so, the method that I know works is to put the child object creation methods in the parent object...
[22:49] <jkridner|work> but this seems really ugly to me.
[22:50] <jkridner|work> for example, I can put a create_child_action, in Parent.
[22:50] <jkridner|work> but, this destroys the modularity of my coding.
[22:50] <jkridner|work> I don't want to put child-related dependencies in the parent.
[22:51] <jkridner|work> So, if "Project" is a type of (child of) "Page", I don't want to have to put my methods for listing "Project" objects inside of my definition for "Page".
[23:05] <midnightmonster> one way to handle creation is generate a temp Project object and let it write out its own forms, then when they submit create another temp Project object to read the data and persist itself
[23:08] <midnightmonster> the only thing you may have to do is write a getChildElement function for your parent to return a temp Project when /new-project comes up
[23:11] <midnightmonster> well, and you also need a constructor for the child so you can pass it a reference to its parent, and you have to overload the href() method of the child so that if the element hasn't been persisted yet, href('edit'), e.g., returns /parent/new-project/edit instead of /parent/73/edit as it would for a persisted object
[23:11] <midnightmonster> but you can do these things very low in your prototype inheritance hierarchy if you like and not have to touch them much later
[23:12] <midnightmonster> I like it better than having a lot of child-specific code in the parents
[23:13] <jkridner|work> do you have any examples?
[23:14] <jkridner|work> getting all of the child-specific code in the parents is driving me nuts.
[23:21] <midnightmonster> hmm... I have some non-confidential code with something close to that pattern, but I've built it and torn it down a bunch of times and it's not quite working ATM.
[23:21] <jkridner|work> k.
[23:21] <midnightmonster> I should have better in a few days, but I don't know that's any help to you
[23:21] <jkridner|work> my code is public, but the current head is a mess.
[23:22] <jkridner|work> http://www.beagleboard.org/gitweb/?p=beagleboard.org.git;a=summary
[23:22] <jkridner|work> this is a both a short-term and long-term issue.
[23:22] <jkridner|work> I'll end up hacking around it with lots of exceptions in the parent, but it is making me crazy.
[23:23] <jkridner|work> I've got some uncommitted changes, but I run the test server at http://beagleboard.org:8081/
[23:24] <midnightmonster> can you point me to or pastebin a specific example? might make it easier for me to make sure I'm addressing the actual problem
[23:24] <jkridner|work> (I'm probably far to trusting, but I have backups and there should be no sensitive data on the server.)
[23:24] <midnightmonster> syntax error on 80:81
[23:24] <midnightmonster> :8081
[23:26] <midnightmonster> I've gtg for now. I'll be back online in about 2 hours
[23:26] <jkridner|work> k. I'll have the test server back up then.
[23:26] <jkridner|work> http://www.beagleboard.org/gitweb/?p=beagleboard.org.git;a=blobdiff;f=code/Page/page.js;h=cbe9a74af32242ce91c787c1a672795eda5385c5;hp=948f1cb7b495236a234db7133d1906a25b7162e1;hb=e18ffb99184a5ccd5533e976fe991a56b11e63f7;hpb=a7c74849155370caa17360566e336a1b8f534ce4
[23:27] <jkridner|work> has one of the patches that was given to me to create the new object type.
[23:27] <jkridner|work> http://www.beagleboard.org/gitweb/?p=beagleboard.org.git;a=blobdiff;f=code/Root/main.js;h=a055cb344183dadab2acd436f52c5ddf0e5d8401;hp=5b603751c6c976077fe59c58cab16d7ff6a9e1b8;hb=e18ffb99184a5ccd5533e976fe991a56b11e63f7;hpb=cf48106fffdf9f70b061a6eb5f2f21e50c2093f4
[23:28] <jkridner|work> that shows the dependency added to my Root object to create the new object.
[23:28] <jkridner|work> I want to remove my 'join_project_action' from Root and move it into Project.

 

 

In the channel now:

Logs by date: