Re: new GroovyCliBuilder

2019-05-24 Thread MG

Thanks Remko, I will switch the import & yes I do :-)

On 24/05/2019 19:39, Remko Popma wrote:
The new CliBuilder annotations API works well for both the Commons CLI 
and the picocli implementation.
(And I agree that the annotations API has some advantages over the 
previous DSL style, but that may be a matter of taste.)


Note that you can swap the implementation from Commons CLI to picocli 
by changing the import

from
import groovy.cli.commons.CliBuilder
to
import groovy.cli.picocli.CliBuilder
With the latter the usage help will show ANSI colors and gives some 
other features like the `cliBuilder.usageMessage 
<http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/picocli/CliBuilder.html>` 
property to customize the usage help message.


Glad you like it! :-)


On Sat, May 25, 2019 at 2:11 AM MG <mailto:mg...@arscreat.com>> wrote:


Hi guys,

just wanted to say that I recently had to revisit some older Groovy script 
code in my project, and I took the opportunity to switch the old CliBuilder 
implementation to the new Picocli based one 
(http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/commons/CliBuilder.html
) - and I can just say that it is an absolute joy to work with: Concise, 
elegant, and type safe G-)


import groovy.cli.commons.CliBuilder
import groovy.cli.Option
import groovy.cli.Unparsed

// Alternative is to use an interface and let Groovy instantiate a class 
instance from it
class MyOptions {
  boolean isTestRun
  @Option(shortName='h', description='output help info') Boolean help
  @Option(shortName='r', description='process regular entries') Boolean 
regular
  // etc (for supported types outside of Boolean see URL above)
  @Unparsed List remaining // all additional options given

  MyScriptOptions(boolean isTestRun) { this.isTestRun = isTestRun }
}
  


final cli = new CliBuilder(usage:'my_powerful_groovy_script')
def opts = new MyOptions(true)
cli.parseFromInstance(opts, args.split())  // From now on all cmd
line params can be accessed in a type safe manner

if(opts.help) {
  println cli.usage()
  System.exit(0)
}

if(opts.regular) {
  ...
}

Cheers,
mg









new GroovyCliBuilder

2019-05-24 Thread MG

Hi guys,

just wanted to say that I recently had to revisit some older Groovy script code 
in my project, and I took the opportunity to switch the old CliBuilder 
implementation to the new Picocli based one 
(http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/commons/CliBuilder.html
) - and I can just say that it is an absolute joy to work with: Concise, 
elegant, and type safe G-)


import groovy.cli.commons.CliBuilder
import groovy.cli.Option
import groovy.cli.Unparsed

// Alternative is to use an interface and let Groovy instantiate a class 
instance from it
class MyOptions {
 boolean isTestRun
 @Option(shortName='h', description='output help info') Boolean help
 @Option(shortName='r', description='process regular entries') Boolean regular
 // etc (for supported types outside of Boolean see URL above)
 @Unparsed List remaining // all additional options given

 MyScriptOptions(boolean isTestRun) { this.isTestRun = isTestRun }
}
 


final cli = new CliBuilder(usage:'my_powerful_groovy_script')
def opts = new MyOptions(true)
cli.parseFromInstance(opts, args.split())  // From now on all cmd line 
params can be accessed in a type safe manner


if(opts.help) {
  println cli.usage()
  System.exit(0)
}

if(opts.regular) {
  ...
}

Cheers,
mg







Re: Static imports seem to win over a method in closure's delegate

2019-04-12 Thread MG

See http://mrhaki.blogspot.com/2009/10/groovy-goodness-static-imports.html

For Web GUI programming we use Groovy together with Vaadin, and I 
recently had some cases, where e.g. an anonymous class method calls a 
Groovy closure which calls a Groovy closure which calls a method of the 
orginal containing class. In these cases it can become hard to have the 
expected method get called, and I also found that (depending on the 
situation) either using import aliasing or introducing a uniquely named 
helper method in the right class can clear things up quick & easy.


Cheers,
mg


On 12/04/2019 23:14, Paul King wrote:

Using import aliases can be a good workaround for such a case.

On Sat, Apr 13, 2019 at 4:58 AM Jochen Theodorou <mailto:blackd...@gmx.org>> wrote:


On 10.04.19 16:05, Herrendorf Johannes wrote:
> Hi Groovy users,
>
> I’m currently building a DSL in groovy and found some strange
behaviour
> I have no explanation for: If a method pointer with name
"myMethod" is
> imported as static import and a closure has a delegate with a method
> "myMethod" and it's delegation strategy is set to
"DELEGATION_ONLY", the
> imported method is always called inside the closure - the delegate
> property seems to be ignored.

two things to always remember:
* closure delegation is a runtime mechanism, it has no influence on
static compiled features
* static imports are compiled statically

The later is not because we want this, but because we have to more or
less. And it is painful. I can imagine a system where this is not
required, but that is far from easy or efficient.

[...]
> import static mailinglist.SomeOtherClass.myMethod
[...]
>           // dispatched to SomeOtherClass.myMethod; correct
>          myMethod "Hello"
>          closureStuff {
>              // dispatched to SomeOtherClass.myMethod, but I
expected that
>                       // it's dispatched to
ClosureDelegate.myMethod instead
>              myMethod "Good Morning"
>          }
[...]
> Am I missing something or is this a bug? Thanks for your help in
advance!

In short it is a limitation. I am not sure we can really do something
against that.

bye Jochen





Re: Become a Groovy Ant GA-)

2019-04-01 Thread MG

Hi Daniel,

On 01/04/2019 02:55, Daniel.Sun wrote:

Thanks a lot for your donating to Friends of Groovy Open Collective,
every little helps.


Spot on - as Tesco has known since 1993 ;-)
https://www.creativereview.co.uk/every-little-helps/


Up to now, the fund can sponsor about 4.5 man-day work according to
the average salary of Java Developer:
https://www.indeed.com/salaries/Java-Developer-Salaries


Thank you for pointing that out. My idea, as I've said, is that the 
large number of Groovy users out there each give a little, so that the 
small number of people who do the actual work can be supported and 
Groovy thrives !
An ocean is made of a myriad of tiny droplets - so please spread the 
word GA-)


Cheers,
mg








Become a Groovy Ant GA-)

2019-03-31 Thread MG

Hi Groovy users,

I have recently decided to back the "Friends of Apache Groovy" Patreon

https://opencollective.com/friends-of-groovy

on the lowest ($5) level.

Here is why: It was clear to me that backing it on the $100 level did 
not feel compatible with our family income (and in turn the Missus ;-) 
), and that my max conceivable level would be in the $50 area. There are 
individuals that back at both these levels, and while I am grateful for 
that, I do not expect that a large number of people will do so. I also 
felt slightly intimitated by their willingness to invest so much money 
every month into a single open source project: Given that I pay 14 EUR 
per month for Netflix for my whole family, or 15 EUR for all of us for 
Spotify, or give 10 EUR per month to the WWF, or 3 EUR to avaaz, at 
least to me it felt slightly off.


So I am calling for everyone to become a Groovy Ant, spread the word, 
and fund this great language on a level that does not personally hurt, 
so that it might live long and prosper GA-)


Cheers,
mg

PS: Alas Patreon does not support backing on a regular basis through 
Paypal, which also threw me off at first (they claim technical 
difficulties). If you prefer to use Paypal, you might consider donating 
$50 for the year (2 months off ;-) ).








Re: Groovy file associations on Windows

2019-02-11 Thread MG
Just a general reminder: Not every company using Groovy has unrestricted 
internet access... :-)

Cheers,
mg

On 11/02/2019 14:11, Keegan Witt wrote:
Do folks using it really need it to be in the lib directory with all 
the other jars? Or could they just use Grapes/Grab?


If it's truly helpful, I can keep it.  I'm just wondering if it's 
overkill.


On Mon, Feb 11, 2019, 2:19 AM Paul King <mailto:pa...@asert.com.au> wrote:


I'd be inclined to keep GPars in the mix for now. It isn't
actively maintained but is still very useful in its current form
and I hope to put some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt mailto:keeganw...@gmail.com>> wrote:

In addition to removing projects that are no longer developed
from the Groovy Windows installer (Gpars, Gaelyk, Scriptom,
EasyB, Gant, GMock), I'm considering removing the exe files
from groovy-native-launcher
<https://github.com/groovy/groovy-native-launcher>. These
haven't been compiled in quite a while and are just another
thing to maintain.  As I see it, there are two primary
benefits these provide.

 1. Provide a way to create file associations so you can
double click a Groovy file, or run myFile.groovy instead
of groovy myFile.groovy.
 2. Hide the command window when launching GroovyConsole.

For #2, I can work around this with a VBScript file (or
NirCmd).  #1 doesn't have a good way to solve other than the
current native binary solution since Launch4J doesn't support
variable expansion
<https://sourceforge.net/p/launch4j/bugs/162/>.  My question
is, do many folks need this functionality? It's something I've
never personally used.  Please weigh in with your thoughts.

-Keegan





Re: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

2019-01-08 Thread MG



Am 08.01.2019 um 11:54 schrieb Paul King:


> (4) While sponsorship is below what we'd like and below what it
has been
> at some previous points in Groovy life, it isn't 0. We have several
> existing sponsors, e.g. OCI. The wording about the collective
should take
> that into consideration.

     Yep. OCI is a great company for Groovy! We always appreciate its
sponsorship.

      Let's imagine that would be really great if more people
involve into
developing Groovy, more big features(e.g. MOP2, async/await) are
completed
and hard issues(e.g. generics of STC) are fixed every year :-)


Totally agree with you, just suggesting the wording used is sensitive 
to existing players. I can help craft wording if needed.




Might be worth thinking about whether existing sponsors would consider 
giving their donation through the same channel ? Could have different 
tiers of sponsorship (gold, silver, etc), with respective logo sizes, 
etc to differentiate. Would lead to a greater exposure for them...
I guess it would also not be too hard to integrate a sponsor names or 
logos into e.g. Groovy console (if Apache allows that)...


Cheers,
mg





Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread MG

Hi,

out of curiosity (and because having a fat jar again might be 
conventient at some point in the future in my work environment (also no 
internet access)):


This solution proposed by Keith does not work
https://github.com/gradle/gradle-groovy-all
?

Cheers,
mg



Am 19.12.2018 um 23:33 schrieb Paul Moore:

On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:

Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
 deploy
}

dependencies {
 deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
 jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
 from configurations.deploy.collect { it.absolutePath }
 into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
 from "src"
 include "*.groovy"
 into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
 dependsOn copyDeps
 dependsOn copy
 from "dest"
 setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
 dependsOn copyDeps
 baseName = 'all-in-one-jar'
 from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul





Re: Long String concatenation failed

2018-09-25 Thread mg
I don't know if your specific case might be improved in the future, but in 
general Groovy supports e.g. operator overloading as well as DSL creation, 
which in turn means that it cannot always be 100% Java copy & paste compatible, 
even if it strives to do so as much as possible.
In any case it should not take long to refactor your code...
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  15:47  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
mg: Yes, I saw that it's working, but still,
groovy should add sugar to java instead of removing support of working code in 
java as:String text= "0"+"1" +"2" +"3";
Which I'm getting error:javax.script.ScriptException: 
groovy.lang.MissingMethodException: No signature of method: 
java.lang.String.positive() is applicable for argument types: () values: 
[]Possible solutions: notify(), tokenize(), size(), size()
Can I open a bug in groovy for this?
On Tue, Sep 25, 2018 at 4:04 PM, mg  wrote:
You can have new lines, just move the "<<" oi the end of the previous line, so 
Groovy knows there is more coming (Groovy does not need end-of-line semicolons 
btw):
String text ="" <" << vars["id2"] << ""
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  14:54  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
Thank for your answers, I still have some comments:mg: I don't want to have a 
huge line with 20 parameters that can't be seen on screen so I need new lines 
between parameters

Nelson, Erick: I don't need XML as the article suggest "
builder classes to create XML "

On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick  
wrote:








No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you














Re: Long String concatenation failed

2018-09-25 Thread mg
You can have new lines, just move the "<<" oi the end of the previous line, so 
Groovy knows there is more coming (Groovy does not need end-of-line semicolons 
btw):
String text ="" <" << vars["id2"] << ""
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  14:54  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
Thank for your answers, I still have some comments:mg: I don't want to have a 
huge line with 20 parameters that can't be seen on screen so I need new lines 
between parameters

Nelson, Erick: I don't need XML as the article suggest "
builder classes to create XML "

On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick  
wrote:








No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you












Re: Long String concatenation failed

2018-09-25 Thread mg
I replied to the original question and how to fix the the compile time error 
shown there, not your (valid) suggestion for a completely different approach... 
:-)
 Ursprüngliche Nachricht Von: "Nelson, Erick" 
 Datum: 25.09.18  14:39  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Long String concatenation failed 


No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you








Re: Long String concatenation failed

2018-09-25 Thread mg
If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  09:56  (GMT+01:00) An: users@groovy.apache.org Betreff: Long 
String concatenation failed 


Hello,I have to 

concatenate a lot of variables in a script and I want to make it readable, but 
I failed to separate lines as in java, The following code doesn't compile due 
to:Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:Script1.groovy: 2: unexpected token: << @ line 2, column 1.   << 
vars["id2"] << ""
Code:
String text ="" <" 
<< vars["id2"] << "";
Is there a workaround or a better way concatenation a string in groovy?
Related 
question:https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables

Thank you


Re: @MapConstructor + @CompileStatic on Static Inner Class => CTE

2018-09-03 Thread MG

Might have been reported before. Will do.

On 04.09.2018 00:12, Paul King wrote:

Please create an issue. VerifyError is always a bug.

On Tue, Sep 4, 2018 at 4:55 AM MG <mailto:mg...@arscreat.com>> wrote:


The following code using @MapConstructor on a static inner class
raises
a compile time error (see end of mail; different error when making
the
inner class non-static):

import groovy.transform.CompileStatic
import groovy.transform.MapConstructor

@CompileStatic
class GroovyMapConstructorCheck {

 @MapConstructor(noArg = true)
 static class Goo {
 final String s0 = "text0"
 final int x0
 final String s1
 final String s2 = "TEXT2"
 final o0

 @Override
 public String toString() {
 return "Goo(|$s0|,|$x0|,|$s1|,|$s2|,|$o0|)"
 }
 }

 void go() {
 println new Goo()
 println new Goo(s0:"abc")
 println new Goo(x0:123, s0:"abc")
 println new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(),
s0:"S0")
 final goo = new Goo(s1:"S1", s2:"S2", x0:-999, o0:new
Object(),
s0:"S0")
 }
}

final check = new GroovyMapConstructorCheck()
check.go()

/*
Compile time error:

java.lang.VerifyError: Bad type on operand stack
Exception Details:
   Location:
GroovyMapConstructorCheck$Goo.(Ljava/util/Map;)V @85:
invokevirtual
   Reason:
 Type 'GroovyMapConstructorCheck$Goo' (current frame,
stack[0]) is
not assignable to 'groovy/lang/Closure'
   Current Frame:
 bci: @85
 flags: { }
 locals: { 'GroovyMapConstructorCheck$Goo', 'java/lang/Object',
'java/lang/String', 'java/lang/String', 'groovy/lang/MetaClass' }
 stack: { 'GroovyMapConstructorCheck$Goo' }
   Bytecode:
 0x000: 2ab7 001b 121d 4d2c 2a5f b500 1f2c 5712
 0x010: 214e 2d2a 5fb5 0023 2d57 2ab6 0027 3a04
 0x020: 1904 2a5f b500 2919 0457 2bc7 0007 04a7
 0x030: 0004 0399 001a 03bd 0004 b800 2f3a 0519
 0x040: 0512 31b8 0035 c000 314c 1905 572a 2bb8
 0x050: 003b 0157 2ab6 0041 c000 4312 44b9 004a
 0x060: 0200 9900 232a b600 41c0 0043 1244 b900
 0x070: 4e02 003a 0619 06b8 0054 c000 562a 5fb5
 0x080: 001f 1906 572a b600 41c0 0043 1257 b900
 0x090: 4a02 0099 0020 2ab6 0041 c000 4312 57b9
 0x0a0: 004e 0200 3a07 1907 b800 5d2a 5fb5 005f
 0x0b0: 1907 572a b600 41c0 0043 1260 b900 4a02
 0x0c0: 0099 0023 2ab6 0041 c000 4312 60b9 004e
 0x0d0: 0200 3a08 1908 b800 54c0 0056 2a5f b500
 0x0e0: 6219 0857 2ab6 0041 c000 4312 63b9 004a
 0x0f0: 0200 9900 232a b600 41c0 0043 1263 b900
 0x100: 4e02 003a 0919 09b8 0054 c000 562a 5fb5
 0x110: 0023 1909 572a b600 41c0 0043 1264 b900
 0x120: 4a02 0099 001d 2ab6 0041 c000 4312 64b9
 0x130: 004e 0200 3a0a 190a 2a5f b500 6619 0a57
 0x140: b1
   Stackmap Table:

full_frame(@50,{Object[#2],Object[#70],Object[#86],Object[#86],Object[#108]},{})
 same_locals_1_stack_item_frame(@51,Integer)

full_frame(@77,{Object[#2],Object[#4],Object[#86],Object[#86],Object[#108]},{})
 same_frame(@133)
 same_frame(@179)
 same_frame(@228)
 same_frame(@277)
 same_frame(@320)


 at

GroovyMapConstructorCheck.go(MapConstructorCheck_inner_class_error.groovy:24)

 at GroovyMapConstructorCheck$go.call(Unknown Source)

 at

MapConstructorCheck_inner_class_error.run(MapConstructorCheck_inner_class_error.groovy:33)
*/





Re: @CompileStatic void method returns null ?

2018-09-03 Thread MG
But the call to Foo#baz() coud return an e.g. GroovyVoidObject instance, 
which in turn throws a "cannot return void from method" if that happens 
to be the last expression in your example, no ?
It feels like returning null here is just a stopgap, not anything one 
actually wants to have in the language...


I don't expect the dynamic compiler to be changed, but should we really 
mirror the dynamic comiler behavior in the static compiler in this case 
? I think it would be much more least surprise in the @CompileStatic case...


Cheers,
mg

PS: Calling void methods better be fine, otherwise why do they exist in 
the first place ;-)  - I am/was always referring to my initial question, 
so the whole thread is about expecting/using void method call results 
somewhere...



On 04.09.2018 01:41, Paul King wrote:

Calling void methods is fine. Expecting a result is the point in question.

For dynamic Groovy, you can't always tell which case you have:

class Foo {
  def bar() { 42 }
  void baz() { }
}

def method(boolean condition, delegate, meth1, meth2) {
  if (condition) delegate."$meth1"()
  else delegate."$meth2"()
}

println method(true, new Foo(), 'bar', 'baz') // 42
println method(false, new Foo(), 'bar', 'baz') // null

Here, "method" is expecting to return some value that happens to be 
the last expression, i.e. the result of the if/then/else expression, 
so we return null in such cases.


Cheers, Paul.


On Tue, Sep 4, 2018 at 7:38 AM MG <mailto:mg...@arscreat.com>> wrote:


What I meant was: What sense does letting void methods be called make
for the dynamic case, i.e. the dynamic compiler ? From a programmer's
perspective, i.e. what is a programming use case for that
feature/behavior, in dynamic Groovy ?

Of course I can do the following in dynamic Groovy:

// Groovy 2.5.0
class Goo {
 //void nogoo() { return 123 } // Dynamic Groovy compiler:
RuntimeParserException: Cannot use return statement with an
expression on a method that returns void
 void nogoo() { 123 }
}

final goo = new Goo()

println "original: goo.nogoo()=${goo.nogoo()}"

goo.metaClass.nogoo = { return 456 }

println "mopped: goo.nogoo()=${goo.nogoo()}"


Which will build, run, and output

original: goo.nogoo()=null
mopped: goo.nogoo()=456

  i.e. returning 456 from a void method in the second case.
But if I am using a library that includes the Goo class, why would I
ever expect a return value from the nogoo method (and therefore call
it), considering its return type is void ? And if I control the Goo
class myself, why would I not just change its return type to int
or def ?

Cheers,
mg


On 03.09.2018 22:36, Jochen Theodorou wrote:
> On 03.09.2018 17:13, mg wrote:
>> But in what scenario does the dynamic behavior make sense ?
>
> for a static compiler? none other than being compatible
>
> bye Jochen
>





Re: @CompileStatic void method returns null ?

2018-09-03 Thread MG
What I meant was: What sense does letting void methods be called make 
for the dynamic case, i.e. the dynamic compiler ? From a programmer's 
perspective, i.e. what is a programming use case for that 
feature/behavior, in dynamic Groovy ?


Of course I can do the following in dynamic Groovy:

// Groovy 2.5.0
class Goo {
    //void nogoo() { return 123 } // Dynamic Groovy compiler: 
RuntimeParserException: Cannot use return statement with an expression on a 
method that returns void
    void nogoo() { 123 }
}

final goo = new Goo()

println "original: goo.nogoo()=${goo.nogoo()}"

goo.metaClass.nogoo = { return 456 }

println "mopped: goo.nogoo()=${goo.nogoo()}"


Which will build, run, and output

original: goo.nogoo()=null
mopped: goo.nogoo()=456

 i.e. returning 456 from a void method in the second case.
But if I am using a library that includes the Goo class, why would I 
ever expect a return value from the nogoo method (and therefore call 
it), considering its return type is void ? And if I control the Goo 
class myself, why would I not just change its return type to int or def ?


Cheers,
mg


On 03.09.2018 22:36, Jochen Theodorou wrote:

On 03.09.2018 17:13, mg wrote:

But in what scenario does the dynamic behavior make sense ?


for a static compiler? none other than being compatible

bye Jochen





@MapConstructor + @CompileStatic on Static Inner Class => CTE

2018-09-03 Thread MG
The following code using @MapConstructor on a static inner class raises 
a compile time error (see end of mail; different error when making the 
inner class non-static):


import groovy.transform.CompileStatic
import groovy.transform.MapConstructor

@CompileStatic
class GroovyMapConstructorCheck {

    @MapConstructor(noArg = true)
    static class Goo {
    final String s0 = "text0"
    final int x0
    final String s1
    final String s2 = "TEXT2"
    final o0

    @Override
    public String toString() {
    return "Goo(|$s0|,|$x0|,|$s1|,|$s2|,|$o0|)"
    }
    }

    void go() {
    println new Goo()
    println new Goo(s0:"abc")
    println new Goo(x0:123, s0:"abc")
    println new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(), 
s0:"S0")
    final goo = new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(), 
s0:"S0")

    }
}

final check = new GroovyMapConstructorCheck()
check.go()

/*
Compile time error:

java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    GroovyMapConstructorCheck$Goo.(Ljava/util/Map;)V @85: 
invokevirtual

  Reason:
    Type 'GroovyMapConstructorCheck$Goo' (current frame, stack[0]) is 
not assignable to 'groovy/lang/Closure'

  Current Frame:
    bci: @85
    flags: { }
    locals: { 'GroovyMapConstructorCheck$Goo', 'java/lang/Object', 
'java/lang/String', 'java/lang/String', 'groovy/lang/MetaClass' }

    stack: { 'GroovyMapConstructorCheck$Goo' }
  Bytecode:
    0x000: 2ab7 001b 121d 4d2c 2a5f b500 1f2c 5712
    0x010: 214e 2d2a 5fb5 0023 2d57 2ab6 0027 3a04
    0x020: 1904 2a5f b500 2919 0457 2bc7 0007 04a7
    0x030: 0004 0399 001a 03bd 0004 b800 2f3a 0519
    0x040: 0512 31b8 0035 c000 314c 1905 572a 2bb8
    0x050: 003b 0157 2ab6 0041 c000 4312 44b9 004a
    0x060: 0200 9900 232a b600 41c0 0043 1244 b900
    0x070: 4e02 003a 0619 06b8 0054 c000 562a 5fb5
    0x080: 001f 1906 572a b600 41c0 0043 1257 b900
    0x090: 4a02 0099 0020 2ab6 0041 c000 4312 57b9
    0x0a0: 004e 0200 3a07 1907 b800 5d2a 5fb5 005f
    0x0b0: 1907 572a b600 41c0 0043 1260 b900 4a02
    0x0c0: 0099 0023 2ab6 0041 c000 4312 60b9 004e
    0x0d0: 0200 3a08 1908 b800 54c0 0056 2a5f b500
    0x0e0: 6219 0857 2ab6 0041 c000 4312 63b9 004a
    0x0f0: 0200 9900 232a b600 41c0 0043 1263 b900
    0x100: 4e02 003a 0919 09b8 0054 c000 562a 5fb5
    0x110: 0023 1909 572a b600 41c0 0043 1264 b900
    0x120: 4a02 0099 001d 2ab6 0041 c000 4312 64b9
    0x130: 004e 0200 3a0a 190a 2a5f b500 6619 0a57
    0x140: b1
  Stackmap Table:
full_frame(@50,{Object[#2],Object[#70],Object[#86],Object[#86],Object[#108]},{})
    same_locals_1_stack_item_frame(@51,Integer)
full_frame(@77,{Object[#2],Object[#4],Object[#86],Object[#86],Object[#108]},{})
    same_frame(@133)
    same_frame(@179)
    same_frame(@228)
    same_frame(@277)
    same_frame(@320)


    at 
GroovyMapConstructorCheck.go(MapConstructorCheck_inner_class_error.groovy:24)


    at GroovyMapConstructorCheck$go.call(Unknown Source)

    at 
MapConstructorCheck_inner_class_error.run(MapConstructorCheck_inner_class_error.groovy:33)

*/


Re: @CompileStatic void method returns null ?

2018-09-03 Thread mg
But in what scenario does the dynamic behavior make sense ? You tell the 
compiler that a method does not have a return value - then you call that method 
using its return value, knowing it will always be null... ?-)
So the following:

final result = voidMethod() // looks like result might contain something 
interesting after the call... ?-)
is 100% equivalent to:
voidMethod()final result = null // ...r - not :-/

I feel at least in the @CompileStatic case using a void return value should 
fail at compile time - what do you think ?


 Ursprüngliche Nachricht Von: Paul King  
Datum: 29.08.18  10:35  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
@CompileStatic void method returns null ? 
See also: https://issues.apache.org/jira/browse/GROOVY-8770
Which I presume was also to mimick dynamic behavior.
Cheers, Paul.

On Wed, Aug 29, 2018 at 4:42 AM Jochen Theodorou  wrote:
On 28.08.2018 19:45, mg wrote:

> Since I just stumbled across this behavior while helping a junior 

> developer debug his code: Why does statically compiled Groovy (2.5.2) 

> return null from void methods, instead of raising a compile error ?



i was actually not aware we kept this logic for static compilation, but 

essentially it is like that because of dynamic Groovy, which derives 

this from the reflective and methodhandles based method invocation



bye Jochen




@CompileStatic void method returns null ?

2018-08-28 Thread mg
Since I just stumbled across this behavior while helping a junior developer 
debug his code: Why does statically compiled Groovy (2.5.2) return null from 
void methods, instead of raising a compile error ? 

E.g. 

import groovy.transform.CompileStatic

@CompileStatic
class Goo {
void calcId(String a, String b) { // Programming error: Return type should be 
String
 "${a}.${b}"
}

String getId() {
 calcId("abera","kadavera")
}

String getId2() {
 String id = calcId("abera","kadavera")
 return id
}
}

final Goo goo = new Goo()
println "goo.calcId(...)=${goo.calcId("x","y")}"
println "goo.id=${goo.id}"
println "goo.id2=${goo.id2}" 


outputs 


goo.calcId(...)=null 
goo.id=null 
goo.id2=null
Cheers,mg



Re: multi-declaration does not work in the for loop, groovy 2.4

2018-08-06 Thread mg
2.5.x does not use the new Parrot parser afaik, the upcoming 3.x and its now 
dormant 2.6.x JDK 7 backport do.
(apart from that: Agree, never used that syntax in any language, never missed 
it in Groovy due to functional constructs)
 Ursprüngliche Nachricht Von: "Nelson, Erick" 
 Datum: 06.08.18  15:10  (GMT+00:00) An: 
users@groovy.apache.org Betreff: Re: multi-declaration does not work in the for 
loop, groovy 2.4 


Same in 2.5.1 from eclipse photon…
 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/Users/en032339/Documents/workspace3/script6/src/erick/erick.groovy: 6: 
unexpected token: = @ line 6, column 14.
   for (int foo = 0, bar = 0; foo

Reply-To: "users@groovy.apache.org" 

Date: Monday, August 6, 2018 at 6:37 AM

To: "users@groovy.apache.org" 

Subject: multi-declaration does not work in the for loop, groovy 2.4


 

Hi there, 

 


I have just bumped into a — presumably — parser error, which causes that a 
declaration of more variables is not accepted in a for loop:


 


===


44
/tmp> /usr/local/groovy-2.4.15/bin/groovy q


org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:


/private/tmp/q.groovy: 1: unexpected token: = @ line 1, column 13.


   for (int foo=0,bar=0;foo /usr/local/groovy-2.4.15/bin/groovy -version


Groovy Version: 2.4.15 JVM: 10.0.1 Vendor: "Oracle Corporation" OS: Mac OS X


45
/tmp> 


===


 


At the moment alas I can't test in newer groovys, not sure whether the problem 
is fixed there or not.


 


All the best,


OC


 




Re: Groovy and JDK 11: Compilation issue

2018-07-30 Thread mg
FYI: Groovy 2.4.15 under the current OpenJDK 11 prerelease, with IntelliJ as 
the build system ran (after the JDK deprecation fixes we needed, described in 
previous email) without any problems with our 900+ (database/integration) tests 
(WIN7), as well as Vaadin 7 (RHEL).
 Ursprüngliche Nachricht Von: Misagh Moayyed 
 Datum: 30.07.18  18:32  (GMT+00:00) An: 
users@groovy.apache.org Betreff: Groovy and JDK 11: Compilation issue 
Has anyone here tried to use Apache Groovy 2.5.1 or 3.x and JDK 11 together? I 
am trying to troubleshoot a build failure (Using Gradle 4.8, or 4.9) that 
manifests itself as:
...
General error during class generation: java.lang.UnsupportedOperationException
java.lang.UnsupportedOperationException
 at 
groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
 at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
 at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
Here is the full output of the 
failure:https://travis-ci.org/apereo/cas/builds/409569422
It appears to me that perhaps JDK 11 support for Groovy still has a few rough 
edges and may not be "officially" there. Could someone confirm this please?
Thanks. 
--Misagh

Groovy with OpenJDK 10 and IntelliJ Build - Solved

2018-07-30 Thread mg
Hi,
we recently had a little bit of time to revisit the OpenJDK 10 build problem: 
As it turns out, it has nothing to do with Groovy, module support, or OpenJDK - 
instead the missing JARs have simply been removed from JDK 10 (they had only 
been deprecated in JDK 9 - quick removal after deprecation in the Java world 
will need some getting used to ;-) ).
All one needs to do to remedy the situation is add external dependencies 
replacing the removed JDK functionality to ones project, in our case:
OJDK 10: glassfish-corba-omgapi-3.2.0-b005.jar (for Notes 9) 

OJDK 11: jaxb-api-2.3.0.jar (for Vaadin 7) 

(All these removals come from the same JEP:

JDK Extension Proposal (no longer a proposal, alreday happening in JDK 9/10/11 
- e.g. JAXB is gone in 11) betreffend das java.corba Problem, das wir gerade 
gelöst haben: 

http://openjdk.java.net/jeps/320 )
Chhers,mg

On Wed, Jul 4, 2018 at 9:28 AM MG 
  wrote:


Hi,

  

  does anyone allready have experience compiling a Groovy
  project under 

  IntelliJ and OpenJDK 10 ?

  We are currently using OpenJDK 8 and would need to evaluate
  (if 

  possible) if our Groovy framework has any problems building
  & running 

  under OpenJDK 10. We are using IntelliJ modules as our build
  system, and 

  with OpenJDK 10 the Groovy build throws an internal compiler
  error that 

  NotesException requires a base class from the java.corba
  module, which 

  can no longer be found. Is there a (quick) way to make Groovy
  code 

  module compatible under IntelliJ 2018.1.5 ?

  

  Cheers,

      mg

Re: XML RPC Service

2018-07-25 Thread MG
This Java lib also looks interesting, since it seems quite compact and 
explicitely mentions support for asynchronous calls (if you need that), 
which looks like it would lend itself nicely to be wrapped in some 
Groovy goodness (see below):

https://github.com/gturri/aXMLRPC

What we have found is, that oftentimes the best approach - if something 
is not covered by the core Groovy libraries already - is to pick the 
best/supported/maintained Java library, and develop your own Groovy 
wrapper as you go along. This is what we did with Vaadin (works like a 
charm), and are now planning to do for Apache LDAP. I usually use a 
static Groovy class for low level function-type support, and add 
configurable instance helper classes as needed. It does not take much 
effort to write these on the go, and you can use the newest Groovy 
features (many older Groovy based libraries are quite dynamic in nature 
I have found; if you are coming from Perl you might not mind, but coming 
from a C/C++/Java background myself I prefer as much static type safety 
as I can get - and modern Groovy (combined with a good IDE with Groovy 
support (I use IntelliJ myself, but the Eclipse Groovy supprt recently 
got a major update afaik) delivers on that, with @CompileStatic, 
@Delegate/traits, final fields support in ctors, etc)).


Cheers,
mg


On 19.07.2018 17:25, Bernhard Donaubauer wrote:

Hello,

I think about replacing an old xml-rpc service written in perl with groovy.

There are examples using groovy-xmlrpc like here:
https://gist.github.com/bjfish/370521

But I wonder if this module is still maintained. While I can find the
jar files in the repositories I can't find the according project or sources.

Regards,
Bernhard Donaubauer





Re: XML RPC Service

2018-07-25 Thread MG
I have no personal experience with either XML-RPC, SOAP or REST (DB 
Developer, Web-GUI needs covered by Vaadin), but this guy expresses a 
different (seemingly pragmatic) opinion (and he is using Groovy ;-) ):

https://sites.google.com/a/athaydes.com/renato-athaydes/posts/thereturnofrpc-orhowrestisnolongertheonlyrespectablesolutionforapis

(Generally speaking, in modern software development especially the web 
development domain to me seems to suffer from an overabundance of "this 
is the /absolute /right way to do things !" - until a newer/hipper/... 
(or simply different ?-) ) approach comes along the next year...; I mean 
I am not saying there is no improvement in some areas, but it took the 
web guys how many decades to rediscover configurable, encapsulated GUI 
components as a general concept ?-) )


Cheers,
mg


On 24.07.2018 12:33, Russel Winder wrote:

I suspect XML-RPC is pure legacy. It evolved into SOAP and that is pure
legacy.

All the Web Services folk I know are now using RESTful HTTP/HTTPS
microservices.

On Sat, 2018-07-21 at 16:50 +0200, Jacques Le Roux wrote:

Hi Bernhard,

Actually XML-RPC is no longer maintained, last fix in3.1.3 is for

http://www.openwall.com/lists/oss-security/2011/10/05/10

And there are CVEs pending :

https://0ang3el.blogspot.com/2016/07/beware-of-ws-xmlrpc-library-in-y
our.html

Other TLPs might be affected, I guess Archiva has been picked because
being the 1st in alphabetical order...

HTH

Jacques


Le 19/07/2018 à 17:25, Bernhard Donaubauer a écrit :

Hello,

I think about replacing an old xml-rpc service written in perl with
groovy.

There are examples using groovy-xmlrpc like here:
https://gist.github.com/bjfish/370521

But I wonder if this module is still maintained. While I can find
the
jar files in the repositories I can't find the according project or
sources.

Regards,
Bernhard Donaubauer







Re: About the groovy code style

2018-07-04 Thread MG

Two questions:

1. Jochen says "Danil  is doing special things with DSL", but "Daniil
   Ovchinnikov" replied regarding IntelliJ Groovy parsing. So is Danil
   == Daniil ?
2. I neither like nor use these syntax varieties - but wouldn't
   changing any of that behavior potentially break Groovy DSLs from
   here to Baghdad (not only "Danil"'s) ?-)

Cheers,
mg


On 04.07.2018 20:40, Paul King wrote:


Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou <mailto:blackd...@gmx.org>> wrote:




Am 03.07.2018 um 04:44 schrieb Daniel.Sun:
> Hi all,
>
>       The following code is supported in the older parser, but I
propose to
> stop supporting the ugly code style in the new Parrot parser.
Any thoughts?
>
> 1) import statement (
https://issues.apache.org/jira/browse/GROOVY-8642 )
> ```
> import java.
> lang.
> Object
> ```
>
> 2) prefix operator (
https://issues.apache.org/jira/browse/GROOVY-8650 )
> ```
> def c = --
> 1

I do not need these.. but since I know Danil is doing special things
with DSL, maybe we should first ask him if he needs that and why


Jochen, even though you say you "do not need these", the real question 
is what set of rules are you replacing the existing conceptual rule with?


Existing rule: if the set of tokens parsed when an end of line is 
reached doesn't make a complete expression/statement, continue reading 
tokens as if the EOL wasn't there.


There are exceptions, e.g. we currently don't allow single quote and 
single double quoted strings to span multiple lines but the list is short.


What are your new rules and new list of exceptions?

We shouldn't be tied down by our existing set of rules but we want to 
keep them simple for our users so they all don't need to be grammar 
experts to use the language.


Cheers, Paul.

bye Jochen





Re: Groovy with OpenJDK 10 and IntelliJ Build

2018-07-03 Thread MG
No, you pick the JDK for the project/module independently from the IDE. 
One problem is that IntelliJ does not (afaikt - I never had the need to 
do so before) support passing parameters to the Groovy compiler (you can 
supply a Groovy configscript).


On 04.07.2018 01:35, Paul King wrote:
Does the JDK you run Intellij under need to be the same as what your 
project settings point to?


On Wed, Jul 4, 2018 at 9:28 AM MG <mailto:mg...@arscreat.com>> wrote:


Hi,

does anyone allready have experience compiling a Groovy project under
IntelliJ and OpenJDK 10 ?
We are currently using OpenJDK 8 and would need to evaluate (if
possible) if our Groovy framework has any problems building & running
under OpenJDK 10. We are using IntelliJ modules as our build
system, and
with OpenJDK 10 the Groovy build throws an internal compiler error
that
NotesException requires a base class from the java.corba module,
which
can no longer be found. Is there a (quick) way to make Groovy code
module compatible under IntelliJ 2018.1.5 ?

    Cheers,
mg







Groovy with OpenJDK 10 and IntelliJ Build

2018-07-03 Thread MG

Hi,

does anyone allready have experience compiling a Groovy project under 
IntelliJ and OpenJDK 10 ?
We are currently using OpenJDK 8 and would need to evaluate (if 
possible) if our Groovy framework has any problems building & running 
under OpenJDK 10. We are using IntelliJ modules as our build system, and 
with OpenJDK 10 the Groovy build throws an internal compiler error that 
NotesException requires a base class from the java.corba module, which 
can no longer be found. Is there a (quick) way to make Groovy code 
module compatible under IntelliJ 2018.1.5 ?


Cheers,
mg





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

2018-06-22 Thread MG

Hi Paul,
sensible choice imho :-)
Cheers,
mg


On 23.06.2018 03:53, Paul King wrote:


There was overwhelming support to drop 2.6 to focus on 3.0 and mixed 
feedback
on whether to do one more 2.6 alpha release or not. So, I'll go ahead 
and do one more
2.6 alpha release - quite possibly much less work than further 
discussions and it gives
us a clean end point which I am highly in favour of to reduce 
subsequent discussions

about what exactly was in the last alpha release.

We aren't planning to delete the branch - so it's still around if we 
need some
further emergency regression fixes down the track, but we aren't 
planning to do
any merges, so it will start to go out of sync with other branches. So 
even if you
have an "emergency fix" for that branch, we'd encourage you to have a 
discussion

on the mailing list before creating PRs against that branch.

Cheers, Paul.


On Sat, Jun 16, 2018 at 8:55 AM Robert Stagner <mailto:restag...@gmail.com>> wrote:


option #2 for me

On Wed, Jun 13, 2018 at 12:06 AM Paul King mailto:pa...@asert.com.au>> wrote:


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.






GraalVM/Truffle ?

2018-06-13 Thread MG
Since GraalVM (https://en.wikipedia.org/wiki/GraalVM) was mentioned here 
recently: Do we have any statement on plans of Groovy with regards to 
GraalVM, including Truffle ? It might be good to have an official 
statement here on the main Groovy page and on Wikipedia 
(https://en.wikipedia.org/wiki/Apache_Groovy), even if it e.g., in 
essence, just states "Groovy runs/will run fine on GraalVM", "The 
Truffle license (GPL 2.0 w CP exception) is not compatible with Apache 
Groovy" or "Truffle makes no sense for Groovy (at this point)"...


Cheers,
mg




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

2018-06-13 Thread MG




On 6/13/2018 10:24 AM, h...@abula.org wrote:
(I may be alone on this one, but I'd even suggest to consider some of 
the Java syntax compatibility, if this helps speed up Groovy 3. If I 
need to write Java code, I can always put it in .java files.)


Java-syntax-compatibility-only-support in Groovy is not there to be used 
by Groovy developers (see previous discussions about warning when using 
these constructs), but to support copy & paste compatibility for people 
considering switching from Java.
I understand where you are coming from, but imho the closesness to Java 
always has been another strong argument for Groovy, and considering 
supporting Java syntax constructs in Groovy 3.0 through the Parrot 
parser seems pretty straightforward I think we should keep doing this.


An alternative would be to support a tool which auto-converts from Java 
to Groovy (I would estimate this would be more effort, and it does not 
really give the "copy & paste Java code and it is Groovy" experience). 
Or IntelliJ/Eclipse/Netbeans could support this as part of their 
respective code refactoring support...


Cheers,
mg




Den 2018-06-13 10:08, skrev Mario Garcia:

I would say 3 as well

2018-06-13 10:04 GMT+02:00 Robert Oschwald :


Same with me. Option 3 seems best, even when some of our projects
are still on Grails 2.

Am 13.06.2018 um 09:50 schrieb Søren Berg Glasius
:
While the project I'm on is still on JDK 7, but due to Grails 2.x I
think that option 3 is the best way to move forward (and nudge
projects on to a higher version of Grails as well).

/Søren

On Wed, 13 Jun 2018, 09.42 , 
wrote:

I agree on option 3 (abandon 2.6 immediately).

JDK 6 or 7 is not in use anywhere that I have project visibility.

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.

Best Regards

FROM: Paolo Di Tommaso [mailto:paolo.ditomm...@gmail.com]
SENT: Wednesday, June 13, 2018 3:18 AM
TO: users@groovy.apache.org
SUBJECT: Re: [DISCUSS] Groovy 2.6 potential retirement to focus on
Groovy 3.0

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
 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.

--

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.






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

2018-06-13 Thread MG

Option 2 or 3 from my side.
I have thought about this, and given the fast movement of the Java 
universe at the moment it seems the right move, from a resources and 
public perception point of view.


Also, Groovy 2.5 is not too shabby, so still being on JDK 7 it is not 
like "no Groovy for you" ;-)


Cheers,
mg


On 6/13/2018 9:05 AM, Paul King wrote:


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.






Re: [ANNOUNCE] Groovy 2.5.0 Windows Installer Released

2018-06-10 Thread MG

Thanks Keegan,
Cheers,
mg

On 10.06.2018 18:55, Keegan Witt wrote:
The Windows installer for Groovy 2.5.0 is available from the usual 
place: 
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-installer.exe


-Keegan





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

2018-06-10 Thread 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: IntelliJ: Full Groovy 2.5.0 Support

2018-06-04 Thread mg
Logically I would say yes, technically evidently no. Thank you Daniel and 
everybody who already voted :-)Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 04.06.18  02:25  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: Re: IntelliJ: Full Groovy 2.5.0 Support 
I thought child issues will be voted if we vote the parent issue...

Cheers,
Daniel.Sun




-
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: IntelliJ: Full Groovy 2.5.0 Support

2018-06-04 Thread mg
Logically I would say yes, technically evidently no. Thank you Daniel and 
everybody who already voted :-)Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 04.06.18  02:25  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: Re: IntelliJ: Full Groovy 2.5.0 Support 
I thought child issues will be voted if we vote the parent issue...

Cheers,
Daniel.Sun




-
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: IntelliJ: Full Groovy 2.5.0 Support

2018-06-02 Thread MG

Hi Daniil,

I have voted for the Groovy 3.0 Features child issues 
(https://youtrack.jetbrains.com/issue/IDEA-188050#tab=Linked%20Issues).


Cheers,
mg


On 02.06.2018 15:52, Daniil Ovchinnikov wrote:
none of the child issues to the Groovy 3.0 umbrella issue seems to 
have any votes

Yep, I should’ve clarified this earlier and invited users to vote.


in the end I myself would just upvote every child issue
And this is good. It’s much better than to upvote parent task and 
forget about it.
At least you will get a notification when each task is closed contrary 
to umbrella task that may remain open for a long time.



I would just do the ones that are quicker to do first

That’s what I’m now doing with 3.0 tasks. But upvotes do matter.

—

Daniil Ovchinnikov
JetBrains


On 2 Jun 2018, at 02:30, MG <mailto:mg...@arscreat.com>> wrote:


I just checked, and none of the child issues to the Groovy 3.0 
umbrella issue (https://youtrack.jetbrains.com/issue/IDEA-188050) 
seems to have any votes. I find that not surprising: As a developer 
that uses Groovy in place of Java to develop a larger framework using 
IntelliJ IDE, I can only use a Groovy feature once it has gotten 
proper IntelliJ support. I can toy around with it before that, of 
course, but to e.g. to finally be able to get rid of using the 
new-keyword in my project, IntelliJ support is tantamount. Other new 
features will be useful in different ways, other again I will have to 
check out further, to find where I can use them best. That makes a 
meaningful pioritization hard - in the end I myself would just upvote 
every child issue...


Others may see this differently of course, but I need support for all 
features, as fast as possible ;-)


To prioritize, I would just do the ones that are quicker to do first.
(Or once you have create the technicl child issues in the way you 
need them structured, you can ask people to vote between 2 or 3 
issues here / the Groovy Slack... (unless Paul/Jochen/Guillaume/... 
object, of course).)


It would be interesting to learn a little bit about the effort that 
goes into certain features, btw,

Cheers,
mg


On 01.06.2018 23:51, mg wrote:

Hi Daniil,

I am a bit confused here: For Groovy 3.0 someone created a similar 
issue, people voted on it to show that Groovy 3.0 feature support 
was important to them, you created a handful of child issues, and 
everything seemed well & fine :-)

How is this different then ?

Cheers,
mg


 Ursprüngliche Nachricht 
Von: Daniil Ovchinnikov 
Datum: 01.06.18 22:42 (GMT+01:00)
An: users@groovy.apache.org
Betreff: Re: IntelliJ: Full Groovy 2.5.0 Support

Hi mg,

First of all thank you for caring.

I just want to let you know that such abstract tickets have almost 
zero meaning other than serving as a parent for other smaller tasks.
It would be much more helpful to prioritize if you create a ticket 
for some particular feature and let others vote for it.


—

Daniil Ovchinnikov
JetBrains


On 1 Jun 2018, at 21:09, MG <mailto:mg...@arscreat.com>> wrote:


Hi,

I have created a Jetbrains issue you can vote on for IntelliJ to 
fully support Groovy 2.5 as soon as possible :-)


https://youtrack.jetbrains.com/issue/IDEA-193168

Cheers,
mg















Re: IntelliJ: Full Groovy 2.5.0 Support

2018-06-01 Thread MG
I just checked, and none of the child issues to the Groovy 3.0 umbrella 
issue (https://youtrack.jetbrains.com/issue/IDEA-188050) seems to have 
any votes. I find that not surprising: As a developer that uses Groovy 
in place of Java to develop a larger framework using IntelliJ IDE, I can 
only use a Groovy feature once it has gotten proper IntelliJ support. I 
can toy around with it before that, of course, but to e.g. to finally be 
able to get rid of using the new-keyword in my project, IntelliJ support 
is tantamount. Other new features will be useful in different ways, 
other again I will have to check out further, to find where I can use 
them best. That makes a meaningful pioritization hard - in the end I 
myself would just upvote every child issue...


Others may see this differently of course, but I need support for all 
features, as fast as possible ;-)


To prioritize, I would just do the ones that are quicker to do first.
(Or once you have create the technicl child issues in the way you need 
them structured, you can ask people to vote between 2 or 3 issues here / 
the Groovy Slack... (unless Paul/Jochen/Guillaume/... object, of course).)


It would be interesting to learn a little bit about the effort that goes 
into certain features, btw,

Cheers,
mg


On 01.06.2018 23:51, mg wrote:

Hi Daniil,

I am a bit confused here: For Groovy 3.0 someone created a similar 
issue, people voted on it to show that Groovy 3.0 feature support was 
important to them, you created a handful of child issues, and 
everything seemed well & fine :-)

How is this different then ?

Cheers,
mg


 Ursprüngliche Nachricht 
Von: Daniil Ovchinnikov 
Datum: 01.06.18 22:42 (GMT+01:00)
An: users@groovy.apache.org
Betreff: Re: IntelliJ: Full Groovy 2.5.0 Support

Hi mg,

First of all thank you for caring.

I just want to let you know that such abstract tickets have almost 
zero meaning other than serving as a parent for other smaller tasks.
It would be much more helpful to prioritize if you create a ticket for 
some particular feature and let others vote for it.


—

Daniil Ovchinnikov
JetBrains


On 1 Jun 2018, at 21:09, MG <mailto:mg...@arscreat.com>> wrote:


Hi,

I have created a Jetbrains issue you can vote on for IntelliJ to 
fully support Groovy 2.5 as soon as possible :-)


https://youtrack.jetbrains.com/issue/IDEA-193168

Cheers,
mg











Re: IntelliJ: Full Groovy 2.5.0 Support

2018-06-01 Thread mg
Hi Daniil,
I am a bit confused here: For Groovy 3.0 someone created a similar issue, 
people voted on it to show that Groovy 3.0 feature support was important to 
them, you created a handful of child issues, and everything seemed well & fine 
:-)How is this different then ?
Cheers,mg

 Ursprüngliche Nachricht Von: Daniil Ovchinnikov 
 Datum: 01.06.18  22:42  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: IntelliJ: Full Groovy 2.5.0 Support 
Hi mg,
First of all thank you for caring.
I just want to let you know that such abstract tickets have almost zero meaning 
other than serving as a parent for other smaller tasks.It would be much more 
helpful to prioritize if you create a ticket for some particular feature and 
let others vote for it.

—

Daniil Ovchinnikov
JetBrains




On 1 Jun 2018, at 21:09, MG  wrote:
Hi,

I have created a Jetbrains issue you can vote on for IntelliJ to fully support 
Groovy 2.5 as soon as possible :-)

https://youtrack.jetbrains.com/issue/IDEA-193168

Cheers,
mg








IntelliJ: Full Groovy 2.5.0 Support

2018-06-01 Thread MG

Hi,

I have created a Jetbrains issue you can vote on for IntelliJ to fully 
support Groovy 2.5 as soon as possible :-)


https://youtrack.jetbrains.com/issue/IDEA-193168

Cheers,
mg







Re: Groovy 2.5.0 IntelliJ support ?

2018-06-01 Thread MG

Hi Alexey,

thank you for the information, I have created an issue for full Groovy 
2.5 support.


Cheers,
mg


On 29.05.2018 11:44, Алексей Афанасьев wrote:
Hi! Partial support for 2.5.0 was announced in 2017.2 
<https://www.jetbrains.com/idea/whatsnew/#v2017-2-groovy-250>, but 
there are several features without proper handling still, for example 
@NamedParam. I think we will take a look at them soon.


Alexey Afanasiev.

2018-05-28 23:22 GMT+03:00 MG <mailto:mg...@arscreat.com>>:


Since the Groovy 3.0 ticket
(https://youtrack.jetbrains.com/issue/IDEA-188050
<https://youtrack.jetbrains.com/issue/IDEA-188050>) just got
updated (thanks to everyone who voted): Do we know what the status
for Groovy 2.5.0 IntelliJ support is ?
The release is around the corner and has some major new features
(http://groovy-lang.org/releasenotes/groovy-2.5.html
<http://groovy-lang.org/releasenotes/groovy-2.5.html>) which
require Intellisense support -  do we need a ticket for that (to
speed things up), Daniil, or is support already underway ?-)
Cheers,
mg








Re: Running a shell script with return value?

2018-05-30 Thread MG

http://groovy-lang.org/syntax.html#all-strings


On 30.05.2018 21:38, Chris Fouts wrote:

Thanks. Here's the complete code snippet

#!/usr/bin/env groovy

String cmd = $/

IFS=" " read -ra LINE <<< `ls -al | grep Music`

echo ${LINE[4]}

/$

StringBuilder outstr = new StringBuilder()

StringBuilder errstr = new StringBuilder()

Process proc = cmd.execute()

proc.waitForProcessOutput(outstr, errstr)

println $output


When I run it, I get

Caught: groovy.lang.MissingPropertyException: No such property: LINE 
for class: file


groovy.lang.MissingPropertyException: No such property: LINE for 
class: file


at file.run(file.groovy:5)



On Wed, May 30, 2018 at 2:59 PM Nelson, Erick 
mailto:erick.nel...@hdsupply.com>> wrote:


I mistyped

It is …

$/

/$

Similar to

'''

'''

They are known as “dollar slashy strings”

Erick Nelson

Senior Developer – IT

HD Supply Facilities Maintenance

(858) 740-6523 

*From: *Chris Fouts mailto:chrisfo...@ziftsolutions.com>>
*Reply-To: *"users@groovy.apache.org
" mailto:users@groovy.apache.org>>
*Date: *Wednesday, May 30, 2018 at 11:55 AM
*To: *"users@groovy.apache.org "
mailto:users@groovy.apache.org>>
*Subject: *Re: Running a shell script with return value?

Thanks. Do the /$ designate a begin/end fo the commands I want to
execute? So using my example, I do

String cmd = /$

IFS=" " read -ra LINE <<< `ls -al | grep some_file`

echo ${LINE[4]}

/$

On Wed, May 30, 2018 at 2:20 PM Nelson, Erick
mailto:erick.nel...@hdsupply.com>> wrote:

String cmd = /$

What you want to shell out and execute here

Remember, java shells out as sh, not bash or your shell of choice

/$

// output and error can be any class that implements Appendable

StringBuilder output = new StringBuilder()

StringBuilder error = new StringBuilder ()

Process proc = cmd.execute()

proc.waitForProcessOutput(output, error)

println proc.exitValue()

Erick Nelson

Senior Developer – IT

HD Supply Facilities Maintenance

(858) 740-6523 

*From: *Chris Fouts mailto:chrisfo...@ziftsolutions.com>>
*Reply-To: *"users@groovy.apache.org
" mailto:users@groovy.apache.org>>
*Date: *Wednesday, May 30, 2018 at 10:58 AM
*To: *"users@groovy.apache.org
" mailto:users@groovy.apache.org>>
*Subject: *Running a shell script with return value?

Inside groovy, I want to write a shell script that parses the
output of some shell command and get some string value back.
How can I get the value of the shell command?

For example say I want to get the file size of some_file, I'll do

x = sh returnStatus: true, script: '''

  IFS=" " read -ra LINE <<< `ls -al | grep some_file`

  echo ${LINE[4]}

'''

How can I store the value of ${LINE[4]} in a groovy variable
to use later?

Thanks,

Chris





Groovy 2.5.0 IntelliJ support ?

2018-05-28 Thread MG
Since the Groovy 3.0 ticket 
(https://youtrack.jetbrains.com/issue/IDEA-188050) just got updated 
(thanks to everyone who voted): Do we know what the status for Groovy 
2.5.0 IntelliJ support is ?
The release is around the corner and has some major new features 
(http://groovy-lang.org/releasenotes/groovy-2.5.html) which require 
Intellisense support -  do we need a ticket for that (to speed things 
up), Daniil, or is support already underway ?-)

Cheers,
mg





Re: What Java tools are developers using? - Vote for Groovy :-)

2018-05-17 Thread MG
Damn, sorry, did not see that its the same link Guillaume posted a few 
days back... *insertanimatedgifofyellowballhittingitshead*
Anyway, since people criticized the survey: I did not find anything 
suspicious, the questions looked fine to me, I did not think the answers 
were manipulative and the survey did not take long - so I add my voice 
to Guillaume's suggesting you invest 5 minutes of your time... :-)


On 17.05.2018 23:08, MG wrote:
If you have not already taken the language/tools/libraries survey 
(called "one of the largest surveys of Java developers" in the latest 
Java Magazine mail (May/June 2018 Edition) ;-) ), go here:

https://snykteam.typeform.com/to/V4LOUZ
and vote for Groovy (and the other tools/etc you use) !

Full disclaimer: Snyk is evidently selling this: https://snyk.io/ 
("Snyk helps you use open source and stay secure. Continuously find & 
fix vulnerabilities in your dependencies").


Never heard of them, but wondering if that
https://snyk.io/test ("Test my GitHub repositories: Get alerted when 
new vulnerabilities are found in your dependencies, and automatic pull 
requests when a fix is available.")

might be interesting for Groovy ?*

Cheers,
mg


*https://snyk.io/plans: "Free plan includes: Unlimited tests on open 
source projects"
















What Java tools are developers using? - Vote for Groovy :-)

2018-05-17 Thread MG
If you have not already taken the language/tools/libraries survey 
(called "one of the largest surveys of Java developers" in the latest 
Java Magazine mail (May/June 2018 Edition) ;-) ), go here:

https://snykteam.typeform.com/to/V4LOUZ
and vote for Groovy (and the other tools/etc you use) !

Full disclaimer: Snyk is evidently selling this: https://snyk.io/ ("Snyk 
helps you use open source and stay secure. Continuously find & fix 
vulnerabilities in your dependencies").


Never heard of them, but wondering if that
https://snyk.io/test ("Test my GitHub repositories: Get alerted when new 
vulnerabilities are found in your dependencies, and automatic pull 
requests when a fix is available.")

might be interesting for Groovy ?*

Cheers,
mg


*https://snyk.io/plans: "Free plan includes: Unlimited tests on open 
source projects"













Re: Question: Updating a database table

2018-05-10 Thread MG

final Sql sql = ...
sql.setEnableMetaDataChecking(false)

(Also see the comment by Saravanan Subiramaniam at the end of the 
comments section; have not tried this myself...)


Cheers,
mg


On 10.05.2018 18:15, Avinash Nanda wrote:
Unfortunately i couldnt combine the queries as i have logic which 
determines what data to update.


Also i tried looking at the below link but could know where i need to 
update the flag:
https://issues.apache.org/jira/browse/GROOVY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=1627#comment-1627 
<https://issues.apache.org/jira/browse/GROOVY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=1627#comment-1627>


Sorry i tried googling around the issue but didnt find anything relavent

On Thu, May 10, 2018 at 12:08 PM, Daniel.Sun <sun...@apache.org 
<mailto:sun...@apache.org>> wrote:


Hi Avinash,

FYI,

https://issues.apache.org/jira/browse/GROOVY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=1627#comment-1627

<https://issues.apache.org/jira/browse/GROOVY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=1627#comment-1627>

https://stackoverflow.com/questions/12192592/java-sql-sqlexception-ora-01000-maximum-open-cursors-exceeded

<https://stackoverflow.com/questions/12192592/java-sql-sqlexception-ora-01000-maximum-open-cursors-exceeded>

In addition, I suggest you try to combine update statement and select
statement and execute only one statement, or write an anonymous block
`BEGIN...END` to finish your query and update.

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
<http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>




--
Regards
Avinash




@MapConstructor(includeSuperProperties = true) => java.lang.NoSuchMethodError ?

2018-05-05 Thread MG
Why does @MapConstructor(includeSuperProperties = true) in the code 
below throw e.g. java.lang.NoSuchMethodError: groovy.A2: method 
()V not found ?
Giving @MapConstructor(pre={super(args)}) seems to be doing what I want, 
i.e. also initialize the super classes...

(It is great that @MapConstructor supports final class members btw)

class GroovyMapConstructorSpike {
  @Test @Ignore @CompileStatic void mapConstructorTest() {
final a0 =new A0([x0:11,s0:"aa"])
final a1 =new A1([x0:111,s0:"aaa",x1:222,s1:"bbb"])
final a2 =new A2([x0:111,s0:"aaa",x1:222,s1:"bbb",x2:,s2:""])
final a3 =new 
A3([x0:111,s0:"aaa",x1:222,s1:"bbb",x2:,s2:"",x3:4,s3:"d"])
println"a0=$a0" println"a1=$a1" println"a2=$a2" println"a3=$a3" }
}

@MapConstructor @ToString class A0 {
  final int x0 final Strings0 }

@MapConstructor(pre={super(args)})@ToString(includeSuper =true)class A1extends 
A0 {
  final int x1 final Strings1 }

@MapConstructor(pre={super(args)})@ToString(includeSuper =true)class A2extends 
A1 {
  final int x2 final Strings2 }

//@MapConstructor(includeSuperProperties = true) @ToString(includeSuper 
= true) class A3 extends A2 { // java.lang.NoSuchMethodError: groovy.A2: 
method ()V not found //@MapConstructor(includeSuperFields = true) 
@ToString(includeSuper = true) class A3 extends A2 { // 
java.lang.NoSuchMethodError: groovy.A2: method ()V not found 
@MapConstructor(pre={super(args)})@ToString(includeSuper =true)class A3extends A2 {// works final int x3 final Strings3 }



Result:

a0=groovy.A0(11, aa)
a1=groovy.A1(222, bbb, groovy.A0(111, aaa))
a2=groovy.A2(, , groovy.A1(222, bbb, groovy.A0(111, aaa)))
a3=groovy.A3(4, d, groovy.A2(, , groovy.A1(222, bbb, 
groovy.A0(111, aaa


Cheers,
mg





Re: [Poll] About supporting Java-like array

2018-05-01 Thread MG
I think we should do this, for cases where the rewards of adhering to 
idiomatic Groovy are less obvious or it might be missed that there even 
_is_ an idiomatic Groovy way to do things (I have heard some people were 
not aware that array initialization without "as" was supported in Groovy 
;-) ).

Any particular thoughts on how to go about adding such warnings ?
Cheers,
mg


On 30.04.2018 16:08, Paul King wrote:
I suggested CodeNarc first partly because it would be a little bit of 
work to add warnings - the Groovy compiler doesn't really have any at 
present.
Also, Groovy has tried to not be too opinionated. If you leave those 
semicolons in, Groovy won't complain. Of course removing the 
semicolons is its own reward! :-)


Cheers, Paul.

On Mon, Apr 30, 2018 at 10:30 PM, mg <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


Yes, but what about all the (hopefully many) people new to Groovy,
who don't use CodeNarc ? How do you educate them about what is
idiomatic Groovy ?
Especially in cases like this, where a completely equivalent
Groovy alternative exists...

I imagine something along the line:

Warning: Using {...} Java style array literals is not idiomatic
Groovy. To avoid confusion with Groovy closures, it is recommended
to use the performance-identical Groovy [...] list literal syntax
instead.

I think we should decide if that is something we want to do in
general, or not. My argument for it is, to avoid Groovy becoming a
Babylonian-syntax-language like e.g. Ruby...

Cheers,
mg





 Ursprüngliche Nachricht 
Von: Paul King <pa...@asert.com.au <mailto:pa...@asert.com.au>>
Datum: 30.04.18 01:51 (GMT+01:00)
An: users@groovy.apache.org <mailto:users@groovy.apache.org>
Betreff: Re: [Poll] About supporting Java-like array



    On Mon, Apr 30, 2018 at 9:10 AM, mg <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:

I would propose the Groovy compiler issue a warning to change
the array initialization from Java- to Groovy-style then...


A codenarc rule would be a great first option.

Cheers,
mg



 Ursprüngliche Nachricht 
Von: Paul King <pa...@asert.com.au <mailto:pa...@asert.com.au>>
Datum: 30.04.18 00:29 (GMT+01:00)
An: users@groovy.apache.org <mailto:users@groovy.apache.org>
Betreff: Re: [Poll] About supporting Java-like array

The preferred Groovy syntax would probably still remain:

int[] fibs = [1, 1, 2, 3, 5, 8]

Cheers, Paul.

On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:

After thinking about this some more for the last weeks
+1 with asterisk
from my side:

1) I am always for being as Java compatible as possible
(though I see that this might not be feasible in all cases
in the future, due to Java changing at a much faster pace
and with more syntax changes now than before; example:
Java considered naming the new "var" keword "def", which
is similar to but not the same as Java-var in Groovy...)

2) I feel  { { } } being interpreted as an array
containing an empty closure is confusing, i.e. not least
surprise. I would rather not see it cut it so close with
regards to what the Parrot parser can handle syntax-wise.
What do others think ?

3) After introducing this syntax extension, what will be
considered the "Groovy way" of initializing an array in
the future ? Is it still
final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
or
final int[] a = { 1, 1, 2, 3, 5, 8 }
?
In the 2nd case I would be worried that the core Groovy
syntax becomes all over the place over time, same as with
the new Java lambda syntax (though less pronounced, since
using/initializing arrays is typically rare).

4) I am not too worried about the breaking edge cases,
because I feel they are quite rare in practice, the
compiler catches them, and they are easy to fix.

Cheers,
mg




On 29.04.2018 15:29, Paul King wrote:

+1

For completeness, I added some more details about the
breaking changes and workarounds into the issue -
included below for easy reading.

Cheers, Paul.

=

Groovy currently "promotes" a singleton instance of an
object into an array for assignments, e.g.:

Integer[] nums = 42
assert nums instanceof Integer[]

Re: [Poll] About supporting Java-like array

2018-05-01 Thread MG
I have created the issue: 
https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-8566


Feel free to comment on the "less lenient for static compilation case ?" 
question:
"An additonal question would be, whether in the static case the 
automatic conversion of the RHS expression to fit the LHS array type 
should be less lenient, i.e. the list structure should be required to 
conform to the array dimensions given on the left ?"


Cheers,
mg


On 30.04.2018 05:18, Paul King wrote:
That sounds like a limitation we'd like to remove when using 
@CompileStatic. Want to create a Jira?


Cheers, Paul.

On Mon, Apr 30, 2018 at 12:39 PM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


Hi Daniel,

I did a quick check and it works with dynamic Groovy, but is
rejected under static compilation:

@Test @Ignore void arrayFromListLiteral() {
   int[] a0 = [1,2,3]
   int[][] aa0 = [[1,2,3],[4,5,6]]
   int[][][] aaa0 = [[[1],[2],[3]],[[4],[5],[6]]]
   int[][][] aaa1 = [[1,2,3],[4,5,6]]
   int[][][] aaa2 = [1,2,3,4,5,6]
   int[][][] aaa3 =1 println"a0=$a0" println"aa0=$aa0" println"aaa0=$aaa0" println"aaa1=$aaa1" 
println"aaa2=$aaa2" println"aaa3=$aaa3" assert a0instanceof int[]
   assert aa0instanceof int[][]
   assert aaa0instanceof int[][][]
   assert aaa1instanceof int[][][]
   assert aaa2instanceof int[][][]
   assert aaa3instanceof int[][][]
}

gives:

a0=[1, 2, 3]
aa0=[[1, 2, 3], [4, 5, 6]]
aaa0=[[[1], [2], [3]], [[4], [5], [6]]]
aaa1=[[[1], [2], [3]], [[4], [5], [6]]]
aaa2=[[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]]
aaa3=[[[1]]]


with @CompileStatic the compiler gives:

Error:(37, 19) Groovyc: [Static type checking] - Cannot assign
value of type java.util.List  into array of
type int[][]
Error:(38, 22) Groovyc: [Static type checking] - Cannot assign
value of type java.util.List  into array of type
int[][][]
Error:(39, 22) Groovyc: [Static type checking] - Cannot assign
value of type java.util.List  into array of
type int[][][]
Error:(40, 22) Groovyc: [Static type checking] - Cannot assign
value of type int into array of type int[][][]
Error:(41, 22) Groovyc: [Static type checking] - Cannot assign
value of type int to variable of type int[][][]

    and one has to do

int[][] aa0 = [[1,2,3],[4,5,6]]as int[][]

etc

Cheers,
mg




On 30.04.2018 02:02, Daniel Sun wrote:

Hi mg,

  As far as I remember, two dimensional array like`int[][] a = [[1, 2,
3], [4, 5, 6]]` will go wrong in the Groovy style.

Cheers,
Daniel.Sun




--
Sent from:http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
<http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>








Re: [Poll] About supporting Java-like array

2018-04-30 Thread mg
Yes, but what about all the (hopefully many) people new to Groovy, who don't 
use CodeNarc ? How do you educate them about what is idiomatic Groovy 
?Especially in cases like this, where a completely equivalent Groovy 
alternative exists...

I imagine something along the line:
Warning: Using {...} Java style array literals is not idiomatic Groovy. To 
avoid confusion with Groovy closures, it is recommended to use the 
performance-identical Groovy [...] list literal syntax instead.
I think we should decide if that is something we want to do in general, or not. 
My argument for it is, to avoid Groovy becoming a Babylonian-syntax-language 
like e.g. Ruby...
Cheers,mg




 Ursprüngliche Nachricht Von: Paul King <pa...@asert.com.au> 
Datum: 30.04.18  01:51  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
[Poll] About supporting Java-like array 


On Mon, Apr 30, 2018 at 9:10 AM, mg <mg...@arscreat.com> wrote:
I would propose the Groovy compiler issue a warning to change the array 
initialization from Java- to Groovy-style then...

A codenarc rule would be a great first option. Cheers,mg


 Ursprüngliche Nachricht Von: Paul King <pa...@asert.com.au> 
Datum: 30.04.18  00:29  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
[Poll] About supporting Java-like array 
The preferred Groovy syntax would probably still remain:

int[] fibs = [1, 1, 2, 3, 5, 8]

Cheers, Paul.
On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com> wrote:

  

  
  
After thinking about this some more for the last weeks

+1 with asterisk

from my side:



1) I am always for being as Java compatible as possible (though I
see that this might not be feasible in all cases in the future, due
to Java changing at a much faster pace and with more syntax changes
now than before; example: Java considered naming the new "var"
keword "def", which is similar to but not the same as Java-var in
Groovy...) 



2) I feel  { { } } being interpreted as an array containing an empty
closure is confusing, i.e. not least surprise. I would rather not
see it cut it so close with regards to what the Parrot parser can
handle syntax-wise. What do others think ?



3) After introducing this syntax extension, what will be considered
the "Groovy way" of initializing an array in the future ? Is it
still 

final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]

or

final int[] a = { 1, 1, 2, 3, 5, 8 }

?

In the 2nd case I would be worried that the core Groovy syntax
becomes all over the place over time, same as with the new Java
lambda syntax (though less pronounced, since using/initializing
arrays is typically rare).



4) I am not too worried about the breaking edge cases, because I
feel they are quite rare in practice, the compiler catches them, and
they are easy to fix.



Cheers,

mg







On 29.04.2018 15:29, Paul King wrote:



  +1



For completeness, I added some more details about the
  breaking changes and workarounds into the issue - included
  below for easy reading.



Cheers, Paul.



=




  Groovy currently "promotes" a singleton instance of an
object into an array for assignments, e.g.:
  

  
  Integer[] nums = 42
  assert nums instanceof Integer[]
  assert nums.size() == 1
  assert nums[0] instanceof Integer
  

  
  This aligns with how Groovy behaves if you try to call
`.each{}` on a non-aggregate. It treats it like a singleton
collection and "iterates" over the one item.
  

  
  The existing behavior also currently works for singleton
Closures:
  

  
  Closure[] fns0 = { }
  assert fns0 instanceof Closure[]
  assert fns0.size() == 1
  assert fns0[0] instanceof Closure
  

  
  To add support for Java array notation, we will need to
partially disable this behavior. The proposed change
involves smart parsing, e.g. it will distinguish cases which
must be an array and cases which must be a closure but there
are some degenerate edge cases which will become breaking
changes.
  

  
  The case with the empty closure above will no longer
work, instead you will get this behavior, i.e. an empty
array is given precedence over an empty closure:
  

  
  Closure[] fns1 = { }
  assert fns1 instanceof Closure[]
  assert fns1.size() == 0
  

  
  To get the old behavi

Re: [Poll] About supporting Java-like array

2018-04-30 Thread mg
Will do. What do we think about the required strictness of the RHS list literal 
matching the LHS array type ? Should this be required to be more 1:1 than in 
the "as" case ?E.g. shallint[][][] aaa3 = 1still be valid ?
Cheers,mg

 Ursprüngliche Nachricht Von: Paul King <pa...@asert.com.au> 
Datum: 30.04.18  05:18  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
[Poll] About supporting Java-like array 
That sounds like a limitation we'd like to remove when using @CompileStatic. 
Want to create a Jira?
Cheers, Paul.
On Mon, Apr 30, 2018 at 12:39 PM, MG <mg...@arscreat.com> wrote:

  

  
  
Hi Daniel,



I did a quick check and it works with dynamic Groovy, but is
rejected under static compilation:

@Test
@Ignore
void arrayFromListLiteral() {
  int[] a0 = [1,2,3]
  int[][] aa0 = [[1,2,3],[4,5,6]]
  int[][][] aaa0 = [[[1],[2],[3]],[[4],[5],[6]]]
  int[][][] aaa1 = [[1,2,3],[4,5,6]]
  int[][][] aaa2 = [1,2,3,4,5,6]
  int[][][] aaa3 = 1

  println "a0=$a0"
  println "aa0=$aa0"
  println "aaa0=$aaa0"
  println "aaa1=$aaa1"
  println "aaa2=$aaa2"
  println "aaa3=$aaa3"

  assert a0 instanceof int[]
  assert aa0 instanceof int[][]
  assert aaa0 instanceof int[][][]
  assert aaa1 instanceof int[][][]
  assert aaa2 instanceof int[][][]
  assert aaa3 instanceof int[][][]
}

gives:



a0=[1, 2, 3]

aa0=[[1, 2, 3], [4, 5, 6]]

aaa0=[[[1], [2], [3]], [[4], [5], [6]]]

aaa1=[[[1], [2], [3]], [[4], [5], [6]]]

aaa2=[[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]]

aaa3=[[[1]]]





with @CompileStatic the compiler gives:



Error:(37, 19) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List  into array of type
int[][]

Error:(38, 22) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List  into array of type
int[][][]

Error:(39, 22) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List  into array of type
int[][][]

Error:(40, 22) Groovyc: [Static type checking] - Cannot assign value
of type int into array of type int[][][]

Error:(41, 22) Groovyc: [Static type checking] - Cannot assign value
of type int to variable of type int[][][]



and one has to do 

int[][] aa0 = [[1,2,3],[4,5,6]] as int[][]
etc



Cheers,

mg

    





On 30.04.2018 02:02, Daniel Sun wrote:



  Hi mg,

 As far as I remember, two dimensional array like`int[][] a = [[1, 2,
3], [4, 5, 6]]` will go wrong in the Groovy style.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





  





Re: [Poll] About supporting Java-like array

2018-04-29 Thread MG

Hi Daniel,

I did a quick check and it works with dynamic Groovy, but is rejected 
under static compilation:


@Test @Ignore void arrayFromListLiteral() {
  int[] a0 = [1,2,3]
  int[][] aa0 = [[1,2,3],[4,5,6]]
  int[][][] aaa0 = [[[1],[2],[3]],[[4],[5],[6]]]
  int[][][] aaa1 = [[1,2,3],[4,5,6]]
  int[][][] aaa2 = [1,2,3,4,5,6]
  int[][][] aaa3 =1 println"a0=$a0" println"aa0=$aa0" println"aaa0=$aaa0" println"aaa1=$aaa1" 
println"aaa2=$aaa2" println"aaa3=$aaa3" assert a0instanceof int[]
  assert aa0instanceof int[][]
  assert aaa0instanceof int[][][]
  assert aaa1instanceof int[][][]
  assert aaa2instanceof int[][][]
  assert aaa3instanceof int[][][]
}

gives:

a0=[1, 2, 3]
aa0=[[1, 2, 3], [4, 5, 6]]
aaa0=[[[1], [2], [3]], [[4], [5], [6]]]
aaa1=[[[1], [2], [3]], [[4], [5], [6]]]
aaa2=[[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]]
aaa3=[[[1]]]


with @CompileStatic the compiler gives:

Error:(37, 19) Groovyc: [Static type checking] - Cannot assign value of 
type java.util.List  into array of type int[][]
Error:(38, 22) Groovyc: [Static type checking] - Cannot assign value of 
type java.util.List  into array of type int[][][]
Error:(39, 22) Groovyc: [Static type checking] - Cannot assign value of 
type java.util.List  into array of type int[][][]
Error:(40, 22) Groovyc: [Static type checking] - Cannot assign value of 
type int into array of type int[][][]
Error:(41, 22) Groovyc: [Static type checking] - Cannot assign value of 
type int to variable of type int[][][]


and one has to do

int[][] aa0 = [[1,2,3],[4,5,6]]as int[][]

etc

Cheers,
mg



On 30.04.2018 02:02, Daniel Sun wrote:

Hi mg,

  As far as I remember, two dimensional array like`int[][] a = [[1, 2,
3], [4, 5, 6]]` will go wrong in the Groovy style.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Re: [Poll] About supporting Java-like array

2018-04-29 Thread mg
Well tickle my belly and colour me green - I always thought using the "as" form 
was mandatory here (based on the examples I saw on the net back then) :-)
That means this is the one case where giving an explicit type is the most 
concise way to get what you want ;-)
I would propose the Groovy compiler issue a warning to change the array 
initialization from Java- to Groovy-style then...Cheers,mg


 Ursprüngliche Nachricht Von: Paul King <pa...@asert.com.au> 
Datum: 30.04.18  00:29  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
[Poll] About supporting Java-like array 
The preferred Groovy syntax would probably still remain:

int[] fibs = [1, 1, 2, 3, 5, 8]

Cheers, Paul.
On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com> wrote:

  

  
  
After thinking about this some more for the last weeks

+1 with asterisk

from my side:



1) I am always for being as Java compatible as possible (though I
see that this might not be feasible in all cases in the future, due
to Java changing at a much faster pace and with more syntax changes
now than before; example: Java considered naming the new "var"
keword "def", which is similar to but not the same as Java-var in
Groovy...) 



2) I feel  { { } } being interpreted as an array containing an empty
closure is confusing, i.e. not least surprise. I would rather not
see it cut it so close with regards to what the Parrot parser can
handle syntax-wise. What do others think ?



3) After introducing this syntax extension, what will be considered
the "Groovy way" of initializing an array in the future ? Is it
still 

final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]

or

final int[] a = { 1, 1, 2, 3, 5, 8 }

?

In the 2nd case I would be worried that the core Groovy syntax
becomes all over the place over time, same as with the new Java
lambda syntax (though less pronounced, since using/initializing
arrays is typically rare).



4) I am not too worried about the breaking edge cases, because I
feel they are quite rare in practice, the compiler catches them, and
they are easy to fix.



Cheers,

mg







On 29.04.2018 15:29, Paul King wrote:



  +1



For completeness, I added some more details about the
  breaking changes and workarounds into the issue - included
  below for easy reading.



Cheers, Paul.



=




  Groovy currently "promotes" a singleton instance of an
object into an array for assignments, e.g.:
  

  
  Integer[] nums = 42
  assert nums instanceof Integer[]
  assert nums.size() == 1
  assert nums[0] instanceof Integer
  

  
  This aligns with how Groovy behaves if you try to call
`.each{}` on a non-aggregate. It treats it like a singleton
collection and "iterates" over the one item.
  

  
  The existing behavior also currently works for singleton
Closures:
  

  
  Closure[] fns0 = { }
  assert fns0 instanceof Closure[]
  assert fns0.size() == 1
  assert fns0[0] instanceof Closure
  

  
  To add support for Java array notation, we will need to
partially disable this behavior. The proposed change
involves smart parsing, e.g. it will distinguish cases which
must be an array and cases which must be a closure but there
are some degenerate edge cases which will become breaking
changes.
  

  
  The case with the empty closure above will no longer
work, instead you will get this behavior, i.e. an empty
array is given precedence over an empty closure:
  

  
  Closure[] fns1 = { }
  assert fns1 instanceof Closure[]
  assert fns1.size() == 0
  

  
  To get the old behavior back you have a couple of
options. Firstly, you can provide the explicit closure
argument delimiter:
  

  
  Closure[] fns2 = { -> } // can't be an array
  assert fns2 instanceof Closure[]
  assert fns2.size() == 1
  assert fns2[0] instanceof Closure
  

  
  Or don't rely on singleton promotion and explicitly
provide also the array curly braces:
  

  
  Closure[] fns3 = { { } }
  assert fns3 instanceof Closure[]
  assert fns3.size() == 1
  assert fns3[0] instanceof Closure
  

  
  Similarly, for the ca

Re: [Poll] About supporting Java-like array

2018-04-29 Thread MG

After thinking about this some more for the last weeks
+1 with asterisk
from my side:

1) I am always for being as Java compatible as possible (though I see 
that this might not be feasible in all cases in the future, due to Java 
changing at a much faster pace and with more syntax changes now than 
before; example: Java considered naming the new "var" keword "def", 
which is similar to but not the same as Java-var in Groovy...)


2) I feel  { { } } being interpreted as an array containing an empty 
closure is confusing, i.e. not least surprise. I would rather not see it 
cut it so close with regards to what the Parrot parser can handle 
syntax-wise. What do others think ?


3) After introducing this syntax extension, what will be considered the 
"Groovy way" of initializing an array in the future ? Is it still

final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
or
final int[] a = { 1, 1, 2, 3, 5, 8 }
?
In the 2nd case I would be worried that the core Groovy syntax becomes 
all over the place over time, same as with the new Java lambda syntax 
(though less pronounced, since using/initializing arrays is typically rare).


4) I am not too worried about the breaking edge cases, because I feel 
they are quite rare in practice, the compiler catches them, and they are 
easy to fix.


Cheers,
mg



On 29.04.2018 15:29, Paul King wrote:

+1

For completeness, I added some more details about the breaking changes 
and workarounds into the issue - included below for easy reading.


Cheers, Paul.

=

Groovy currently "promotes" a singleton instance of an object into an 
array for assignments, e.g.:


Integer[] nums = 42
assert nums instanceof Integer[]
assert nums.size() == 1
assert nums[0] instanceof Integer

This aligns with how Groovy behaves if you try to call `.each{}` on a 
non-aggregate. It treats it like a singleton collection and "iterates" 
over the one item.


The existing behavior also currently works for singleton Closures:

Closure[] fns0 = { }
assert fns0 instanceof Closure[]
assert fns0.size() == 1
assert fns0[0] instanceof Closure

To add support for Java array notation, we will need to partially 
disable this behavior. The proposed change involves smart parsing, 
e.g. it will distinguish cases which must be an array and cases which 
must be a closure but there are some degenerate edge cases which will 
become breaking changes.


The case with the empty closure above will no longer work, instead you 
will get this behavior, i.e. an empty array is given precedence over 
an empty closure:


Closure[] fns1 = { }
assert fns1 instanceof Closure[]
assert fns1.size() == 0

To get the old behavior back you have a couple of options. Firstly, 
you can provide the explicit closure argument delimiter:


Closure[] fns2 = { -> } // can't be an array
assert fns2 instanceof Closure[]
assert fns2.size() == 1
assert fns2[0] instanceof Closure

Or don't rely on singleton promotion and explicitly provide also the 
array curly braces:


Closure[] fns3 = { { } }
assert fns3 instanceof Closure[]
assert fns3.size() == 1
assert fns3[0] instanceof Closure

Similarly, for the case of the identity closure:

Closure[] fns4 = { it }

Previously this worked but under this proposal will give:

groovy.lang.MissingPropertyException: No such property: it ...

Your options are to add the extra array braces as per above, or use 
explicit params, e.g.:


Closure[] fns5 = { it -> it }
assert fns5 instanceof Closure[]
assert fns5.size() == 1
assert fns5[0] instanceof Closure

Alternatively, for this special case you have the following additional 
option:


Closure[] fns6 = Closure.IDENTITY
assert fns6 instanceof Closure[]
assert fns6.size() == 1
assert fns6[0] instanceof Closure

There are other cases as well, e.g. this code which currently creates 
a closure array containing a closure returning the integer 0:


Closure[] fns7 = { 0 }

will no longer be supported and will fail with:

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot 
cast object '0' with class 'java.lang.Integer' to class 
'groovy.lang.Closure'

The solutions are similar to previously (explicit delimiter):

Closure[] fns8 = { -> 0 }

or (explicit outer array braces):

Closure[] fns9 = { { 0 } }


On Sun, Apr 29, 2018 at 8:37 PM, Daniel.Sun <sun...@apache.org 
<mailto:sun...@apache.org>> wrote:


Hi all,

     As we all know, Java array is one of features widely applied
in Java
projects. In order to improve the compatibility with Java(Copy &
Paste). The
PR[1] will make Groovy support java-like array and make the
differences[2]
with Java less and less, e.g.

*One-Dimensional array*
```
String[] names = {'Jochen', 'Paul', 'Daniel'}
```

*Two-Dimensional array*
```
int[][] data = {
    {1, 2, 3},
    {4, 5, 6},
    {7, 8, 9},
    new int[] { 10, 11, 12 },
    {13, 14, 15}
}
```

  

Error:Groovyc: Abstract method 'getInstance1' is not implemented but a method of the same name but different return type is defined

2018-04-24 Thread MG
With regards to the problem described by Schalk Cronjé: This is the 
persistent, non-deterministic build problem I have had in Groovy since 
groovy-2.1.x up to groovy-2.4.x and IntelliJ_CE_13_1_3 to IntelliJ2017_3:


The schematic code shown below (which exists in similar from in the code 
multiple times) sometimes throws the following error during a (larger) 
minimal rebuild:


Error:Groovyc: Abstract method 'basePackage.getInstance1' is not 
implemented but a method of the same name but different return type is 
defined: method 'foooPackage.getInstance1'


The error disappears through just restarting the build multiple times. 
Rebuilding the same module multiple times in a row seems to have a much 
higher chance of the build failing again (starting a minimal rebuild of 
the whole project takes forever and is practically guaranteed to fail).


Cheers,
mg


interface BaseIntf {
  BaseIntf getInstance1()
}

// basePackage abstract class Baseimplements BaseIntf {
  Stringname Base(String name) {this.name = name }
  abstract Base getInstance1()
  static String makeName(String n,int i) {"$n$i" }
}

// foooPackage class Foooextends Base {
  static final Foooinstance0 static final Foooinstance1 static {
instance0 =new Fooo('ABC')
instance1 =new Fooo(makeName(instance0.name,1))
  }

  protected Fooo(String name) {super(name) }

  @Override Fooo getInstance1() {return instance1 }// Leads to indeterministic bug //@Override Base getInstance1() { return 
instance1 } // Works }






Re: Java does not see method implemented in Groovy

2018-04-23 Thread mg
Are you using the Gradle build cache ?Have you tried building the code using 
the IntelliJ build system (I am not sure if you mean that by "In IntelliJ this 
is not flagged up as an issue either" or that only Intellisense does not 
complain) ?
Cheers,mg
 Ursprüngliche Nachricht Von: Schalk Cronjé <ysb...@gmail.com> 
Datum: 23.04.18  12:05  (GMT+01:00) An: users@groovy.apache.org Betreff: Java 
does not see method implemented in Groovy 

Hi all,
I have build an hierarchy that effectively looks like:



  Abstract Base #1 (Java)

      ^

      |

  Abstract Base #2 (Groovy, CompileStatic)

      ^

      |

Abstract Base #3 (Groovy, CompileStatic)

      ^

      |

Abstract Base #4 (Groovy, CompileStatic) <- Implements
  methodA from Abstract Base #1

      ^    ^ ^  

      |    | |

  ExampleG (Groovy)    ExampleJ (Java)   ExampleK (Kotlin)



Finally there are three examples - one each in  Groovy, Java and
  otlin example. They extend #4 with concrete classes. The Groovy
  and Kotlin examples compile fine, but the Java complains that
  methodA is not implemented. The real signature of methodA is
  actually

  SeekableByteChannel newByteChannel(Path path, Set options, FileAttribute[]
  attrs) throws IOException

  

This could be down to what the Groovy compiler (2.4.11) has done
  with the generics, but it has me me confused. I am even more
  surprised that only the Java compiler complains and not the Kotlin
  compiler.  In IntelliJ this is not flagged up as an issue either.
  It only occurs when compiling the project with Gradle.


I know my example is slightly vague, but it removes all of the
  noise. The actual code of the offending class is here ->
https://gitlab.com/ysb33rOrg/java-nio2-providers/blob/development/commons-compress-provider-core/src/test/java/org/ysb33r/nio/provider/commons_core/examples/java/GzFileSystemProvider.java
Now I'm hoping if anyone has seen issues like this before or have
  an idea where I can start diagnosing it.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
  

Re: Groovy 3.0: Multiline list/map arguments

2018-04-06 Thread MG

Hi Jochen,

yes newline is a whitespace in Groovy, but not every whitespace is a 
newline. For me that is why Daniel's Ruby counter-example does not fit 
in my case, since a newline is much more visible than a space (or tab).
Answering "how likely is something" with "in [0,1]" is always correct, 
yes. But have you (or anyone else on this list) ever seen an index 
access that goes over multipe lines ?


It is about the example I gave (which is actually from a Groovy test I 
am working on), not about println, and the method accepting the List is 
not always under your control, so changing it to accepting Object... 
instead is not always possible (also what if someone has a List, then he 
has to convert it to an Object array).


In your println example, why would people not assign the list to a 
variable - since it is now used 2x that makes sense, also with regard to 
the classic error of not updating what you print in relation to what you 
return from the method.


I would also require one or more space or tab characters after the 
"list" in your multiline example, i.e.


// Compiles to list([0])
list [
  0
]

instead of

// Does not compile
list[
  0
]

Cheers,
mg



On 06.04.2018 23:29, Jochen Theodorou wrote:

On 06.04.2018 21:21, MG wrote:
My suggestion was not to consider allowing any whitespace to break 
syntax ambiguity here, but only a newline after the opening square 
bracket, i.e.:


whitespace in terms of the groovy grammar includes newline usually.


// Still does not compile
final result = foo [ "some rather long literal string argument",
 "another long literal string argument",
 "and so on and so forth...",
]

// Parsed as foo([ ... ])  (not foo-index-access)
final result = foo [
  "some rather long literal string argument",
 "another long literal string argument",
 "and so on and so forth...",
]


so you want

list[0]

keep as is now and

list[
  0
]

be instead list([0])?

If the parser can do it, it would feel Groovy to me to allow it for 
this use case (Of course it could still mean "index access", but how 
many people would really write an index access on foo that way ?).


asking "but how many people would" is always to be answered with 
"potentially many"


Groovy 3.0 is the place to ponder such questions, imho, because 
breaking changes will come anyway afaiks (Java 9 modules), so you do 
it here, or not for a long time...


Would be interested what others think, or if someone has a counter 
example that makes it clear it is a bad idea to go down that route,


why not use


final result = foo (
 "some rather long literal string argument",
 "another long literal string argument",
 "and so on and so forth..."
)


instead and make foo use Object...? The real problem is a different 
one imho.


people try things and start debugging code with println. They have for 
example


return [x,y]

and change this now to

println [x,y]
return [x,y]

or log it...

Obviously they started with a list and do not want indexing at all. 
They want the method call variant you propose. But in my experience 
this has really been the only case where it plays a role. And I think 
to give it up just because of that... give up I mean because I prefer 
having to write println([x,y]) to simulate the method call, than 
having to write... println.getAt([x,y]) to simulate the index. 
Especially since the later requires people to actually now the method 
name used for the index operation, which in most cases, they will not 
care about really. And do you really want to write


println [
 x,y]

to get a method call?

bye Jochen





Re: Groovy 3.0: Multiline list/map arguments

2018-04-06 Thread MG
My suggestion was not to consider allowing any whitespace to break 
syntax ambiguity here, but only a newline after the opening square 
bracket, i.e.:


// Still does not compile
final result = foo [ "some rather long literal string argument",
    "another long literal string argument",
    "and so on and so forth...",
]

// Parsed as foo([ ... ])  (not foo-index-access)
final result = foo [
 "some rather long literal string argument",
    "another long literal string argument",
    "and so on and so forth...",
]

If the parser can do it, it would feel Groovy to me to allow it for this 
use case (Of course it could still mean "index access", but how many 
people would really write an index access on foo that way ?).


Groovy 3.0 is the place to ponder such questions, imho, because breaking 
changes will come anyway afaiks (Java 9 modules), so you do it here, or 
not for a long time...


Would be interested what others think, or if someone has a counter 
example that makes it clear it is a bad idea to go down that route,

mg


On 06.04.2018 19:49, Daniel.Sun wrote:

Hi mg,

   It's dangerous to let blank characters determine the grammar, which is
the lesson learned from Ruby ;-)

```ruby
def f(p)
   return p * 2
end

f(3+2)+1 #  11
f (3+2)+1#  12,  have you seen the space between `f` and `(`  ?
```
(you can try the above code at http://tryruby.org)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Re: Groovy 3.0: Multiline list/map arguments

2018-04-06 Thread MG

Hi Daniel,

I know that  "println [1, 2, 3]" fails, but I literally have never 
wanted to literally print a list literal ;-)


My question was related to the fact that there is only whitespace + 
newline right after the opening list bracket "[", and that this syntax 
variety would  conceivably not be used if someone was going for an index 
expression.
Backward compatibility breaking changes aside, would the Parrot be able 
to discern these cases ?


Cheers,
mg


On 06.04.2018 18:25, Daniel.Sun wrote:

Hi mg,

   `foo []` is ambiguous, parser can parse it as index expression or
parse it as method invocation without parentheses, the former is applied to
solve the ambiguity.

Similarly, `println [1, 2, 3]` will fail too ;-)

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Groovy 3.0: Multiline list/map arguments

2018-04-06 Thread MG
Quick question, since I just came across that again in Groovy 2.4: Will 
Groovy 3.0 support passing multiline lists/maps to a method without 
surrounding it with brackets ?


E.g.

def foo(List l) { ... }

could be called giving

final result = foo [
 "some rather long literal string argument",
    "another long literal string argument",
    "and so on and so forth (not the language)",
]

instead of

final result = foo ([
 "some rather long literal string argument",
    "another long literal string argument",
    "and so on and so forth (not the language)",
])





Groovy 3.0: What's Coming

2018-03-27 Thread MG

Hi guys,

for everyone that has not seen it yet, there is a big article on the 
upcoming Groovy 3.0 in the newest Java Magazine:

http://www.javamagazine.mozaicreader.com/MarApr2018/Default/61/0#=61=0=0

Cheers,
mg




Re: JDK 10: Use of var over def?

2018-03-25 Thread MG
Here is an improved version of my own sample (with var keyword, i.e. 
non-executable), hopefully better exemplifying my point:


@Canonical class Foo {int x }
@InheritConstructors class SonOfFooextends Foo {int sonOfFooMethod() { ... } }
@InheritConstructors class SonOfSonOfFooextends SonOfFoo {int 
sonOfSonOfFooMethod() { ...} }

SonOfFoo mayReturnSonOfSonOfFoo() { ... }

@CompileStatic void flowTypedVar() {
  var f =new SonOfFoo(21)// Transformed by compiler to: SonOfFoo f = new SonOfFoo(21); no other 
changes to Groovy necessary f =new Foo(-1)// Fails at compile time with "Cannot assign value of type Foo to 
variable of type SonOfFoo" f.sonOfFooMethod()// works // ... f = mayReturnSonOfSonOfFoo()// works // ... if(finstanceof SonOfSonOfFoo) {

f.sonOfsonOfFooMethod()// Works because of flow typing (fails at compile 
time in Java) }
}

I hope that exemplifies better my thinking that var != def and flow 
typing are not necessarily either or, but orthogonal Groovy features, 
which would conceivably play well together.
I understand that you have a gut feeling that there mightbe a case out 
there where this may not hold, but until someone can come up with an 
example, I would hate to conceptually loose flow typing (which is a 
really powerful feature) just because of using var :-)


Cheers,
mg


On 25.03.2018 15:19, Paul King wrote:
For the majority of cases, you will be able to conceptually think of 
it as if the declaration type of the LHS is the inferred type of the RHS.
Until we have thought about non-denotable types etc. a bit more, I 
don't want to preempt whether a more sophisticated conceptual model 
will sometimes be needed.
Also, note that it isn't Object in your example but SomeTestClass$1 or 
something like that.


Cheers, Paul.

On Sun, Mar 25, 2018 at 12:30 AM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


There is no "var" in my example because it is currently valid
Groovy code, so I already had to do the var -> typeof(RHS)
substitution in the line "SonOfFoo f = new SonOfFoo(21)". I maybe
should have made that more explicit :-)
The reason I used currently valid Groovy was, that the point I am
trying to make is: Why should var not just become typeof(RHS),
while all the rest stays the same ? That should give us Java-like
type safety, with some added Groovy goodness...

Your example as currently working Groovy (JUnit) code through only
replacing var with its RHS type:

static class Main {}

@Test @Ignore @CompileStatic void main() {
   // mg: was "var x = new Object() {" Object x =new Object() {
 public void myMethod() { System.out.println(new Date()); } };
x.myMethod(); // okay because the inferred type is the AIC // mg:
Was "var y = new Main();" Main y =new Main();
   y =new Main() {// reassignment okay because new type is subclass of 
inferred type
public void myMethod() { System.out.println(new Date());}
   };

   // mg: Works y.myMethod(); // <=== error: cannot find symbol //
mg: If commented in, fails (as expected) with "Cannot assign value
of type Integer to variable of type Main"//y = new Integer(3); //
<=== error: incompatible types: Integer cannot be converted to Main }

Cheers,
mg




On 24.03.2018 13:08, Paul King wrote:

I don't see a var in your example?

Basically, we can use def and have flow typing (which would be
the behavior if we make var always an alias for def) or we can
behave like Java:

// Java
import java.util.Date;

public class Main {
public static void main(String[] args) {
var x = new Object() {
public void myMethod() { System.out.println(new Date());}
};
x.myMethod(); // okay because the inferred type is the AIC
var y = new Main();
y = new Main() { // reassignment okay because new type is
subclass of inferred type
public void myMethod() { System.out.println(new Date());}
};

//y.myMethod(); // <=== error: cannot find symbol
            // symbol: method myMethod()
            // location: variable y of type Main

//y = new Integer(3); // <=== error: incompatible types: Integer
cannot be converted to Main
}
}

which effectively means that we infer as we do now but no flow
typing. Conceptually, you may think that in the above Java
example that var y has type Main (typeof RHS) but that isn't
reflected in the bytecode in the same way that a type for a field
or parameter would be reflected, so it's much more a concept that
the compiler knows about rather than a concept that the bytecode
knows about. Currently flow typing allows both the above "error"
lines to succeed. But to behave like Java, we need both to fail.

Cheers, Paul.


On Sat, Mar 24, 2018 at 3:14 AM, MG <mg...@arscreat.com
<mailto:mg...@ars

Re: JDK 10: Use of var over def?

2018-03-24 Thread MG
There is no "var" in my example because it is currently valid Groovy 
code, so I already had to do the var -> typeof(RHS) substitution in the 
line "SonOfFoo f = new SonOfFoo(21)". I maybe should have made that more 
explicit :-)
The reason I used currently valid Groovy was, that the point I am trying 
to make is: Why should var not just become typeof(RHS), while all the 
rest stays the same ? That should give us Java-like type safety, with 
some added Groovy goodness...


Your example as currently working Groovy (JUnit) code through only 
replacing var with its RHS type:


static class Main {}

@Test @Ignore @CompileStatic void main() {
  // mg: was "var x = new Object() {" Object x =new Object() {
public void myMethod() { System.out.println(new Date()); }
  };
  x.myMethod();// okay because the inferred type is the AIC // mg: Was "var y = new 
Main();" Main y =new Main();
  y =new Main() {// reassignment okay because new type is subclass of inferred type 
public void myMethod() { System.out.println(new Date());}

  };

  // mg: Works y.myMethod();// <=== error: cannot find symbol // mg: If commented in, fails (as 
expected) with "Cannot assign value of type Integer to variable of type 
Main"//y = new Integer(3); // <=== error: incompatible types: Integer 
cannot be converted to Main }


Cheers,
mg



On 24.03.2018 13:08, Paul King wrote:

I don't see a var in your example?

Basically, we can use def and have flow typing (which would be the 
behavior if we make var always an alias for def) or we can behave like 
Java:


// Java
import java.util.Date;

public class Main {
public static void main(String[] args) {
var x = new Object() {
public void myMethod() { System.out.println(new Date());}
};
x.myMethod(); // okay because the inferred type is the AIC
var y = new Main();
y = new Main() { // reassignment okay because new type is subclass of 
inferred type

public void myMethod() { System.out.println(new Date());}
};

//y.myMethod(); // <=== error: cannot find symbol
// symbol: method myMethod()
// location: variable y of type Main

//y = new Integer(3); // <=== error: incompatible types: Integer 
cannot be converted to Main

}
}

which effectively means that we infer as we do now but no flow typing. 
Conceptually, you may think that in the above Java example that var y 
has type Main (typeof RHS) but that isn't reflected in the bytecode in 
the same way that a type for a field or parameter would be reflected, 
so it's much more a concept that the compiler knows about rather than 
a concept that the bytecode knows about. Currently flow typing allows 
both the above "error" lines to succeed. But to behave like Java, we 
need both to fail.


Cheers, Paul.


On Sat, Mar 24, 2018 at 3:14 AM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


Hi Paul,

wouldn't it make sense to combine flow typing with  var x = RHS 
being identical to  typeof(RHS) x = RHS  :

@Canonical static class Foo {
   int x }

@InheritConstructors static class SonOfFooextends Foo {
   int sonOfFooMethod() {2*x }
}


@Test @Ignore @CompileStatic void flowTypedVar() {
   SonOfFoo f =new SonOfFoo(21)
   //f = new Foo(-1) // compile time fails with "Groovyc: [Static
type checking] - Cannot assign value of type
groovy.GroovyGeneralSpike$Foo to variable of type
groovy.GroovyGeneralSpike$SonOfFoo" //f.sonOfFooMethod() //
compile time fails with "Groovyc: [Static type checking] - Cannot
find matching method
groovy.GroovyGeneralSpike$Foo#sonOfFooMethod()." if(finstanceof SonOfFoo) {
 println f.sonOfFooMethod()// works because of flow typing }
}

Cheers,
mg




On 23.03.2018 15:42, Paul King wrote:

The Parrot parser already has support for this at the grammar
level but we regard some of the current implementation details as
experimental.

At the moment it is almost just an alias for "def" but
discussions have been around whether we can make the behavior
closer to Java when used within static Groovy code. We haven't
defined exactly what this would mean yet but roughly I suspect it
could mean the same inferencing as now but without flow typing.

Cheers, Paul.


On Fri, Mar 23, 2018 at 10:12 PM, Merlin Beedell
<mbeed...@cryoserver.com <mailto:mbeed...@cryoserver.com>> wrote:

I see that the newly release JDK 10 now supports the “var”
declaration for local variables where the type can clearly be
inferred from its initialiser:

http://openjdk.java.net/jeps/286
<http://openjdk.java.net/jeps/286>

I note that Groovy’s “def” syntax (among others) was
mentioned but rejected.

Would Groovy move to support this syntax in the same way
(support ‘var’ only for Type Safe inferred declarations) or

Re: JDK 10: Use of var over def?

2018-03-23 Thread MG

Hi Paul,

wouldn't it make sense to combine flow typing with  var x = RHS being 
identical to  typeof(RHS) x = RHS  :


@Canonical static class Foo {
  int x }

@InheritConstructors static class SonOfFooextends Foo {
  int sonOfFooMethod() {2*x }
}


@Test @Ignore @CompileStatic void flowTypedVar() {
  SonOfFoo f =new SonOfFoo(21)
  //f = new Foo(-1) // compile time fails with "Groovyc: [Static type 
checking] - Cannot assign value of type groovy.GroovyGeneralSpike$Foo to 
variable of type groovy.GroovyGeneralSpike$SonOfFoo" 
//f.sonOfFooMethod() // compile time fails with "Groovyc: [Static type 
checking] - Cannot find matching method 
groovy.GroovyGeneralSpike$Foo#sonOfFooMethod()." if(finstanceof SonOfFoo) {

println f.sonOfFooMethod()// works because of flow typing }
}

Cheers,
mg



On 23.03.2018 15:42, Paul King wrote:
The Parrot parser already has support for this at the grammar level 
but we regard some of the current implementation details as experimental.


At the moment it is almost just an alias for "def" but discussions 
have been around whether we can make the behavior closer to Java when 
used within static Groovy code. We haven't defined exactly what this 
would mean yet but roughly I suspect it could mean the same 
inferencing as now but without flow typing.


Cheers, Paul.


On Fri, Mar 23, 2018 at 10:12 PM, Merlin Beedell 
<mbeed...@cryoserver.com <mailto:mbeed...@cryoserver.com>> wrote:


I see that the newly release JDK 10 now supports the “var”
declaration for local variables where the type can clearly be
inferred from its initialiser:

http://openjdk.java.net/jeps/286 <http://openjdk.java.net/jeps/286>

I note that Groovy’s “def” syntax (among others) was mentioned but
rejected.

Would Groovy move to support this syntax in the same way (support
‘var’ only for Type Safe inferred declarations) or as a general
alias to the “def” keyword?

JDK 10 also has support for “docker” containers.  The ecosystem
has certainly shifted!

Merlin Beedell






Re: Vote for Groovy 3 support in IntelliJ :-)

2018-03-22 Thread MG
Voting for "IDEA-188050 Support for Groovy 3 syntax" has slowed down, 
2^7-1 at the moment.


For anyone who is interested, here are all issues sorted by # of votes:
https://youtrack.jetbrains.com/issues?q=sort%20by:%20Votes%20

(Yes, evidently "IDEA-163208 Add support for MacBook Touch Bar (Magic 
Toolbar)" has 789 votes, just slightly below the front runner, "CPP-494 
Support Makefile projects" at 816 - maybe someone could tell these guys 
it's 2000++++ ;-) )

mg


On 21.03.2018 14:36, Daniel.Sun wrote:

Here is the link:  https://youtrack.jetbrains.com/issue/IDEA-188050

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Re: Groovy 3 lambda, method reference, default methods

2018-03-22 Thread mg
That answers the 2.6 question, thank you Daniil :-)mg
 Ursprüngliche Nachricht Von: Daniil Ovchinnikov 
<daniil.ovchinni...@jetbrains.com> Datum: 22.03.18  13:59  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy 3 lambda, method reference, default 
methods 
It will be deduced it from library with a single switch to use Parrot in 
2.6.There is no other reason not to use library version, since Groovy can’t 
cross compile classes to run with old Groovy versions.

—

Daniil Ovchinnikov
Software Developer
JetBrains
jetbrains.com
“Drive to develop”





On 22 Mar 2018, at 15:42, mg <mg...@arscreat.com> wrote:
Will Groovy 3.0 feature support be configurable (as for Java), or will it be 
deduced from Groovy libs used, ... ?
 Ursprüngliche Nachricht Von: Daniil Ovchinnikov 
<daniil.ovchinni...@jetbrains.com> Datum: 22.03.18  12:41  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy 3 lambda, method reference, default 
methods 
IntelliJ will support Groovy 3 but with own parser. 

- using the parser provided by Groovy library restricts support to that library 
version;
- compiler parsers are usually non-recoverable, but in IntelliJ we want to 
provide ability to work with broken code as much as possible, so we have own 
parsers for (almost) each language.

—

Daniil Ovchinnikov
Software Developer
JetBrains
jetbrains.com
“Drive to develop”



> On 21 Mar 2018, at 22:30, mg <mg...@arscreat.com> wrote:
> 
> I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be 
> switchable in IntelliJ, anything else would make little sense to me.
> But we have the expert on this mailing list, who should be able to tell us... 
> :-)
> mg
> 
>  Ursprüngliche Nachricht 
> Von: "Daniel.Sun" <sun...@apache.org>
> Datum: 21.03.18 17:10 (GMT+01:00)
> An: us...@groovy.incubator.apache.org
> Betreff: RE: Groovy 3 lambda, method reference, default methods
> 
> You can write Java8 style code(e.g. lambda, method/constructor reference,
> etc.) when Parrot parser is enabled :-)
> See https://github.com/danielsun1106/groovy-parser
> 
> 
> > Is there then a major difference in language between 2.6+Parrot and 3.0?
> 
> 3.0 enables Parrot parser by default, so no differences.
> 
> 
> > I wonder if the IntelliJ support ticket should be updated to say support
> > new language features in Groovy 2.6 as well?
> 
> I see the title contains "Groovy 3", so I am not sure if it will support 2.6
> 
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html




Re: Groovy 3 lambda, method reference, default methods

2018-03-22 Thread mg
Will Groovy 3.0 feature support be configurable (as for Java), or will it be 
deduced from Groovy libs used, ... ?
 Ursprüngliche Nachricht Von: Daniil Ovchinnikov 
<daniil.ovchinni...@jetbrains.com> Datum: 22.03.18  12:41  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy 3 lambda, method reference, default 
methods 
IntelliJ will support Groovy 3 but with own parser. 

- using the parser provided by Groovy library restricts support to that library 
version;
- compiler parsers are usually non-recoverable, but in IntelliJ we want to 
provide ability to work with broken code as much as possible, so we have own 
parsers for (almost) each language.

—

Daniil Ovchinnikov
Software Developer
JetBrains
jetbrains.com
“Drive to develop”



> On 21 Mar 2018, at 22:30, mg <mg...@arscreat.com> wrote:
> 
> I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be 
> switchable in IntelliJ, anything else would make little sense to me.
> But we have the expert on this mailing list, who should be able to tell us... 
> :-)
> mg
> 
>  Ursprüngliche Nachricht 
> Von: "Daniel.Sun" <sun...@apache.org>
> Datum: 21.03.18 17:10 (GMT+01:00)
> An: us...@groovy.incubator.apache.org
> Betreff: RE: Groovy 3 lambda, method reference, default methods
> 
> You can write Java8 style code(e.g. lambda, method/constructor reference,
> etc.) when Parrot parser is enabled :-)
> See https://github.com/danielsun1106/groovy-parser
> 
> 
> > Is there then a major difference in language between 2.6+Parrot and 3.0?
> 
> 3.0 enables Parrot parser by default, so no differences.
> 
> 
> > I wonder if the IntelliJ support ticket should be updated to say support
> > new language features in Groovy 2.6 as well?
> 
> I see the title contains "Groovy 3", so I am not sure if it will support 2.6
> 
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html



RE: Groovy 3 lambda, method reference, default methods

2018-03-21 Thread mg
I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be 
switchable in IntelliJ, anything else would make little sense to me.But we have 
the expert on this mailing list, who should be able to tell us... :-)mg
 Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> 
Datum: 21.03.18  17:10  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: RE: Groovy 3 lambda, method reference, default methods 
You can write Java8 style code(e.g. lambda, method/constructor reference,
etc.) when Parrot parser is enabled :-)
See https://github.com/danielsun1106/groovy-parser


> Is there then a major difference in language between 2.6+Parrot and 3.0?

3.0 enables Parrot parser by default, so no differences.


> I wonder if the IntelliJ support ticket should be updated to say support
> new language features in Groovy 2.6 as well?

I see the title contains "Groovy 3", so I am not sure if it will support 2.6


Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html


RE: Groovy 3 lambda, method reference, default methods

2018-03-21 Thread mg
I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be 
switchable in IntelliJ, anything else would make little sense to me.But we have 
the expert on this mailing list, who should be able to tell us... :-)mg
 Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> 
Datum: 21.03.18  17:10  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: RE: Groovy 3 lambda, method reference, default methods 
You can write Java8 style code(e.g. lambda, method/constructor reference,
etc.) when Parrot parser is enabled :-)
See https://github.com/danielsun1106/groovy-parser


> Is there then a major difference in language between 2.6+Parrot and 3.0?

3.0 enables Parrot parser by default, so no differences.


> I wonder if the IntelliJ support ticket should be updated to say support
> new language features in Groovy 2.6 as well?

I see the title contains "Groovy 3", so I am not sure if it will support 2.6


Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html


Re: Groov 3.0 - nested code blocks - block/eval

2018-03-20 Thread MG

Hi Daniel,

On 21.03.2018 01:33, Daniel Sun wrote:

  Parrot is smart enough to distinguish closure and code block, so
`block` is not necessary.


Under http://groovy-lang.org/releasenotes/groovy-3.0.html it says:

"Be aware though that in Groovy having a code block looking structure 
after any method call will be seen as an attempt to pass a closure as 
the last parameter in the method call. This happens even after a new 
line. So it’s safe to start an anonymous code block after any other 
block (e.g. an if-then-else statement or another anonymous code block). 
Anywhere else and you might need to terminate the previous statement 
with a semicolon. In which case, see the note above about refactoring 
your code! :-)"


If that is no longer true, it should be updated :-)

Apart from that, as I said, "block" would make the semantic explicit. I 
always found nested code blocks inelegant/error prone, so in C++ I used

#define block if(false) {} else


  BTW, new keywords may break existing code ;)


Yes, every new reserverd word / keword must be evaluated whether it is 
worth introducing, also under this criteria.




  As for `eval`, we can use `{ /* do something here */ }()` instead, e.g.
`{ 'abc' }()`


Yes, that is what I used to use. Now I am wrapping it in a statically 
imported helper method, since the "()" at the end of the closure is 
syntactically inelegant:


static def eval(finalClosure cls) { cls() }

eval { ... }

But this creates a Closure instance, so it is inefficient. If Groovy had 
"inline closure" support, I would use that, but since it looks like this 
is still a long way off (if it ever comes - it was shot down a few years 
back when someone else created a ticket for it), I suggest this special 
version of it.


Cheers,
mg






Groov 3.0 - nested code blocks - block/eval

2018-03-20 Thread MG
With regards to the Groovy 3.0 Release Notes 
(http://groovy-lang.org/releasenotes/groovy-3.0.html) "Nested code 
blocks" section:
What about in addition supporting two reserved keywords, "block" and 
"eval", as follows:


void foo() {
  block {
    // Makes nested code block explicit (without it, the block could 
e.g. have a missing if or else construct before it)
    // Avoids the need to use semicolon before nested code block to 
distinguish code block from a closure

    // Otherwise no difference to Java nested code block
  }

  // equivalent to:
  if(true) { ... }


  final x = eval {
 // Nested code block whose final evaluated statement is its return 
value

  }

  // semi-equivalent to:
   final x =  true ? (...;...;...) : null
}


The application for these constructs for me lie in cases where one needs 
to create a scope with a local variables, but where one would need to 
pass a large number of parameters to a helper method that coud be 
introduced, or one would really have to try hard to come up with a 
meaningful method name (implying that the functionality is too 
small/specialized to be moved into a seperate method).


Thoughts ?
mg





Re: Vote for Groovy 3 support in IntelliJ :-)

2018-03-17 Thread MG

Congrats, up to 84 votes now :-)

On 17.03.2018 15:30, Derek Visch wrote:

Done, up to 77!

On Sat, Mar 17, 2018, 7:13 AM Dierk König <dierk.koe...@canoo.com 
<mailto:dierk.koe...@canoo.com>> wrote:


Done.

Dierk

sent from:mobile

Am 17.03.2018 um 06:52 schrieb Edgar Harutyunyan
<eharutyun...@fipsoft.com <mailto:eharutyun...@fipsoft.com>>:


done


On 03/16/2018 09:20 PM, MG wrote:

40 votes to date - great job everyone... :-)
Cheers,
mg


On 16.03.2018 09:18, Edd Grant wrote:

Also done!

Cheers,

Edd

On 16 March 2018 at 03:31, Daniel Sun <realblue...@hotmail.com
<mailto:realblue...@hotmail.com>> wrote:

Done :-)

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html




-- 
Web: http://www.eddgrant.com

Email: e...@eddgrant.com <mailto:e...@eddgrant.com>
Mobile: +44 (0) 7861 394 543





-- 
Kind Regards,

Edgar






Re: Vote for Groovy 3 support in IntelliJ :-)

2018-03-16 Thread MG

40 votes to date - great job everyone... :-)
Cheers,
mg


On 16.03.2018 09:18, Edd Grant wrote:

Also done!

Cheers,

Edd

On 16 March 2018 at 03:31, Daniel Sun <realblue...@hotmail.com 
<mailto:realblue...@hotmail.com>> wrote:


Done :-)

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
<http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>




--
Web: http://www.eddgrant.com
Email: e...@eddgrant.com <mailto:e...@eddgrant.com>
Mobile: +44 (0) 7861 394 543





Vote for Groovy 3 support in IntelliJ :-)

2018-03-15 Thread MG

Vote to get Groovy 3.0 support in IntelliJ as early as possible:

1. https://youtrack.jetbrains.com/issue/IDEA-188050
2. Log in
3. Click on icon right of "Voters" on the right

13 votes and counting,
Cheers,
mg





Re: Fund Groovy Development - Jira Task

2018-03-15 Thread mg

Hi Jochen,
I was considering all kind of / suggested funding approaches, including newer 
crypto currency based ones. My rationale for choosing the Jira task was that I 
considered it (at the very least) a good test balloon:# It did not require any 
of the core Groovy devs to invest time due to its informal nature - which## 
allows to keep the exact details of a funded feature a little bit fuzzy## as 
well as the way of transferring said funds## and even whether you will transfer 
the funds in the end - not what one wants, of course, but it means the 
commitment level is low# It does not require people to create a seperate 
account# It collects all funding goals in a single place# It allows to mix 
general (Java 9) and more specific goals easily# I expected people to voice 
their opinion on alternative preferred ways of funding (with hopefully a 
champion emerging)
I had hoped this informal approach would work, butif people prefer 
https://www.bountysource.com, then all for it :-)
(I am just worried that the sums that can be gathered that way are pretty small 
- that seemed to be the problem with all the services I have looked at; it 
seems people need the "all together now" and emotional involvement of a 
Kickstarter to give sizable sums...Feel free to prove me wrong everyone :-) )
(Also I cannot set this up, since you already need to know where the money 
goes, etc...)
Cheers,mg


 Ursprüngliche Nachricht Von: Jochen Theodorou 
<blackd...@gmx.org> Datum: 15.03.18  14:51  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Fund Groovy Development - Jira Task 
Just randomly using a post of this thread for the topic.

I just stumbled over https://www.bountysource.com/. Wouldn't that be an 
interesting platform for this kind of idea

Am 11.03.2018 um 19:43 schrieb mg:
> Sure :-)
> 
>  Ursprüngliche Nachricht 
> Von: "Daniel.Sun" <sun...@apache.org>
> Datum: 11.03.18 17:52 (GMT+01:00)
> An: us...@groovy.incubator.apache.org
> Betreff: Re: Fund Groovy Development - Jira Task
> 
> Well, my bad... I just wish more and more volunteers would involve in the
> development of Groovy :)
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html


Re: groovy regex match group

2018-03-14 Thread mg
ps: if(matcher) invokes Groovy truth (asBoolean()), which calls find() on the 
matcher
 Ursprüngliche Nachricht Von: Vladimir Frelikh 
 Datum: 14.03.18  12:17  (GMT+01:00) An: 
users@groovy.apache.org Betreff: groovy regex match group 
Hello,could someone help with the following code:
text = 'test'def matcher = text =~ /(test)/print matcher.group(1)
getting error:java.lang.IllegalStateException: No match found

but the following code works as expected:
text = 'test'def matcher = text =~ /(test)/if (matcher ) {    print 
matcher.group(1)}
Thanks!



Re: groovy regex match group

2018-03-14 Thread mg
you have to call matches() on the matcher...
 Ursprüngliche Nachricht Von: Vladimir Frelikh 
 Datum: 14.03.18  12:17  (GMT+01:00) An: 
users@groovy.apache.org Betreff: groovy regex match group 
Hello,could someone help with the following code:
text = 'test'def matcher = text =~ /(test)/print matcher.group(1)
getting error:java.lang.IllegalStateException: No match found

but the following code works as expected:
text = 'test'def matcher = text =~ /(test)/if (matcher ) {    print 
matcher.group(1)}
Thanks!



Re: Fund Groovy Development - Jira Task

2018-03-11 Thread mg
Sure :-)
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 11.03.18  17:52  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: Re: Fund Groovy Development - Jira Task 
Well, my bad... I just wish more and more volunteers would involve in the
development of Groovy :)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html


Re: Fund Groovy Development - Jira Task

2018-03-11 Thread mg
Sure :-)
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 11.03.18  17:52  (GMT+01:00) An: us...@groovy.incubator.apache.org 
Betreff: Re: Fund Groovy Development - Jira Task 
Well, my bad... I just wish more and more volunteers would involve in the
development of Groovy :)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html


Re: Fund Groovy Development - Jira Task

2018-03-11 Thread MG

Hi Daniel,

if you write stuff like that, I feel you are effectively discouraging 
people to praticipate in this test balloon.
We can switch to whatever fits best later on, but right now we should 
see what people's reaction to this is - which might very well also be: 
"I would prefer to fund through xyz".
If people do not want to fund Groovy development (at least the generic 
"fund Java 9 compatibility" bounty/target should appeal to anyone 
interested in the advancement of Groovy), then it does not matter what 
funding platform you offer.


Funding by multiple people would already possible through the Jira 
approach (just pledge in the comment section).


Splitting money between multiple contributors is a problem that we can 
hopefully solve once there is some money to split.


Cheers,
mg


On 11.03.2018 17:28, Daniel.Sun wrote:

BTW, each issue or feature can be sponsored by multiple people and can be
fixed by multiple volunteers. Compared with JIRA to record sponsorship
details, I prefer to use PR of Github. The groovy sponsorship project
repository can be setup at groovy/sponsorship of Github, which we should ask
Groovy project lead for approving.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Re: Fund Groovy Development - Jira Task

2018-03-11 Thread MG

Hi Daniel,

thank you. I have thought (and discussed with my wife) at length about 
getting seriously involved in the devlopment of the Groovy language, but 
due to a multitude of reasons I cannot make that commitment at this 
point in time.
So I was thinking maybe more people feel the same way, and would instead 
like to give money to further "The language that is Groovy" ( (C) ;-) ).


We'll have to see how this goes, I have just posted the funding message 
to the Groovy Slack 
(https://groovy-community.slack.com/messages/C2NEFCM55/).


I guess 1000+ Groovers pledging e.g 5 to 10 EUR/$ per month would also 
go a long way to helping Groovy grow, but here I feel at least the 
Paypal address o.s. where the money shall flow should come from the 
"Lifetime Achievement Groovy Award" holders who are most active on the 
mailing list etc (Paul, Jochen, etc), and the funding Paypal link should 
go on the main Groovy web page. The important thing here would be to get 
people to commit to regular funding...


Cheers,
mg


On 11.03.2018 14:58, Daniel.Sun wrote:

Hi  MG,

  After Pivotal stopped sponsoring Groovy, Groovy evolves much slower
than before. As we can see, Groovy project lead Guillaume, tech lead Jochen,
Cédric have much less time to contribute to Groovy. Luckily, Paul still has
been contributing so much :-)

 In order to improve the situation, I discussed similar topic with Paul
some months ago. I wish we could find some sponsorship for volunteers to fix
some issues or achieve some new features, which I think can help Groovy
evolves faster and adopted wider.

 Thank you for making the similar idea on the way ;-)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html





Re: traits fields initialization order ?

2018-03-10 Thread MG

Hi Paul,

thank you for the feedback (I searched the Groovy Jira, but was using 
"field assignment" as the search term, so missed this issue).
Weird bug, just taking away all the final qualifiers actually works, no 
@Lazy required - I didn't even test that far, since that is such a 
general problem, that I would have thought people would already have 
complained about this in troves...


Cheers,
mg


On 10.03.2018 22:10, Paul King wrote:

There is a known bug in trait initialization for final fields:

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

It's on my list to fix before 2.5.0 final. Happy for any assistance.

Cheers, Paul.


On Sun, Mar 11, 2018 at 6:37 AM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


Hi,

I recently refactored the reflection code of my framework to
support using traits to share fields. The shared fields are
initialized during field declaration (i.e. not in a ctor) for user
convenience (they represent columns in a table). In this
particular case, fields needed to be passed as parameters to to
other field's ctors. In this case the problem is, that the fields
passed to other fields ctors seem to alwys be null. The same code
constructs have been working for years when using them directly
inside a class.

Questions:

 1.  What is the expected behavior in this case ? Should this work
in traits ?
 2. If this is not a bug in Groovy: What is the best workaround ?
I only had very little time to work on this last week, so I
used a @Memoized helper method whose return value is used in
both the field initializations - works, but a pretty terrible
solution and user experience.
I just did a quick spike at home using @Lazy on one field:
This seems to work, but not, if combined with final - so the
field could be reassigned (which I don't want) unless the
framework user introduces a shared @Lazy "hidden" private
helper field (similar to my @Memoized method).
 3. In general: What is the exact order that fields get
initialized in Groovy - and is this behavior expected to
change in the future ?

Cheers,
mg








traits fields initialization order ?

2018-03-10 Thread MG

Hi,

I recently refactored the reflection code of my framework to support 
using traits to share fields. The shared fields are initialized during 
field declaration (i.e. not in a ctor) for user convenience (they 
represent columns in a table). In this particular case, fields needed to 
be passed as parameters to to other field's ctors. In this case the 
problem is, that the fields passed to other fields ctors seem to alwys 
be null. The same code constructs have been working for years when using 
them directly inside a class.


Questions:

1.   What is the expected behavior in this case ? Should this work in
   traits ?
2. If this is not a bug in Groovy: What is the best workaround ? I only
   had very little time to work on this last week, so I used a
   @Memoized helper method whose return value is used in both the field
   initializations - works, but a pretty terrible solution and user
   experience.
   I just did a quick spike at home using @Lazy on one field: This
   seems to work, but not, if combined with final - so the field could
   be reassigned (which I don't want) unless the framework user
   introduces a shared @Lazy "hidden" private helper field (similar to
   my @Memoized method).
3. In general: What is the exact order that fields get initialized in
   Groovy - and is this behavior expected to change in the future ?

Cheers,
mg





Fund Groovy Development - Jira Task

2018-03-10 Thread MG

Hi Groovy enthusiasts !-)

after having thought about the topic of "putting some money where your 
mouth is and help fund Groovy development" some more, and taking into 
consideration what people have suggested, I have created a (somewhat 
experimental) Jira task* where people can pledge bounties for Groovy 
features/fixes they woud like to support:


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

I have added bounties for some ares that I would like to see Groovy to 
grow in - feel free to suggest additional features/fixes, or pledge for 
existing ones.


Please make sure beforehand there has been at least some sort of 
discussion about and some tentative agreement on possible ways forward 
for the topic you would like to advance on this mailing list. There is 
not much sense in cluttering the Jira task with pledges for features no 
one of the main contributors think are feasible, a good idea - or who 
have been outright rejected at this point :-)


I think it is easiest for people to pledge in "their" currency (Euro in 
my case), so they do not incur any exchange rate uncertainties.
I also feel the minimum amount pledged should be in the 10 USD/EUR area, 
based on that if we have a lot of people pledging smaller amounts, the 
Jira task is definitely not the right approach.

All of this is of course open for discussion... :-)

Regular (monthly) Groovy funding is a topic for another post - for now I 
have added a generic "Make Groovy Java 9 compatible" topic at the top of 
the funding table in https://issues.apache.org/jira/browse/GROOVY-8503.


Cheers,
mg

*I think we should see if this appoach does not suffice, before going 
down the route of a 
Kickstarter/Indiegogo/tribe.taiga.io/bountysource.com/Patroon/fundrequest.io 
- thank you to anyone who suggested/commented on this topic :-)












Re: Alternative JVM with Groovy (Azul,...) ?

2018-03-09 Thread MG

On 08.03.2018 15:05, Eric Helgeson wrote:
PS: Maybe worth reaching out to Azul and asking what tests they did to 
mention Scala - and to add Groovy there too :D


I don't know why Groovy is so often flying under the radar - maybe to do 
with the fact that it is still not seen as a "full blown language" - 
beats me all the time...


Speaking of Scala, I just saw this when looking up Scala val/var usage 
mentioned in http://openjdk.java.net/jeps/286 on how to define a Java 
bean compatible Scala class 
(https://javabeat.net/fields-which-satisfy-javabean-specification-beanproperites-in-scala/):


class Book {
  @BeanProperty var title:String
  @BeanProperty val isbn:String = "ISBN10"
}

i.e. what in Groovy is:

class Book {
  String title
  final String isbn = "ISBN10"
}

If that really is the correct Scala syntax for that use case, it is just 
completely smothering meaningful information under a heap of 
"boilerplate syntax" (I guess the "String" in the second line of the 
example could be dropped, but that does not help much).
That is on top of choosing "var" and "val" as utterly-non-distinct 
keywords... :-)


Not saying Groovy cannot learn something from Scala in some areas, but 
syntax is definitely not one of them (Note: I could have choosen Scala a 
few years back instead of Groovy, but the syntax drove me away - and I 
did not even get as far as @BeanProperty...)

m;-)groovy





Re: Alternative JVM with Groovy (Azul,...) ?

2018-03-09 Thread MG

Thank you to all that gave feedback :-)

Russel, could you elaborate a bit on the incompatibilities you mention ?


On 08.03.2018 15:45, Russel Winder wrote:

On Thu, 2018-03-08 at 13:09 +0100, mg wrote:

Hi,
I would be interested to hear if anyone has experience with using
alternative JVMs with Groovy, especially Azul (https://www.azul.com/)
?
Licensing costs for long term OpenJDK support seem to be much lower,
and the JVM has additional benefits such as an elastic memory model
(JVM memory is dynamically allocated/deallocated from the os),
continuous concurrent garbage collection without freeze-the-world
fallback, and application startup (warmup) time improvements.But I am
worried about Groovy compatibility (they only mention Scala
explicitly on the web page)...
Cheers,mg

On Debian Sid I use Azul JDKs (Zulu 8 and Zulu 9) because they provide
a deb repository and it is easy. On Fedora Rawhide I use the Fedora
provided OpenJDK, Azul do not provide a Fedora rawhide rpm repository,
but they do provide a RHEL/CentOS one. Why not the Debian provided
OpenJDK and ignore Azul? It comes down to being told Debian Sid OpenJDK
was unreliable and that I should trust Azul.

I have discovered some incompatibilities of Groovy 2.4.14 running on
Zulu 8 compared to Zulu 9. I have yet to try on Fedora OpenJDK to see
if it is an Azul problem or a Groovy problem.

I am not about to use OracleJDK ever again.

Obviously though I am always using the free versions, I do not pay a
licence fee.






Alternative JVM with Groovy (Azul,...) ?

2018-03-08 Thread mg
Hi,
I would be interested to hear if anyone has experience with using alternative 
JVMs with Groovy, especially Azul (https://www.azul.com/) ?
Licensing costs for long term OpenJDK support seem to be much lower, and the 
JVM has additional benefits such as an elastic memory model (JVM memory is 
dynamically allocated/deallocated from the os), continuous concurrent garbage 
collection without freeze-the-world fallback, and application startup (warmup) 
time improvements.But I am worried about Groovy compatibility (they only 
mention Scala explicitly on the web page)...
Cheers,mg



@NamingConvention: Supply class/method/field/... name patterns to compiler

2018-03-04 Thread MG

Hi,

an @NamingConvention could supply information about 
class/method/field/variable/parameter names to the Groovy compiler, 
which would allow to reduce the required number of class lookups and 
could potentially be combined with the classNamePattern @Newify extension:

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

Cheers,
mg





Extend @Newify to support a class name pattern parameter

2018-03-04 Thread MG

Hi,

I have created an issue for an extension to @Newify, that would allow to 
support the concise (and imho very Groovy) Python/Kotlin/... ctor 
calling support (i.e. without requiring a new keyword), in 99.9% of all 
cases without breaking backwards compatibility:


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

Please comment,
Cheers,
mg




Re: Groovy Champions proposal feedback

2018-02-24 Thread MG
I agree. The point I was trying to make is however, that the "I can 
honestly say if someone had shown me the Programming in Scala book..." 
quote is the one I find on Google, and I found it quoted by people in 
typical "Java vs Groovy vs ..." threads.
Having the creator of a language say that another language is better, 
looks like the ultimate knockout in such threads, and if no one is ther 
to counter (the way you just did), you might just have lost a potential 
new Groovy user.
The myth about Groovy being "slow" I wrote about in the past is also 
still on the net. The lesson is: Bad messages spread easily and die 
hard, most people do not take the time to check if e.g. the creator of 
Groovy has later changed his opinion on Scala, or if Groovy is actually 
still slow.
(The message, that the Groovy project has honored one of the people 
behind Kotlin would evidently imho be such a message. )


Cheers,
mg

On 16.02.2018 01:24, Jochen Theodorou wrote:

On 14.02.2018 22:38, MG wrote:
[...]
Would you suggest we also honor Groovy inventor James Strachan, who 
wrote in 2009 in his Blog "I can honestly say if someone had shown me 
the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill 
Venners back in 2003 I'd probably have never created Groovy.":
http://macstrac.blogspot.co.at/2009/04/scala-as-long-term-replacement-for.html 

https://www.quora.com/Is-Groovy-going-away-When-the-author-of-Groovy-says-he-would-have-never-created-Groovy-if-he-knew-about-Scala-then-it-makes-me-wonder-if-there-is-a-future-at-all 


?


I counter with https://twitter.com/jstrachan/status/784333918078169088:

I still love groovy (jenkins pipelines are so groovy!), java, go, 
typescript and kotlin. I don’t use scala any more


I think that proofs, that this discussion with Scala is just not worth 
it really.






Re: @Groovy Champions: Groovy Development Funding ?

2018-02-21 Thread MG

Hi Mario,

thank you for the input. If I interpret the information on the webpage 
correctly, the system works for one-on-one funding of tasks between e.g. 
a developer and a stakeholder for specific tasks of a project. I don't 
know if this would work in the case of Groovy, because here we would 
probably have a larger number of  people giving smaller amounts to fund 
a development goal together...


Cheers,
mg


On 21.02.2018 15:50, Mario Garcia wrote:

Ithought this could be worth sharing.

The company I work for developed some time ago, Tribe 
(https://tribe.taiga.io/)


Tribe is a task-based employment marketplace for product development. 
It was created with software development in mind. The tasks can be 
managed through the open sourced Taiga management platform 
(https://taiga.io/). So tasks could be managed in the context of a 
project.


More details about Tribe (how it works, payments...) :

https://tribe.taiga.io/help/how-it-works

I hope this helps
Mario

2018-02-18 17:17 GMT+01:00 MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>>:


Hi Eric,

thank you for the suggestion. Do you know how much money they take
for their service and if they accept Paypal (I just thought about
this, and not accepting Paypal is imho close to a knockout, to
keep the entry barrier as low as possible; that would exclude
Kickstarter according to their FAQ, but here one could probably
assume that many potential Groovy backers would already have an
account...).

Do they support specific funding foals also (which typically
attract more funding), or is a subscription only model ?

Cheers,
mg



On 18.02.2018 14:15, Eric Kinsella wrote:

I know of some indie game developers and podcasters that are
using Patreon. A possible alternative to something like
KickStarter/Indiegogo with more of a subscription model which
could even be $1/month.

https://www.patreon.com

What is Patreon? - video
https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg
<https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg>

Cheers,
Eric Kinsella


On Fri, Feb 16, 2018 at 12:37 PM, MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:

That should be no problem, I would be happy to do a Groovy
"thank you" mug o.s.  :-)


On 16.02.2018 17:11, Mario Garcia wrote:

+1 but also keep in mind that sometimes could be also
something as simple as a "grateful box pack" with a T-shirt,
sticker or a mug. I would love that too.

Mario

El 16 feb. 2018 11:49 a. m., "Jochen Theodorou"
<blackd...@gmx.org <mailto:blackd...@gmx.org>> escribió:



Am 16.02.2018 um 03:27 schrieb Paul King:

Actually, Apache also accept donations but I think
the standard policy is that it isn't then directed
back to a specific project.


I actually am of the impression that this is the only
policy... might be wrong here.

I think in general we would be in favor of doing
this so long as it was done well - and most of us
wonder whether we have the time to market/advertise
it well. I also suspect that having a well-defined
goal (like what JUnit 5 did to some degree) greatly
helps to attract some one-off investment interest.


+1

bye Jochen











Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-20 Thread mg
Groovy Bright Giants(a subclass of Red Giants ;-) )
 Ursprüngliche Nachricht Von: mg <mg...@arscreat.com> Datum: 
20.02.18  20:29  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: Groovy 
Champions proposal feedback - Groovy MVPs ? 
Groovy (Red) Giants
 Ursprüngliche Nachricht Von: Rahul Somasunderam 
<rsomasunde...@transcendinsights.com> Datum: 20.02.18  18:43  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy Champions proposal feedback - 
Groovy MVPs ? 

Person with Groove ?




On Feb 20, 2018, at 7:30 AM, Kyle Boon <kyle.f.b...@gmail.com> wrote:



Groovy Person of Interest?
Groovy Notable Human?
Contributor of Significance? 



On Tue, Feb 20, 2018 at 4:14 AM, Søren Berg Glasius 
<soe...@glasius.dk> 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




On Tue, 20 Feb 2018 at 11:07 Guillaume Laforge <glafo...@gmail.com> wrote:



Or even GrooVIP :-D


On Tue, Feb 20, 2018 at 9:20 AM, Cédric Champeau 
<cedric.champ...@gmail.com> wrote:


I agree with Guillaume: MVP sounds "Minimal Viable Product" in my head :) 
Anoter option: VIP ;)






2018-02-20 8:32 GMT+01:00 Jennifer Strater
<jenn.stra...@gmail.com>:


Although there seems to be a lot of disagreement about the name, everyone seems 
to be in favor of the idea. What is the next step, Paul?





On 20. Feb 2018, at 07:56, Peter McNeil <pe...@mcneils.net> wrote:






You're all missing the obvious "Groovy GR8" :-)





On 20/02/18 11:35, Paul King wrote:



Supreme Thanks Award Recognising contributions? :-)


On Tue, Feb 20, 2018 at 7:08 AM, Kostas Saidis 
<sai...@gmail.com> wrote:




My own few cents, too:



Groovy Star, Groovy Champion, Groovy MVP all have their pros and cons. I would 
suggest something along the lines of Groovy Exceptional Community Member 
(Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM). New 
acronym, professional enough, focusing
 on the overall community and not only the language per se.



Kostas






On 19/2/2018 10:26 μμ, MG wrote:






I have never heard "MVP" =  "Minimum Viable Product", so I doubt this would 
pose a problem. Also do you suggest that people would actually read "Groovy has 
announced its Minimum Viable Products of 2018" ?

STAR has 129 meanings as an acronym, btw, according to 
https://acronyms.thefreedictionary.com/STAR




On 19.02.2018 20:39, Guillaume Laforge wrote:



For me, MVP sounds too much like Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product





On Mon, Feb 19, 2018 at 8:32 PM, MG 
<mg...@arscreat.com> wrote:


Following the sports analogy, what about




"Groovy MVPs" 



?



Any game can have Most Valuable Players (even if only one is typically crowned 
in the US), and I think "Groovy announced its 2018 MVPs" has a nice ring to it.



Cheers,

mg








On 19.02.2018 12:03, Søren Berg Glasius wrote:



I disagree with MG.



A star is an object that shines, and in this case shines light on the Groovy 
language and ecosystem. Hence I think the name is both professional, and since 
it can be directly linked to the star in the Groovy logo I think it makes 
perfect sense.
 In sports you also have star players and in music (and Java) you have rock 
stars. That you can find examples that relates to games on Nintendo does not 
make a valid point IMO. The "All Stars" just makes it so much better - as 
that's what Paul, Jochen and others
 are .



My few cents worth.



/Søren



On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com> wrote:








On 18.02.2018 13:38, Eric Kinsella wrote:



+1up on Groovy Stars. 





"Get a life" ;-)



But seriously, all the people one-upping "Groovy Stars" - consider whether that 
name really sends the right professional message with regards to Groovy ? I am 
convinced it does not.


Managers who might decide whether Groovy can be used in a project are typically 
conservative and sensitive to those things, and they do not normally follow 
nerd humor... (next suggestion I see coming along the Stars-crossed-line, is to 
call Paul and Jochen
 "Groovy All Stars")



As another example, it looks like "Pokemon Stars" on the Nintendo Switch might 
become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game














On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun 
<realblue...@hotmail.com> wrote:


Hi Paul,



     “Groovy Champions” make people associate it with "Java Champions"

easily. As for "Groovy Stars", it is interesting but let me associate "Song

Stars" and "Kungfu Stars" easily... I wish other people would not associate

as I do...



      Similarly, many

Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-20 Thread mg
Groovy (Red) Giants
 Ursprüngliche Nachricht Von: Rahul Somasunderam 
<rsomasunde...@transcendinsights.com> Datum: 20.02.18  18:43  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy Champions proposal feedback - 
Groovy MVPs ? 

Person with Groove ?




On Feb 20, 2018, at 7:30 AM, Kyle Boon <kyle.f.b...@gmail.com> wrote:



Groovy Person of Interest?
Groovy Notable Human?
Contributor of Significance? 



On Tue, Feb 20, 2018 at 4:14 AM, Søren Berg Glasius 
<soe...@glasius.dk> 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




On Tue, 20 Feb 2018 at 11:07 Guillaume Laforge <glafo...@gmail.com> wrote:



Or even GrooVIP :-D


On Tue, Feb 20, 2018 at 9:20 AM, Cédric Champeau 
<cedric.champ...@gmail.com> wrote:


I agree with Guillaume: MVP sounds "Minimal Viable Product" in my head :) 
Anoter option: VIP ;)






2018-02-20 8:32 GMT+01:00 Jennifer Strater
<jenn.stra...@gmail.com>:


Although there seems to be a lot of disagreement about the name, everyone seems 
to be in favor of the idea. What is the next step, Paul?





On 20. Feb 2018, at 07:56, Peter McNeil <pe...@mcneils.net> wrote:






You're all missing the obvious "Groovy GR8" :-)





On 20/02/18 11:35, Paul King wrote:



Supreme Thanks Award Recognising contributions? :-)


On Tue, Feb 20, 2018 at 7:08 AM, Kostas Saidis 
<sai...@gmail.com> wrote:




My own few cents, too:



Groovy Star, Groovy Champion, Groovy MVP all have their pros and cons. I would 
suggest something along the lines of Groovy Exceptional Community Member 
(Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM). New 
acronym, professional enough, focusing
 on the overall community and not only the language per se.



Kostas






On 19/2/2018 10:26 μμ, MG wrote:






I have never heard "MVP" =  "Minimum Viable Product", so I doubt this would 
pose a problem. Also do you suggest that people would actually read "Groovy has 
announced its Minimum Viable Products of 2018" ?

STAR has 129 meanings as an acronym, btw, according to 
https://acronyms.thefreedictionary.com/STAR




On 19.02.2018 20:39, Guillaume Laforge wrote:



For me, MVP sounds too much like Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product





On Mon, Feb 19, 2018 at 8:32 PM, MG 
<mg...@arscreat.com> wrote:


Following the sports analogy, what about




"Groovy MVPs" 



?



Any game can have Most Valuable Players (even if only one is typically crowned 
in the US), and I think "Groovy announced its 2018 MVPs" has a nice ring to it.



Cheers,

mg








On 19.02.2018 12:03, Søren Berg Glasius wrote:



I disagree with MG.



A star is an object that shines, and in this case shines light on the Groovy 
language and ecosystem. Hence I think the name is both professional, and since 
it can be directly linked to the star in the Groovy logo I think it makes 
perfect sense.
 In sports you also have star players and in music (and Java) you have rock 
stars. That you can find examples that relates to games on Nintendo does not 
make a valid point IMO. The "All Stars" just makes it so much better - as 
that's what Paul, Jochen and others
 are .



My few cents worth.



/Søren



On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com> wrote:








On 18.02.2018 13:38, Eric Kinsella wrote:



+1up on Groovy Stars. 





"Get a life" ;-)



But seriously, all the people one-upping "Groovy Stars" - consider whether that 
name really sends the right professional message with regards to Groovy ? I am 
convinced it does not.


Managers who might decide whether Groovy can be used in a project are typically 
conservative and sensitive to those things, and they do not normally follow 
nerd humor... (next suggestion I see coming along the Stars-crossed-line, is to 
call Paul and Jochen
 "Groovy All Stars")



As another example, it looks like "Pokemon Stars" on the Nintendo Switch might 
become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game














On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun 
<realblue...@hotmail.com> wrote:


Hi Paul,



     “Groovy Champions” make people associate it with "Java Champions"

easily. As for "Groovy Stars", it is interesting but let me associate "Song

Stars" and "Kungfu Stars" easily... I wish other people would not associate

as I do...



      Similarly, many years ago some one suggested to name current "Grape"

as "Groovy Baby", the latter is interesting but not formal...



      To sum up, +1 to “Groovy Champions”.



Cheers,

Daniel.Sun







--

Sent from: 
http://groovy.329449.n5.na

Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-20 Thread mg
Syvoorg / SyvoorgsGroosGrooviansGroovers

 Ursprüngliche Nachricht Von: Rahul Somasunderam 
<rsomasunde...@transcendinsights.com> Datum: 20.02.18  18:43  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy Champions proposal feedback - 
Groovy MVPs ? 

Person with Groove ?




On Feb 20, 2018, at 7:30 AM, Kyle Boon <kyle.f.b...@gmail.com> wrote:



Groovy Person of Interest?
Groovy Notable Human?
Contributor of Significance? 



On Tue, Feb 20, 2018 at 4:14 AM, Søren Berg Glasius 
<soe...@glasius.dk> 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




On Tue, 20 Feb 2018 at 11:07 Guillaume Laforge <glafo...@gmail.com> wrote:



Or even GrooVIP :-D


On Tue, Feb 20, 2018 at 9:20 AM, Cédric Champeau 
<cedric.champ...@gmail.com> wrote:


I agree with Guillaume: MVP sounds "Minimal Viable Product" in my head :) 
Anoter option: VIP ;)






2018-02-20 8:32 GMT+01:00 Jennifer Strater
<jenn.stra...@gmail.com>:


Although there seems to be a lot of disagreement about the name, everyone seems 
to be in favor of the idea. What is the next step, Paul?





On 20. Feb 2018, at 07:56, Peter McNeil <pe...@mcneils.net> wrote:






You're all missing the obvious "Groovy GR8" :-)





On 20/02/18 11:35, Paul King wrote:



Supreme Thanks Award Recognising contributions? :-)


On Tue, Feb 20, 2018 at 7:08 AM, Kostas Saidis 
<sai...@gmail.com> wrote:




My own few cents, too:



Groovy Star, Groovy Champion, Groovy MVP all have their pros and cons. I would 
suggest something along the lines of Groovy Exceptional Community Member 
(Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM). New 
acronym, professional enough, focusing
 on the overall community and not only the language per se.



Kostas






On 19/2/2018 10:26 μμ, MG wrote:






I have never heard "MVP" =  "Minimum Viable Product", so I doubt this would 
pose a problem. Also do you suggest that people would actually read "Groovy has 
announced its Minimum Viable Products of 2018" ?

STAR has 129 meanings as an acronym, btw, according to 
https://acronyms.thefreedictionary.com/STAR




On 19.02.2018 20:39, Guillaume Laforge wrote:



For me, MVP sounds too much like Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product





On Mon, Feb 19, 2018 at 8:32 PM, MG 
<mg...@arscreat.com> wrote:


Following the sports analogy, what about




"Groovy MVPs" 



?



Any game can have Most Valuable Players (even if only one is typically crowned 
in the US), and I think "Groovy announced its 2018 MVPs" has a nice ring to it.



Cheers,

mg








On 19.02.2018 12:03, Søren Berg Glasius wrote:



I disagree with MG.



A star is an object that shines, and in this case shines light on the Groovy 
language and ecosystem. Hence I think the name is both professional, and since 
it can be directly linked to the star in the Groovy logo I think it makes 
perfect sense.
 In sports you also have star players and in music (and Java) you have rock 
stars. That you can find examples that relates to games on Nintendo does not 
make a valid point IMO. The "All Stars" just makes it so much better - as 
that's what Paul, Jochen and others
 are .



My few cents worth.



/Søren



On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com> wrote:








On 18.02.2018 13:38, Eric Kinsella wrote:



+1up on Groovy Stars. 





"Get a life" ;-)



But seriously, all the people one-upping "Groovy Stars" - consider whether that 
name really sends the right professional message with regards to Groovy ? I am 
convinced it does not.


Managers who might decide whether Groovy can be used in a project are typically 
conservative and sensitive to those things, and they do not normally follow 
nerd humor... (next suggestion I see coming along the Stars-crossed-line, is to 
call Paul and Jochen
 "Groovy All Stars")



As another example, it looks like "Pokemon Stars" on the Nintendo Switch might 
become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game














On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun 
<realblue...@hotmail.com> wrote:


Hi Paul,



     “Groovy Champions” make people associate it with "Java Champions"

easily. As for "Groovy Stars", it is interesting but let me associate "Song

Stars" and "Kungfu Stars" easily... I wish other people would not associate

as I do...



      Similarly, many years ago some one suggested to name current "Grape"

as "Groovy Baby", the latter is interesting but not formal...



      To sum up, +1 to “Groovy Champions”.



Cheers,

Daniel.Sun







--

Sent from: 
http:/

Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-20 Thread mg
GrooVIP I like, it's in the tradition of GString... :-)
"The Apache Groovy project announced its 2018 GrooVIPs" works for me.
mg



 Ursprüngliche Nachricht Von: Guillaume Laforge 
<glafo...@gmail.com> Datum: 20.02.18  11:07  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Groovy Champions proposal feedback - 
Groovy MVPs ? 
Or even GrooVIP :-D
On Tue, Feb 20, 2018 at 9:20 AM, Cédric Champeau <cedric.champ...@gmail.com> 
wrote:
I agree with Guillaume: MVP sounds "Minimal Viable Product" in my head :) 
Anoter option: VIP ;)

2018-02-20 8:32 GMT+01:00 Jennifer Strater <jenn.stra...@gmail.com>:
Although there seems to be a lot of disagreement about the name, everyone seems 
to be in favor of the idea. What is the next step, Paul?

On 20. Feb 2018, at 07:56, Peter McNeil <pe...@mcneils.net> wrote:


  

  
  
You're all missing the obvious "Groovy GR8" :-)




On 20/02/18 11:35, Paul King wrote:



  Supreme Thanks Award Recognising contributions? :-)
  

On Tue, Feb 20, 2018 at 7:08 AM, Kostas
  Saidis <sai...@gmail.com>
  wrote:

  

  My own
few cents, too:



Groovy Star, Groovy Champion, Groovy MVP all have their
pros and cons. I would suggest something along the lines
of Groovy Exceptional Community Member (Groovy ECM) or
Groovy Distinguished Community Member (Groovy DCM). New
acronym, professional enough, focusing on the overall
community and not only the language per se.



Kostas

  

    

On 19/2/2018 10:26 μμ, MG wrote:

  

  
  

   I have never heard "MVP" = 
"Minimum Viable Product", so I doubt this would pose
a problem. Also do you suggest that people would
actually read "Groovy has announced its Minimum
Viable Products of 2018" ?

STAR has 129 meanings as an acronym, btw, according
to https://acronyms.thefreedictionary.com/STAR



On
  19.02.2018 20:39, Guillaume Laforge wrote:



  For me, MVP sounds too much like
Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product


  
      

On Mon, Feb 19, 2018 at
  8:32 PM, MG <mg...@arscreat.com>
  wrote:

  

  Following the sports analogy, what about 

  

  "Groovy MVPs" 

  

  ?

  

  Any game can have Most Valuable Players
  (even if only one is typically crowned in
  the US), and I think "Groovy announced its
  2018 MVPs" has a nice ring to it.

  

  Cheers,

  mg

  

  

  

  On
19.02.2018 12:03, Søren Berg Glasius
wrote:

  
  
I disagree with MG.
  

  
  A star is an object that shines,
and in this case shines light on the
Groovy language and ecosystem. Hence
I think the name is both
professional, and since it can be
directly linked to the star in the
Groovy logo I think it makes perfect
sense. In sports you also have star
players and in music (and Java) you
have rock stars. That you can find
examples that relates to games on
Nintendo does not make a valid point
  

Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-19 Thread MG
I have never heard "MVP" =  "Minimum Viable Product", so I doubt this 
would pose a problem. Also do you suggest that people would actually 
read "Groovy has announced its Minimum Viable Products of 2018" ?
STAR has 129 meanings as an acronym, btw, according to 
https://acronyms.thefreedictionary.com/STAR


On 19.02.2018 20:39, Guillaume Laforge wrote:

For me, MVP sounds too much like Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product

On Mon, Feb 19, 2018 at 8:32 PM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


Following the sports analogy, what about

"Groovy MVPs"

?

Any game can have Most Valuable Players (even if only one is
typically crowned in the US), and I think "Groovy announced its
2018 MVPs" has a nice ring to it.

Cheers,
mg



On 19.02.2018 12:03, Søren Berg Glasius wrote:

I disagree with MG.

A star is an object that shines, and in this case shines light on
the Groovy language and ecosystem. Hence I think the name is both
professional, and since it can be directly linked to the star in
the Groovy logo I think it makes perfect sense. In sports you
also have star players and in music (and Java) you have rock
stars. That you can find examples that relates to games on
Nintendo does not make a valid point IMO. The "All Stars" just
makes it so much better - as that's what Paul, Jochen and others
are .

    My few cents worth.

/Søren

On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:



On 18.02.2018 13:38, Eric Kinsella wrote:

+1up on Groovy Stars.


"Get a life" ;-)

But seriously, all the people one-upping "Groovy Stars" -
consider whether that name really sends the right
professional message with regards to Groovy ? I am convinced
it does not.
Managers who might decide whether Groovy can be used in a
project are typically conservative and sensitive to those
things, and they do not normally follow nerd humor... (next
suggestion I see coming along the Stars-crossed-line, is to
call Paul and Jochen "Groovy All Stars")

As another example, it looks like "Pokemon Stars" on the
Nintendo Switch might become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game

<http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game>





On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun
<realblue...@hotmail.com <mailto:realblue...@hotmail.com>>
wrote:

Hi Paul,

     “Groovy Champions” make people associate it with
"Java Champions"
easily. As for "Groovy Stars", it is interesting but let
me associate "Song
Stars" and "Kungfu Stars" easily... I wish other people
would not associate
as I do...

      Similarly, many years ago some one suggested to
name current "Grape"
as "Groovy Baby", the latter is interesting but not
formal...

      To sum up, +1 to “Groovy Champions”.

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
<http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>




-- 
Best regards / Med venlig hilsen,

Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88 <tel:+45%2040%2044%2091%2088>, Skype:
sbglasius
--- Press ESC once to quit - twice to save the changes.





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

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+ 
<https://plus.google.com/u/0/114130972232398734985/posts>




Re: Groovy Champions proposal feedback - Groovy MVPs ?

2018-02-19 Thread MG

Following the sports analogy, what about

"Groovy MVPs"

?

Any game can have Most Valuable Players (even if only one is typically 
crowned in the US), and I think "Groovy announced its 2018 MVPs" has a 
nice ring to it.


Cheers,
mg



On 19.02.2018 12:03, Søren Berg Glasius wrote:

I disagree with MG.

A star is an object that shines, and in this case shines light on the 
Groovy language and ecosystem. Hence I think the name is both 
professional, and since it can be directly linked to the star in the 
Groovy logo I think it makes perfect sense. In sports you also have 
star players and in music (and Java) you have rock stars. That you can 
find examples that relates to games on Nintendo does not make a valid 
point IMO. The "All Stars" just makes it so much better - as that's 
what Paul, Jochen and others are .


My few cents worth.

/Søren

On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:




On 18.02.2018 13:38, Eric Kinsella wrote:

+1up on Groovy Stars.


"Get a life" ;-)

But seriously, all the people one-upping "Groovy Stars" - consider
whether that name really sends the right professional message with
regards to Groovy ? I am convinced it does not.
Managers who might decide whether Groovy can be used in a project
are typically conservative and sensitive to those things, and they
do not normally follow nerd humor... (next suggestion I see coming
along the Stars-crossed-line, is to call Paul and Jochen "Groovy
All Stars")

As another example, it looks like "Pokemon Stars" on the Nintendo
Switch might become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game





On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun
<realblue...@hotmail.com <mailto:realblue...@hotmail.com>> wrote:

Hi Paul,

     “Groovy Champions” make people associate it with "Java
Champions"
easily. As for "Groovy Stars", it is interesting but let me
associate "Song
Stars" and "Kungfu Stars" easily... I wish other people would
not associate
as I do...

      Similarly, many years ago some one suggested to name
current "Grape"
as "Groovy Baby", the latter is interesting but not formal...

      To sum up, +1 to “Groovy Champions”.

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html




--
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.




Re: Groovy Champions proposal feedback

2018-02-19 Thread MG

Hi Søren,

I agree that they are all stars. One can have all stars without having 
"Groovy Stars" however ;-)


Regarding your arguments, I in turn disagree :-)

1. I think that the image of star as a celestial body is not the
   typical association with the word in this context, especially if
   used in plural (i.e. Groovy Stars).
2. As I have said before, the star in the Groovy logo can imho easily
   be missed (on the Apache Groovy start page it is even partially cut
   off), so the link here to me is weak.
3. Since many people in this industry have most probably played
   Nintendo games (at least) when they were younger, I uphold the
   validity of my argument regarding this association.
4. "Rock Stars" in the Java world are "Rock Star speakers at Java One",
   i.e. people who give presentations that, are supposed to "rock". The
   term "rock star" associates with a certain amount or coolness and
   rebellion - things that are typically absent from Java conferences,
   so it is clear why they would like to inject that by choosing the
   term ;-)
5. "Star players" in e.g. sports are exactly that: People who make a
   lot of money and are known and are revered by millions of people.
   Calling yourself a "star" if you are not even close to that level
   feels tacky to me.

Cheers,
mg



On 19.02.2018 12:03, Søren Berg Glasius wrote:

I disagree with MG.

A star is an object that shines, and in this case shines light on the 
Groovy language and ecosystem. Hence I think the name is both 
professional, and since it can be directly linked to the star in the 
Groovy logo I think it makes perfect sense. In sports you also have 
star players and in music (and Java) you have rock stars. That you can 
find examples that relates to games on Nintendo does not make a valid 
point IMO. The "All Stars" just makes it so much better - as that's 
what Paul, Jochen and others are .


My few cents worth.

/Søren

On Sun, 18 Feb 2018 at 17:02 MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:




On 18.02.2018 13:38, Eric Kinsella wrote:

+1up on Groovy Stars.


"Get a life" ;-)

But seriously, all the people one-upping "Groovy Stars" - consider
whether that name really sends the right professional message with
regards to Groovy ? I am convinced it does not.
Managers who might decide whether Groovy can be used in a project
are typically conservative and sensitive to those things, and they
do not normally follow nerd humor... (next suggestion I see coming
along the Stars-crossed-line, is to call Paul and Jochen "Groovy
All Stars")

As another example, it looks like "Pokemon Stars" on the Nintendo
Switch might become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game





On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun
<realblue...@hotmail.com <mailto:realblue...@hotmail.com>> wrote:

Hi Paul,

     “Groovy Champions” make people associate it with "Java
Champions"
easily. As for "Groovy Stars", it is interesting but let me
associate "Song
Stars" and "Kungfu Stars" easily... I wish other people would
not associate
as I do...

      Similarly, many years ago some one suggested to name
current "Grape"
as "Groovy Baby", the latter is interesting but not formal...

      To sum up, +1 to “Groovy Champions”.

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html




--
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.




Re: @Groovy Champions: Groovy Development Funding ?

2018-02-18 Thread MG

Hi Eric,

thank you for the suggestion. Do you know how much money they take for 
their service and if they accept Paypal (I just thought about this, and 
not accepting Paypal is imho close to a knockout, to keep the entry 
barrier as low as possible; that would exclude Kickstarter according to 
their FAQ, but here one could probably assume that many potential Groovy 
backers would already have an account...).


Do they support specific funding foals also (which typically attract 
more funding), or is a subscription only model ?


Cheers,
mg


On 18.02.2018 14:15, Eric Kinsella wrote:
I know of some indie game developers and podcasters that are using 
Patreon. A possible alternative to something like 
KickStarter/Indiegogo with more of a subscription model which could 
even be $1/month.


https://www.patreon.com

What is Patreon? - video
https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg

Cheers,
Eric Kinsella


On Fri, Feb 16, 2018 at 12:37 PM, MG <mg...@arscreat.com 
<mailto:mg...@arscreat.com>> wrote:


That should be no problem, I would be happy to do a Groovy "thank
you" mug o.s.  :-)


On 16.02.2018 17:11, Mario Garcia wrote:

+1 but also keep in mind that sometimes could be also something
as simple as a "grateful box pack" with a T-shirt, sticker or a
mug. I would love that too.

Mario

El 16 feb. 2018 11:49 a. m., "Jochen Theodorou"
<blackd...@gmx.org <mailto:blackd...@gmx.org>> escribió:



Am 16.02.2018 um 03:27 schrieb Paul King:

Actually, Apache also accept donations but I think the
standard policy is that it isn't then directed back to a
specific project.


I actually am of the impression that this is the only
policy... might be wrong here.

I think in general we would be in favor of doing this so
long as it was done well - and most of us wonder whether
we have the time to market/advertise it well. I also
suspect that having a well-defined goal (like what JUnit
5 did to some degree) greatly helps to attract some
one-off investment interest.


+1

bye Jochen








Re: Groovy Champions proposal feedback

2018-02-18 Thread MG



On 18.02.2018 13:38, Eric Kinsella wrote:

+1up on Groovy Stars.


"Get a life" ;-)

But seriously, all the people one-upping "Groovy Stars" - consider 
whether that name really sends the right professional message with 
regards to Groovy ? I am convinced it does not.
Managers who might decide whether Groovy can be used in a project are 
typically conservative and sensitive to those things, and they do not 
normally follow nerd humor... (next suggestion I see coming along the 
Stars-crossed-line, is to call Paul and Jochen "Groovy All Stars")


As another example, it looks like "Pokemon Stars" on the Nintendo Switch 
might become a reality:

http://www.techradar.com/news/pokemon-stars-all-the-latest-leaks-from-the-rumored-nintendo-switch-game




On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun > wrote:


Hi Paul,

     “Groovy Champions” make people associate it with "Java Champions"
easily. As for "Groovy Stars", it is interesting but let me
associate "Song
Stars" and "Kungfu Stars" easily... I wish other people would not
associate
as I do...

      Similarly, many years ago some one suggested to name current
"Grape"
as "Groovy Baby", the latter is interesting but not formal...

      To sum up, +1 to “Groovy Champions”.

Cheers,
Daniel.Sun



--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html







Re: Groovy Champions proposal feedback

2018-02-16 Thread MG
I do not remember anyone ever listing some negative side effects - very 
interested to learn about this, since up to now it was only ever "Groovy 
already has support for that through @Newify" (which I evidently do not 
agree with :-) ).


Apart from that: Much of the Groovy goodness comes from its syntax, 
which also consists of allowing to leave unecessary things away. 
Otherwise it could still require a semicolon at the end of each line, or 
require brackets around arguments, or to supply last-parameter-closure 
arguments to be given inside method argument brackets, or not allow 
closures without an explicit empty parameter list, or not support "it" 
as single closure argument name, etc etc.


So right now I do not understand that argument at all, but maybe the 
negative side effects you mentioned will make this clear :-)


(The "new" operator in Java (and consecutively Groovy) is an artifact 
coming from C++, where stack based alloaction uses the ctor call alone, 
and the new keyword before the ctor call result in heap allocation - 
which is of course the only allocation variety supported in Java/Groovy, 
so no need to discern between the two cases exist...)


Cheers,
mg


On 16.02.2018 01:55, Jochen Theodorou wrote:

On 15.02.2018 06:04, MG wrote:
One other thing from the no-brainers section that Kotlin does better 
than Groovy: Ctors can be called without the new keyword.
(Groovy's offer in this regard is alas severly lacking, hence nobody 
uses it...)


I know this from Scala, how is the usage of this in Kotlin? Just to 
not to have to write "new" is not enough of an advantage for me to 
implement this and get all the negative side effects. There must be 
more to the usage than just that. And I assume there is in Kotlin, 
which I do not know about


bye Jochen






Re: Groovy Champions proposal feedback

2018-02-16 Thread MG



On 16.02.2018 01:52, Jochen Theodorou wrote:
for the named parameters support the map solution does only not 
suffice for the static compiler in the end... A pragmatic solution 
would be to say foo(x:1) can call foo(int) if the parameter is named x 
and that this call is taken even if there is a foo(Map) variant, plus 
that dynamic Groovy will always call the map variant. And then 
somebody has to implement this based on the java8 parameter 
information (which means java8 will be required for this feature of 
course). All doable, given time


While I like the flexibility of being dynamic in Groovy, the static, 
type safe case is imho important ( see also my recent groovypp comment), 
and I think there is currently also a rediscovery of the fact, that the 
larger a software project, the more static typing becomes valuable (see 
e.g also TypeScript vs JavaScript).


Just being able to use named parameters for Groovy classes would already 
be a 95% solution, since for me the most important application would be 
to be able to easily extend ctors which already have a lot of arguments.


The existing map based solution does not help with that, in addition to 
Intellisense not being able to lend any support...


For me that would probably be the #1 feature I would fund :-)
Cheers,
mg




  1   2   >