groovysh and local variables

2017-05-24 Thread Jochen Theodorou

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


Re: groovysh and local variables

2017-05-24 Thread Remi Forax
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" 
> À: dev@groovy.apache.org
> 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


Re: groovysh and local variables

2017-05-24 Thread Andres Almiray
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  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" 
> > À: dev@groovy.apache.org
> > 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
>


Re: groovysh and local variables

2017-05-24 Thread Guillaume Laforge
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  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  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" 
>> > À: dev@groovy.apache.org
>> > 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  / Google+



Re: groovysh and local variables

2017-05-24 Thread Guillaume Laforge
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 
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 
> 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  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" 
>>> > À: dev@groovy.apache.org
>>> > 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  / Google+
> 
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+



Re: groovysh and local variables

2017-05-24 Thread Jochen Theodorou



On 24.05.2017 10:57, Remi Forax 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 ?)


bindings are not typed

bye Jochen


Re: groovysh and local variables

2017-05-24 Thread Jochen Theodorou

thanks, I added that to the user list post

On 24.05.2017 11:32, Guillaume Laforge wrote:

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 mailto:glafo...@gmail.com>> 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 mailto:aalmi...@gmail.com>> 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 mailto:fo...@univ-mlv.fr>> 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" mailto:blackd...@gmx.org>>
> À: dev@groovy.apache.org 
> 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  / Google+





--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+



Re: Help with task: GroovyConsole improvement: configurable output area size

2017-05-24 Thread John Wagenleitner
Hi Emilian,

Nice work, I tried out the new prefs dialog on Linux and Windows and it
looks good to me.  I don't have a Mac to test with, but it sounds like a
nice touch adding it into the Mac menu bar.

I would recommend putting the commit in a separate feature branch before
submitting a pull request.  It makes merging in changes from upstream
easier.

John

On Sun, May 21, 2017 at 1:32 PM, Emilian Bold 
wrote:

> See https://github.com/emilianbold/groovy/commit/
> 6d0e4fa95190580d49e225b47158c79c42fa68f6
>
> I've started from your solution and made some changes:
>
> * Console.groovy also needs to load maxOutputChars from the prefs
> * ConsolePreferences.groovy fixes only this issue, without the log file.
> The layout is also simpler and with less hardcoded dimensions
> * MacOSXMenuBar.groovy moves the action into the standard App |
> Preferences menu
>
>
> --emi
>
> On Sat, May 20, 2017 at 6:16 PM, John Wagenleitner <
> john.wagenleit...@gmail.com> wrote:
>
>> Hi Emilian,
>>
>> On Sat, May 20, 2017 at 7:35 AM, Emilian Bold 
>> wrote:
>>
>>> You initial dialog is a good start, but what should it hold: all the
>>> pref keys from Console? Or just start with maxOutputChars?
>>>
>>>
>> I don't think it would be necessary to add all the options already
>> available to the dialog, so initially I'd just see it having the
>> maxOutputChars setting.  Another option would be to add the setting under
>> the "View" menu and have it pop up a specialized dialog used to just
>> capture the maxOutputChars.  Not sure which is better, just sort of feels
>> like the existing menu is getting kind of crowded so that's why I was
>> initially thinking a general "Settings" dialog would a way to go.
>>
>>
>>> The log file UI should be added once #8180 is done.
>>>
>>> I never touched GroovyConsole before, but it seems interesting. Reminds
>>> me of ANTLRWorks which I just used the other week for some small parser.
>>>
>>> Also, this console would also make a fine IDE plugin. Any particular
>>> reason GroovyConsole has to be standalone?
>>>
>>>
>> I know IDEA provides a GroovyConsole and GroovyShell under the Tools menu
>> when Groovy is part of the project.
>>
>>
>>>
>>>
>>> --emi
>>>
>>> On Fri, May 19, 2017 at 6:01 PM, John Wagenleitner <
>>> john.wagenleit...@gmail.com> wrote:
>>>
 Hi Emilian,

 I added a comment on that issue, I think it would also be handy to have
 a new Preferences dialog for general settings such as this. Having a dialog
 behind a new menu item such as Edit > Preferences could have an edit box
 for inputting/displaying the output limit that is backed by a preference.
 This could also be where the log to file option could be place (another
 request [1]).  In case some bits may be helpful, I started to play with
 this a while back just to get more familiar with Swing/Groovy but never
 finished [2].

 Glad to hear you found this issue on the help wanted site.

 John

 [1] https://issues.apache.org/jira/browse/GROOVY-8180
 [2] https://github.com/jwagenleitner/groovy/commit/f0181f156
 4fdb0357b3852d15b0730582cc468ce

 On Fri, May 19, 2017 at 7:31 AM, Emilian Bold 
 wrote:

> Hello,
>
> I would like to help out with the task listed at
> https://helpwanted.apache.org/task.html?72ff9c55
>
> Console.groovy maxOutputChars already has a System.property so I'm not
> certain what's required for #GROOVY-3270, perhaps something like:
>
> -int maxOutputChars = 
> System.getProperty('groovy.console.output.limit','2')
> as int
> +int maxOutputChars = prefs.getInt("outputLimit", 2)
>
> --emi
>


>>>
>>
>


Re: Help with task: GroovyConsole improvement: configurable output area size

2017-05-24 Thread Emilian Bold
I made a separate branch and a PR https://github.com/apache/groovy/pull/548

If you want you can commit with your user, most of the code is actually
yours.



--emi

On Wed, May 24, 2017 at 6:01 PM, John Wagenleitner <
john.wagenleit...@gmail.com> wrote:

> Hi Emilian,
>
> Nice work, I tried out the new prefs dialog on Linux and Windows and it
> looks good to me.  I don't have a Mac to test with, but it sounds like a
> nice touch adding it into the Mac menu bar.
>
> I would recommend putting the commit in a separate feature branch before
> submitting a pull request.  It makes merging in changes from upstream
> easier.
>
> John
>
> On Sun, May 21, 2017 at 1:32 PM, Emilian Bold 
> wrote:
>
>> See https://github.com/emilianbold/groovy/commit/6d0e4fa9519
>> 0580d49e225b47158c79c42fa68f6
>>
>> I've started from your solution and made some changes:
>>
>> * Console.groovy also needs to load maxOutputChars from the prefs
>> * ConsolePreferences.groovy fixes only this issue, without the log file.
>> The layout is also simpler and with less hardcoded dimensions
>> * MacOSXMenuBar.groovy moves the action into the standard App |
>> Preferences menu
>>
>>
>> --emi
>>
>> On Sat, May 20, 2017 at 6:16 PM, John Wagenleitner <
>> john.wagenleit...@gmail.com> wrote:
>>
>>> Hi Emilian,
>>>
>>> On Sat, May 20, 2017 at 7:35 AM, Emilian Bold 
>>> wrote:
>>>
 You initial dialog is a good start, but what should it hold: all the
 pref keys from Console? Or just start with maxOutputChars?


>>> I don't think it would be necessary to add all the options already
>>> available to the dialog, so initially I'd just see it having the
>>> maxOutputChars setting.  Another option would be to add the setting under
>>> the "View" menu and have it pop up a specialized dialog used to just
>>> capture the maxOutputChars.  Not sure which is better, just sort of feels
>>> like the existing menu is getting kind of crowded so that's why I was
>>> initially thinking a general "Settings" dialog would a way to go.
>>>
>>>
 The log file UI should be added once #8180 is done.

 I never touched GroovyConsole before, but it seems interesting. Reminds
 me of ANTLRWorks which I just used the other week for some small parser.

 Also, this console would also make a fine IDE plugin. Any particular
 reason GroovyConsole has to be standalone?


>>> I know IDEA provides a GroovyConsole and GroovyShell under the Tools
>>> menu when Groovy is part of the project.
>>>
>>>


 --emi

 On Fri, May 19, 2017 at 6:01 PM, John Wagenleitner <
 john.wagenleit...@gmail.com> wrote:

> Hi Emilian,
>
> I added a comment on that issue, I think it would also be handy to
> have a new Preferences dialog for general settings such as this. Having a
> dialog behind a new menu item such as Edit > Preferences could have an 
> edit
> box for inputting/displaying the output limit that is backed by a
> preference. This could also be where the log to file option could be place
> (another request [1]).  In case some bits may be helpful, I started to 
> play
> with this a while back just to get more familiar with Swing/Groovy but
> never finished [2].
>
> Glad to hear you found this issue on the help wanted site.
>
> John
>
> [1] https://issues.apache.org/jira/browse/GROOVY-8180
> [2] https://github.com/jwagenleitner/groovy/commit/f0181f156
> 4fdb0357b3852d15b0730582cc468ce
>
> On Fri, May 19, 2017 at 7:31 AM, Emilian Bold 
> wrote:
>
>> Hello,
>>
>> I would like to help out with the task listed at
>> https://helpwanted.apache.org/task.html?72ff9c55
>>
>> Console.groovy maxOutputChars already has a System.property so I'm
>> not certain what's required for #GROOVY-3270, perhaps something like:
>>
>> -int maxOutputChars = 
>> System.getProperty('groovy.console.output.limit','2')
>> as int
>> +int maxOutputChars = prefs.getInt("outputLimit", 2)
>>
>> --emi
>>
>
>

>>>
>>
>


Re: Help with task: Groovydoc improved comment extraction

2017-05-24 Thread Paul King
Ah, yes I had forgotten about that when I wrote the ticket. I'll rework the
ticket in a little while.

Cheers, Paul.

On Wed, May 24, 2017 at 8:02 AM, Emilian Bold 
wrote:

> I would like to help out with the task listed at
> https://helpwanted.apache.org/task.html?6afc5096
>
> I've only briefly explored the code, but it seems to me
> SimpleGroovyClassDocAssembler#getJavaDocCommentsBeforeNode() is called
> with the ANTLR 2.7.7 parsers JavaRecognizer and GroovyRecognizer which
> produce org.codehaus.groovy.antlr.GroovySourceAST trees.
>
> Parrot will produce org.codehaus.groovy.ast.ASTNode trees.
>
> So the issue isn't just about changing getJavaDocCommentsBeforeNode and
> using the comment node (assuming we have EXTRACTING_DOC_COMMENT_ENABLED).
>
> SimpleGroovyClassDocAssembler must more or less be rewritten for the
> Parrot parser.
>
> --emi
>
>