Re: G-String embedded Closure calling bug?

2017-12-21 Thread Jochen Theodorou 

On 22.12.2017 00:20, Paul King wrote:

I suspect this is intentional but was before my time. Try this also:

int triggered = 0
def o1 = { -> triggered++ }
def o2 = { println '*' + it; triggered++ }

println(o1) // ConsoleScript11$_run_closure1@
println(o2) // ConsoleScript11$_run_closure2@

assert triggered == 0
println("xyzzy$o1") // xyzzy0
assert triggered == 1
println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZ
assert triggered == 3


ah yes... good old times with John Wilson... I think the idea was back 
then to leverage the Closures for templating engine purposes.. like for 
example GStringTemplateEngine the whole template in there is basically a 
Closure and writing is channeld by the writeTo method, that is also used 
for toString.


I really wonder how much this feature is used. If you look at the code 
you will see, that it does lead to very surprising behaviour, for 
example toString on Closure and writeTo in GString do not fit very well 
together and the GString base evaluation may lead to a double evaluation 
by working on the result of the Closure call. Plus of course the 
different behaviour for if the closure does or does not take a parameter 
where we one time work on the result and one time we ignore the result 
and instead let the Closure itself work things out.


Frankly, this is on my list of features to be removed. I have not yet 
fully investigated the impact of this - and I suspect there will be much 
more impact here than it looks like on first glance


bye Jochen

Re: Building Groovy

2017-12-21 Thread MG 
But the fact that it is an internal implementation detail does not 
prohibit technical minded people to be interested in them. Most 
developers I have met were interested in such things.
Most men have e.g. at least some knowledge about the inner workings of 
their car, even if that are internal implementation details.
In any case I think it would be worth a try, if nothing comes of it, 
nothing is lost...


On 21.12.2017 15:59, Cédric Champeau wrote:




I disagree. 99% of our users don't even know what call site
caching is. They don't know what invokedynamic means,


You think that 99% of Java professionals do not know what a
feature that has been around since Java 7 is ?
And even if that was the case: Google "java invoke dynamic" =>

https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it


from 2011


Of course. It's not a user facing feature. It's an internal 
implementation detail of JVM languages. Even if you play with 
`MethodHandles`, you will never deal directly with invoke dynamic.

Re: G-String embedded Closure calling bug?

2017-12-21 Thread Nathan Harvey 
Yeah, I don't understand this behavior either. Seems better to write "${o()}"
if you want call it. Anyone against changing that?

MG, yes that operator has been proposed for Parrot, but I'm not sure what
happened to it. Maybe start another thread for it.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: G-String embedded Closure calling bug?

2017-12-21 Thread mg 
I have never wanted to embed a Closure obj in a GString, but the behavior is 
definitely a bit unexpected.
I must admit that I feel that Groovy features like being able to iterate over 
null, or that an empty collection is Groovy-true are more of a problem imho. I 
have never had any application for the latter, but have a lot of code where I 
have to say
final cols = colsIn != null ? colsIn : defaultCols()
instead of just
final cols = colsIn ?: defaultCols()

Btw has an ?= operator ever been suggested, which assigns the RHS iff the LHS 
has value null ? If it where also supported for assigning default parameter 
values one could do:
void foo(final Columns cols ?= defaultCols(), String s) {  s ?= defaultString()}
This would allow to pass in null as parameter value which is passed through 
several calls without the need to duplicate e.g. the cols parameter default 
value in method definitions, and elegantly assign the default value in the last 
method called...


 Ursprüngliche Nachricht Von: Paul King  
Datum: 22.12.17  00:25  (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: 
G-String embedded Closure calling bug? 
Or change the last two lines a little more:

println("XX${o2}YY${o2(42)}ZZ$o2")  // *42\n*XX\n*XXYY1ZZ\nXXYY1ZZassert 
triggered == 4
It looks weird to me but perhaps there was a reason to it?

On Fri, Dec 22, 2017 at 9:20 AM, Paul King  wrote:
I suspect this is intentional but was before my time. Try this also:

int triggered = 0def o1 = { -> triggered++ }def o2 = { println '*' + it; 
triggered++ }
println(o1) // ConsoleScript11$_run_closure1@println(o2) // 
ConsoleScript11$_run_closure2@
assert triggered == 0println("xyzzy$o1") // xyzzy0assert triggered == 
1println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZassert triggered == 3

On Fri, Dec 22, 2017 at 8:20 AM, Nathan Harvey  wrote:
Take the following code:



int triggered = 0

def o = { -> triggered++ }



println(o) // A

println("$o") // B

println("${o}") // C



After A, triggered is 0; after B, it's 1; after C, it's 2. The Closure is

being called and the result of it is being printed instead. Is this behavior

intended?







--

Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: G-String embedded Closure calling bug?

2017-12-21 Thread Paul King 
Or change the last two lines a little more:

println("XX${o2}YY${o2(42)}ZZ$o2")  // *42\n*XX\n*XXYY1ZZ\nXXYY1ZZ
assert triggered == 4

It looks weird to me but perhaps there was a reason to it?


On Fri, Dec 22, 2017 at 9:20 AM, Paul King  wrote:

> I suspect this is intentional but was before my time. Try this also:
>
> int triggered = 0
> def o1 = { -> triggered++ }
> def o2 = { println '*' + it; triggered++ }
>
> println(o1) // ConsoleScript11$_run_closure1@
> println(o2) // ConsoleScript11$_run_closure2@
>
> assert triggered == 0
> println("xyzzy$o1") // xyzzy0
> assert triggered == 1
> println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZ
> assert triggered == 3
>
>
> On Fri, Dec 22, 2017 at 8:20 AM, Nathan Harvey 
> wrote:
>
>> Take the following code:
>>
>> int triggered = 0
>> def o = { -> triggered++ }
>>
>> println(o) // A
>> println("$o") // B
>> println("${o}") // C
>>
>> After A, triggered is 0; after B, it's 1; after C, it's 2. The Closure is
>> being called and the result of it is being printed instead. Is this
>> behavior
>> intended?
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>

Re: G-String embedded Closure calling bug?

2017-12-21 Thread Paul King 
I suspect this is intentional but was before my time. Try this also:

int triggered = 0
def o1 = { -> triggered++ }
def o2 = { println '*' + it; triggered++ }

println(o1) // ConsoleScript11$_run_closure1@
println(o2) // ConsoleScript11$_run_closure2@

assert triggered == 0
println("xyzzy$o1") // xyzzy0
assert triggered == 1
println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZ
assert triggered == 3


On Fri, Dec 22, 2017 at 8:20 AM, Nathan Harvey 
wrote:

> Take the following code:
>
> int triggered = 0
> def o = { -> triggered++ }
>
> println(o) // A
> println("$o") // B
> println("${o}") // C
>
> After A, triggered is 0; after B, it's 1; after C, it's 2. The Closure is
> being called and the result of it is being printed instead. Is this
> behavior
> intended?
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

G-String embedded Closure calling bug?

2017-12-21 Thread Nathan Harvey 
Take the following code:

int triggered = 0
def o = { -> triggered++ }

println(o) // A
println("$o") // B
println("${o}") // C

After A, triggered is 0; after B, it's 1; after C, it's 2. The Closure is
being called and the result of it is being printed instead. Is this behavior
intended?



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Keeping DGM helper methods?

2017-12-21 Thread Cédric Champeau 
+1

2017-12-12 17:42 GMT+01:00 Jochen Theodorou :

> Hi all,
>
>
> If we all agree on using only Indy in Groovy 3, we could get rid of all
> the DGM helper methods. What do you guys think?
>
> bye Jochen
>

Re: Keeping DGM helper methods?

2017-12-21 Thread Nathan Harvey 
Ah, I misunderstood and thought you meant getting rid of DGM methods
themselves. Sorry!



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Keeping DGM helper methods?

2017-12-21 Thread Jochen Theodorou 

On 21.12.2017 05:06, Nathan Harvey wrote:

What do you mean "get rid of them"? How would they still function?


right now they are used as convenient way of calling methods in DGM. 
With invokedynamic I have no need for that.


bye Jochen

Re: GPars progress [was CC and build revision]

2017-12-21 Thread Russel Winder 
I have started a TODO wiki page at https://github.com/GPars/GPars/wiki/
TODO

I'll try to refine it and make it less opaque, and to highlight so
specific things to get done. People should feel free to chip in
questions on the page to help in the refining process.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: About SmartASMifier

2017-12-21 Thread Shil Sinha 
Nice!

On Thu, Dec 21, 2017 at 8:45 AM, Daniel.Sun  wrote:

> Thanks ;-)
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Building Groovy

2017-12-21 Thread Cédric Champeau 
>
>
> I disagree. 99% of our users don't even know what call site caching is.
> They don't know what invokedynamic means,
>
>
> You think that 99% of Java professionals do not know what a feature that
> has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-
> invokedynamic-and-how-do-i-use-it from 2011
>

Of course. It's not a user facing feature. It's an internal implementation
detail of JVM languages. Even if you play with `MethodHandles`, you will
never deal directly with invoke dynamic.

Re: About SmartASMifier

2017-12-21 Thread Daniel.Sun 
Thanks ;-)



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About SmartASMifier

2017-12-21 Thread Graeme Rocher 
Very useful. Nice work!

On Thu, Dec 21, 2017 at 10:48 AM, Paul King  wrote:
> Nice work!
>
> On Thu, Dec 21, 2017 at 5:11 PM, Daniel.Sun  wrote:
>>
>> Hi all,
>>
>>  Recently I spend some spare time to investigate bytecode generation
>> of
>> native lambda. In order to view the ASM source code(or bytecode) easily, I
>> developed a tool named SmartASMifier(
>> https://github.com/danielsun1106/SmartASMifier ). Now I share it with you
>> :-)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
>



-- 
Graeme Rocher