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 ex

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 th

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 reque

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

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 t

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 j

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

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 -

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

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 ch