Re: Possible New Groovy Features... - ctor calls without new keyword

[John Wagenleitner]

Just thought I'd mention list and map constructors [1], with those you can
not only leave out the `new` keyword but also leave off the type (at least
on the RHS)

Foo foo = ['abc']

[1] http://groovy-lang.org/semantics.html#_list_and_map_constructors

On Tue, Aug 22, 2017 at 4:16 PM, MG  wrote:

> Hi Paul,
>
> On 21.08.2017 04:30, Paul King wrote:
>
> Always allow ctor calls without new keyword:
>
>>
> final foo = Foo("abc") // creates a new Foo instance by calling Foo class
>> ctor with signature
>> Rationale: new keyword was necessary in C++ to distinguish heap vs stack
>> variable allocation. No such need exists in Groovy, so the keyword just
>> clutters the source code. Naming convention of method names being always
>> lowercase prevents name clashes with methods.
>>
>
>  A partial solution to this is available via @Newify. As far as I know,
> @Newify hasn't been super popular, so we'd need to think carefully about
> introducing this.
>
>
> I am not surprised that the @Newify annotation (
> http://docs.groovy-lang.org/latest/html/api/groovy/lang/Newify.html) is
> not popular: When I first read the Groovy documentation (somewhere around
> 1.8.x) and came across @Newify, I was "Yes - fanta... wait... you have to
> do what ?". It felt like a feature that was introduced to kill it off
> immediately...
> The Ruby Foo.new(...) syntax falls short for me, since it basically just
> moves the "new" String around, i.e. it does not make the code much more
> readable / compact. And for the Foo(...) style, you have to give the
> classes it shall work for explicitely in the @Newify, which is imho too
> cumbersome.
>
> If @Newify with Foo(...) ctor calls would work without arguments, one
> could apply it through a compiler customizer, so can you tell me the
> rationale for not going down that route (and if the rationale ist still
> valid in 2017 ;-) ), together with the cryptic "The annotation is intended
> to be used sparingly" in the @Newify doc ?
>
> For me, getting rid of "new" would be as Groovy as e.g. dropping the
> semicolon end of line character - which was not necessary since the days of
> K - or being able to give the Closure argument like a block construct :-)
>
> Now crush my hopes with some backward-compatibility-Groovy-
> insider-error-situations-handler-reason,
> Ma;-)rkus
>
>
>

Re: foo() || return false ?

[John Wagenleitner]

Since the `||` operator expects an expression a return statement is not
valid there.  If the goal is to call the method `doSomething()` and then
return false, then both can be put on separate lines or a semicolon can be
used to separate the statements to keep it a one-liner, e.g.,
`doSomething(); return false`.

On Mon, Jul 17, 2017 at 5:24 PM, Guy Matz <guym...@gmail.com> wrote:

> Thanks so much for the reply!  I'm not trying to do this, though: || false
>
> I'm trying to do this: || return false
>
> Is there a more groovy way?
>
> Thanks!!
>
>
> On Mon, Jul 17, 2017 at 5:06 PM, John Wagenleitner <
> john.wagenleit...@gmail.com> wrote:
>
>> That is not a valid start of an expression which is expected for the
>> binary expression (expr || expr) so that's why it wont compile. I am not
>> familiar with Scriptler and it is hard to tell without some more context,
>> but how about just:
>>
>> doSomething()
>>
>> You can simplify by dropping the `|| false`.  If that's the last line in
>> a boolean returning method/context it will return true if doSomething()
>> returns a non-null/non-zero/non-false value, else false.  Otherwise you
>> could coerce the value to a boolean with:
>>
>> doSomething() as boolean
>>
>>
>> On Mon, Jul 17, 2017 at 1:18 PM, Guy Matz <guym...@gmail.com> wrote:
>>
>>> Hello!
>>> I'm trying to do the following in scriptler (Jenkins), but I can't get
>>> this to work:
>>> doSomething() || return false
>>>
>>> This fails in scripler with:
>>>
>>> Execution of script [promoteBuild.groovy] failed - 
>>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
>>> failed:
>>> Script1.groovy: 51: unexpected token: return @ line 51, column 85.
>>>doSomething() || return fal
>>>
>>>
>>> Anyone know why this seemingly valid groovy does not work in scriptler?
>>>
>>>
>>> Thanks!
>>>
>>>
>>> P.S. - I asked the jenkins community but no one responded
>>>
>>>
>>
>

Re: foo() || return false ?

[John Wagenleitner]

That is not a valid start of an expression which is expected for the binary
expression (expr || expr) so that's why it wont compile. I am not familiar
with Scriptler and it is hard to tell without some more context, but how
about just:

doSomething()

You can simplify by dropping the `|| false`.  If that's the last line in a
boolean returning method/context it will return true if doSomething()
returns a non-null/non-zero/non-false value, else false.  Otherwise you
could coerce the value to a boolean with:

doSomething() as boolean


On Mon, Jul 17, 2017 at 1:18 PM, Guy Matz  wrote:

> Hello!
> I'm trying to do the following in scriptler (Jenkins), but I can't get
> this to work:
> doSomething() || return false
>
> This fails in scripler with:
>
> Execution of script [promoteBuild.groovy] failed - 
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
> failed:
> Script1.groovy: 51: unexpected token: return @ line 51, column 85.
>doSomething() || return fal
>
>
> Anyone know why this seemingly valid groovy does not work in scriptler?
>
>
> Thanks!
>
>
> P.S. - I asked the jenkins community but no one responded
>
>

Re: Invokedynamic

[John Wagenleitner]

On Fri, Apr 28, 2017 at 8:59 AM, Janice Treshova  wrote:

> Hi Groovy Users!
>
> I am new to Groovy and trying 2.4.11 on Windows (8.1).
>
> The "Invoke dynamic support" page on the Groovy-lang.org site says:
>
> The usual way to run a script from the command line is by "groovy
>> foo.groovy",
>> where foo.groovy is the groovy program in source form. To use indy for
>> this you
>> have to use the indy distribution and "groovy --indy foo.groovy". Doing
>> this
>> without the indy distribution will result in an error message.
>>
>
> But if I remove all indy-related jars from the distribution, my scripts
> still run with the --indy switch without any error message.
>
> When I set DEBUG, "groovy --indy test.groovy" results the following:
>
> "C:\Program Files\Java\jdk1.8.0_121\bin\java.exe" "-Xmx128m"
> -Dprogram.name="" -Dgroovy.home="c:\Groovy" -Dtools.jar="C:\Program
> Files\Java\jdk1.8.0_121\lib\tools.jar" 
> -Dgroovy.starter.conf="c:\Groovy\conf\groovy-starter.conf"
> -Dscript.name="C:\Temp\--indy"  -classpath "c:\Groovy\lib\groovy-2.4.11.jar"
> org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain
> --conf "c:\Groovy\conf\groovy-starter.conf" --classpath "."  --indy
> test.groovy
>
> Note the
>
> -Dscript.name="C:\Temp\--indy"
>
> part - is it OK?
>
> Is there a way to check whether my script runs with invokedynamic support?
>
>
Hi Janice,

I think that the last 2 sections (Running groovy script from command line &
The compilation flag) of that page [1] are not correct about needing the
groovy-*-indy.jar files in order to use indy with your scripts.  The Groovy
compiler is able to compile scripts using invokedynamic instructions
regardless of whether the indy or non-indy Groovy jar files are used.   You
can see this if you use groovyc to compile the script and then use javap to
see the bytecodes generated.

The only difference I'm aware of between the indy and non-indy jar files in
the Groovy distribution has to do with how the Groovy source files that
make up Groovy itself are compiled.  But user supplied Groovy sources will
be generated with invokedynamic instructions regardless of which set of
jars are used if the indy flag is used.

John

[1] http://www.groovy-lang.org/indy.html

Re: Optimising a Groovy script

[John Wagenleitner]

Hi Paul,

The milliseconds to seconds conversion was off, so that puts the real time
at ~0.5 seconds.


> println "Took ${time/100} sec"


Using the following I get somewhere close to 0.15.  Using an int array may
be worth it for higher values of N to avoid the boxing/unboxing of the ints.

@Grapes(
@Grab(group='org.apache.commons', module='commons-math3', version=
'3.6.1')
)
import org.apache.commons.math3.random.MersenneTwister

def benchmark = { closure ->
  start = System.currentTimeMillis()
  closure.call()
  now = System.currentTimeMillis()
  now - start
}

@groovy.transform.CompileStatic
class Twister {
static MersenneTwister rng = new MersenneTwister()

static int roll() {
rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
}

static Map rolls(int num) {
Map results = [:]
num.times {
int n = roll()
results[n] = results.containsKey(n) ? results[n] + 1 : 1
}
return results
}
}

int N = 100
def results

def time = benchmark {
results = Twister.rolls(N)
}

println "Took ${time/1000} sec"
for (e in results.sort()) {
println "$e.key: $e.value"
}



On Tue, Mar 28, 2017 at 1:25 PM, Paul Moore  wrote:

> I'm very much a newbie with Groovy, so I apologise in advance if this
> is not the right place for questions like this. I couldn't find
> anywhere else that looked like a better option - if there is somewhere
> I should have asked, feel free to redirect me.
>
> I want to write a simulation script using Groovy - this is something
> of a hobby challenge for me, I have a friend who has done a similar
> task in C++, and I'm looking for a more user-friendly language to
> write the code, while not losing too much performance over the C
> version.
>
> The code is basically to simulate "a game". The particular game is
> defined by the user, as a function that generates scores. The program
> runs the game many times, and summarises the distribution of the
> results. Basically, a Monte Carlo simulation. My current code in
> Groovy for this, using "roll 3 dice and add up the results" as the
> target game, looks as follows:
>
> @Grapes(
> @Grab(group='org.apache.commons', module='commons-math3',
> version='3.6.1')
> )
> import org.apache.commons.math3.random.MersenneTwister
>
> def benchmark = { closure ->
>   start = System.currentTimeMillis()
>   closure.call()
>   now = System.currentTimeMillis()
>   now - start
> }
>
> rng = new MersenneTwister()
>
> int roll() {
> rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
> }
>
> int N = 100
> def results = [:]
>
> def time = benchmark {
> N.times {
> int n = roll()
> results[n] = results.containsKey(n) ? results[n] + 1 : 1
> }
> }
>
> println "Took ${time/100} sec"
> for (e in results.sort()) {
> println "$e.key: $e.value"
> }
>
> This does exactly what I want, but takes about 5 seconds to run the
> simulation on my PC. My friend's C++ code runs a similar simulation in
> about 0.1 second. That's a massive penalty for Groovy, and likely
> means that for more realistic simulations (which would be a lot more
> complex than 3d6!) I wouldn't even be close to competitive.
>
> The code above is completely unoptimised. I know that Groovy's dynamic
> programming features can introduce some overhead, but I also get the
> impression from the documentation that by careful use of exact types,
> and similar techniques, this can be speeded up a lot (the docs claim
> potentially better than C performance in some cases).
>
> What should I be looking at to optimise the above code? The areas I
> can think of are:
>
> 1. The RNG. I assume that the apache commons code is pretty efficient,
> though. I do want a reasonably decent RNG, and I'd heard that the JVM
> RNG is not sufficient for simulation. For now I'm assuming that this
> is sufficiently good.
> 2. The roll() function. This is the core of the inner loop, and likely
> the big bottleneck. I've declared the type, which I guess is the first
> step, but I don't know what else I can do here. I tried a
> CompileStatic annotation, but that gave me errors about referencing
> the rng variable. I'm not sure what that implies - is my code doing
> something wrong in how it references the global rng variable?
> 3. Collecting the results in a map is likely not ideal. Is there a
> better data structure I should be using? I basically want to be able
> to count how many times each result appears - results 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 

Re: Testing the Java 8 / Parrot parser online!

[John Wagenleitner]

On Sat, Mar 25, 2017 at 1:26 AM, Jochen Theodorou  wrote:

> On 25.03.2017 07:52, Russel Winder wrote:
>
>> On Fri, 2017-03-24 at 21:36 +0100, Guillaume Laforge wrote:
>>
>>> […]
>>>
>>> It's built with Java 8, and runs on the upcoming version of Google
>>> App
>>> Engine's Java runtime running on an OpenJDK 8. It's using the "indy"
>>> jar,
>>> thus with the invoke dynamic support automatically.
>>> […]
>>>
>>
>> What is the exact difference between the indy artefacts and the non-
>> indy artefacts?
>>
>>
My understanding is that the only difference between the "-indy" and
non-indy jars pertains to class files generated from .groovy source files
within the Groovy project itself.  Using the indy jars does affect scripts
compiled or run against those jars, the default is still the legacy
callsite code.  In order compile with indy you'd still have to set the indy
setting in the compiler config or pass -indy to groovyc.  Since core
contains very few groovy source files (I think maybe just one), using the
-indy jars would mainly affect those using subprojects such as
groovy-console, groovy-docgenerator, etc. that are mostly written using
Groovy.



> Why are we still making two complete sets of artefacts int eh Groovy
>> build, surely now we should have just one.
>>
>
> I cannot suggest to users to use indy with a normal JDK7, so the minimum
> requirement for it is JDK8. And we are not there yet.
>
> bye Jochen
>
>
Based on what I've seen I agree, at least for making indy the default mode
for compilation would be best to wait until jdk8 is the min version.

Re: when does JsonSlurper return LazyMap vs LazyValueMap ?

[John Wagenleitner]

On Thu, Jan 26, 2017 at 12:27 PM, garneke  wrote:

> Update:
>
> I have determined that the difference in the return type has to do with
> the JsonSlurper type.  The INDEX_OVERLAY returns a LazyValueMap.
>
>
>
> That being said…
>
> What is the correct way to add a node or otherwise modify the LazyValueMap
> objects?
>
>
>


I think the easiest way to do this if there are no nested objects is to
create a new Map from the LazyValueMap.  If there are no nested objects
then the following would work.


def newMap = new LinkedHashMap(lazyValueMap)
newMap.mediaHash = mediaHash


If there are nested objects then it takes more work as you'd have to
recurse/iterate over each nested LazyValueMap and convert it as well.
There's an issue [1] requesting the ability to convert to a regular map.

[1] https://issues.apache.org/jira/browse/GROOVY-7532



>
>
> *From:* garneke [via Groovy] [mailto:ml-node+[hidden email]
> ]
> *Sent:* Thursday, January 26, 2017 12:31 PM
> *To:* Kenton Garner <[hidden email]
> >
> *Subject:* Re: when does JsonSlurper return LazyMap vs LazyValueMap ?
>
>
>
> -- Sorry for the first post ( formatting was lost )
>
> Environment: groovy-all-2.4.6
>
> In my environment I am seeing that JsonSlurper returns LazyMap in my test
> code using the groovyConsole but it returns a LazyValueMap in my compiled
> java code.
>
> I am trying to add a node to the json object and it works great in the
> groovyConsole but fails in java.
>
> This code works in the groovyConsole...
>
>
>
>
>
>
>
> *   def slurper = new JsonSlurper()  def json = slurper.parseText( jsonTxt
> )  json.put("mediaHash", mediaHash)  // -- or  --  json."mediaHash" =
> mediaHash *
>
> In the  groovyConsole  slurper.parseText() returns a LazyMap
> But in Java it returns a LazyValueMap and I get the exception ... die("Not
> that kind of map");
>
> What is the correct way to add a node and why do I get different results?
> Thanks
>
> --
>
> *If you reply to this email, your message will be added to the discussion
> below:*
>
> http://groovy.329449.n5.nabble.com/when-does-JsonSlurper-
> return-LazyMap-vs-LazyValueMap-tp5738132p5738133.html
>
> To unsubscribe from when does JsonSlurper return LazyMap vs LazyValueMap
> ?, click here.
> NAML
> 
>
> --
> View this message in context: RE: when does JsonSlurper return LazyMap vs
> LazyValueMap ?
> 
>
> Sent from the Groovy Users mailing list archive
>  at
> Nabble.com.
>

Re: parsing YAML with snakeyaml

[John Wagenleitner]

On Wed, Dec 21, 2016 at 11:58 AM, Dimitar Vassilev <
dimitar.vassi...@gmail.com> wrote:

> Good evening/morning/day,
> Quick one how can I parse a YAML file with groovy and snakeyaml
>
> I have a nested hash YAML like:
>
> pkgcolls:
>   pkgcol1:
>  software:Foo
>  version:baz
>   pkgcol2:
>  software:baz
>  version:Foo
>
> In Ruby I can do something like in the irb/file
> require 'yaml'
> thing = YAML.load_file('some.yml')
> puts thing.inspect
>
> How can I do similar thing in groovy using
>
> import org.yaml.snakeyaml.DumperOptions
> import org.yaml.snakeyaml.Yaml
>
> and the yaml.load(object) function?
> I would like to loop through the YAML structure and figure out which kind
> of loop to use.
> I'm interested in dealing directly with the pkgcol(1-N) attributes
> directly if possible.
> Thanks
>


Something like the following could be run in the GroovyConsole

```
@Grab(group='org.yaml', module='snakeyaml', version='1.17')
import org.yaml.snakeyaml.*

String yamlText = '''
pkgcolls:
  pkgcol1:
software:Foo
  version:baz
  pkgcol2:
software:baz
  version:Foo
'''

Yaml yaml = new Yaml()
def result = yaml.load(yamlText)
// or from a file
// new File('/tmp/test.yml').withReader('UTF-8') { reader ->
//def result = yaml.load(reader)
//
// }

result.pkgcolls.each {
assert it.key == 'pkgcol1' || it.key == 'pkgcol2'
}

println result.inspect()
```

Re: 2.5 JsonBuilder Converters thoughts

[John Wagenleitner]

I think there is consensus and a PR would be great.

On Fri, Nov 4, 2016 at 9:23 AM, James Kleeh <james.kl...@gmail.com> wrote:

> Do we have any consensus on this? Should I submit a PR with the change?
>
> > On Oct 28, 2016, at 6:51 AM, Graeme Rocher <graeme.roc...@gmail.com>
> wrote:
> >
> > one thing to note. I would assume if we allow JsonOutput.unescaped it
> > would the convert method would have to return Object? Currently the
> > JsonUnescaped type doesn't implement CharSequence
> >
> > If that is the case it may also be interesting to support return types
> > of Writable since.
> >
> > Cheers
> >
> > On Fri, Oct 28, 2016 at 12:46 PM, Graeme Rocher <graeme.roc...@gmail.com>
> wrote:
> >> Yeah I agree JsonOutput.unescaped allows the same flexibility without
> >> compromising the most common use case.
> >>
> >> Cheers
> >>
> >> On Tue, Oct 25, 2016 at 10:32 PM, John Wagenleitner
> >> <john.wagenleit...@gmail.com> wrote:
> >>> On Tue, Oct 25, 2016 at 12:07 PM, James Kleeh <james.kl...@gmail.com>
> wrote:
> >>>>
> >>>> Currently if one were to register a converter with options like so:
> >>>>
> >>>> JsonGenerator.Options options = new JsonGenerator.Options()
> >>>> options.addConverter(MyCustomType) { MyCustomType mct ->
> >>>>mct.name
> >>>> }
> >>>>
> >>>>
> >>>> Assuming “mct.name” returns a string, it will be output without
> quotes
> >>>> because of:
> >>>>
> >>>> Converter converter = findConverter(objectClass);
> >>>> if (converter != null) {
> >>>>writeRaw(converter.convert(object, key), buffer);
> >>>>return;
> >>>> }
> >>>>
> >>>> I’d be curious to hear what the use case is for outputting the data as
> >>>> raw. I think the percentage of users that would prefer to have their
> data
> >>>> further processed by that method would vastly outnumber the ones that
> do
> >>>> not.
> >>>>
> >>>> I think something like this would be a better solution:
> >>>>
> >>>> Converter converter = findConverter(objectClass);
> >>>> if (converter != null) {
> >>>>object = converter.convert(object, key);
> >>>> }
> >>>>
> >>>> Thoughts?
> >>>
> >>>
> >>>
> >>> I had aimed for making it as flexible as possible and purposefully had
> it
> >>> not participate in further processing to avoid surprises and be able to
> >>> output JSON that otherwise wouldn't be possible due to the way the
> generator
> >>> was already configured (nulls or being able to write out a number such
> as
> >>> 9.3e7).
> >>>
> >>> I like your suggestion and think the flexibility could still be
> accomplished
> >>> using JsonOutput.unescaped; and since 2.5 isn't out yet there's still
> time
> >>> to refine how it works.
> >>>
> >>> I also would like to hear what others think.
> >>>
> >>> John
> >>
> >>
> >>
> >> --
> >> Graeme Rocher
> >
> >
> >
> > --
> > Graeme Rocher
>
>

Re: Congratulations to our newest committer Daniel Sun

[John Wagenleitner]

On Nov 3, 2016 9:27 PM, "Paul King"  wrote:
>
> Congratulations to Daniel Sun who is now a Groovy committer:
>
> https://projects.apache.org/committee.html?groovy
> http://people.apache.org/phonebook.html?unix=groovy
>
> Daniel has been mostly working on the new Antlr 4 parser which will
> see some exciting steps forward for the Groovy compiler.
>
> Cheers, Paul.

Welcome Daniel!

Re: 2.5 JsonBuilder Converters thoughts

[John Wagenleitner]

On Tue, Oct 25, 2016 at 12:07 PM, James Kleeh  wrote:

> Currently if one were to register a converter with options like so:
>
> JsonGenerator.Options options = new JsonGenerator.Options()
> options.addConverter(MyCustomType) { MyCustomType mct ->
> mct.name
> }
>
>
> Assuming “mct.name” returns a string, it will be output without quotes
> because of:
>
> Converter converter = findConverter(objectClass);
> if (converter != null) {
> writeRaw(converter.convert(object, key), buffer);
> return;
> }
>
> I’d be curious to hear what the use case is for outputting the data as
> raw. I think the percentage of users that would prefer to have their data
> further processed by that method would vastly outnumber the ones that do
> not.
>
> I think something like this would be a better solution:
>
> Converter converter = findConverter(objectClass);
> if (converter != null) {
> object = converter.convert(object, key);
> }
>
> Thoughts?
>


I had aimed for making it as flexible as possible and purposefully had it
not participate in further processing to avoid surprises and be able to
output JSON that otherwise wouldn't be possible due to the way the
generator was already configured (nulls or being able to write out a number
such as 9.3e7).

I like your suggestion and think the flexibility could still be
accomplished using JsonOutput.unescaped; and since 2.5 isn't out yet
there's still time to refine how it works.

I also would like to hear what others think.

John

Re: JsonOutput serialization options feature

[John Wagenleitner]

On Wed, Sep 21, 2016 at 3:22 AM, Graeme Rocher <graeme.roc...@gmail.com>
wrote:

> Hi John,
>
> Looks very useful, so +1
>
> One thing that would also be useful is to be able to configure the
> ability to disable unicode encoding. It doesn't seem to be recommended
> for all circumstances. See:
>
> http://stackoverflow.com/questions/12271547/shouldnt-json-
> stringify-escape-unicode-characters?noredirect=1=1
>
> And it is blocking resolution of this issue:
>
> https://github.com/grails/grails-views/issues/71
>
> Thoughts?
>


Hi Graeme,

Good suggestion, and also seems to be a requested feature in GROOVY-6975
[1].  So seems worthwhile to add a disableUnicodeEscaping or
disableNonAsciiEscaping option.  I'll see if I can add that to the PR soon.


[1] https://issues.apache.org/jira/browse/GROOVY-6975





>
> On Mon, Sep 12, 2016 at 12:02 AM, John Wagenleitner
> <john.wagenleit...@gmail.com> wrote:
> > On Sun, Sep 11, 2016 at 11:51 AM, Kostas Saidis <sai...@gmail.com>
> wrote:
> >>
> >> +1, definitely!
> >>
> >> If it is possible, the dateFormat method should also accept an optional
> >> Locale parameter (as mentioned in TODO comment in the source), with a
> >> default value of Locale.US.
> >>
> >> Cheers,
> >> Kostas
> >>
> >
> >
> > Thanks for pointing that out, I had forgot about that.  I added a new
> method
> > that accepts both a date format string and Locale.
> >
> >
> >>
> >>
> >> On 11/9/2016 6:59 πμ, John Wagenleitner wrote:
> >>
> >> Groovy Json users,
> >>
> >> I recently worked on a project where it would have been helpful if
> >> JsonOutput/JsonBuilder/StreamingJsonBuilder had options for
> controlling the
> >> output.  I noticed there were some open tickets [1] for feature requests
> >> around this so decided to try to add some options to control the
> >> serialization and have proposed a pull request
> >> (https://github.com/apache/groovy/pull/371).
> >>
> >> Just wanted to poll those that use the Json generating features in
> Groovy
> >> to see if you think these options would be useful and would welcome any
> code
> >> review for those that would be interested in reviewing the PR.  For a
> quick
> >> overview I've included a sample below [2].
> >>
> >> [1]
> >> GROOVY-6699: JSON slurper ability to ignore propertie/field names (at
> >> least the serializing part)
> >> GROOVY-6854: JsonOutput should be configurable with ISO 8601 UTC time
> zone
> >> instead of GMT
> >> GROOVY-7682: JsonBuilder or JsonOutput incompatible with JodaTime (for
> now
> >> via a closure converter)
> >> GROOVY-7780: JSONBuilder/JSONSlurper: Option to Only Include NonNull
> >> values
> >> GROOVY-7858: Make JsonBuilder configurable to not write entries with
> null
> >> values
> >>
> >> [2]
> >>
> >> import groovy.json.*
> >>
> >> def options = JsonOutput.options()
> >> .excludeNulls()
> >> .excludeFieldsByName('make', 'country', 'record')
> >> .excludeFieldsByType(Number)
> >> .addConverter(URL) { url -> '"http://groovy-lang.org;' }
> >>
> >> StringWriter writer = new StringWriter()
> >> StreamingJsonBuilder builder = new StreamingJsonBuilder(writer, options)
> >>
> >> builder.records {
> >> car {
> >> name 'HSV Maloo'
> >> make 'Holden'
> >> year 2006
> >> country 'Australia'
> >> homepage new URL('http://example.org')
> >> record {
> >> type 'speed'
> >> description 'production pickup truck with speed of 271kph'
> >> }
> >> }
> >> }
> >>
> >> assert writer.toString() == '{"records":{"car":{"name":"HSV
> >> Maloo","homepage":"http://groovy-lang.org"}}}'
> >>
> >>
> >
>
>
>
> --
> Graeme Rocher
>

Re: JsonOutput serialization options feature

[John Wagenleitner]

On Sun, Sep 11, 2016 at 11:51 AM, Kostas Saidis <sai...@gmail.com> wrote:

> +1, definitely!
>
> If it is possible, the dateFormat method should also accept an optional
> Locale parameter (as mentioned in TODO comment in the source), with a
> default value of Locale.US.
>
> Cheers,
> Kostas
>
>

Thanks for pointing that out, I had forgot about that.  I added a new
method that accepts both a date format string and Locale.



>
> On 11/9/2016 6:59 πμ, John Wagenleitner wrote:
>
> Groovy Json users,
>
> I recently worked on a project where it would have been helpful if
> JsonOutput/JsonBuilder/StreamingJsonBuilder had options for controlling
> the output.  I noticed there were some open tickets [1] for feature
> requests around this so decided to try to add some options to control the
> serialization and have proposed a pull request (https://github.com/apache/
> groovy/pull/371).
>
> Just wanted to poll those that use the Json generating features in Groovy
> to see if you think these options would be useful and would welcome any
> code review for those that would be interested in reviewing the PR.  For a
> quick overview I've included a sample below [2].
>
> [1]
> GROOVY-6699: JSON slurper ability to ignore propertie/field names (at
> least the serializing part)
> GROOVY-6854: JsonOutput should be configurable with ISO 8601 UTC time zone
> instead of GMT
> GROOVY-7682: JsonBuilder or JsonOutput incompatible with JodaTime (for now
> via a closure converter)
> GROOVY-7780: JSONBuilder/JSONSlurper: Option to Only Include NonNull values
> GROOVY-7858: Make JsonBuilder configurable to not write entries with null
> values
>
> [2]
>
> import groovy.json.*
> def options = JsonOutput.options()
> .excludeNulls()
> .excludeFieldsByName('make', 'country', 'record')
> .excludeFieldsByType(Number)
> .addConverter(URL) { url -> '"http://groovy-lang.org;' }
>
> StringWriter writer = new StringWriter()
> StreamingJsonBuilder builder = new StreamingJsonBuilder(writer, options)
>
> builder.records {
> car {
> name 'HSV Maloo'make 'Holden'year 2006country 
> 'Australia'homepage new URL('http://example.org')
> record {
> type 'speed'description 'production pickup truck with 
> speed of 271kph'}
> }
> }
> assert writer.toString() == '{"records":{"car":{"name":"HSV 
> Maloo","homepage":"http://groovy-lang.org"}}}'
>
>
>

JsonOutput serialization options feature

[John Wagenleitner]

Groovy Json users,

I recently worked on a project where it would have been helpful if
JsonOutput/JsonBuilder/StreamingJsonBuilder had options for controlling the
output.  I noticed there were some open tickets [1] for feature requests
around this so decided to try to add some options to control the
serialization and have proposed a pull request (
https://github.com/apache/groovy/pull/371).

Just wanted to poll those that use the Json generating features in Groovy
to see if you think these options would be useful and would welcome any
code review for those that would be interested in reviewing the PR.  For a
quick overview I've included a sample below [2].

[1]
GROOVY-6699: JSON slurper ability to ignore propertie/field names (at least
the serializing part)
GROOVY-6854: JsonOutput should be configurable with ISO 8601 UTC time zone
instead of GMT
GROOVY-7682: JsonBuilder or JsonOutput incompatible with JodaTime (for now
via a closure converter)
GROOVY-7780: JSONBuilder/JSONSlurper: Option to Only Include NonNull values
GROOVY-7858: Make JsonBuilder configurable to not write entries with null
values

[2]

import groovy.json.*

def options = JsonOutput.options()
.excludeNulls()
.excludeFieldsByName('make', 'country', 'record')
.excludeFieldsByType(Number)
.addConverter(URL) { url -> '"http://groovy-lang.org;' }

StringWriter writer = new StringWriter()
StreamingJsonBuilder builder = new StreamingJsonBuilder(writer, options)

builder.records {
car {
name 'HSV Maloo'
make 'Holden'
year 2006
country 'Australia'
homepage new URL('http://example.org')
record {
type 'speed'
description 'production pickup truck with speed of 271kph'
}
}
}

assert writer.toString() == '{"records":{"car":{"name":"HSV
Maloo","homepage":"http://groovy-lang.org"}}}'

Re: TemplateEngines and Out of Memory

[John Wagenleitner]

Adding the following system property may help to extend the time before OOM:

groovy.use.classvalue=true

At least for me on Groovy 2.4.7 with jdk8_91 using that property let the
loop run 25 minutes (made about half the iterations) vs. ~2.5 minutes
without the property.  I used a 64m heap.

I believe the problem is related to GROOVY-7683.

On Fri, Jun 24, 2016 at 11:12 PM, t.schoellhorn <
t.schoellh...@plattform-gmbh.de> wrote:

> Hi, we are using Groovy in our web-application. There we create a "lot" of
> dynamic String and are handling that with the TemplateEngine as we need
> more complex expressions there. Now we noticed that we are running into a
> kind of weird OOM situation. I could narrow the problem down to a quite
> simple reproducible example:
>
> package kos.tools.template;
>
> import java.util.HashMap;
> import java.util.Map;
>
> import javax.script.Bindings;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.SimpleBindings;
>
> public class Test {
>
>
>   public static void main(String[] args) throws Exception {
>   ScriptEngineManager factory = new ScriptEngineManager();
>   ScriptEngine engine = factory.getEngineByName("groovy");
>   
>   String template = "step-${i}";
>   
>   String groovy =
>   "def engine = new 
> groovy.text.GStringTemplateEngine();\n" +
>   "def res = 
> engine.createTemplate(template).make(bindings);\n" +
>   "return res.toString();";
>
>   for (int i = 0; i < (1000); i++) {
>   Bindings vars = new SimpleBindings();
>   vars.put("template", template);
>   
>   Map templateObjects = new HashMap<>();
>   vars.put("bindings", templateObjects);
>   templateObjects.put("i", i);
>
>   Object res = engine.eval(groovy, vars);
>   
>   if (i % 100 == 0) {
>   System.out.println("->" + res);
>   }
>   }
>   }
>   
> }
>
> Running that example with an Oracle JDK 1.8 and a quite small memory (just
> for keeping the running time small) of 32M leads to an OOM at around 2500
> steps. I opened up a disussion on Stackoverflow where John Vint gave me
> some hints (see here
> )
> and it might be also a bug of the GarbageCollector itself. But in essence I
> think there should be a way to use the TemplateEngine in a stable way. I am
> happy for any suggestions and examples of how to solve this situation. Tino
> --
> View this message in context: TemplateEngines and Out of Memory
> 
> Sent from the Groovy Users mailing list archive
>  at
> Nabble.com.
>

Re: XmlSlurper Namespace Question

[John Wagenleitner]

Are you doing more than just removing nodes?  The following seems to retain
the namespace prefixes when serializing back out after removing a node.


import groovy.xml.*

String xml = '''

child1
child2
child3

'''

def root = new XmlSlurper().parseText(xml)
root.child2.replaceNode {}

String newXml = XmlUtil.serialize(root)
def newRoot = new XmlSlurper().parseText(newXml)

println XmlUtil.serialize(newRoot)
assert newRoot.lookupNamespace('a') == 'urn:a'
assert newRoot.child3.lookupNamespace('c') == 'urn:c'


Don't believe there's a defined way to get all the namespaces from the
original files, other than possibly picking at the
non-public namespaceTagHints field or by visiting each node and using
#namespaceURI() to get it's namespace.

On Mon, Apr 11, 2016 at 9:40 AM, garneke  wrote:

> I have a requirement in my application to receive xml files from a user and
> filter out specific nodes based on a configuration option ( accepts GPath
> String ).
>
> This is fine.
> I can use XmlSlurper to parse the file and with the defined GPath I can
> find
> and remove the node and rewrite the file.
>
> My application is generic and can accept any XML.
> My user base is not terribly savvy so I need to be able to have the GPath
> specified without the namespace prefixes.   This is also fine if the
> XmlSlurper is created to be namespace aware.
>
> *The problem is...*
> If my XmlSlurper is namespace aware and I remove a node, when I re-write
> the
> XML file all of the namespace prefixes get altered to "tag0:", "tag1:",
> "tag2:" etc.
>
> Is there a way to produce the XML with its original namespace prefixes?
> Is there someway I can query the original file for its namespaces and use
> that declare the namespaces for the slurper?
>
> Thanks in advance for your help.
>
>
>
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/XmlSlurper-Namespace-Question-tp5732293.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: Can anyone comment on this stackoverflow posting that indicates XmlSlurper is actually namespace aware by default

[John Wagenleitner]

Setting namespaceAware to true (default) means that it provides support for
namespaces, so in your sampleDoc it recognizes that an element such as
"xact:update" is actually "{com.here.repl}update" instead of just
"xact:update".  Usually this would be used together with declareNamespace
since the important information is the URI and you wouldn't want to have to
rely on the prefix always being the same.

For example:

def xml  = new
XmlSlurper(false,true).parseText(sampleDoc).declareNamespace(a:
'com.here.repl', b: 'com.here.repl.data');
assert xml.'a:update'.'b:table'.'b:after','b:CLASSIFICATION'.text() ==
'UNCLASSIFIED'
assert xml.'update'.'table'.'after','CLASSIFICATION'.text() ==
'UNCLASSIFIED'

Since it's namespaceAware you can even forgo including the namespace as
long as it's not required to uniquely identify the element.

Setting namespaceAware to false means the parser wont recognize namespaces
so it expects you to access the element by the full name "xact:update".  On
a non-namespaceAware parser using the declareNamespace wont have any affect.




On Tue, Apr 5, 2016 at 1:15 PM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> After seeing this a few times now, including being bit by it myself and my
> work team, I have submitted a JIRA and PR to remove the 4 confusing
> characters from the Javadoc :).
>
> https://issues.apache.org/jira/browse/GROOVY-7810  XmlSluper default
> constructor documentation about namespace aware incorrect.
> https://github.com/apache/groovy/pull/305  GROOVY-7810 fix XmlSlurper
> default ctor doc
>
> I posted answer to SO explaining the situation
> http://stackoverflow.com/a/36435993/3875382
>
> Jason
>
> -Original Message-
> From: garneke [mailto:kenton.gar...@issinc.com]
> Sent: Tuesday, April 05, 2016 3:59 PM
> To: us...@groovy.incubator.apache.org
> Subject: Re: Can anyone comment on this stackoverflow posting that
> indicates XmlSlurper is actually namespace aware by default
>
> Here is an unsophisticated example…
>
> testparse.groovy
> 
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Can-anyone-comment-on-this-stackoverflow-posting-that-indicates-XmlSlurper-is-actually-namespace-awat-tp5732204p5732207.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: Groovy SQL: Stored Procedure Call Not Executing configureStatement Closure

[John Wagenleitner]

Hi Guillermo,

Yes, I think it was a bug.  The call method taking a closure was not
passing the created statement off to the configureStatement closure.  This
should be fixed by https://github.com/apache/groovy/pull/263 and the fix
should be in 2.4.7.

John

On Thu, Mar 10, 2016 at 1:38 PM, Guillermo Roman <
guillermo.roman.deara...@gmail.com> wrote:

> Hi,
>
> I came across this issue while running some test cases on Groovy 2.4.5.
>
> The following code works as expected. If the stored procedure call takes
> longer than 5 seconds an SQLException will be thrown indicating that the
> query timed out:
>
> sql.withStatement { stmt ->
> stmt.queryTimeout = 5
> }
>
> sql.call("{call Add_User($user.email, $user.password, ${Sql.BIGINT})}")
>
> However, if I pass a closure to the stored procedure call to retrieve the
> returned values the configureStatement never gets executed and therefore
> the query timeout value is ignored:
>
> sql.withStatement { stmt ->
> stmt.queryTimeout = 5
> }
>
> sql.call("{call Add_User($user.email, $user.password, ${Sql.BIGINT})}”) { ID
> ->
> println “Auto generated User ID: $ID"
> }
>
> Is this is a bug in Groovy? or am I doing something wrong?
>
> Regards,
> Guillermo Roman
>

Re: Sql cacheConnection/withTransaction always closes connection

[John Wagenleitner]

On Wed, Dec 9, 2015 at 6:20 AM, Alexander Holand Salgado <
alexander.salg...@otrum.com> wrote:

> Hi,
>
>
> It seems that groovy.sql.Sql's cacheConnection {} and withTransaction {}
> both close the used connection on returning, regardless of the
> surrounding context, and if using a data source the currently used
> connection is set to NULL. E.g. if you do:
>
> sql.cacheConnection { cc ->
>
> sql.withTransaction { tc -> /* tc is same object as cc */
>
> }
>
> /* connection closed/null here */
> }
>
> You'll get an error if trying to execute any database queries using the
> cc-connection after the withTransaction closure.
> Also, for the same reason, you cannot have nested cacheConnection {}
> closures (if you wanted to for some reason).
>
> Looking at the source code for these methods it seems that they both
> purposely ignore the current cacheConnection state during resource
> clean-up and therefore end up closing/nulling the connection regardless
> of context.
>
> To me this seems incorrect - am I missing something here?
>
>

I don't think you're missing something, those methods don't look like they
were designed to be nested (with each other or themselves).   If nesting
were allowed, it doesn't seem like the following could be handled correctly
for both datasource and single connection backed instances.

withTransaction (or cacheConnection) {
insert A...
withTransaction {
insert B...
}
// both A and B are committed
}