Unexpected invocation of getter method with Groovy 4

2023-10-28 Thread Paolo Di Tommaso
Dear community,

After switching to Groovy 4, I've observed an expected invocation of the
Map get method while resolving a closure delegate context.

Consider the following custom Map object in which both `get` and
`invokeMethod` methods are overridden:

class Context implements Map {

@Delegate private Map target

Context(Map target) { this.target = target }

@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}

@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}



Now, a closure tries to invoke the `foo` method via a context delegate, as
shown below:

def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK'



However, the above snipper fails with the following message:

java.lang.Exception: Missing key: foo


Why does the closure try to access the `foo` attribute instead of invoking
it as a method? This code works as expected with Groovy 3.



Thanks,
Paolo


Re: Update the Groovy color used on github.

2021-06-16 Thread Paolo Di Tommaso
Nice!

On Wed, Jun 16, 2021 at 3:10 PM sigzero  wrote:

> +1
>
> On Wed, Jun 16, 2021 at 7:57 AM Søren Berg Glasius 
> wrote:
>
>> +1
>>
>> Good call!
>>
>> Best regards / Med venlig hilsen,
>> Søren Berg Glasius
>>
>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>> Mobile: +45 40 44 91 88, Skype: sbglasius
>> --- Press ESC once to quit - twice to save the changes.
>>
>>
>> Den ons. 16. jun. 2021 kl. 09.11 skrev Mario Garcia > >:
>>
>>> +1
>>>
>>> El mié, 16 jun 2021 a las 1:15, Paul King ()
>>> escribió:
>>>
 +1

 On Fri, Jun 11, 2021 at 3:24 PM Michael Bailey <
 michaelbail...@gmail.com> wrote:

> I opened a PR to get the Groovy color on Github updated to the blue
> from the logo.
> See https://github.com/github/linguist/pull/5418
>
> If you would like to see Github use the color from the Groovy logo,
> please reply with a +1 to this thread and give a thumbs up on this PR ->
> https://github.com/github/linguist/pull/5418
>
> The plus one on this thread will help show community support.
>



Re: No signature of method: javax.swing.JMenu.setMnemonic()

2020-11-09 Thread Paolo Di Tommaso
Turns out here the problem was that since I'm using a custom classloader,
it was not applying properly the extensions methods defined in groovy-swing
module.


p

On Thu, Oct 15, 2020 at 11:15 AM Paolo Di Tommaso 
wrote:

> Unfortunately no. Not sure how to address it because it seems a type
> conversion problem in the `MacOSXmenuBar`
>
> ```
> menu(text: 'File', mnemonic: 'F') {
> menuItem(newFileAction, icon:null)
> menuItem(newWindowAction, icon:null)
> menuItem(openAction, icon:null)
> separator()
> menuItem(saveAction, icon:null)
> menuItem(saveAsAction, icon:null)
> separator()
> menuItem(printAction, icon:null)
> }
> ```
>
> it should be
>
> ```
> menu(text: 'File', mnemonic: 'F' as char)
> ```
>
>
> On Tue, Oct 13, 2020 at 9:18 PM Mariusz W  wrote:
>
>> Hi,
>> Have you resolved that issue?
>> I have done some tests but on Windows and it works ok.
>>
>> Regards,
>> M
>>
>> On Sun, 11 Oct 2020 at 19:35, Paolo Di Tommaso 
>> wrote:
>>
>>> Dear all,
>>>
>>> I'm getting this exception while launching the Groovy console from my
>>> app.
>>>
>>>
>>> groovy.lang.MissingMethodException: No signature of method:
>>> javax.swing.JMenu.setMnemonic() is applicable for argument types: (String)
>>> values: [F]
>>> Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
>>> at
>>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:70)
>>> at
>>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:76)
>>> at
>>> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:80)
>>> at
>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
>>> at
>>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy:79)
>>> at
>>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy)
>>> :
>>>Complete stack trace here <https://pastebin.pl/view/0e4fbff3>.
>>>
>>>
>>> I saw this was an issue with Groovy 3 beta
>>> <https://issues.apache.org/jira/browse/GROOVY-8253>, however, I'm using
>>> Groovy 3.0.5, Java 8 on MacOS.
>>>
>>>
>>>
>>> Any clue what's could be the problem?
>>>
>>>
>>> Thanks,
>>> Paolo
>>>
>>>


Re: No signature of method: javax.swing.JMenu.setMnemonic()

2020-10-15 Thread Paolo Di Tommaso
Unfortunately no. Not sure how to address it because it seems a type
conversion problem in the `MacOSXmenuBar`

```
menu(text: 'File', mnemonic: 'F') {
menuItem(newFileAction, icon:null)
menuItem(newWindowAction, icon:null)
menuItem(openAction, icon:null)
separator()
menuItem(saveAction, icon:null)
menuItem(saveAsAction, icon:null)
separator()
menuItem(printAction, icon:null)
}
```

it should be

```
menu(text: 'File', mnemonic: 'F' as char)
```


On Tue, Oct 13, 2020 at 9:18 PM Mariusz W  wrote:

> Hi,
> Have you resolved that issue?
> I have done some tests but on Windows and it works ok.
>
> Regards,
> M
>
> On Sun, 11 Oct 2020 at 19:35, Paolo Di Tommaso 
> wrote:
>
>> Dear all,
>>
>> I'm getting this exception while launching the Groovy console from my
>> app.
>>
>>
>> groovy.lang.MissingMethodException: No signature of method:
>> javax.swing.JMenu.setMnemonic() is applicable for argument types: (String)
>> values: [F]
>> Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
>> at
>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:70)
>> at
>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:76)
>> at
>> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:80)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
>> at
>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy:79)
>> at
>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy)
>> :
>>Complete stack trace here <https://pastebin.pl/view/0e4fbff3>.
>>
>>
>> I saw this was an issue with Groovy 3 beta
>> <https://issues.apache.org/jira/browse/GROOVY-8253>, however, I'm using
>> Groovy 3.0.5, Java 8 on MacOS.
>>
>>
>>
>> Any clue what's could be the problem?
>>
>>
>> Thanks,
>> Paolo
>>
>>


No signature of method: javax.swing.JMenu.setMnemonic()

2020-10-11 Thread Paolo Di Tommaso
Dear all,

I'm getting this exception while launching the Groovy console from my app.


groovy.lang.MissingMethodException: No signature of method:
javax.swing.JMenu.setMnemonic() is applicable for argument types: (String)
values: [F]
Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:70)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:76)
at
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:80)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
at
groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy:79)
at
groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy)
:
   Complete stack trace here .


I saw this was an issue with Groovy 3 beta
, however, I'm using
Groovy 3.0.5, Java 8 on MacOS.



Any clue what's could be the problem?


Thanks,
Paolo


Groovy job opportunity

2020-09-18 Thread Paolo Di Tommaso
Hello community!

We are looking for an experienced Groovy/Java developer, ideally
Barcelona/Europe located to expand the Nextflow ecosystem.

More details at this link:

https://seqera.io/jobs/snr-software-eng-java-groovy/


Spread the word!


Thanks, Paolo


Re: Congratulations to our newest committer Mikko Värri

2020-06-08 Thread Paolo Di Tommaso


On Mon, Jun 8, 2020 at 12:37 PM Mikko Värri  wrote:

> Thank you all!  I'm honored and looking forward to spending more time on
> Groovy!
>
> I'm not sure if it's customary to write a short introduction but I'll do
> it anyway: I'm from Finland, I've been into Groovy for almost 10 years I
> think, my twitter bio says "sneaking Groovy into customer systems" and
> that's what I've been doing all those years ;D
>
> Yes, I tend to care about documentation, so fixing glitches in groovydoc
> has been an interest of mine.
>
> -mikko
>
>
> > On 8. Jun 2020, at 3.06, 孙 岚  wrote:
> >
> > Congratulations to Mikko Värri who is now an Apache Groovy committer:
> >
> > https://projects.apache.org/committee.html?groovy
> > http://people.apache.org/phonebook.html?unix=groovy
> >
> > Mikko has been mostly working on the groovydoc, which is important to
> Groovy users and developers.
> >
> > Keep on your great work, Mikko.
> >
> > Cheers,
> > Daniel Sun
>
>


NoClassDefFoundError: groovy.swing.SwingBuilder

2020-02-11 Thread Paolo Di Tommaso
Has anybody experienced `NoClassDefFoundError: groovy.swing.SwingBuilder`
while building a project with the latest Groovy 3 and Gradle 6.0.1?

The complete stack trace at this link

https://pastebin.com/j2JYvGdG


Cheers, p


Re: [ANNOUNCE] Apache Groovy 3.0.0 released

2020-02-10 Thread Paolo Di Tommaso
Congrats, folks!! 

On Mon, Feb 10, 2020 at 3:46 PM Søren Berg Glasius 
wrote:

> Awesome. A new Era has begun 
>
> Med venlig hilsen / Best regards
>
> Søren Berg Glasius
>
> Sent from my phone, thus brief
>
> On Mon, Feb 10, 2020, 14:06 Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 3.0.0 of Apache
>> Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the https://groovy.apache.org website.
>>
>> We are sure you'll enjoy the features in this new version of Groovy.
>> Your feedback on any unintentional glitches is welcome.
>>
>> This release includes 15 bug fixes/improvements since RC3 as outlined
>> in the changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345566
>> (There are over 500 new features, improvements and bug fixes since Groovy
>> 2.5!)
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: https://groovy.apache.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want to thank
>> everyone who contributed to this release. We value all forms of
>> contribution from our contributors past and present but special
>> mention for this release should be made to Daniel Sun for his
>> instrumental contributions to the Parrot parser and Eric Milles for
>> his recent improvements to Groovy's static compiler.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>


GROOVY-9209

2020-01-22 Thread Paolo Di Tommaso
Dear all,

I want to report again the issue GROOVY-9209
 that
plagues the Groovy compilation with IntelliJ Idea.

The IntelliJ incremental compilation is much faster than delegating it to
Gradle, however, the groovyc compiler reports a compilation bug every time
a class is modified with a code generation annotation (e.g. Grails GORM,
Micronaut, etc).

This makes the overall experience extremely painful.


Cheers,
Paolo


Re: Byte literal

2020-01-16 Thread Paolo Di Tommaso
For reference

https://issues.apache.org/jira/browse/GROOVY-9366


p

On Wed, Jan 15, 2020 at 11:37 PM Paolo Di Tommaso 
wrote:

> To summarize the current status
>
> First try:
>
> public @interface Version {
> byte value();
> }
> class Foo {
>   @Version(0x01) String bar
> }
>
>
>   Error: Attribute 'value' should have type 'java.lang.Byte'; but
> found type 'int' in @Version
>
> Second try:
>
> public @interface Version {
> byte value();
> }
> class Foo {
>   @Version(1 as byte) String bar
> }
>
> Expected '(byte) 1' to be an inline constant of type byte in @Version
>  at line: 6, column: 14
>
> Attribute 'value' should have type 'java.lang.Byte'; but found type
> 'java.lang.Object' in @Version
>  at line: -1, column: -1
>
>
> Third try:
>
>
> public @interface Version {
> byte value();
> }
> class Foo {
>   public static final byte ONE = 0b01
>   @Version(ONE) String bar
> }
>
> Expected 'ONE' to be an inline constant of type byte not a field
> expression in @Version
>  at line: 7, column: 12
>
> Attribute 'value' should have type 'java.lang.Byte'; but found type
> 'java.lang.Object' in @Version
>  at line: -1, column: -1
>
>
>
> This is a very sad story.
>
>
> p
>
>
> On Wed, Jan 15, 2020 at 11:14 PM Simon Sadedin  wrote:
>
>> >I'm getting the following error:
>> >
>> > Error:Groovyc: Attribute 'value' should have type 'java.lang.Byte'; but
>> found type 'java.lang.Integer' in @Version
>>
>> I have a similar type of problem where I cannot find any way to invoke
>> Arrays.fill() for the byte version  - even with explicit workarounds that
>> should ensure a primitive byte is passed, for example:
>>
>> def result = new byte[10][10]
>> final Byte minusOne = -1
>> for(int i=0; i<10; ++i) {
>> Arrays.fill(result, 0, dim, minusOne.byteValue())
>> }
>>
>> It happens with and without CompileStatic and results in:
>>
>> java.lang.ArrayStoreException: java.lang.Byte
>> at java.util.Arrays.fill(Arrays.java:3155)
>>
>> For these kind of cases  I'm left having to create little Java stub
>> workarounds to get it to call the right underlying Java API.
>>
>> Would be nice to have at least a way to work around this!
>>
>> Cheers,
>>
>> Simon
>>
>>
>>


Re: Byte literal

2020-01-15 Thread Paolo Di Tommaso
To summarize the current status

First try:

public @interface Version {
byte value();
}
class Foo {
  @Version(0x01) String bar
}


  Error: Attribute 'value' should have type 'java.lang.Byte'; but found
type 'int' in @Version

Second try:

public @interface Version {
byte value();
}
class Foo {
  @Version(1 as byte) String bar
}

Expected '(byte) 1' to be an inline constant of type byte in @Version
 at line: 6, column: 14

Attribute 'value' should have type 'java.lang.Byte'; but found type
'java.lang.Object' in @Version
 at line: -1, column: -1


Third try:


public @interface Version {
byte value();
}
class Foo {
  public static final byte ONE = 0b01
  @Version(ONE) String bar
}

Expected 'ONE' to be an inline constant of type byte not a field expression
in @Version
 at line: 7, column: 12

Attribute 'value' should have type 'java.lang.Byte'; but found type
'java.lang.Object' in @Version
 at line: -1, column: -1



This is a very sad story.


p


On Wed, Jan 15, 2020 at 11:14 PM Simon Sadedin  wrote:

> >I'm getting the following error:
> >
> > Error:Groovyc: Attribute 'value' should have type 'java.lang.Byte'; but
> found type 'java.lang.Integer' in @Version
>
> I have a similar type of problem where I cannot find any way to invoke
> Arrays.fill() for the byte version  - even with explicit workarounds that
> should ensure a primitive byte is passed, for example:
>
> def result = new byte[10][10]
> final Byte minusOne = -1
> for(int i=0; i<10; ++i) {
> Arrays.fill(result, 0, dim, minusOne.byteValue())
> }
>
> It happens with and without CompileStatic and results in:
>
> java.lang.ArrayStoreException: java.lang.Byte
> at java.util.Arrays.fill(Arrays.java:3155)
>
> For these kind of cases  I'm left having to create little Java stub
> workarounds to get it to call the right underlying Java API.
>
> Would be nice to have at least a way to work around this!
>
> Cheers,
>
> Simon
>
>
>


Re: Byte literal

2020-01-15 Thread Paolo Di Tommaso
Even more strangely, I can use Byte.MAX_VALUE as an argument, but if I try
to use a const declared as

public static final byte BAR = 1;


Im getting the following error:

Error:Groovyc: Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Integer' in @Version


What am I missing?


Thanks, p


On Wed, Jan 15, 2020 at 6:26 PM Paolo Di Tommaso 
wrote:

> Hello folks,
>
> Is there any way to specify an inline byte literal with groovy? I'm asking
> because I'm stuck trying to specify a byte parameter into an
> annotation declared as such
>
> public @interface Version {
> byte value();
> }
>
>
> I was unable to find a solution.
>
> Thanks a lot.
>
> p
>
>
>


Byte literal

2020-01-15 Thread Paolo Di Tommaso
Hello folks,

Is there any way to specify an inline byte literal with groovy? I'm asking
because I'm stuck trying to specify a byte parameter into an
annotation declared as such

public @interface Version {
byte value();
}


I was unable to find a solution.

Thanks a lot.

p


Re: Groovy 3.0.0-beta3 and Spock

2019-08-08 Thread Paolo Di Tommaso
Yes, fix solves the compilation error, tho now I got a bunch of failing
tests, tho it looks more related to a Spock problem.

Thanks!

On Thu, Aug 8, 2019 at 12:37 AM Marcin Zajączkowski  wrote:

> On 2019-08-07 20:33, Paolo Di Tommaso wrote:
> > Team, congrats for a new build toward Groovy 3.0
> >
> > I've was giving it a try and I'm getting this compilation error related
> to
> > Spock:
> >
> > startup failed:
> > Could not instantiate global transform class
> > org.spockframework.compiler.SpockTransform specified at
> >
> jar:file:/Users/pditommaso/.gradle/caches/modules-2/files-2.1/org.spockframework/spock-core/1.3-groovy-2.5/6f0df2cf4549dcc4b914971675da7e224e893e82/spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> >  because of exception java.lang.reflect.InvocationTargetException
> >
> >
> >  May a new version of Spock is expected to be used with Groovy 3?
>
> Hi. You may want to checked with the snapshot version of Spock as
> described in that issue:
> https://github.com/spockframework/spock/issues/997 and report the
> potential problems there.
>
> Marcin
>
> --
> https://blog.solidsoft.info/ - Working code is not enough
>


Groovy 3.0.0-beta3 and Spock

2019-08-07 Thread Paolo Di Tommaso
Team, congrats for a new build toward Groovy 3.0

I've was giving it a try and I'm getting this compilation error related to
Spock:

startup failed:
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/Users/pditommaso/.gradle/caches/modules-2/files-2.1/org.spockframework/spock-core/1.3-groovy-2.5/6f0df2cf4549dcc4b914971675da7e224e893e82/spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
 because of exception java.lang.reflect.InvocationTargetException


 May a new version of Spock is expected to be used with Groovy 3?


Re: (no subject)

2019-07-24 Thread Paolo Di Tommaso
Sure thing, here it is the build scan

https://scans.gradle.com/s/bhg44ys4znhei


The critical error looks this

Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/Users/pditommaso/.gradle/caches/modules-2/files-2.1/org.spockframework/spock-core/1.3-groovy-2.5/6f0df2cf4549dcc4b914971675da7e224e893e82/spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
 because of exception java.lang.reflect.InvocationTargetException



p

On Thu, Jul 25, 2019 at 1:46 AM Daniel.Sun  wrote:

> Could you provide more details? e.g. gradle scan report, compilation error
> messages, etc.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


[no subject]

2019-07-24 Thread Paolo Di Tommaso
Is anybody experiencing this compilation error using Groovy 3.0.0-Beta-2?

https://pastebin.com/raw/MW5933Rz



p


Re: Which issue do you MOST want to fix

2019-02-20 Thread Paolo Di Tommaso
Dear community,

Regarding important issues to fix in Groovy 3.0, I would raise your
attention to the problem that currently Groovy does not allow the
overriding of the toString and equals methods for custom collection object
i.e. Set, List, Map.

I've raised several times this problem in the past and though the community
agreed that this is an important limitation, there was not consensus on the
solution. Groovy 3.0 could be a good opportunity to have this problem
solved. I've opened an issue including a possible solution.

https://issues.apache.org/jira/browse/GROOVY-9003

Hope you will take in consideration for the next Groovy major release.

Cheers,
Paolo


On Mon, Feb 18, 2019 at 6:32 AM Basil Peace  wrote:

> Hi, Daniel!
>
> Nice to hear that!
> Thanks.
>
> --
> Best regards,
> Basil Peace
>
>
> 17.02.2019, 07:08, "Daniel.Sun" :
> > Hi Basil,
> >
> >   We plan to re-write Groovydoc from scratch to gain better
> maintenance
> > and fix all the existing issues. It is targeted to Groovy 3.0.0.
> >
> > Cheers,
> > Daniel.Sun
> >
> > -
> > Apache Groovy committer
> > Blog: http://blog.sunlan.me
> > Twitter: @daniel_sun
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: GraalVM with Groovy and Grape

2019-01-16 Thread Paolo Di Tommaso
I've made a skeleton to quick start with it

https://github.com/pditommaso/groovy-native


p

On Thu, Jan 17, 2019 at 6:48 AM Daniel Sun  wrote:

> Nice post. I've read it.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


[no subject]

2018-12-24 Thread Paolo Di Tommaso
Dear all,

I'm the only one experiencing the following exception every time I'm modify
a source in the code base and then trying to run a test with IntelliJ?

The only way to make it work is to use the "rebuild" command which takes
quite a long.


Error:Groovyc: While compiling nextflow_main: BUG! exception in phase
'class generation' in source unit '/Users/.../ProcessFactory.groovy' JVM
class can't be loaded for nextflow.executor.Executor
at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:88)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:176)
at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1359)
at
org.codehaus.groovy.classgen.asm.BytecodeHelper.getClassInternalName(BytecodeHelper.java:63)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateInstanceof(BinaryExpressionHelper.java:644)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:275)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:707)
at
org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:51)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBooleanExpression(AsmClassGenerator.java:829)
at
org.codehaus.groovy.ast.expr.BooleanExpression.visit(BooleanExpression.java:42)
at
org.codehaus.groovy.classgen.asm.StatementWriter.writeIfElse(StatementWriter.java:292)
at
org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeIfElse(OptimizingStatementWriter.java:323)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitIfElse(AsmClassGenerator.java:651)
at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:43)
at
org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:93)
at
org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:205)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:635)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:110)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:121)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:495)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:431)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:132)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:576)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:269)
at
org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:858)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1095)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:649)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:627)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:604)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:160)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:89)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException:
nextflow.processor.TaskProcessor
at
org.jetbrains.groovy.compiler.rt.ClassDependencyLoader.loadClassDependencies(ClassDependencyLoader.java:106)
at

Re: Clousure expression transformation

2018-09-25 Thread Paolo Di Tommaso
Replying to myself, for some reason the closure expression needs to be
explicitly visited. The following transformer do the trick:

   new ClassCodeExpressionTransformer() {

protected SourceUnit getSourceUnit() { unit }

Expression transform(Expression expr) {
if( expr.class == BinaryExpression ) {
return .. // my replacement where
}
else if( expr instanceof ClosureExpression) {
// explicitly visit the closure
visitClosureExpression(expr)
}
super.transform(expr)
}
}



p

On Mon, Sep 24, 2018 at 7:34 PM Paolo Di Tommaso 
wrote:

> Dear all,
>
>
> I'm trying to write a global transformation for my DSL to apply a custom
> logic on binary expression. For example:
>
> @GroovyASTTransformation(phase = CompilePhase.CONVERSION)
> class FooXformImpl implements ASTTransformation {
>
> SourceUnit unit
>
> @Override
> void visit(ASTNode[] nodes, SourceUnit source) {
> this.unit = unit
> createVisitor().visitClass((ClassNode)nodes[1])
> }
>
> protected ClassCodeExpressionTransformer createVisitor() {
>
> new ClassCodeExpressionTransformer() {
>
> protected SourceUnit getSourceUnit() { unit }
>
> Expression transform(Expression expr) {
> if( expr.class == BinaryExpression ) {
> return .. // my replacement where
> }
> super.transform(expr)
> }
> }
> }
> }
>
>
> The transformation is correctly applied, however it turns out the
> expressions nested in a closure definition are *not* visited. Therefore the
> above transformation is not applied to binary expressions inside a closure.
>
> Is that expected? How to manage this use case ?
>
>
> Cheers,
> Paolo
>
>


Clousure expression transformation

2018-09-24 Thread Paolo Di Tommaso
Dear all,


I'm trying to write a global transformation for my DSL to apply a custom
logic on binary expression. For example:

@GroovyASTTransformation(phase = CompilePhase.CONVERSION)
class FooXformImpl implements ASTTransformation {

SourceUnit unit

@Override
void visit(ASTNode[] nodes, SourceUnit source) {
this.unit = unit
createVisitor().visitClass((ClassNode)nodes[1])
}

protected ClassCodeExpressionTransformer createVisitor() {

new ClassCodeExpressionTransformer() {

protected SourceUnit getSourceUnit() { unit }

Expression transform(Expression expr) {
if( expr.class == BinaryExpression ) {
return .. // my replacement where
}
super.transform(expr)
}
}
}
}


The transformation is correctly applied, however it turns out the
expressions nested in a closure definition are *not* visited. Therefore the
above transformation is not applied to binary expressions inside a closure.

Is that expected? How to manage this use case ?


Cheers,
Paolo


Re: Can @Delegate wrap stubs in own processor? Or other trick for proxying.

2018-08-27 Thread Paolo Di Tommaso
I had a similar problem that I solved mixing a @Delegate with the
GroovyInterceptable annotation, for example:


class Foo implements Set, GroovyInterceptable {

@Delegate
private Set target = new HashSet()

@Override
Object invokeMethod(String name, Object args) {
System.out.println('BEFORE')
def result = InvokerHelper.invokeMethod(target, name, args)
System.out.println('AFTER')
return result
}
}



Hope it helps

p




On Mon, Aug 27, 2018 at 2:37 AM ocs@ocs  wrote:

> Hi there,
>
> I guess this must be Groovy 101, but whatever I try, I can't find a proper
> solution.
>
> The goal is pretty plain — to implement own set. Conceptually, it should
> look like this:
>
> ===
> class MySet {
>   def delegate=[] as Set
>   def methodMissing(String name, Object args) {
> ... some preprocessing ...
> def mm=delegate.getClass().metaClass.getMetaMethod(name,args)
> def result=mm.invoke(delegate,args)
> ... some postprocessing ...
> result
>   }
> }
> ===
>
> Without the implements Set it works like a charm... up to a point. Alas,
> if I try e.g.
>
> ===
> MySet mySet=
> def f=[1,2]+mySet
> ===
>
> I don't get the assumed result (of adding the *contents* of mySet to the
> list).
>
> Presumably, it would help if I added implements Set. Here's where it gets
> hairy: the compiler does not allow me to do that, wanting me either to
> implement a number of completely unnecessary method stubs manually, or make
> the class abstract, which would prevent its instantiation.
>
> Using @Delegate does not help, for I need pre- and post-process all the
> methods. Nevertheless, if @Delegate allowed me to use, say, a closure to
> wrap all the stubs into, or a pair of static methods to be called always
> pre- and post-calling the delegate method, it would help very much. Is
> there something like that?
>
> Or, if not, is there some other easy way out, without having to write and
> maintain a screenful of very ugly very much Java-like boilerplate code?
>
> Thanks and all the best,
> OC
>
>


Groovy 2.5.x @Canonical annotation and IntelliJ IDEA

2018-08-22 Thread Paolo Di Tommaso
I've noticed that, after migrating to Groovy 2.5.x, IntelliJ IDEA is
marking with an error instantiation of classes annotated with @Canonical
annotation.

The error reported by IDEA is "Cannot apply default constructor for class
Xxx", however the application is correctly compiled.

I'm inclined to think that's an IDEA issue, however I was wondering if this
is somehow expected by the changes introduced by Groovy 2.5.x and if any
workaround is available.


Cheers,
Paolo


Re: Groovydoc task failing with 2.5.1

2018-08-21 Thread Paolo Di Tommaso
Fixed adding the following snippet in my gradle build file:


tasks.withType(Groovydoc) {
groovyClasspath = project.configurations.groovyDoc
includes  = ["nextflow/**"]
}


See more here
<https://github.com/nextflow-io/nextflow/blob/df4e6acdf1e2078a364e7ad5774283383c6dc412/build.gradle#L133-L136>
.


p

On Tue, Aug 21, 2018 at 3:54 PM Paolo Di Tommaso 
wrote:

> After upgrading to groovy 2.5.1 I'm getting the following error in my
> Gradle build:
>
>
> Execution failed for task ':nxf-commons:groovydoc'.
> > java.lang.NoClassDefFoundError: groovy/text/TemplateEngine
>
>
>
> Any idea what's wrong with that ?
>
>
> Cheers,
> Paolo
>
>


Groovydoc task failing with 2.5.1

2018-08-21 Thread Paolo Di Tommaso
After upgrading to groovy 2.5.1 I'm getting the following error in my
Gradle build:


Execution failed for task ':nxf-commons:groovydoc'.
> java.lang.NoClassDefFoundError: groovy/text/TemplateEngine



Any idea what's wrong with that ?


Cheers,
Paolo


Groovy 2.5.1 array issue

2018-07-26 Thread Paolo Di Tommaso
Dear all,

I've found a evil change in the 2.5.1 when using an array list.


The following snippet is OK on 2.4.x

def stack = new ArrayList()
stack.push('a')
stack.push('b')
stack.push('c')
assert stack.join('.') == 'a.b.c'


When using 2.5.1 it the assertion fails


stack.join('.') == 'a.b.c'
| | |
| c.b.a false
[c, b, a]   2 differences (60% similarity)
(c).b.(a)
(a).b.(c)


It looks the semantic of `push` is changed. Is that expected?


p


NPE with new Macro feature

2018-07-16 Thread Paolo Di Tommaso
Dear all,

I'mv trying to use the new `macro` feature to execute a class method call
expression using an executor service.

I've tried:


private BlockStatement wrap(MethodCallExpression mce) {
return macro(true,{

def executor =
java.util.concurrent.Executors.newCachedThreadPool()
def list = new ArrayList(1)
list.add( { return $v{ mce } } as Callable )
def result = executor.invokeAll(list)
return result.get(0).get()

})
}


and


private BlockStatement wrap(MethodCallExpression mce) {
return macro(true,{

def task = new java.util.concurrent.Callable() {
@Override
Object call() throws Exception { return $v{ mce } }
}

ExecutorService executor =
java.util.concurrent.Executors.newCachedThreadPool()
def list = new ArrayList(1)
list.add(task)
def result = executor.invokeAll(list)
return result.get(0).get()

})
}


However none of them work. The first return a NPE during compilation and
the second reports:

Groovyc: [Static type checking] - Cannot find matching method
nextflow.ast.ProxyImpl$1#$v(groovy.lang.Closure). Please check if the
declared type is correct and if the method exists.

(using CompileDynamic I got a NPE error one more time)


What I'm missing? is it possible to handle this use case with an ast macro ?



p


Re: AST to replace `==` with `equals` method invocation

2018-06-16 Thread Paolo Di Tommaso
Thanks Mario,

Looking at Asteroid code put me in the right direction. In a nutshell it is
not possible to mix ClassCodeVisitorSupport logic with class
ClassCodeExpressionTransformer
one. I need to use two different classes.


p

On Wed, Jun 13, 2018 at 9:52 AM, Mario Garcia  wrote:

> Hi Paolo:
>
> A couple of years ago I created Asteroid (https://github.com/grooviter/
> asteroid) a library to deal with AST transformations. I needed to create
> a minor release so I've taken the oportunity to solve this problem and I
> think is pretty easy.
>
>- Create a Transformer. A transformer is just a class transforming a
>specific type of node, and it uses a criteria to filter nodes.
>- Create a Global transformation that includes the previous
>transformer to apply it to the whole codebase
>- Test that the AST generated has changed from a BinaryExpression to a
>MethodCallExpression
>- Profit :)
>
> You can find the source code here:
>
>- Transformer: https://github.com/grooviter/asteroid/blob/
>master/asteroid-test/src/main/groovy/asteroid/global/samples/
>ChangeEqualsTransformer.groovy
>
> <https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/main/groovy/asteroid/global/samples/ChangeEqualsTransformer.groovy>
>
>- Transformation: https://github.com/grooviter/asteroid/
>blob/master/asteroid-test/src/main/groovy/asteroid/global/samples/
>ChangeEqualsTransformation.groovy
>
> <https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/main/groovy/asteroid/global/samples/ChangeEqualsTransformation.groovy>
>- Test: https://github.com/grooviter/asteroid/blob/
>master/asteroid-test/src/test/groovy/asteroid/global/samples/
>ChangeEqualsTransformationSpec.groovy
>
> <https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/test/groovy/asteroid/global/samples/ChangeEqualsTransformationSpec.groovy>
>
> You can find also some documentation at: http://grooviter.github.
> io/asteroid/
>
> Of course any feedback on the library is appreciated :)
>
> I hope this helps
> Mario
>
> 2018-06-10 21:27 GMT+02:00 MG :
>
>> Hi Paolo,
>>
>> I have not used it myself, but have you had a look at the new Groovy 2.5
>> "abstract syntax tree search and replace"-feature (
>> http://groovy-lang.org/releasenotes/groovy-2.5.html & search for "AST
>> matching") ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> On 10.06.2018 16:55, Paolo Di Tommaso wrote:
>>
>> Dear all,
>>
>> I'm trying to implement an AST transformation to replace any `==` binary
>> expression with a equals method call invocation as suggested here
>> <https://stackoverflow.com/questions/28355773/in-groovy-why-does-the-behaviour-of-change-for-interfaces-extending-compar#comment45123447_28387391>
>> .
>>
>>
>> My understanding is that it's required to override each the visitor for
>> each node where a binary expression can appear ie. if statement, while
>> statement, assignment, for loop, method call, etc.
>>
>> That looks a bit overkill. I was wondering if there's a better way to
>> replace globally all `==` binary expressions with `equals` method
>> invocations.
>>
>>
>> Cheers,
>> Paolo
>>
>>
>>
>


Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

2018-06-13 Thread Paolo Di Tommaso
I agree on option 3 (abandon 2.6 immediately).

Full support for JKD9+ is becoming a pressing issue. Users are concerned
about the ability of Groovy to run on future JDK releases (including
GraalVM), more than legacy support.


Cheers,
p

On Wed, Jun 13, 2018 at 9:11 AM, David Dawson <
david.daw...@simplicityitself.com> wrote:

> I would vote 2.
>
> Actually, i would vote 3) abandon 2.6 immediately.
>
> No projects I have any knowledge of still use jdk 7.
>
> *From:* pa...@asert.com.au
> *Sent:* 13 June 2018 08:06
> *To:* users@groovy.apache.org
> *Reply to:* users@groovy.apache.org
> *Subject:* [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy
> 3.0
>
>
> Hi everyone,
>
> There was some discussion at gr8conf about how to speed up delivery of
> Groovy 3.0. Some of that discussion was around the scope of what we want to
> include and have yet to complete in 3.0 but I won't discuss that right now.
>
> One of the other discussion points was Groovy around 2.6. As many of you
> know, we have released alpha versions of Groovy 2.6. That version is a
> backport of most but not all of Groovy 3.0 to JDK7 including the Parrot
> parser (though it isn't enabled by default). The purpose of this version
> has always been to assist people/projects wanting to use the Parrot parser
> but who might be stuck on JDK7. So in some sense it is an intermediate
> version to assist with porting towards Groovy 3.0. While that is still a
> noble goal in theory, in practice, many of our users are already on JDK8
> and we have limited resources to work on many potential areas.
>
> With that in mind, we'd like to understand the preferences in our user
> base for the following two options:
>
> Option 1: please continue releasing the best possible 2.6 even if that
> slows down the final release of Groovy 3.0 and delays further work on
> better support for JDK9+.
>
> Option 2: please release one more alpha of 2.6 over the next month or so
> which will become the best version to use to assist porting for users stuck
> on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired
> though we will consider PRs from the community for critical fixes.
>
> Feedback welcome.
>
> Cheers, Paul.
>
>
>


AST to replace `==` with `equals` method invocation

2018-06-10 Thread Paolo Di Tommaso
Dear all,

I'm trying to implement an AST transformation to replace any `==` binary
expression with a equals method call invocation as suggested here

.


My understanding is that it's required to override each the visitor for
each node where a binary expression can appear ie. if statement, while
statement, assignment, for loop, method call, etc.

That looks a bit overkill. I was wondering if there's a better way to
replace globally all `==` binary expressions with `equals` method
invocations.


Cheers,
Paolo


Re: Java NIO2 and the Groovy ClassLoader conundrum

2018-05-31 Thread Paolo Di Tommaso
The NIO api can be very annoying.

Hover I think here the problem is that Paths.get() is designed
to only return default file (local) system path objects.

Instead Paths.get() allows the automatic creation of a new file system
as stated by the documentation

.

*Throws *
*FileSystemNotFoundException - The file system, identified by the URI, does
not exist and cannot be created *automatically*, or the provider identified
by the URI's scheme component is not installed*



However is role of FileSystemProvider implementation to automatically
create a new file system if does not exist and, I think, the
ZipFileSystemProvider is not doing that.



p


On Thu, May 31, 2018 at 8:53 AM, Schalk Cronjé  wrote:

> HI all,
>
> Java NIO2 providers (https://docs.oracle.com/javase/8/docs/api/java/nio/
> file/spi/FileSystemProvider.html) works by providing filesystems via SPI.
> Ideally one would just write the appropriate classes and drop them on the
> classpath . This allows somebody does to write something like:
>
> Paths.get('gz:/path/to/compressed.gz')
>
> This all works fine when done within a normal application but it fails
> when used within GroovyConsole or just running a normal Groovy script. ONe
> would expect the following just to work
>
> @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
> @Grab('org.slf4j:slf4j-simple:1.7.5')
>
> import java.nio.file.*
>
> Paths.get('gz:/path/to/compressed.gz')
>
> However the following workaround is required
>
> @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
> @Grab('org.slf4j:slf4j-simple:1.7.5')
>
> import java.nio.file.*
>
> FileSystem fs
>
> try {
> fs = FileSystems.getFileSystem(gzURI)
> } catch(FileSystemNotFoundException) {
> fs = FileSystems.newFileSystem(gzURI,[:],this.class.
> classLoader.parent.parent)
> }
>
> Path gzPath = fs.provider().getPath(gzURI)
>
> NOTE: Using @GrabConfig(initContextClassLoader=true,
> systemClassLoader=true) does not solve the problem in this case
>
>
> At Gr8Conf I sat with with Andres, Jochen and Guillaume to work through
> this. The issue that that providers are loaded via the system class loader,
> whereas with GroovyConsole and command-line Groovy it will be loaded via an
> instance of RootLoader. This leads to one having to manually loading the
> filesystem.
>
> From the point of view of someone using NIO2 providers this is surprising
> behaviour. One would expect it just to work out of the box (as per the
> Javadoc for FileSystemProvider).
>
> My question is now. Is there something that can be done to way
> GroovyConsole and Groovy scripts are started so that the expectd behaviour
> of NIO2 providers can be obtained? (Maybe adding an additional method to
> GrabConfig?).
>
> Groovy luck.
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>


Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-20 Thread Paolo Di Tommaso
+1

On Tue, Feb 20, 2018 at 11:14 AM, Søren Berg Glasius 
wrote:

> Are we at a point where there should be put out a vote for which name to
> use? There are several good ones, and a few not so good... not judging
> however :D
>


Re: Groovy Champions proposal feedback

2018-02-13 Thread Paolo Di Tommaso
It sound a nice idea also to promote the visibility of the groovy
community.


p

On Tue, Feb 13, 2018 at 12:18 PM, Søren Berg Glasius 
wrote:

> I'm definitely +1
>
> It is always important to recognize and encourage the ones making a
> difference to the community.
>
> On Tue, 13 Feb 2018 at 11:32 Schalk Cronjé  wrote:
>
>>
>> That's a +1 from me for the concep.
>>
>>
>> On 13/02/2018 10:58, Paul King wrote:
>> >
>> > Hi everyone,
>> >
>> > A few of us have had various discussions (in fact over many years)
>> > about having a recognition scheme similar to Java Champions,
>> > perhaps called "Groovy Champions" or "Apache Groovy Champions"
>> > or something else entirely if we think of a better name.
>> >
>> > I think the idea has always been to recognize contribution within the
>> > whole Groovy ecosystem not just the Apache Groovy project. The many
>> > tens of projects within the ecosystem are often where many ideas come
>> > from for the project's future evolution and also where future
>> contributors
>> > may arise. And in any case, Groovy has always been about making
>> > coding productive and fun and we should celebrate that widely!
>> >
>> > There are various questions to ask like should such a scheme
>> > be formally coordinated by the project/by Apache or should it be run as
>> a
>> > community-driven unsanctioned activity and if so what guidelines should
>> > be in place. Also, there are many details like how will the scheme
>> > operate?
>> > How are new members elected? Is it a lifetime recognition or is there
>> > an "emeritus" status? And so forth. Java Champions vote themselves
>> > on new champions and the recognition has a lifetime status for instance.
>> > if we progress this idea, we'd need to make that all clear but that
>> isn't
>> > the purpose of this email - we need to first decide if we like the idea.
>> >
>> > Even if we like the idea, there are still some hurdles to step through.
>> > We've already sought some informal feedback from other parts of
>> > Apache and other projects within the Groovy Ecosystem and we'll
>> > likely need further discussions. We want something that embraces
>> > the whole community but fits in with Apache project governance
>> > around trademarks/branding.
>> >
>> > So, the first question is: are we as a project in favor of such a
>> scheme?
>> >
>> > Cheers, Paul.
>>
>>
>> --
>> Schalk W. Cronjé
>> Twitter / Ello / Toeter : @ysb33r
>>
>> --
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>


Re: AST nodeMetaData

2018-02-08 Thread Paolo Di Tommaso
Well, actually that would be my use case.

I'm trying to capture a closure source code (string) when parsing a groovy
config file with a (custom) ConfigSlurper.

I'm able to read the source code from the closure BlockStatement using and
AST xform. Then the idea was to inject it into the nodeMetaData. But it
looks the `myClosure.metaClass.classNode` is returning null.


p

On Thu, Feb 8, 2018 at 2:46 PM, Cédric Champeau <cedric.champ...@gmail.com>
wrote:

> In general `metaClass.classNode` is unsafe: you never know if there's
> going to be something there. It only works for scripts compiled "on the
> fly" for which you keep a reference. Not precompiled classes, typically.
>
> 2018-02-08 14:44 GMT+01:00 Paolo Di Tommaso <paolo.ditomm...@gmail.com>:
>
>> I see. Actually my idea was to populate the nodeMetaData map and access
>> it via `class.metaClass.classNode.nodeMetaData`, but it seems not
>> possible.
>>
>> But the the use of annotation sounds a nice idea.
>>
>> Thanks.
>> p
>>
>> On Thu, Feb 8, 2018 at 2:35 PM, Cédric Champeau <
>> cedric.champ...@gmail.com> wrote:
>>
>>> Unless you have an AST xform that takes that node metadata and injects
>>> it into bytecode in a way that it's available at runtime (say, within an
>>> annotation), no, it's not possible.
>>>
>>> 2018-02-08 14:30 GMT+01:00 Paolo Di Tommaso <paolo.ditomm...@gmail.com>:
>>>
>>>> Dear all,
>>>>
>>>> Is it possible to inject some values in a nodeMetaData during AST
>>>> transformation and access such values at runtime  ?
>>>>
>>>>
>>>> p
>>>>
>>>
>>>
>>
>


Re: AST nodeMetaData

2018-02-08 Thread Paolo Di Tommaso
I see. Actually my idea was to populate the nodeMetaData map and access it
via `class.metaClass.classNode.nodeMetaData`, but it seems not possible.

But the the use of annotation sounds a nice idea.

Thanks.
p

On Thu, Feb 8, 2018 at 2:35 PM, Cédric Champeau <cedric.champ...@gmail.com>
wrote:

> Unless you have an AST xform that takes that node metadata and injects it
> into bytecode in a way that it's available at runtime (say, within an
> annotation), no, it's not possible.
>
> 2018-02-08 14:30 GMT+01:00 Paolo Di Tommaso <paolo.ditomm...@gmail.com>:
>
>> Dear all,
>>
>> Is it possible to inject some values in a nodeMetaData during AST
>> transformation and access such values at runtime  ?
>>
>>
>> p
>>
>
>


AST nodeMetaData

2018-02-08 Thread Paolo Di Tommaso
Dear all,

Is it possible to inject some values in a nodeMetaData during AST
transformation and access such values at runtime  ?


p


Re: Upcoming releases

2018-02-06 Thread Paolo Di Tommaso
I renew my plea for this PR

https://github.com/apache/groovy/pull/566


Cheers,
Paolo




On Tue, Feb 6, 2018 at 9:11 AM, Mario Garcia  wrote:

> That's good News :)
>
> 2018-02-06 8:19 GMT+01:00 Paul King :
>
>>
>> I am planning to prepare a 2.5.0-beta-3 release towards the end of this
>> week and 2.4.14 not long after. Now's a good time to let us know if there
>> is something critical you need for those releases.
>>
>> I am expecting 2.5.0-beta-3 to be the last beta for 2.5.0 and while there
>> are a couple of things we are still planning to finish for 2.5.0, I am
>> expecting the next release to kick off the RC release(s), so a final
>> release shouldn't be too far away!
>>
>> Thanks, Paul.
>>
>>
>


Re: @CompileStatic null iteration

2017-12-14 Thread Paolo Di Tommaso
Just found the same problem. This difference can introduce subtle bugs when
refactoring groovy code to CompileStatic.

I suggest to report a bug for that.


Cheers, Paolo


On Tue, Dec 12, 2017 at 12:45 AM, MG  wrote:

> Hi guys,
>
> just a quick question since we came across it today when testing code that
> had been converted from dynamic to static Groovy: Is the behavior that
> statically compiled Groovy throws a NPE when the iterable to be iterated
> over is null (same as Java), while dynamically compiled Groovy uses the
> NullObject.iterator(), i.e. does not throw but instead iterates over an
> empty collection by design ?
>
> Cheers,
> mg
>
>
>


Re: ConfigSlurper issue

2017-11-25 Thread Paolo Di Tommaso
I've opened an issue for this problem.

https://issues.apache.org/jira/browse/GROOVY-8390


I've also tried to debug it, but I was unable to find a solution. Any help
would be appreciated.


Cheers,
Paolo


On Fri, Nov 24, 2017 at 9:16 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com
> wrote:

> It was my understanding that a ConfigObject dot notation is equivalent to
> curly brackets.
>
> However the following snippets create two different objects
>
>
> def first = '''
> alpha.container = 'foo'
>
> profiles {
> beta.container='x/y'
> delta.container='1/2'
> alpha.container='bar'
> }
> '''
>
> def second = '''
> alpha.container = 'foo'
>
> profiles.beta.container='x/y'
> profiles.delta.container='1/2'
> profiles.alpha.container='bar'
> '''
>
> assert new ConfigSlurper().parse(first) == new
> ConfigSlurper().parse(second) // fail
>
>
>
> in particular printing the first ConfigObject it return the following
> string:
>
>
> alpha.container='bar'
> profiles {
> beta.container='x/y'
> delta.container='1/2'
> }
>
>
> that doesn't make much sense. Is this a bug or I'm missing something?
>
>
>
> Cheers,
> Paolo
>
>
>


ConfigSlurper issue

2017-11-24 Thread Paolo Di Tommaso
It was my understanding that a ConfigObject dot notation is equivalent to
curly brackets.

However the following snippets create two different objects


def first = '''
alpha.container = 'foo'

profiles {
beta.container='x/y'
delta.container='1/2'
alpha.container='bar'
}
'''

def second = '''
alpha.container = 'foo'

profiles.beta.container='x/y'
profiles.delta.container='1/2'
profiles.alpha.container='bar'
'''

assert new ConfigSlurper().parse(first) == new
ConfigSlurper().parse(second) // fail



in particular printing the first ConfigObject it return the following
string:


alpha.container='bar'
profiles {
beta.container='x/y'
delta.container='1/2'
}


that doesn't make much sense. Is this a bug or I'm missing something?



Cheers,
Paolo


Re: NF build error

2017-11-16 Thread Paolo Di Tommaso
OK. Thanks!

p

On Thu, Nov 16, 2017 at 2:16 PM, Paul King <pa...@asert.com.au> wrote:

> Actually, I created GROOVY-8382 to cover some new cases and fix the bug
> you observed.
>
> On Thu, Nov 16, 2017 at 9:05 PM, Paul King <pa...@asert.com.au> wrote:
>
>> Incidentally, here is the reproducer I have been using:
>>
>> @groovy.transform.CompileStatic
>> class Foo {
>>   List baz = ['foo'] ?: [] // 1
>>   def bar() {
>> List items = ['foo'] ?: [] // 2
>>   }
>>   static bar2() {
>> new Foo().baz = ['foo'] ?: [] // 3
>>   }
>> }
>>
>> new Foo().bar()
>>
>> The applied fix targets 2, doesn't cover 1 and gives the
>> ClassCastException for 3. Our test coverage obviously still needs further
>> attention. :-(
>>
>> Cheers, Paul.
>>
>>
>> On Thu, Nov 16, 2017 at 8:59 PM, Paul King <pa...@asert.com.au> wrote:
>>
>>> Feel free to create one. We can always close it if we end up fixing
>>> under another issue number.
>>>
>>> On Thu, Nov 16, 2017 at 6:51 PM, Paolo Di Tommaso <
>>> paolo.ditomm...@gmail.com> wrote:
>>>
>>>> Let me know if you want I open an issue for this problem.
>>>>
>>>>
>>>> Cheers,
>>>> Paolo
>>>>
>>>>
>>>> On Wed, Nov 15, 2017 at 10:19 PM, Paolo Di Tommaso <
>>>> paolo.ditomm...@gmail.com> wrote:
>>>>
>>>>> Apparently the latest 2.4.13 SNAPSHOT introduced a compilation error
>>>>> in the Nextflow joint build:
>>>>>
>>>>>
>>>>>  startup failed:
>>>>>  General error during instruction selection:
>>>>> org.codehaus.groovy.ast.expr.PropertyExpression cannot be cast to
>>>>> org.codehaus.groovy.ast.expr.VariableExpression
>>>>>
>>>>>  java.lang.ClassCastException: 
>>>>> org.codehaus.groovy.ast.expr.PropertyExpression
>>>>> cannot be cast to org.codehaus.groovy.ast.expr.VariableExpression
>>>>>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
>>>>> checkForTargetType(StaticTypeCheckingVisitor.java:3455)
>>>>>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
>>>>> visitTernaryExpression(StaticTypeCheckingVisitor.java:3428)
>>>>>   at org.codehaus.groovy.ast.expr.TernaryExpression.visit(Ternary
>>>>> Expression.java:45)
>>>>>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
>>>>> visitBinaryExpression(StaticTypeCheckingVisitor.java:585)
>>>>>   at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryEx
>>>>> pression.java:51)
>>>>>   at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionSt
>>>>> atement(CodeVisitorSupport.java:71)
>>>>>   at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpress
>>>>> ionStatement(ClassCodeVisitorSupport.java:196)
>>>>>
>>>>>
>>>>> More details here
>>>>> <http://ci.groovy-lang.org/viewLog.html?buildId=44081=JointBuilds_Nextflow_Groovy24xJointBuild=buildLog#_focus=141=141>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


Re: NF build error

2017-11-16 Thread Paolo Di Tommaso
Let me know if you want I open an issue for this problem.


Cheers,
Paolo


On Wed, Nov 15, 2017 at 10:19 PM, Paolo Di Tommaso <
paolo.ditomm...@gmail.com> wrote:

> Apparently the latest 2.4.13 SNAPSHOT introduced a compilation error in
> the Nextflow joint build:
>
>
>  startup failed:
>  General error during instruction selection: 
> org.codehaus.groovy.ast.expr.PropertyExpression
> cannot be cast to org.codehaus.groovy.ast.expr.VariableExpression
>
>  java.lang.ClassCastException: org.codehaus.groovy.ast.expr.PropertyExpression
> cannot be cast to org.codehaus.groovy.ast.expr.VariableExpression
>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> checkForTargetType(StaticTypeCheckingVisitor.java:3455)
>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> visitTernaryExpression(StaticTypeCheckingVisitor.java:3428)
>   at org.codehaus.groovy.ast.expr.TernaryExpression.visit(
> TernaryExpression.java:45)
>   at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> visitBinaryExpression(StaticTypeCheckingVisitor.java:585)
>   at org.codehaus.groovy.ast.expr.BinaryExpression.visit(
> BinaryExpression.java:51)
>   at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(
> CodeVisitorSupport.java:71)
>   at org.codehaus.groovy.ast.ClassCodeVisitorSupport.
> visitExpressionStatement(ClassCodeVisitorSupport.java:196)
>
>
> More details here
> <http://ci.groovy-lang.org/viewLog.html?buildId=44081=JointBuilds_Nextflow_Groovy24xJointBuild=buildLog#_focus=141=141>
> .
>
>
>
> p
>
>
>


Re: Cannot execute shell scripts/command separated by ";" with execute() method

2017-10-17 Thread Paolo Di Tommaso
Do

cmdArgs = ["bash", "-c", "/opt/test.sh; sqlplus username" ];
cmdArgs.execute(env, workDir);

p

On Tue, Oct 17, 2017 at 4:49 PM, cortez21  wrote:

> Hi All,
>
>  Maybe you can help me with issue I have with executing linux command
> separated by ";".
> I am using execute function but got error:
>
>  No such file or directory
>
> but file exist.
>
> Code I am executing:
>
> cmdArgs = ["/opt/test.sh; sqlplus username"];
> cmdArgs.execute(env, workDir);
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: upcoming release(s)

2017-08-05 Thread Paolo Di Tommaso
Reading 2.4.13 it would be good to have 8157
 fixed in this release.

Nextflow is currently reporting a bunch of errors caused by that issue. See
here

.


Cheers,
Paolo


On Sun, Jul 23, 2017 at 2:07 AM, Paul King  wrote:

>
> Hi everyone,
>
> We are planning to release 2.4.13, 2.5.0-beta-2 and the first alpha
> release of 2.6.0 and/or 3.0.0 over the coming weeks. We already have a
> bunch of fixes/features we are targeting for those releases but we are keen
> for any feedback. If there is a particular release you are waiting for or
> particular bugs/features, let us know and that can help us set priorities.
> Some of us have the opportunity at the upcoming GR8Conf US for some more
> in-depth discussions. And certainly, for those that can't make it to the
> conference, don't let that stop you from submitting PRs! :-)
>
> Cheers, Paul.
>
>


Spying a DataflowVariable

2017-08-01 Thread Paolo Di Tommaso
Hi all,

I've having a problem testing a DataflowVariable with a Spock test.

Consider the following test case:


class Lazy {

def bar(final x) {
return x
}

def foo() {
def closure = { bar('Hello') }
new LazyDataflowVariable(closure) .getVal()
}
}



I want to check that the `bar` method is invoked exactly one time by the
LazyDataflowVariable when the method `foo` is called. The test I'm using is
the following:


class LazyTest extends Spefication {

def 'should invoke bar method' () {
given:
def lazy = Spy(Lazy)
when:
def result = lazy.foo()
then:
1 * lazy.bar('Hello') >> 'Hello'
result == 'Hello'
}
}



However what happens is that is just hangs, because it seems that the
dataflow variable never invokes the initialisation closure.

Any idea what is wrong? or any workaround ?


Re: [VOTE]About the Union Type for method/constructor declaration

2017-07-23 Thread Paolo Di Tommaso
I agree with Paul.

-1


p

On Sun, Jul 23, 2017 at 1:50 AM, Paul King  wrote:

> I would be leaning towards -1 without further justification. Even though I
> don't think we want to rush into union types in Groovy, wouldn't this
> syntax rule out us having it down the track?
>
> Cheers, Paul.
>
>
> On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun 
> wrote:
>
>> Hi all,
>>
>>I've been thinking about Union Type for method/constructor
>> declaration. It is similar to multi-catch in try-catch statement, e.g.
>>
>> class UnionTypeSample {
>>   public UnionTypeSample(A|B|C p) {
>>  // do something
>>   }
>>
>>   def m(D|E p) {
>> // do something
>>   }
>> }
>>
>>   Groovy will translate the above code into the following code, which
>> is
>> also the same way how multi-catch is handled.
>>
>> class UnionTypeSample {
>>   public UnionTypeSample(A p) {
>>  // do something
>>   }
>>
>>   public UnionTypeSample(B p) {
>>  // do something
>>   }
>>
>>   public UnionTypeSample(C p) {
>>  // do something
>>   }
>>
>>   def m(D p) {
>> // do something
>>   }
>>
>>   def m(E p) {
>> // do something
>>   }
>> }
>>
>>  Any thoughts?
>> --
>>   [+1] I like it
>>   [  0] Not bad
>>   [-1] I do not like it
>> --
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/VOTE-About-the-Union-Type-for-method-constructor-
>> declaration-tp5742265.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>


Re: upcoming release(s)

2017-07-23 Thread Paolo Di Tommaso
Any chance to see this PR merged in future Groovy release?

https://github.com/apache/groovy/pull/566


p

On Sun, Jul 23, 2017 at 3:00 PM, Daniel Sun  wrote:

> According to the original plan, the Parrot parser will be the default
> parser for Groovy 3.0.0 eventually. But currently about 20 tests(e.g.
> different error messages) fail when setting Parrot as default, so we will
> try our best to fix them all before releasing GA version.
>
> Cheers,
> Daniel.Sun
>
>
>  原始邮件 
> 主题:Re: upcoming release(s)
> 发件人:"Russel Winder-3 [via Groovy]"
> 收件人:Daniel Sun
> 抄送:
>
>
> On Sun, 2017-07-23 at 04:55 -0700, Daniel Sun wrote:
> > Looking forward to 2.6.0 and 3.0.0, which contains the Parrot parser
> > providing many new features :)
> >
> > p.s. use  -Dgroovy.antlr4=true  to enable the Parrot parser
> >
>
> Will the new parser not be the default in Groovy 3?
>
> --
> Russel.
> =
>
> Dr Russel Winder  t: +44 20 7585 2200 <+44%2020%207585%202200>
> voip: sip:[hidden email]
> 
> 41 Buckmaster Roadm: +44 7770 465 077 <+44%207770%20465077>   xmpp: 
> [hidden
> email] 
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> * signature.asc* (849 bytes) Download Attachment
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://groovy.329449.n5.nabble.com/upcoming-release-s-
> tp5742269p5742277.html
> To unsubscribe from upcoming release(s), click here.
> NAML
> 
>
>
> --
> View this message in context: 回复:upcoming release(s)
> 
>
> Sent from the Groovy Users mailing list archive
>  at
> Nabble.com.
>


Groovy AOT compilation

2017-05-08 Thread Paolo Di Tommaso
Dear all,

I just want to share with you my experience with the Java AOT compiler

a came across a few days ago.


Although they said clearly that it still an experimental project and it
does not support dynamic class loading and most of reflection, I turns out
it's possible to compile a basic static Groovy class, eg:

@groovy.transform.CompileStatic
class Hello {

  static void main( String... args ) {
System.out.println "Hello world!"
  }
}


This mean that it creates a native 5MB binary executable, that can run on
any machine without the need of the Java VM nor the Groovy runtime! in 12
millisecond! cool!!


Unfortunately the good news stops here. I was unable to successfully
compile any other piece of code, which for example uses a Groovy "println"
method or just instantiate a class. The problem seems to be that, even
though the code is statically compiled, Groovy uses reflection behind the
scene to instantiate classes and performs other operations.

Now, I guess this is certainly not a Groovy top priority, however since
there is an on-going discussion around a major Groovy reengineering to make
it compatible with the upcoming Java 9 module system, I was wondering if it
would not make sense to include the support for the Java AOT compiler as a
goal for a future Groovy 3/4 release?

Personally I think it would be an extremely useful feature and a major
achievement for the project.


What do you think ?


Cheers,
Paolo


Re: [VOTE]About the "implies" operator(=>) for Groovy 3

2017-01-27 Thread Paolo Di Tommaso
I agree on this. It could be very useful for custom DSL.


Cheers, Paolo

On Fri, Jan 27, 2017 at 9:27 PM, Krzysztof Kowalczyk <
kowalczyk.krzysz...@gmail.com> wrote:

> -1
>
> but I would like to have some extra operators for AST transformation that
> are reserved, have priority and does not have assigned logic, for instance
> =>, |>, @@, ^^, <-, := etc
>
> On 27 January 2017 at 08:18, Graeme Rocher 
> wrote:
>
>> -1 from me, not immediately obvious what it does and seems like it
>> would just confuse users for little syntactic gain.
>>
>> On Thu, Jan 26, 2017 at 5:27 PM, Daniel Sun 
>> wrote:
>> > Hi all,
>> >
>> >   The new parser(Parrot) supports "implies" operator(=>) now, e.g.
>> >
>> > // if and only if isDistributedTxFailed is true and isCompensated is
>> false,
>> > yields notConsistent.
>> > if (isDistributedTxFailed => isCompensated) {
>> > println 'eventuallyConsistent '
>> > } else {
>> > println 'notConsistent'
>> > }
>> >
>> > // One more example:
>> > if (itIsRaining => iAmUsingUmbrella) {
>> >   println 'I am dry'
>> > } else {
>> >   println 'I am wet'
>> > }
>> >
>> >*More examples can be found at:*
>> > 1)
>> > https://github.com/danielsun1106/groovy-parser/blob/
>> impliesOperator/src/test/resources/core/ImpliesOp_01x.groovy
>> > 2)
>> > https://github.com/danielsun1106/groovy-parser/blob/
>> impliesOperator/src/test/resources/core/ImpliesOp_02x.groovy
>> > 3)
>> > https://github.com/danielsun1106/groovy-parser/blob/
>> impliesOperator/src/test/resources/core/ImpliesOp_03x.groovy
>> >
>> > *Background of the "implies" operator(=>) :*
>> > http://mathworld.wolfram.com/Implies.html
>> > *Please let us know whether you like it, vote here:
>> > *https://twitter.com/daniel_sun/status/824552059395465218
>> >
>> > Cheers,
>> > Daniel.Sun
>> >
>> >
>> >
>> > --
>> > View this message in context: http://groovy.329449.n5.nabble
>> .com/VOTE-About-the-implies-operator-for-Groovy-3-tp5738129.html
>> > Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Graeme Rocher
>>
>
>


Re: References books for Groovy and Gradle

2016-07-21 Thread Paolo Di Tommaso
Groovy in Action is the bible.


p

On Thu, Jul 21, 2016 at 2:38 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> What books would you recommend today as references for Groovy and Gradle?
> A best couple would be enough ;)
>
> TIA
>
> Jacques
>
>


Re: List and GString

2016-05-26 Thread Paolo Di Tommaso
>
>
> At the end of the day it should to be possible to use meta-programming to
> override Java compiled code.
>


Oops, I meant: *it should *not* be possible to use meta-programming*


Re: List and GString

2016-05-26 Thread Paolo Di Tommaso
Looking in the GString implementation I noticed that it call the
InvokeHelper.write
<https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/runtime/InvokerHelper.java#L500>
method.

I've tried implementing a DelegatingMetaClass
<https://objectpartners.com/2013/07/30/customizing-mop-in-groovy/> but it
does not work. At the end of the day it should to be possible to use
meta-programming to override Java compiled code.

Maybe the trick you are mentioning is ExpondoMetaClass.enableGlobally
<http://docs.groovy-lang.org/latest/html/api/groovy/lang/ExpandoMetaClass.html#enableGlobally%28%29>
?


Is there any other possible workaround ?


Cheers,
Paolo


On Thu, May 26, 2016 at 11:02 PM, Emmanuel Rosa <goaway1...@gmail.com>
wrote:

> The rendering is actually produced by InvokerHelper:
> https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/runtime/InvokerHelper.java#L123
>
> I tried overriding it with a category and also via the metaClass, but
> neither worked. I recall some kind of trick that’s needed when using the
> metaClass with some classes, to get it to take, but I don’t remember the
> details. :(
>
> On May 26, 2016, at 2:06 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com>
> wrote:
>
> Dear all,
>
> I have a use case in which I need to override the `toString` method of a
> custom List class and use it when interpolating that list object in a
> GString.
>
> It turns out the Groovy uses its own formatting methods for List and other
> structures, so the my custom `toString` is simply ignored.
>
> To explain it better take in consideration this example:
>
> class MyList extends ArrayList {
>
>   String toString() {
> this.join('-')
>   }
>
> }
>
>
> def x = new MyList()
> x << 1 << 2 << 3
>
> assert x.toString() == '1-2-3'
> assert "$x" == '1-2-3'
>
> Assertion failed:
> assert "$x" == '1-2-3'
>  |  |
>  |  false
>  [1, 2, 3]
>
> The second assertion fails for the reason said above. Now I'm wondering it
> there's any way to override somehow the GString default rendering mechanism
> in such a way I can inject my own formatting rule for my custom class.
>
> Any suggestion is appreciated.
>
>
>
> Cheers,
> Paolo
>
>
>
>
>


Re: Groovy kernel for Jupyter Notebook

2016-05-02 Thread Paolo Di Tommaso
I don't know any another project but I could be interested to contribute to
a Groovy kernel for Jupiter.


Cheers,
Paolo


On Mon, May 2, 2016 at 11:24 PM, Suderman Keith  wrote:

> Does anyone know of a Groovy kernel for iPython/Jupyter (
> http://jupyter.org/)?   My searches have not turned up much. I don't want
> a Groovy alternative to iPython/Jupyter notebooks (i.e.
> http://beakernotebook.com/ won’t cut it), I need a Groovy kernel for
> Jupyter I can extend to integrate with a Python application/framework we
> are using.
>
> I found https://github.com/jericks/geoscript-groovy-kernel but it is a
> simply a Python wrapper that calls geoscript-groovy and I was hoping for a
> native implementation, that is, something written in Groovy that listens to
> and responds on the ZMQ sockets.
>
> I have a simple proof of concept implementation working, but I don't want
> to put more effort into reinventing the wheel if there is already something
> better out there.
>
> Cheers,
> Keith
> --
> Research Associate
> Department of Computer Science
> Vassar College
> Poughkeepsie, NY
>
>


@Slf4j transformation does not check level guard

2016-01-29 Thread Paolo Di Tommaso
Dear all,

I've noticed that a logger defined with a @Slf4j transformation does check
the *implicit* trace level guard as expected.

For example the following code report an error for the `foo` method.

@groovy.util.logging.Slf4j
class TestLog {
  def bar () {
int count=0
if( log.isTraceEnabled() )  {
log.trace "${count++}"
}
return count
  }

  def foo () {
int count=0
log.trace "${count++}"
return count
  }

}

assert new TestLog().bar() == 0
assert new TestLog().foo() == 0

Assertion failed:
assert new TestLog().foo() == 0
   | | |
   | 1 false
   TestLog@416b8a53



Even more strangely, checking the code generated by Slf4j transformation
using the groovy console I can see that the "log.trace" line is correctly
replaced by the code:

log.isTraceEnabled() ? log.trace("$(count++)") : null



This really confuse me. Any clue what's wrong?


Cheers,
Paolo