Hopbot log for 2008-08-04 - Helma IRC channel: #helma on irc.freenode.net
2008-08-04:
[8:17] <daniel_> i seem to be unable to send emails to the helma-dev mailing list. could anyone of you verify if there is a problem with the list (e.g. by sending an email yourself)?[8:22] <zumbrunn> daniel_: do you get an error message back?
[8:22] <zumbrunn> I know helma-dev was supposed to be discontinued
[8:22] <zumbrunn> (in favor of the helma-ng list)
[8:23] <daniel_> no i do not get any error message back
[8:23] <zumbrunn> anyway... I believe one shouldn't use helma-dev anymore anyway
[8:24] <zumbrunn> anything helma 1.x related should go to helma-user
[8:24] <zumbrunn> anything helma-ng related should go to helma-ng
[8:25] <daniel_> but helma 1.x development didn't completly end yet? did it?
[8:26] <zumbrunn> nope, certainly not
[8:26] <zumbrunn> the mailing list decision was a bit strange in my opinion
[8:27] <daniel_> seems a bit strange in my opinion too
[8:27] <daniel_> i would make sense although if it is not planned to have any further 1.x releases after 1.7 has been finished
[8:27] <daniel_> is this the case?
[8:28] <zumbrunn> no, helma 1.x would continue to move forward
[8:29] <daniel_> i guess as long as there is no helma ng 1.0, right?
[8:30] <zumbrunn> of course, if helma-ng serves as a complete replacement and there is no ineterest in further helma 1.x development... then it would stop, I guess
[8:32] <zumbrunn> daniel_, did you make sure you are subscribed with the email you are using?
[8:33] <daniel_> yes, i subscribed to all four, and at least helma-user works fine for me
[8:36] <daniel_> i just returned to helma after not using it for some years and therfore not actively following discussions and developments that have taken place in the meantime.
[8:37] <daniel_> what is your personal feeling on how much time is still invested in helma 1.x development and how much time is already dedicated to helma ng?
[8:39] <zumbrunn> I think the "development fun" definitely goes into helma-ng exclusively now, while helma 1.x development is purely based on needs
[8:39] <daniel_> to me closing down the helma-dev list looks like one can expect bugs to be resolved in helma 1.x but should not expect any new features anymore
[8:39] <zumbrunn> it depends on interest
[8:40] <zumbrunn> it's probably fair to say that hannes hopes interest for new features shifts to helma-ng
[8:41] <zumbrunn> I think you are looking at helma-ng a bit to negatively
[8:42] <zumbrunn> for example regarding the support for different languages...
[8:42] <zumbrunn> it might well be the case that a rhino/js based core makes sense even if multi-language support is added to helma
[8:43] <zumbrunn> as you know, helma 1.x was very much built around the concept of being language agnostic
[8:43] <zumbrunn> so other language support could be added as a *replacement* for js
[8:44] <zumbrunn> helma-ng makes a bigger commitment to js as the core scripting language
[8:44] <daniel_> but a js would always be there even if other languages would be added as core framework functionality will be shifted to js
[8:45] <daniel_> so either one needs to reimplemnt this functionality in the added language or use js and the new language
[8:45] <zumbrunn> yes, one possible approach for a multi-language helma-ng would be to allow modules to be written in different languages
[8:45] <daniel_> i know that this depends on the definition of core functionality, which is not that easy to define
[8:47] <daniel_> you already said it and i need to admit it: i don't like the helma ng philosophy, so yes i am looking at it a bit too negative (-:
[8:47] <zumbrunn> btw, my test message to helma-dev so far hasn't gone through either
[8:48] <daniel_> i still don't understand why some should want to move core functionality to js
[8:49] <daniel_> i do understand that helma 1.x is not flexible enough and that a lot of areas are missing plugin capabilities, but i simply don't understand why that shouldn't remain in java
[8:51] <zumbrunn> but do you loose that ability with helma-ng?
[8:51] <zumbrunn> nobody said modules couldn't be written in java
[8:52] <zumbrunn> it's just that you gain the ability to do more in js
[8:54] <zumbrunn> helma-ng is really more *platform* than a framework
[8:55] <zumbrunn> (or platform and framework become to different layers)
[8:56] <daniel_> the thing i don't understand is why its needed to have the framework in js
[8:56] <zumbrunn> two different layers, I meant
[8:57] <daniel_> understood. a platform in java that allows frameworks to be developed in any scripting language accessible from java with a default implementation in js
[8:58] <zumbrunn> or with javascript as the *glue* between platform and framework
[8:59] <daniel_> you mean in the situation where i would want to use another scripting language but do not want to reimplement the framework in that specific scripting language?
[9:02] <zumbrunn> a platform in java that allows frameworks and/or modules to be developed in any scripting language available on the jvm, using javascript as the glue between the different components
[9:04] <daniel_> compared to helma 1.x, what functionality is platform and what functionality belongs to framework?
[9:06] <daniel_> i am not sure yet where there is the borderline...
[9:07] <zumbrunn> in my opinion, templating, orm, url-mapping etc are framework, the lower levels platform tasks
[9:12] <daniel_> i agree on the definition
[9:13] <daniel_> but then it looks like the intention of helma ng is to be written in js, but because not all can be done in js, java is still needed for low level tasks although helma ng would love to work even without having java at all <sarcasm/>
[9:14] <zumbrunn> hehe
[9:15] <zumbrunn> I think the idea should be to pick the language most suitable for each component
[9:15] <zumbrunn> of course, people may disagree on that quite often
[9:16] <zumbrunn> but that is when we could have different implementations
[9:16] <daniel_> well, but those languages will only consist of js and java for what can not be done in js
[9:16] <zumbrunn> ?
[9:17] <zumbrunn> not sure what you mean
[9:17] <zumbrunn> oh, I should read correctly what you write
[9:18] <zumbrunn> yes
[9:18] <daniel_> i mean that finally helma ng will end up in a situation where those languages will only consist of js and java, like helma 1.x is now
[9:18] <daniel_> although it would be theoretically possible to ...
[9:18] <zumbrunn> but it would be possible to add support for other languages
[9:19] <daniel_> yes, but i fear that the platform itself will never be ported to any other languages
[9:19] <zumbrunn> it is true that helma-ng embraces javascript more than helma 1.x used to
[9:20] <daniel_> which results in happy wrapping (-;
[9:21] <daniel_> assume php as scripting language would want to create a hopobject, java would provide a php wrapped version, which it would unwrap and wrap again for js for doing the framework stuff, once done, java would unwrap it to wrap it for returning it to php
[9:22] <daniel_> i am not so sure if this will help other languages to be available for helma ng at some time in the future
[9:23] <daniel_> if they are either slow or in need of reimplementing the framework
[9:24] <daniel_> i am still not even sure if wrapping everything for the js framework for the feeling of ultimate flexibility is worth it (-:
[9:25] * zumbrunn thinks wrapping is useful for the purpose of abstraction
[9:25] <zumbrunn> so that the implementation can be changed without having to touch the code of the business logic of an app
[9:26] <daniel_> which implementation do think of when say it can be changed?
[9:27] <daniel_> +2*you (-;
[9:28] <zumbrunn> for example a module that provides ftp or xmttp functionality
[9:29] <daniel_> thats neither framework nore platform however
[9:29] <zumbrunn> true
[9:31] <daniel_> but, lets stay with the example... where do i have the abstraction? you probably mean beacause modules can be imported in helma ng into any namespace, right?
[9:31] <daniel_> so i could have had import("org.lala.FTP", "ftp") before
[9:31] <daniel_> and would simply change it to import("com.lulu.FTP", "ftp") to use the new module
[9:31] <daniel_> without changing the business logic
[9:32] <daniel_> but who, in a language that does not support anything like this, would check if the new module is fully compatible to what i have used from the old module?
[9:33] <daniel_> same functions/methods, expecting same number and type of arguments, ...
[9:33] <daniel_> so i am not sure if i would want to have pluggable components in js neither
[9:34] <zumbrunn> the switch from org.lala.FTP to org.lulu.FTP might require more changes in the modules code, but the js interface it exposes could remain the same
[9:35] <daniel_> i'd agree to have such modules in js and i'd agree that importing and seperated namespaces is a cool thing, if it would solve all the problems
[9:39] <daniel_> but it only introduces the problem that i can replace the framework's session manager module with the ftp module
[9:40] <daniel_> </sarcasm>
[9:41] <zumbrunn> ;-)
[9:41] <zumbrunn> a more framework related example would be the storage.js and hibernate-ng code in helma-ng, which both share the same code for making the objects available but implement a different backend for data persistence
[9:41] <daniel_> agreed, thats ultimate flexibilty, but at least for the framework i'd rather prefer to replace one module with something that at least looks like the old module, having a programming language like java which makes sure that my business logic will really still work
[9:46] <daniel_> my last message was not related to your last message, but to relate them, why should i want to do that in js, where i have no real interfaces, no types and no type checking in my functions declaration...
[9:48] <daniel_> btw, are you from austria? because i am missing a translation for "das st?llt ma die hoor auf"
[9:48] <daniel_> "... wenn i nur dron denk, des in js zu mochen"
[9:48] <daniel_> regarding framework modules
[9:50] <daniel_> ah, i saw you are from switzerlan, so you should understand what i've written (-;
[9:51] <zumbrunn> yep, got it ;-)
[9:52] <zumbrunn> well, have of my response would be that helma-ng doesn't force us to do things in js that we do not want to be in js
[9:53] <zumbrunn> the other have is, yes, helma-ng embraces js more, entrusting javascript to be able to solve more complex tasks
[9:54] <zumbrunn> have = half
[9:56] <daniel_> and now, finally, someone please show me the language constructs of js that are worth the effort and trust and will allow to solve more complex tasks (-;
[9:57] <daniel_> that one was not addressed to you, at least not if you do not have the answer or do not like to answer it at all (-:
[9:58] <zumbrunn> years ago, js was *underestimated*, I think you will agree?
[9:58] <zumbrunn> I agree there is no need to *overestimate* it now
[9:58] <daniel_> i totally agree
[9:59] <daniel_> and thats my point, i believe the time and effort is spent on the wrong place.
[10:00] <daniel_> making helma more flexible? yes!
[10:01] <zumbrunn> maybe you are still underestimating js ;-)
[10:01] <daniel_> rewriting it in js in the hope someday js might be the successor of java? no!
[10:01] <zumbrunn> I don't think that's the idea
[10:02] <zumbrunn> more flexibility is the idea
[10:02] <zumbrunn> so much more flexibility that you can't do it in java
[10:03] <daniel_> i agree that having the framework in js, makes it ways more flexible than having it in java.
[10:04] <daniel_> but i disagree that the exent of flexibility only available in js will ever be needed for framework modules
[10:05] <zumbrunn> if you are right, then more components of the framework could be implemented in java
[10:05] <daniel_> i believe the flexibility of java is more than enough for the framework modules, but of course, as everyone else, i might be wrong with my opinion
[10:05] <zumbrunn> helma-ng doesn't prevent that from happening
[10:09] <daniel_> i am not sure
[10:10] <zumbrunn> neither am I, I have to admit
[10:10] <zumbrunn> but that's the question to investigate, I guess
[10:10] <daniel_> how would a java module implement a js interface if there is none? so implementing any module in java would make it loose the advanges of java
[10:12] <zumbrunn> yeah, that's when happy wrapping would come into the game
[10:13] <zumbrunn> which we would want to avoid
[10:13] <daniel_> happy wrapping as well as heavy usage of java reflection i guess
[10:14] <zumbrunn> there is no better time than now to think of the ideal structure helma-ng should provide to be extendable/flexible in the ways you need as well
[10:14] <zumbrunn> (java flexibility vs js flexibility)
[10:15] <zumbrunn> have you discussed helma-ng with hannes already?
[10:15] <daniel_> no, as said before, i just returned back to helma several days ago...
[10:16] <zumbrunn> I can image the culture shock the helma-ng plans have provided ;-)
[10:16] <zumbrunn> imagine
[10:17] <zumbrunn> but nothing is written in stone
[10:25] <daniel_> probably not in stone, but wherever else, i've made the experience in the past, that writing on that whatever is quite restricted (-;
[11:42] <zumbrunn> much less restricted with helma-ng, because it is so fricking flexible ;-)
[11:50] <zumbrunn> Many helma ways diverged in a yellow wood. Everybody was able to take one less traveled by, and it made all the difference.
[12:29] <daniel_> i think i will interprete the fact, that my repository implementation is currently the only helma 1.x core module living on in helma ng, as sign that helma 1.x wants me to rewrite it from the inside instead of being rewritten as js framework (-;
[12:30] <zumbrunn> :-)
[12:31] <daniel_> to be honest, i already starting doing that yesterday, but till today i was not sure if will continue on it or if it is just for fun
[12:32] <daniel_> i am currently working on php as alternative scripting language to have a real alternative and not only a "it would theoretically be possible"
[12:33] <zumbrunn> for 1.x or ng?
[12:34] <daniel_> that was rhetorical, right?
[12:34] <zumbrunn> no!
[12:34] <daniel_> 1.x
[12:34] <zumbrunn> well, I guess it was rhetorical
[12:34] <daniel_> the interfaces are there, the php interpreter is out there, but nobody did it so far
[12:35] <zumbrunn> what I meant is, I would which you would do this for ng, not 1.x
[12:35] <zumbrunn> wish
[12:37] <daniel_> you know i don't feel comfortable with ng (-;
[12:38] <zumbrunn> yeah, it's a cool addition for 1.x as well, of course :-)
[13:57] <daniel_> quit late, but your mail to helma-dev just arrived. mine however did not yet.
[13:58] <zumbrunn> yep, just got mine, too ...and yours not yet
[20:37] <midnightmonste1> anyone around? I've gotta figure out why some of my empty collections are empty collections and some are null
[20:53] <zumbrunn> midnightmonster, I saw you mentioning that before, but I have no idea why that would be
[20:53] <midnightmonster> am I right in thinking empty collection is the right behavior?
[20:54] * zumbrunn also would expect empty collections, not null
[21:03] <midnightmonster> this is (one case) that crashes:
[21:03] <midnightmonster> this.customers.list()
[21:03] <midnightmonster> from type.properties:
[21:03] <midnightmonster> customers = collection(Customer)
[21:03] <midnightmonster> customers.filter = CUSTOMERID in (SELECT DISTINCT CUSTOMERID FROM DISTRIBUTIONS WHERE PRODID IN (SELECT PRODID from PRODUCTS where MFGID = ${MFGID}))
[21:03] <midnightmonster> customers.loadmode = aggressive
[21:03] <midnightmonster> customers.order = CUSTOMERNAME
[21:08] <midnightmonster> (and now I appear to have database corruption, so who knows what the heck is going on)
[21:08] <midnightmonster> (but on a different system than the problem originally showed up on)
[21:25] <midnightmonster> I think I've got it figured out. standby.
[21:54] <midnightmonster> the problem only happened with new objects--that is, the collections of the new (saved) object were not behaving properly. calling this.invalidate() after res.commit() fixed it