Re: [groovy-dev] Why not fewer commands in groovy/bin ?

Re: [groovy-dev] Why not fewer commands in groovy/bin ?

Huxi LI schrieb:

> 
>>the only command needed for beginners is the "groovy" command, and every
>>tutorial should mention this.
> 
> That would be great if the "groovy" command works for interactive mode. 
> I means if users type
> "groovy" without any argument, the interactive shell should be started 
> (Jython and many others
> do that). Unfortunately, the current "groovy" command does not do that.

and the compiler?

> Another thing I would like to say use this email: the "startgroovy" 
> script does not work on my machine (windows 2000). Here is the error 
> message:

take a look into the opther bat files. They are using startGroovy. 
startGroovy is not really something to execute directly. I plan to make 
that possible when I have time to look at the scripts again. Or maybe 
you want to do that. Currently it is:

 <at> rem Determine what directory it is in.
set DIRNAME=%~dp0
if "%DIRNAME%" == "" set DIRNAME=.\

"%DIRNAME%\startGroovy.bat" "%DIRNAME%" groovy.ui.GroovyMain %*

I don't know a way to make a difference between startingGroovy directly 
and through another script. Afaik there is no include mechanism. %~dp0 
gets the current directory. I can't do that in startGroovy, because as 
long as another script is calling startGroovy %~dp0 will change to the 
directory of the other script but that's not the working directory I need.

So if you want to use the startGroovy command directly give it a 
directotry name and the class name. For exmaple:

startGroovy.bat . groovy.ui.Console

Note: the .sh version works a little bit different

bye blackdrag

[groovy-dev] continuations for Groovy!?

Hi,

I thought a little about how to make continuations possible for groovy. 
And then I thought it may be easy. As far as I understand continuations, 
the neat thing is that the stack isn't polluted. I continue a method 
call with another call. This emans we have to leave somehow the method. 
In Java we can do this by return and by Exception.

Let us think we have an ContinuationObject that is returned whenver a 
continuation call is made. That object would store all the data needed 
for the next call. We don't have to return completly to the caller. 
Instead we could, for exmaple in Invoker, test if such a object is 
returned and then make a call to the method inside that object instead. 
Problem here is, a method returning "int" may have problems with the 
verifier if something different that "int" is returned.

Another possibility would be to use Exceptions for this. Again would the 
Exception not go through to the original caller. For Exmaple Invoker 
could catch it and handle it the way as above.

The effect would be that we would leave a method but don't return to the 
caller. Instead we would continue the method call with another method.

To mark a continuation call as such I propose to use "returncc" instead 
of "return". The implementation is really easy as no bytecode is needed 
for this. The next release could have them

comments?

bye blackdrag

Re: [groovy-dev] continuations for Groovy!?

I have to note, that my description is only covering the most simple 
form of continuations and not the more advanced versions.

bye blackdrag

Re: [groovy-dev] continuations for Groovy!?

> Hi,
>
> I thought a little about how to make continuations possible for  
> groovy. And then I thought it may be easy. As far as I understand  
> continuations, the neat thing is that the stack isn't polluted. I  
> continue a method call with another call. This emans we have to  
> leave somehow the method. In Java we can do this by return and by  
> Exception.

In theory javaflow [1] should also work for groovy ...we use bytecode  
instrumentation
to achieve the continuation behavior. I haven't tried it yet though.  
It's still on my
long todo list.

> To mark a continuation call as such I propose to use "returncc"  
> instead of "return". The implementation is really easy as no  
> bytecode is needed for this. The next release could have them

Hm... that sounds really interesting

cheers
--
Torsten

Re: [groovy-dev] Why not fewer commands in groovy/bin ?

Re: [groovy-dev] continuations for Groovy!?

Ups!

[1] http://jakarta.apache.org/commons/sandbox/javaflow

>
>> Hi,
>>
>> I thought a little about how to make continuations possible for  
>> groovy. And then I thought it may be easy. As far as I understand  
>> continuations, the neat thing is that the stack isn't polluted. I  
>> continue a method call with another call. This emans we have to  
>> leave somehow the method. In Java we can do this by return and by  
>> Exception.
>
> In theory javaflow [1] should also work for groovy ...we use  
> bytecode instrumentation
> to achieve the continuation behavior. I haven't tried it yet  
> though. It's still on my
> long todo list.
>
>> To mark a continuation call as such I propose to use "returncc"  
>> instead of "return". The implementation is really easy as no  
>> bytecode is needed for this. The next release could have them
>
> Hm... that sounds really interesting
>
> cheers
> --
> Torsten
>

Re: [groovy-dev] continuations for Groovy!?

On 2 Dec 2005, at 09:29, Jochen Theodorou wrote:

> I have to note, that my description is only covering the most  
> simple form of continuations and not the more advanced versions.

Could you post a small example showing how this would be used?

Would this be something like the Python generator? See: http:// 
www.python.org/peps/pep-0255.html

John Wilson
The Wilson Partnership
http://www.wilson.co.uk

Re: [groovy-dev] continuations for Groovy!?

Torsten Curdt schrieb:
>> Hi,
>>
>> I thought a little about how to make continuations possible for  
>> groovy. And then I thought it may be easy. As far as I understand  
>> continuations, the neat thing is that the stack isn't polluted. I  
>> continue a method call with another call. This emans we have to  leave 
>> somehow the method. In Java we can do this by return and by  Exception.
> 
> In theory javaflow [1] should also work for groovy ...we use bytecode  
> instrumentation
> to achieve the continuation behavior. I haven't tried it yet though.  
> It's still on my long todo list.

the problem is to save the stack. My "solution" would destroy the stack. 
It's more something like a explicit tail recursion call that throws away 
the current stack element and continues the execution in another. You 
can simulate some advanced continuations when you allow returncc to 
usean additional  closures

def foo(x) {
   if (x>100000) return
   y=x+1
   foo(y)
   println y
}

would be transformed into

def foo(x) {
   if (x>100000) return
   y=x+1
   returncc foo(y),{println y}
}

the closure saves the value of y even if we leave foo. returncc would 
leave the function foo and continue the call foo(y) saving the the 
closure in a list. If there is no continuation call left, then we would 
take the top element of the list and execute it. If more continuation 
calls are done then the list would be expanded. But this too is not what 
a real continuation is or am I wrong about that? Oh, and of course it is 
not easy to continue a normal loop that way:

def foo(x) {
   if (x>100000) return
   y=x+1
   for (i in 1..4) { foo(y) }
   println y
}

closure are even more complicated as you don't wnat to leave the 
closures call only, you want to leave the whole function.

>> To mark a continuation call as such I propose to use "returncc"  
>> instead of "return". The implementation is really easy as no  bytecode 
>> is needed for this. The next release could have them
> 
> Hm... that sounds really interesting

the use may be limited, but I think it is still usefull.

implementing our own version of javaflow would be another solution. The 
mechanism I described does not return a continuation object. So you 
can't control it like in javaflow.
Unlike javaflow's starting point we have full control about the things 
we generate and don't need to transform method calls later. So we don't 
really have to keep a complete Stackframe of our own, we could let the 
compiler find out what is needed and what not. It's a mechanism like we 
use for closures.

bye blackdrag

Re: [groovy-dev] continuations for Groovy!?

> implementing our own version of javaflow would be another solution.

It always is ;) ...but be sure I'll be at least watching ;)

> The mechanism I described does not return a continuation object. So  
> you can't control it like in javaflow.
> Unlike javaflow's starting point we have full control about the  
> things we generate and don't need to transform method calls later.

Which is a much better starting point ...yepp!

> So we don't really have to keep a complete Stackframe of our own,  
> we could let the compiler find out what is needed and what not.

Well, we don't really keep a second copy of all stack
frames until you return the continuation.

...we analyse the bytecode to see what's on the stack
at a certain instruction and make sure we have the right
code in place to save and restore the call stack. So in
fact the resulting continuation is a copy of the call
stack with some information where to resume.

Given that the objects in the resulting stack frames
are serializable you can even write that continuation
to disk! ...and resume it later on of course

cheers
--
Torsten