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

2018-12-18 Thread Keith Suderman
Option 4) Use the Maven Assembly plugin or the Shade plugin to build your own 
groovy-all Jar file.  Or just use https://github.com/gradle/gradle-groovy-all 


- Keith


> On Dec 17, 2018, at 3:49 AM, Paul Moore  > wrote:
> 
> I use Groovy as a scripting language for small tasks, running on
> application servers that do not have very good scripting tools
> available, and to which I only have limited access. Prior to Groovy
> 2.5, I've used the groovy-all jar as a low-impact, easy to deploy
> scripting option. I run scripts as
> 
>java -cp .../groovy-all-2.4.x.jar;. groovy.ui.Main myscript.groovy
> 
> The advantages of this approach are:
> 
> 1. One-off deployment of a single binary file to the server, with all
> subsequent script deployments being text files (the actual scripts).
> 2. Works with whatever Java is present on the server.
> 3. Doesn't need to rely on any particular directory structure on the server.
> 4. Doesn't need source code to be held elsewhere (it's a
> run-from-source solution rather than a compiled binary).
> 
> Since Groovy 2.5, the -all jar has been discontinued - the release
> notes explain why, although the reasons don't really apply to me
> (getting something as modern as Java 1.9 on the machines I work with
> would be a miracle!) But they don't really offer a good replacement
> for my use case.
> 
> What's the best option for a situation like mine? Things I've considered are:
> 
> 1. Deploy the full Groovy lib directory and use "-cp
> groovy-2.5.x/lib/*;.". Probably the best option, but either requires
> copying the full lib directory around or hard-coding its path (at the
> moment, I can just dump a copy of the -all jar in the directory
> alongside my script).
> 2. Use the full install and the supplied bat file wrapper. As well as
> the same problem of hard coded paths/copying directories, I find bat
> file wrappers extremely problematic - as bat files don't nest, you
> have to remember to say "call groovy.bat ..." when running from a
> batch script - which frequently gets forgotten.
> 3. Compile my scripts with the needed Groovy jars embedded. This means
> every script needs to be deployed as a binary, and source needs
> managing. Also minor changes involve a full build-deploy cycle.
> 
> Ideally, I'd like a simple means of creating the old -all jar file.
> Even if it comes with warnings and limitations, that would be fine for
> me (at least, assuming the limitations aren't any worse than they were
> in 2.4.x). However, I'm *not* a Java developer, so unfortunately I
> don't know how to translate the comment from the release notes stating
> "We also provided a convenience "all" jar by jarjar’ing the core and
> "module" jars" into instructions for how I could create the -all jar
> file for myself. And the comment "we do provide an "all" pom" doesn't
> mean much to me either - I understand it's something to do with maven,
> but as I don't use tools like maven,. that's not much help to me...
> 
> If anyone can offer any suggestions, I'd be most grateful.
> 
> Paul



Re: Start shell/REPL without launching java monitor?

2018-10-20 Thread Keith Suderman
Ok, I see what you mean now.  I don't use groovysh enough for that to be an 
issue for me, but I wonder if the issue is the same on Windows machines? 

However, I see that the "inspect" command uses a Swing GUI and I suspect this 
is what is causing the issue.  I also see that the "inspect" command is 
disabled if Java is running in "headless" mode.  So a relatively simple work 
around is to set java.awt.headless=true in JAVA_OPTS before running groovysh. 
I.E.

$> export JAVA_OPTS=-Djava.awt.headless=true
$> groovysh

-or-

$> JAVA_OPTS=-Djava.awt.headless=true groovysh

-or-

$> alias gsh='JAVA_OPTS=-Djava.awt.headless=true groovysh'
$> gsh

Now the applet is not launched and doesn't steal the focus away from the 
terminal window.  However, I haven't tested the above (other to ensure the 
applet isn't started) so I don't know what else might be affected.

Hope this helps,
- Keith

> On Oct 15, 2018, at 4:22 PM, Tzu-Li Chen  wrote:
> 
>  1.png 
> <https://drive.google.com/file/d/1R8fj07vPRwtcazXoLIsFw4XcyEGqgw-M/view?usp=drive_web>
>  2.png 
> <https://drive.google.com/file/d/173hrjKQ7fGqiWBYXEf--Vlz3EnIeBiYO/view?usp=drive_web>
>  diag.png 
> <https://drive.google.com/file/d/1ZoNPAnFWgqxtZwRehrQJqnR7M8AcdmcK/view?usp=drive_web>
> Hi Keith,
> 
> Thanks for your reply! I think I know `groovy` command and now I exactly 
> suffer from `groovysh`. Let me try to speak it clearly.
> 
> (on macOS)
> 1. I open a terminal.
> 2. Type "groovysh" and 
> 3. A new window looks like a Java applet, named "Groovy Shell" launched, and 
> the focus switch to it.
> 4. I switch the focus back to the terminal, and start to interact with REPL.
> 
> What I am suffering is 3 and 4, each time I want to interact with REPL I have 
> to switch the focus. Think about `jshell` or `python`, the REPL is of course 
> a process, but not another window and even force switch the focus.
> 
> Also photos in attach links, please pay attention to the focus is switched 
> from 1 to 2.
> 
> Best,
> tison.
> 
> 
> Keith Suderman mailto:suder...@anc.org>> 于2018年10月15日周一 
> 下午10:44写道:
> Hi Tison,
> 
> I am not sure what you are asking... groovysh is the "Groovy Shell" so you 
> should see a terminal window named "GroovyShell" launched that allows you to 
> execute Groovy commands interactively.  This is the expected behaviour.  Or 
> are you just pointing out the exception when quitting groovysh?  How did you 
> kill groovysh?  With the Unix `kill` command (or Windows equivalent) or using 
> one of the "exit" commands in the shell itself (:exit, :x, etc)?
> 
> I suspect you may simply want the `groovy` command that you can use to run 
> Groovy scripts/programs. 
> 
> $ echo "println 'hello world'" > test.groovy
> $ cat test.groovy
> println 'hello world'
> $ groovy test.groovy 
> hello world
> 
> Hope this helps,
> Keith
> 
>> On Oct 11, 2018, at 10:54 PM, Tzu-Li Chen > <mailto:wander4...@gmail.com>> wrote:
>> 
>> Hi Groovy community,
>> 
>> I am new to Groovy and when running `groovysh` with "3.0.0-alpha-3, JVM: 
>> 1.8.0_171" on macOS, I see a, hmm, Java monitor(?), named "GroovyShell" 
>> launched.
>> 
>> If I kill it, process `groovysh` quit with exception below. I'd like to know 
>> if we can suppress the launch of "GroovyShell" process. It switch the focus 
>> of cursor and quite annoying for me.
>> 
>> Best,
>> tison.
>> 
>> [printStackTrace]:
>> 
>> ➜  ~ groovysh
>> Groovy Shell (3.0.0-alpha-3, JVM: 1.8.0_171)
>> Type ':help' or ':h' for help.
>> ---
>> groovy:000> 2018-10-12 10:51:09.084 java[34387:1479007] 
>> java.lang.SecurityException: Use of System.exit() is forbidden!
>>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>  at 
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>  at 
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>  at 
>> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>>  at 
>> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>>  at 
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>>  at 
>> org

Re: Start shell/REPL without launching java monitor?

2018-10-15 Thread Keith Suderman
Hi Tison,

I am not sure what you are asking... groovysh is the "Groovy Shell" so you 
should see a terminal window named "GroovyShell" launched that allows you to 
execute Groovy commands interactively.  This is the expected behaviour.  Or are 
you just pointing out the exception when quitting groovysh?  How did you kill 
groovysh?  With the Unix `kill` command (or Windows equivalent) or using one of 
the "exit" commands in the shell itself (:exit, :x, etc)?

I suspect you may simply want the `groovy` command that you can use to run 
Groovy scripts/programs. 

$ echo "println 'hello world'" > test.groovy
$ cat test.groovy
println 'hello world'
$ groovy test.groovy 
hello world

Hope this helps,
Keith

> On Oct 11, 2018, at 10:54 PM, Tzu-Li Chen  <mailto:wander4...@gmail.com>> wrote:
> 
> Hi Groovy community,
> 
> I am new to Groovy and when running `groovysh` with "3.0.0-alpha-3, JVM: 
> 1.8.0_171" on macOS, I see a, hmm, Java monitor(?), named "GroovyShell" 
> launched.
> 
> If I kill it, process `groovysh` quit with exception below. I'd like to know 
> if we can suppress the launch of "GroovyShell" process. It switch the focus 
> of cursor and quite annoying for me.
> 
> Best,
> tison.
> 
> [printStackTrace]:
> 
> ➜  ~ groovysh
> Groovy Shell (3.0.0-alpha-3, JVM: 1.8.0_171)
> Type ':help' or ':h' for help.
> ---
> groovy:000> 2018-10-12 10:51:09.084 java[34387:1479007] 
> java.lang.SecurityException: Use of System.exit() is forbidden!
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>   at 
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:238)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:250)
>   at 
> org.codehaus.groovy.tools.shell.util.NoExitSecurityManager.checkExit(NoExitSecurityManager.groovy:51)
>   at java.lang.Runtime.exit(Runtime.java:107)
>   at java.lang.System.exit(System.java:971)
>   at 
> com.apple.eawt._AppEventHandler.performQuit(_AppEventHandler.java:145)
>   at com.apple.eawt.QuitResponse.performQuit(QuitResponse.java:51)
>   at 
> com.apple.eawt._AppEventHandler$_QuitDispatcher.performDefaultAction(_AppEventHandler.java:390)
>   at 
> com.apple.eawt._AppEventHandler$_AppEventDispatcher.dispatch(_AppEventHandler.java:512)
>   at 
> com.apple.eawt._AppEventHandler.handleNativeNotification(_AppEventHandler.java:202)
> 



--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






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

2018-06-13 Thread Keith Suderman


> On Jun 13, 2018, at 2:17 PM, Paul King  wrote:
> 
> 
> 
> On Wed, Jun 13, 2018 at 5:11 PM, David Dawson 
>  <mailto:david.daw...@simplicityitself.com>> wrote:
> I would vote 2.
> 
> Actually, i would vote 3) abandon 2.6 immediately.
> 
> We identified a few major things that were broken in the previous alpha 
> release of
> 2.6 but only due to trivial packaging issues, hence the plan to do one more 
> release.

How about an option #4.  If you are planning to do one more release of 2.6.0 
anyway just drop the 'alpha' from the name and announce that it is the first 
and last 2.6.x release expected.

- Keith

> 
> Also, Jesper identified a few things that can easily be aligned from 3.0 in
> a very short period of time. I am happy to wait for his thumbs up before 
> proceeding.
> 
> I am also keen on releasing another alpha of 3.0 at the same time as the 2.6 
> alpha.
> I believe that will make our life easier when answering future 
> support-oriented questions
> about 2.6 on the mailing list going forward.
> 
> So, doing one more alpha release of 2.6 has minimal impact on 3.0 timing and 
> leaves
> us in as clean a state as can be hoped for when retiring a previously planned 
> branch.
> 
> Cheers, Paul.
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Availability of 2.5.0 groovy-all in Maven Central

2018-06-03 Thread Keith Suderman
Daniel beat me to it.  I tried using the Groovy Eclipse compiler (2.5.0-01) and 
I need to explicitly set the type to 'pom' or I get a not found message for 
groovy-all:jar:2.5.0

- Keith


> On Jun 3, 2018, at 9:47 PM, Daniel.Sun  wrote:
> 
> Please add `pom` and try again, here is the complete pom file:
> 
> ```
> 
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
> 
>me.sunlan
>try-groovy-via-mvn
>1.0-SNAPSHOT
> 
>
>
>org.codehaus.groovy
>groovy-all
>2.5.0
>pom
>
>
> 
> ```
> 
> and here is result of `mvn dependency:tree`:
> ```
> [INFO] me.sunlan:try-groovy-via-mvn:jar:1.0-SNAPSHOT
> [INFO] \- org.codehaus.groovy:groovy-all:pom:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-ant:jar:2.5.0:compile
> [INFO]|  +- org.apache.ant:ant:jar:1.9.9:compile
> [INFO]|  +- org.apache.ant:ant-junit:jar:1.9.9:runtime
> [INFO]|  +- org.apache.ant:ant-launcher:jar:1.9.9:compile
> [INFO]|  \- org.apache.ant:ant-antlr:jar:1.9.9:runtime
> [INFO]+- org.codehaus.groovy:groovy-bsf:jar:2.5.0:compile
> [INFO]|  +- bsf:bsf:jar:2.4.0:compile
> [INFO]|  \- commons-logging:commons-logging:jar:1.2:compile
> [INFO]+- org.codehaus.groovy:groovy-cli-picocli:jar:2.5.0:compile
> [INFO]|  \- info.picocli:picocli:jar:3.0.2:compile
> [INFO]+- org.codehaus.groovy:groovy-console:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-datetime:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-docgenerator:jar:2.5.0:compile
> [INFO]|  \- com.thoughtworks.qdox:qdox:jar:1.12.1:compile
> [INFO]+- org.codehaus.groovy:groovy-groovydoc:jar:2.5.0:compile
> [INFO]|  \- org.codehaus.groovy:groovy-dateutil:jar:2.5.0:runtime
> [INFO]+- org.codehaus.groovy:groovy-groovysh:jar:2.5.0:compile
> [INFO]|  \- jline:jline:jar:2.14.6:compile
> [INFO]+- org.codehaus.groovy:groovy-jmx:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-json:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-jsr223:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-macro:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-nio:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-servlet:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-sql:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-swing:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-templates:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-test:jar:2.5.0:compile
> [INFO]|  \- junit:junit:jar:4.12:compile
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:compile
> [INFO]+- org.codehaus.groovy:groovy-test-junit5:jar:2.5.0:compile
> [INFO]|  +- org.junit.platform:junit-platform-launcher:jar:1.2.0:compile
> [INFO]|  |  +- org.apiguardian:apiguardian-api:jar:1.0.0:compile
> [INFO]|  |  \-
> org.junit.platform:junit-platform-engine:jar:1.2.0:compile
> [INFO]|  | +-
> org.junit.platform:junit-platform-commons:jar:1.2.0:compile
> [INFO]|  | \- org.opentest4j:opentest4j:jar:1.1.0:compile
> [INFO]|  \- org.junit.jupiter:junit-jupiter-engine:jar:5.2.0:runtime
> [INFO]| \- org.junit.jupiter:junit-jupiter-api:jar:5.2.0:runtime
> [INFO]+- org.codehaus.groovy:groovy-testng:jar:2.5.0:compile
> [INFO]|  \- org.testng:testng:jar:6.9.10:runtime
> [INFO]| \- com.beust:jcommander:jar:1.48:runtime
> [INFO]\- org.codehaus.groovy:groovy-xml:jar:2.5.0:compile
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 02:47 min
> [INFO] Finished at: 2018-06-04T09:42:43+08:00
> [INFO] Final Memory: 17M/216M
> [INFO]
> 
> ```
> 
> No matter it works or not, please let me know.
> 
> 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



--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: [Poll] About supporting Java-like array

2018-04-29 Thread Keith Suderman
e:
>> 
>> 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}
>> }
>> ```
>> 
>> *Annotation array*
>> ```
>> @PropertySources({
>> @PropertySource("classpath:1.properties"),
>> @PropertySource("file:2 <>.properties")
>> })
>> public class Controller {}
>> ```
>> 
>> *More examples*
>> Please see the examples on the PR page[1]
>> 
>> *Known breaking changes*
>> 1. Closure array in the dynamic mode
>> Before
>> ```
>> Closure[] y = { {-> 1 + 1 } }
>> assert y[0].call().call() == 2
>> ```
>> After
>> ```
>> Closure[] y = { {-> 1 + 1 } }
>> assert y[0].call() == 2
>> ```
>> 2. String array in the dynamic mode
>> Before
>> ```
>> String[] a = {}
>> assert 1 == a.length
>> assert a[0].contains('closure')
>> ```
>> After
>> ```
>> String[] a = {}
>> assert 0 == a.length
>> ```
>> 
>> 
>>   If Groovy 3 supports Java-like array, what do you think about the new
>> feature? Do you like it? We need your feedback. Thanks in advance!
>> 
>> [+1] I like it
>> [ 0] Not bad
>> [-1] I don't like it, because...
>> 
>> Cheers,
>> Daniel.Sun
>> [1] https://github.com/apache/groovy/pull/691 
>> <https://github.com/apache/groovy/pull/691>
>> [2] http://groovy-lang.org/differences.html 
>> <http://groovy-lang.org/differences.html>
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html 
>> <http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>
>> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: [Poll] About supporting Java-like array

2018-04-29 Thread Keith Suderman
h 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}
>> }
>> ```
>> 
>> *Annotation array*
>> ```
>> @PropertySources({
>> @PropertySource("classpath:1.properties"),
>> @PropertySource("file:2 .properties")
>> })
>> public class Controller {}
>> ```
>> 
>> *More examples*
>> Please see the examples on the PR page[1]
>> 
>> *Known breaking changes*
>> 1. Closure array in the dynamic mode
>> Before
>> ```
>> Closure[] y = { {-> 1 + 1 } }
>> assert y[0].call().call() == 2
>> ```
>> After
>> ```
>> Closure[] y = { {-> 1 + 1 } }
>> assert y[0].call() == 2
>> ```
>> 2. String array in the dynamic mode
>> Before
>> ```
>> String[] a = {}
>> assert 1 == a.length
>> assert a[0].contains('closure')
>> ```
>> After
>> ```
>> String[] a = {}
>> assert 0 == a.length
>> ```
>> 
>> 
>>   If Groovy 3 supports Java-like array, what do you think about the new
>> feature? Do you like it? We need your feedback. Thanks in advance!
>> 
>> [+1] I like it
>> [ 0] Not bad
>> [-1] I don't like it, because...
>> 
>> Cheers,
>> Daniel.Sun
>> [1] https://github.com/apache/groovy/pull/691 
>> <https://github.com/apache/groovy/pull/691>
>> [2] http://groovy-lang.org/differences.html 
>> <http://groovy-lang.org/differences.html>
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html 
>> <http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>
>> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Groovy Champions proposal feedback

2018-02-20 Thread Keith Suderman
I may as well chip in my $0.00 worth.

I like the concept,  that it will be retroactive, and will consider more than 
just code contributions.

I also think the chosen name should be professions looking/sounding and not be 
"cutesy".  Therefore my preference(s) would be:

1. Groovy Champion (to be as close as possible to Java Champion)
2. Groovy Star (due to the logo tie-in)
3. Groovy MVP

Anyone confusing "Most Valuable Player" with "Minimum Viable Product" needs to 
get out and watch more sports ;-)

- Keith

> On Feb 13, 2018, at 4:58 AM, Paul King <pa...@asert.com.au> wrote:
> 
> 
> Hi everyone,
> 
> A few of us have had various discussions (in fact over many years)
> about having a recognition scheme similar to Java Champions,
> perhaps called "Groovy Champions" or "Apache Groovy Champions"
> or something else entirely if we think of a better name.
> 
> I think the idea has always been to recognize contribution within the
> whole Groovy ecosystem not just the Apache Groovy project. The many
> tens of projects within the ecosystem are often where many ideas come
> from for the project's future evolution and also where future contributors
> may arise. And in any case, Groovy has always been about making
> coding productive and fun and we should celebrate that widely!
> 
> There are various questions to ask like should such a scheme
> be formally coordinated by the project/by Apache or should it be run as a
> community-driven unsanctioned activity and if so what guidelines should
> be in place. Also, there are many details like how will the scheme operate?
> How are new members elected? Is it a lifetime recognition or is there
> an "emeritus" status? And so forth. Java Champions vote themselves
> on new champions and the recognition has a lifetime status for instance.
> if we progress this idea, we'd need to make that all clear but that isn't
> the purpose of this email - we need to first decide if we like the idea.
> 
> Even if we like the idea, there are still some hurdles to step through.
> We've already sought some informal feedback from other parts of
> Apache and other projects within the Groovy Ecosystem and we'll
> likely need further discussions. We want something that embraces
> the whole community but fits in with Apache project governance
> around trademarks/branding.
> 
> So, the first question is: are we as a project in favor of such a scheme?
> 
> Cheers, Paul.

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Unknown type: METHOD_DEF

2018-01-05 Thread Keith Suderman
What error are you seeing?  Do you see the error at runtime or in your IDE?  
Your code works for me (Groovy 2.4.9) so maybe check for unbalanced braces 
elsewhere in your code.

However, you shouldn't catch/rethrow the InterruptedException as you do. The 
InterruptedException is not thrown for "some reason", it is thrown when another 
thread calls Thread.interrupt() on your thread (e.g. to wake your thread up so 
it can check its state).  For example:

Thread t = Thread.start {
boolean running = true
while (running) {
doSomeWork()
try {
Thread.sleep(1000) 
}
catch (InterruptedException e) {
running = shouldIKeepRunning()
return true
}
}
}
// At program shutdown/cleanup
t.interrupt()
t.join()
println "Our thread has termintated."

The Closure passed to the Thread.sleep method can be used in place of the 
try/catch block.  That is the closure will be called when Thread.interrupt() is 
called on your thread i.e.:

Thread t = Thread.start {
boolean running = false
while(running) {
doSomeWork()
Thread.sleep(1000) {
// Called then Thread.sleep() is interrupted.
running = false
return true
}
}
}
// ...
t.interrupt()
t.join()


Finally, if you are doing complicated threading work you should really be using 
GPars or Java's Executors, ThreadPools, et al.

Cheers,
Keith

> On Jan 5, 2018, at 11:01 AM, Mohan Radhakrishnan 
> <radhakrishnan.mo...@gmail.com> wrote:
> 
> 
> 
> 
> Hi,
>  I am new to groovy. Here I tried to create
> a simple wrapper around 'sleep'.
> I see the error in the subject at 'def'. What's wrong ?
> Thanks,
> Mohan
> 
> /**
>  * Our custom sleep logic.
>  */
> trait ThreadSleeper {
>  long ms
>  Closure cl = {}
> 
> /*Sleep with an action taken*/
> def  sleeperWithAction() {
> try{
> 
> Thread.sleep ms, cl
> 
> }catch( InterruptedException ie ){
> throw new SleepInterruptedException( ie, "Thread.sleep is 
> interrupted for "+
>   "some reason [" + 
> ie.getMessage() +"]");
> }
> }
> 
> 
> /*If there is no action to be taken then we call this*/
> def  sleeper() {
> try{
> 
> Thread.sleep ms
> 
> }catch( InterruptedException ie ){
> throw new SleepInterruptedException( ie, "Thread.sleep is 
> interrupted for "+
>  "some reason [" + 
> ie.getMessage() +"]");
> }
> }
> }

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Simple question.. how to call a java class method in Groovy Script

2017-05-22 Thread Keith Suderman

> On May 22, 2017, at 2:13 PM, RJ <ssogu...@gmail.com> wrote:
> 
> Thanks for the response, Jochen.  Tried your suggestion, it doesn't like it:
> 
> 2017-05-22 14:06:15,871 ERROR -  signature of method: static com.example.auth.principal.getId() is applicable 
> for argument types: () values: []
> Possible solutions: getAt(java.lang.String), wait(), find(), grep(), 
> wait(long), grep(java.lang.Object)>
> org.codehaus.groovy.runtime.InvokerInvocationException: 
> groovy.lang.MissingMethodException: No signature of method: static 
> com.example.auth.principal.getId() is applicable for argument types: () 
> values: []
> Possible solutions: getAt(java.lang.String), wait(), find(), grep(), 
> wait(long), grep(java.lang.Object)

Is the class name Principal or principal? Also, what IDE are you using?  Any 
decent IDE should be able to show you the available method signatures and do 
auto-completion for you.

> 
> We try something like this in Java.. Whats the equivalent in Groovy Script ?

Whenever in doubt just use the Java syntax.  Apart from some Java 8 stuff 
(coming soon), Groovy is perfectly happy with Java syntax.  Once the code is 
working then you can worry about making it more "Groovy"

Cheers,
Keith

> 
> import com.example.auth.principal;
> public String1 abcd(final principal Principal){
> return Principal.getId();
> }
> 
> On Mon, May 22, 2017 at 2:03 PM, Jochen Theodorou <blackd...@gmx.org 
> <mailto:blackd...@gmx.org>> wrote:
> On 22.05.2017 19 <tel:22.05.2017%2019>:40, RJ wrote:
> Here is my script. Highlighted the method call.. tried some google
> searches for the syntax. Thanks for the help!
> 
> import java.util.*
> import com.example.auth.user;
> 
> class EBSAttrRelease {
>  def Map<UserString, List> run(final UserObject... args) {
>  def userid=com.example.auth.user.getId()
>  return [MYLOGINID:userid]
>  }
> }
> 
> try "import com.example.auth.user as User" instead of "import 
> com.example.auth.user" and then "def userid=User.getId()"... assuming of 
> course that getId is a static method in the class com.example.auth.user
> 
> bye Jochen
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Binary to Base64 Conversion

2017-05-16 Thread Keith Suderman
lson
> Senior Developer
> HD Supply, FM
> Cell 858-740-6523 <tel:(858)%20740-6523>
> Home 760-930-0461 <tel:(760)%20930-0461>
> 
> CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and 
> may contain information that is confidential, proprietary or exempt from 
> disclosure, and subject to terms at: http://www.hdsupply.com/email 
> <http://www.hdsupply.com/email>.
> 
> From: RJ <ssogu...@gmail.com <mailto:ssogu...@gmail.com>>
> Reply-To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
> <users@groovy.apache.org <mailto:users@groovy.apache.org>>
> Date: Friday, May 12, 2017 at 7:05 PM
> To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
> <users@groovy.apache.org <mailto:users@groovy.apache.org>>
> Subject: Binary to Base64 Conversion
> 
> I have to deal with a binary value of base64 ID in a groovy script. So, first 
> I need to covert binary data to base64 format and then decodeBase64(). 
> 
> Any clues/thoughts ? Thanks!!
> 
> 
> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Optimising a Groovy script

2017-03-29 Thread Keith Suderman
 will be integers
> (in certain cases I might want non-integers but I can handle them
> exceptionally) but I don't necessarily know the range in advance (so
> I'd avoid a static array unless it gives significant performance
> benefits - when I did a quick test, I got about a second faster
> runtime, noticeable, but not enough to get me anywhere near my sub-1
> second target)
> 
> I tried using the GProf profiler to see if that shed any light on what
> I should do. When I ran with a realistic number of iterations it took
> forever and then failed with an out of memory error. Dropping it to
> 1 iterations, I got
> 
> %cumulative   selfself totalselftotal
> selftotal
> time   secondsseconds  calls  ms/call  ms/call  min ms  min ms
> max ms  max ms  name
> 34.50.04 0.04  1 0.00 0.000.000.00
> 0.911.13  blackpool$_run_closure2$_closure3.roll
> 18.50.06 0.02  39984 0.00 0.000.000.00
> 0.530.53  java.lang.Integer.plus
> 15.90.08 0.02  1 0.00 0.010.000.00
> 0.281.26  blackpool$_run_closure2$_closure3.doCall
> 11.00.10 0.01  3 0.00 0.000.000.00
> 0.360.36  org.apache.commons.math3.random.MersenneTwister.nextInt
> 5.10.10 0.00  1 0.00 0.000.000.00
> 0.190.19  java.util.LinkedHashMap.containsKey
> 4.40.11 0.00  1 0.00 0.000.000.00
> 0.020.02  java.util.LinkedHashMap.putAt
> 4.00.12 0.00  1 5.25   125.625.25  125.62
> 5.25  125.62  java.lang.Integer.times
> 3.90.12 0.00   9984 0.00 0.000.000.00
> 0.020.02  java.util.LinkedHashMap.getAt
> 2.2    0.12 0.00  1 2.85   128.482.85  128.48
> 2.85  128.48  blackpool$_run_closure2.doCall
> 
> But I don't really know how to interpret that. (Also, am I somehow
> using GProf wrongly? It seems like it shouldn't run out of memory
> profiling a 5-second program run...)
> 
> Can anyone offer any advice on what I should be looking at here?
> 
> Thanks,
> Paul

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Maven coordinates going forward

2017-03-29 Thread Keith Suderman
Given Cédric's email and recent comments I think I have been convinced to 
change my vote to a -1 for changing Maven coordinates or package names.

Is there a compelling technical argument for either change?  Going by the old 
adage, "if it ain't broke don't fix it", what exactly is being "fixed"?  It 
seems most arguments in favour are political/aesthetic and not technical in 
nature.

Besides, think of using org.codehaus.groovy as paying homage to Groovy's long 
and storied history. ;-)

Keith

> On Mar 29, 2017, at 5:08 AM, Miro Bezjak <bezjak.m...@gmail.com> wrote:
> 
> -1 for both maven coordinates and package change. Please don't break 
> backwards compatibility. Maybe I'm missing something but I see no good reason 
> for either change.
> 
> As others have mentioned, there is a lot of unmaintained code that would stop 
> working as a result of a package change. So in my opinion, pros would need to 
> be greater than the fact that the whole groovy ecosystem can suddenly do less 
> than before the change.
> 
> As for maven coordinates, please see Cédric's mail. Again, pros do not 
> outweigh the cons in my opinion. Dependecy resolution conflict problem that 
> doesn't exist if maven coordinates stay the same.
> 
> Just my 2 cents.
> 
> On Mar 28, 2017 7:42 PM, "Cédric Champeau" <cedric.champ...@gmail.com 
> <mailto:cedric.champ...@gmail.com>> wrote:
> One thing one has to consider when changing Maven coordinates, is... Maven. 
> Despite being a build tool, it does a fairly poor job when coordinates 
> change. In particular, think of conflict resolution. What should it decide if 
> A depends on org.codehaus.groovy:2.4.10 and B depends on 
> org.apache.groovy:groovy-all:3.0? Maven is pretty bad at this. We have 
> strategies to deal with this in Gradle (dependency substitution), but it will 
> imply that projects could find different artifacts on classpath in the 
> future, for a dependency on Groovy.
> 
> That said, I'm open to changing the coordinates. I would do this for the 
> "breaking" version of Groovy, whatever it is, but not before. Which means, 
> the same version as the one we change package names.
> 
> 2017-03-28 19:03 GMT+02:00 Keegan Witt <keeganw...@gmail.com 
> <mailto:keeganw...@gmail.com>>:
> I'm +1 on Maven coordinate change.  That should be fairly low impact.
> 
> I agree package renames should be taken on a case-by-case basis.  Offhand, 
> the two biggest things that come to mind are custom ASTs, and the compilation 
> bits.  For the former, I'd think it shouldn't be any worse than the 
> groovy.transforms move.  For the latter, it might make sense to wait to 
> rename that package until the compilation is decoupled from the core.
> 
> On Tue, Mar 28, 2017 at 9:36 AM, Jochen Theodorou <blackd...@gmx.org 
> <mailto:blackd...@gmx.org>> wrote:
> 
> On 27.03.2017 22 <tel:27.03.2017%2022>:14, Wilson MacGyver wrote:
> as I recall, there are also rules about jigsaw not allowing same package
> path from multiple modules. It's not till java 9, but that maybe a concern.
> 
> That is right, yes... it is only a problem for Groovy as named or automatic 
> module though. As long as Groovy stays in the classpath/annonymous module 
> variant, there is no such problem with multiple jars, as long as the 
> overlapping package names are all from the classpath/annonymous module
> 
> 
> bye Jochen
> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: Maven coordinates going forward

2017-03-27 Thread Keith Suderman
+1 for changing Maven coordinates.

-1 for changing package names.  Sure, new code can use the new package names, 
but changing existing packages is just breaking changes for the sake of 
breaking things with no real benefit.  I hope the Groovy team tries to break as 
little as possible to avoid the "Python3 Effect", whether real or imagined.

Having said that, how much public facing code is in org.codehaus.groovy 
packages?  I don't think I've typed "import org.codehaus.groovy..." in my life, 
but IntelliJ may have inserted a few for me.

Keith


> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <blackd...@gmx.org> wrote:
> 
> On 27.03.2017 20:08, Winnebeck, Jason wrote:
>> The key thing in my mind is that you can't make a change that breaks
>> 100% of libraries at one time without fracturing the community or at
>> least introducing a major hindrance to upgrade that will mean
>> maintaining 2.x series for a very long time. Even if the upgrade
>> process is as easy as a recompile, there are a lot of published
>> libraries no longer maintained. Even for the ones that are
>> maintained, there are people who might not want to be forced to
>> upgrade every library. I'm not a Grails user, but my impression is
>> that the framework relies on a lot of plugins and is one of the (if
>> not the most) active Groovy communities and I have a hard time
>> envisioning how that upgrade path will take. You'd have to maintain
>> Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
>> have to upgrade everything at one time to the (most likely) latest
>> version.
>> 
>> What is the possibility that the package names are changed, the
>> parser, metaprogramming model, etc. that all break in Groovy 3
>> change, but yet still have a compatibility JAR implementing the
>> minimal Groovy 2.x classes in a way that allows interoperability with
>> Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
>> to view Groovy 2 classes the same way as any other Java class. I
>> think many concerns would be lifted if Groovy 2 and 3 could co-exist
>> at the same time, allowing you to upgrade incrementally.
> 
> If you see the new metaprogramming model as chance, then it would make sense 
> to implement that in the new packages instead of transferring old and to be 
> deprecated classes. The goal would the to be able to run old and new system 
> at the same time, where the Groovy 1.x/2.x classes would use Groovy 3.x/4.x 
> classes as implementation.
> 
> The problem with this approach is simply manpower and of course some 
> conceptual problems still to be solved.
> 
> bye Jochen

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






Re: 17th in the TIOBE programming language index

2016-01-08 Thread Keith Suderman
It is great that Groovy is in the top 20 (and Java is #1), but I have to 
question their methodology and numbers as well.  For instance Pascal is at #16. 
 Really?  Pascal?  Number 16?  Is there a huge Pascal development community 
somewhere that I don’t know about? Similarly, Delphi/Object Pascal is at number 
12!  The future for Pascal programmers looks bright indeed ;-)

Keith

> On Jan 8, 2016, at 3:56 AM, Guillaume Laforge  wrote:
> 
> You're of course totally right!
> 
> It's just that following the index in the past, I noticed the big
> fluctuations from month to month, which are just not plausible in real
> life. A language wouldn't jump up'n down in popularity that much (nor
> in terms of actual usage).
> 
> Also, statistically speaking, seeing a ranking with percentages with
> some many figures after the comma, for just one small percent, makes
> me think that it's not relevant, accurate, or realistic for
> comparisons.
> 
> But that's nice to be in the top-20 nonetheless ;-)
> 
> Guillaume
> 
> On Fri, Jan 8, 2016 at 8:57 AM, Pierre Smits  wrote:
>> While I agree that position in rankings can be argued, it does have it
>> effect on potential adopters. A high position tells the potential adopter
>> something, and it is commonly known that there are more followers than
>> leaders.
>> 
>> So congratulations on this achievement by the community.
>> 
>> Best regards,
>> 
>> Pierre Smits
>> 
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>> 
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet
> 
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+



--
Research Associate
Department of Computer Science
Vassar College
Poughkeepsie, NY