Re: Java continuations with joeq
Christopher Oliver wrote: Bertrand Delacretaz wrote: Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? My opinion: probably not. However, I just thought of another drawback with using Joeq's interpreter, namely you wouldn't be able to debug it with a standard Java debugger. The Brakes-like approach doesn't have this limitation. In addition, since that approach simply modifies the bytecode it would still be optimized by Hotspot and would still outperform any scripting language. Torsten, what's the status of your work on this? Chris Slight correction: the current implementation of Brakes does indeed have this limitation - it discards debugging info during class file enhancement - that would have to be fixed to make it truly usable, in my opinion. Chris
Re: Java continuations with joeq
Bertrand Delacretaz wrote: Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? My opinion: probably not. However, I just thought of another drawback with using Joeq's interpreter, namely you wouldn't be able to debug it with a standard Java debugger. The Brakes-like approach doesn't have this limitation. In addition, since that approach simply modifies the bytecode it would still be optimized by Hotspot and would still outperform any scripting language. Torsten, what's the status of your work on this? Chris
Re: Java continuations with joeq
Stefano Mazzocchi wrote: Brian McCallister wrote: Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) Correction: as of a few days ago, PHP is no more a project of the ASF :-) Interesting... I always wondered why PHP is sooo non-Apache... Neither Apache front page nor PHP yet got updated with these news. Vadim
Re: Java continuations with joeq
Brian McCallister wrote: On Feb 21, 2004, at 2:47 PM, Steven Noels wrote: Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) Correction: as of a few days ago, PHP is no more a project of the ASF :-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: Java continuations with joeq
Reinhard Poetz dijo: > Since Cocoon supports continuations they seem to attract more and more > interest in the web development world ;-) This is great! This means Cocoon is the leader in webapp development! :-DD > Anyway, for me only **Java** Flowscript would really make sense because > this would safe the two (technical) arguments against JavaScript flow: > Java is type safe and it is compiled. So you can catch (some) errors at > compile time and not at run time. But it can be abused too. This is one of the "plus" we found a year ago. AFAIK, the initial wisdom started with scheme, then we switched to javascript (thanks to Christian Oliver). All is documented in the 1 year of development in maillists. After Flow development reached a milestone, people started to comment about the pros and cons of using Javascript. Here is a interesting mail of these times (from Stefano): http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105284906231855&w=2 The full thread is here: http://marc.theaimsgroup.com/?t=10527582916&r=1&w=2 Now we have a year of Flow in Cocoon and based on our experience with Flow it is time to think how to improve it. I am not sure if Java is the best. Sometimes I will like to have the power of the eclipse IDE to debug my show flows, but In short I think this is a very interesting discusion that for sure will bring Flow to the next level. Best Regards, Antonio Gallardo
Re: Java continuations with joeq
On Feb 21, 2004, at 2:47 PM, Steven Noels wrote: Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) -Brian
Re: Java continuations with joeq
Steven Noels dijo: > On 21 Feb 2004, at 17:48, Reinhard Poetz wrote: > >> Since Cocoon supports continuations they seem to attract more and more >> interest in the web development world ;-) > > Which proves Ovidiu's visionary skills. We owe him a great deal because > of this. +1 Best Regards, Antonio Gallardo
Re: Java continuations with joeq
Bertrand Delacretaz wrote: Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/archives/001745.html, he says "I'll soon have added support for continuations with Groovy in RIFE too" From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? Groovy itself doesn't have any support for continuations. In RIFE this is provided by the RIFE framework (however, RIFE doesn't appear to support general continuations in Java). Chris
Re: Java continuations with joeq
On 21 Feb 2004, at 19:24, Gianugo Rabellino wrote: Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. I'm two of a kind on this: at the very least, JavaScript is a well-known standardized language, and looking at other uses of Rhino, it is a well-known and robust library. Too bad about the fork unfortunately. Groovy might have more sensible bindings with the Java language, it looks cool, but it's still a little language ATM. Then again, the expression language we use in Woody is a little language as well. Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: Java continuations with joeq
From: Gianugo Rabellino > Reinhard Poetz wrote: > > > If there is support for Groovy, Pyhton, [or whatever] > continuations, I > > personally don't care because it doesn't make a real difference > > (languages are a matter of taste ...) and I don't think we should > > spread our energy over different Flowscript interpreter > > implementations which have to be maintained. > > Well, we actually have to maintain a non-current forked > version of Rhino > (even if pretty stable actually), so I'd much rather change > my taste (I > quite like Javascript flow actually) if that buys me a more > hassle-free > continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
RE: Java continuations with joeq
From: Gianugo Rabellino > Reinhard Poetz wrote: > > > If there is support for Groovy, Pyhton, [or whatever] > continuations, I > > personally don't care because it doesn't make a real difference > > (languages are a matter of taste ...) and I don't think we should > > spread our energy over different Flowscript interpreter > > implementations which have to be maintained. > > Well, we actually have to maintain a non-current forked > version of Rhino > (even if pretty stable actually), so I'd much rather change > my taste (I > quite like Javascript flow actually) if that buys me a more > hassle-free > continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
Re: Java continuations with joeq
Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Ciao, -- Gianugo Rabellino
Re: Java continuations with joeq
On 21 Feb 2004, at 17:48, Reinhard Poetz wrote: Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Which proves Ovidiu's visionary skills. We owe him a great deal because of this. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: Java continuations with joeq
From: Bertrand Delacretaz > Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a > écrit : > > > ...I did some informal tests and it appears to actually be > slower than > > interpreted Rhino (not sure exactly why, perhaps because Rhino > > bytecodes are higher level), but was significantly faster than > > BeanShell (which is a Java source code interpreter). > > Is it a lot slower, do you think it would make a significant > difference? > > > 2) It has an LGPL license. > > Means we might have to talk its author into changing the license, it > wouldn't be the first one ;-) > > Note also an interesting comment of Geert Bevin on Steven's > weblog at > http://blogs.cocoondev.org/stevenn/arch> ives/001745.html, he > says "I'll soon have added support for > continuations with Groovy in RIFE too" > > From what I've seen Groovy looks like a very nice and fairly > complete > scripting language, which also has an ASF-like license. > > So, if Groovy is really close to have continuations, we might want to > wait or help? > > The only mention of continuations that I found on the groovy mailing > lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Anyway, for me only **Java** Flowscript would really make sense because this would safe the two (technical) arguments against JavaScript flow: Java is type safe and it is compiled. So you can catch (some) errors at compile time and not at run time. If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Only my 2 cents ... -- Reinhard
Re: Java continuations with joeq
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/archives/001745.html, he says "I'll soon have added support for continuations with Groovy in RIFE too" From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? The only mention of continuations that I found on the groovy mailing lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 -Bertrand
