Just found it by looking at the code, of course :-) *groovy:*000*>* :set interpreterMode true
*groovy:*000*>* def a = 1 *===>* 1 *groovy:*000*>* println a 1 On Wed, May 24, 2017 at 11:27 AM, Guillaume Laforge <[email protected]> wrote: > There's a parameter, I believe, for enabling this behavior already. > I just can't remember what it is, but I'm pretty sure there is. > > On Wed, May 24, 2017 at 11:00 AM, Andres Almiray <[email protected]> > wrote: > >> Reusing the binding between invocations would be a way to get around this >> problem. >> However we'd need a new command to clear/reset the binding. >> >> Cheers, >> Andres >> >> ------------------------------------------- >> Java Champion; Groovy Enthusiast >> http://andresalmiray.com >> http://www.linkedin.com/in/aalmiray >> -- >> What goes up, must come down. Ask any system administrator. >> There are 10 types of people in the world: Those who understand binary, >> and those who don't. >> To understand recursion, we must first understand recursion. >> >> On Wed, May 24, 2017 at 10:57 AM, Remi Forax <[email protected]> wrote: >> >>> Hi Jochen, >>> jshell, the equivalent of groovysh for java included in 9, does >>> something like this, >>> it stores the content of all variables declaration as fields into a >>> synthetic class and all statements as method so statement have access to >>> the content of the field. >>> >>> But because you have bindings in groovy, it may be simpler ? (i do not >>> know if bindings are typed ?) >>> >>> cheers, >>> Rémi >>> >>> ----- Mail original ----- >>> > De: "Jochen Theodorou" <[email protected]> >>> > À: [email protected] >>> > Envoyé: Mercredi 24 Mai 2017 09:49:32 >>> > Objet: groovysh and local variables >>> >>> > Hi, >>> > >>> > a User on the user-list mentioned it is currently not possible to >>> define >>> > a local variable in one evaluation and use it in the next. So for >>> example >>> > >>> > > def x = 10 >>> > >>> > > println x >>> > >>> > this fails because the eval for println x has no knowledge about x=10. >>> > >>> > Is this correct, did we have any plans to change this? I mean I know >>> why >>> > it behaves like that and as a script you would get the same. But in the >>> > context of groovysh I really wonder if that makes sense. We could >>> > extract the top level local variables using a transform and make them >>> > and their values available to the next evaluation >>> > >>> > bye Jochen >>> >> >> > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
