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@
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 imp
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.nab
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 fo
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 t
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(
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
int
+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
>
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
Interesting. So, what's the next step if we want to get a feature like this
started? Do we need to poll it first or something? I think building it on
top of 3.0 makes the most sense, but I haven't delved deep enough into how
the language works to know for sure.
--
Sent from: http://groovy.329449
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
On 21.12.2017 05:02, Nathan Harvey wrote:
That's true, "use" does offer control over the scope. Why is it more
difficult to implement it in a dynamic context versus a static one?
"use" activates categories, but to activate them, you need to know them.
In dynamic Groovy that is the runtime, in
Good move, Russell :-)
Ursprüngliche Nachricht Von: Russel Winder
Datum: 21.12.17 17:59 (GMT+01:00) An:
dev@groovy.apache.org Cc: GPars Users ,
Groovy_Users Betreff: Re: GPars progress [was CC and
build revision]
I have started a TODO wiki page at https://github.com/GPars/
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.
==
On Wed, 2017-12-20 at 17:48 -0700, Nathan Harvey wrote:
>
[…]
> and
> advertised forum. Unfortunately the concept of a mailing list is
> deeply
[…]
For some people forums are anathema, email being the only sane way.
Other believe the opposite. The only community I know that deal with
this is the
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
>
>
>
> 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"
Thanks ;-)
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
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
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/daniel
20 matches
Mail list logo
