gmane.comp.lang.groovy.devel

Re: [groovy-dev] Effective hash codes for closures.

2012-05-18T11:00:37

On 18/05/2012, at 6:58 AM, Jochen Theodorou wrote:


What would be the cost here? Slow class loading? Excessive perm gen usage?


No, because we are comparing across invocations so the class may be the same but the impl changed.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Grape and versioning

Paul King — 2012-05-18T09:21:45

Hi Russel,

If you believe this is a recent reversion (ignoring for now the Jira),
there was a change recently which might be related:

https://github.com/groovy/groovy-core/commit/f2f5e4b380be3c28310b075f592115800efc8d0b

Any chance that you can add the following attribute:

     checkmodified="true"

onto the "cachedGrapes" filesystem resolver element and tell us
whether you then observe behavior closer to what you are after?
This might be in direct conflict with what GROOVY-4001 is about
but at least will give us some more information.

Thanks, Paul.

On 18/05/2012 4:27 PM, Russel Winder wrote:


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Grape and versioning

Jochen Theodorou — 2012-05-18T07:11:12

Am 18.05.2012 08:27, schrieb Russel Winder:
[...]

Russel, if you can give us an ivy configuration that works, then please 
do so. I know not enough about ivy to do this. I would btw not suggest 
grap uninstall, instead I would suggest a local ivy config that fits 
your purposes.

bye blackdrag

[groovy-dev] Grape and versioning

Russel Winder — 2012-05-18T06:27:41

Experimental evidence indicates that Grape still does not treat snapshot
artefacts specially, but as though they were released artefacts, i.e.
when a < at >Grab happens the artefact is looked up in the local Grape cache
and if present search terminates. This is fine for released artefacts
given the rule that no artefact of a given release number can change.
Snapshot artefacts are however varying things, the release number is not
a guarantee of anything. For snapshot artefacts Grape should check
whether a new download is required.

Before someone responds "just 'grap uninstall ...' the artefact first",
I will point out that this is an unacceptable response :-) My point here
is that Grape is applying a contract regarding artefacts that is not
valid for snapshots and so should not be applied.

I recollect we had this debate around this time last year and someone
said they were going to fix this. As evidence I offer JIRA issue
GROOVY-4809  https://jira.codehaus.org/browse/GROOVY-4809

Re: [groovy-dev] Effective hash codes for closures.

Jochen Theodorou — 2012-05-18T05:58:57

Am 17.05.2012 16:23, schrieb ld-Hc2V4H83aCrQT0dZR+AlfA< at >public.gmane.org:
[...]

at the moment yes. If we would store the AST in the closure, then this 
dream may come true by comparing the asts. But storing the ast is 
difficult, as it means too much data in the bytecode.

"Two closure are functionally equivalent if they are of the same class" 
is not a condition you can work with?

bye blackdrag

[groovy-dev] Effective hash codes for closures.

2012-05-17T14:23:18

For Gradle, it would be very useful to have Closure#hashCode() return something that considered the implementation of the closure and its state.

The reason is that we track values over invocations and need to detect if they have changed or not. So, at the moment we can't effectively use closures as these kinds of values. It would be very useful to be able to do so.

The more I think about this though, the less possible it seems. I'm not sure if it's possible to generate a hash code for a closure implementation, or even if that's possible whether or not it would be possible to calculate this efficiently enough. Then there is the issue of requiring everything in “scope” (including this, owner and delegate) to have proper hashCode impls.

At the core, what we need is a way to identify whether or not a closure object is functionally equivalent to a closure object we have seen in a previous invocation.

Is this a pipe dream?
---------------------------------------------------------------------
To unsubscribe

Re: [groovy-dev] Re: < at >DelegatesTo annotation for tooling support.

2012-05-16T19:26:53

On 16/05/2012, at 8:20 PM, Peter Niederwieser wrote:


I had a nagging feeling this was not an original thought. 

Raised as http://jira.codehaus.org/browse/GROOVY-5455

This would be huge for Gradle.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] Re: < at >DelegatesTo annotation for tooling support.

Peter Niederwieser — 2012-05-16T19:20:45

ld-Hc2V4H83aCrQT0dZR+AlfA< at >public.gmane.org wrote

I proposed this some time ago:
http://groovy.329449.n5.nabble.com/Annotation-for-specifying-a-closure-s-delegate-type-td4888079.html#a4888911

Andrew Eisenberg liked the idea a lot. I still think this would be an
immense improvement, with virtually no effort as far as Groovy is concerned.

Cheers,
Peter 

--
View this message in context: http://groovy.329449.n5.nabble.com/DelegatesTo-annotation-for-tooling-support-tp5709816p5709821.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] < at >DelegatesTo annotation for tooling support.

2012-05-16T14:51:01

Howdy,

Has anyone floated the idea of something like this?…

void buildStuff(< at >DelegatesTo(SomeBuilder) Closure closure) {

}

Not the most aesthetically pleasing granted, but this could be very useful for tooling (e.g. auto complete).
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Re: Dynamic dispatch/static type clarification

Jochen Theodorou — 2012-05-16T09:35:25

Am 16.05.2012 05:14, schrieb tnabe:

tests/profiling is very much welcome. Of course your participation in 
actual coding as well, but tests and profiling done by a third party 
usually reveals the corners and edges nobody else thought of.


with unreachable branches you mean I guess the return null stuff at the 
end of a method... just ignore it for now... or help removing it without 
causing bytecode problems ;) The $getCallSiteArray() should actually not 
appear if indy is activated. Instead of those number reference to the 
call site array you should find invokedynamic instructions. But of 
course you have to activate indy... even in the indy enabled jar you 
have to activate it first.


for indy I suggest to open the class IndyInterface and set a breakpoint 
in either selectMethod, if you want to see how the method is selected 
and how the handles are constructed. Or in realBootstrap the almost 
beginning of the bootstrapping in indy for Groovy


I gave you some pointers, should they not be enough, just

[groovy-dev] Re: Dynamic dispatch/static type clarification

tnabe — 2012-05-16T03:14:07

Jochen,

Yeah, a multiplicity of paths seems inevitable with a dynamic language.

Anyways, I'd like to help with indy/method selection.  Maybe just by writing
tests/profiling, maybe by proffering bad ideas that help to clarify the good
ones.
But to be of any use, I need to understand the existing code.  As with any
complex problem, the hardest part is knowing how/where to start.
I tried looking at the decompiled code of a very simple script, but frankly
it looked unrecognizable (calls to $getCallSiteArray() that seemed unused;
unreachable branches, etc).
So, what would you recommend as an effective way to build an understanding
of the method resolution code (using indy), say for the following script:

static add(x, inc) { x + inc }

add(5, 1)
add("what", "ever")
add("poly", 2);
add(2, "times")
add(new Date(), 6)
...

it seems this covers a nice set of dynamic requirements (of course by no
means all) (particularly by having to dynamically "reset" the callsite's
MethodHandle).  I've played around with invokedy

[groovy-dev] GroovyC changes between 1.7.6 and 1.7.7 (and later)

Jeff Adamson — 2012-05-15T19:29:25

Hi I have what is hopefully a quick question.

The following ant snippet worked in 1.7.4 (quickly tested also works in
1.7.5, 1.7.6), but does not in 1.7.7 or 1.8.x and later
        <!-- validate that the groovy scripts compile -->
        <mkdir dir="${build.dir}/tmp"/>
        <groovyc destdir="${build.dir}/tmp" srcdir="${plugin.groovy.dir}">
            <classpath>
              <path><fileset dir="${lib.dir}/subdir"
includes="*.jar"/></path>
              <pathelement
location="${lib.dir}/jar-containing-groovy-files.jar"/>
            </classpath>
        </groovyc>
where the groovy files in plugin.groovy.dir would reference groovy classes
which are in jar-containing-groovy-files.jar (non-compiled).

Was this an abuse of an undocumented implementation detail or is this a
useful feature and therefore a regression?
I don't see any release note that sounds like it impact this
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=17020

Thanks
Jeff

Re: [groovy-dev] Re: Dynamic dispatch/static type clarification

Jochen Theodorou — 2012-05-15T11:15:26

Am 15.05.2012 12:10, schrieb tnabe:
[...]

using types can, in Groovy 1.8, under certain conditions, speed up 
performance quite much actually. But prim opts are currently limited to 
operations and primitive types. In general using types means using 
possibly more casts, which costs, thus a typed program can be slower 
than an untyped one. But it really depends. There is no simple answer. 
Groovy has the potential to speedup those things, but using it is 
difficult. For example to know if I can do an int+int as IADD in byecode 
instead of doing a dynamic dispatch for that I currently have to guard 
that statement with a meta class check, that ensures no other plus 
method was used on int. If it is, then I have to go another path. I am 
not so happy with this solution, since getting this information is 
possibly expensive and then the direct method call or direct operation 
plus guard might be slower than doing it the dynamic way always, and 
save bytecode size along with it. I could possibly extend my primo

Re: [groovy-dev] Re: Dynamic dispatch/static type clarification

Rémi Forax — 2012-05-15T10:32:20

with invokedynamic, it should, but the support of invokedynamic
is too young for that now (in Groovy *and* in the VM).

Rémi


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] Re: Additional dummy return

tnabe — 2012-05-15T10:11:45

Thanks for that clarification--makes more sense now.

--
View this message in context: http://groovy.329449.n5.nabble.com/Additional-dummy-return-tp5696182p5709787.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] Re: Dynamic dispatch/static type clarification

tnabe — 2012-05-15T10:10:41

Well, I think there is quite a bit of conflation going on (type coercion with
casting, diamond inheritance with double dispatch) but I said I wouldn't
belabor the point . . .
It's not that I don't understand what groovy is doing (and I certainly
understand what Java is doing!), it's just that I guess I disagree with it
(or at least am ambivalent).


Here's one thing I don't quite understand.  Does statically typing an
*argument** (or explicitly casting it) in anyway speed up the runtime method
resolution process (or maybe in re-using the cached Callsite)?  i.e. can the
static type annotation be used to help the runtime method resolution employ
some sort of shortcuts in determining the concrete method that will be
invoked?  Somewhere in the recess of my mind, I think the 1st edition
/Groovy in Action/ suggested not and that it might even slow it down; but I
could be mis-remembering and anyways a lot has changed since that book came
out.

*I'm distinguishing argument to refer to the variables passed as part of

Re: [groovy-dev] Re: Additional dummy return

Jochen Theodorou — 2012-05-15T09:10:16

Am 15.05.2012 11:06, schrieb tnabe:

It is an compilation artifact we couldn't get rid of yet. It has in your 
example absolutely no meaning and it is not called for side effects.

bye blackdrag

Re: [groovy-dev] Re: Dynamic dispatch/static type clarification

Jochen Theodorou — 2012-05-15T09:08:55

Am 15.05.2012 10:00, schrieb tnabe:

it is as simple as this: the cast is not redundant in Groovy since it 
has a semantic effect.


if you mean with statically annotation a variable to declare it using a 
type (because before it was about casting), then this has no effect on 
method selection. It has one on assignments though.


The reason as of why we have this forcing mechanism is a pragmatic one. 
Assume the following program:

interface I{}
interface J{}
class A implements I,J{}

def foo(I i){1}
def foo(J j){2}
def a = new A()
assert foo(a)==?

In Java this does not compile, because for foo(a) it cannot tell if you 
want to call foo(I) or foo(J). So in Java you have to write for example
foo((I)a) to force the call to use foo(I). And in this case it has an 
effect in bytecode, since there you will find the method signature 
foo(I)Ljava/lang/Object; being used for the method call. The same 
program in Groovy would compile, but fail at runtime because it cannot 
decide which method to call. Again the cast

[groovy-dev] Re: Additional dummy return

tnabe — 2012-05-15T09:06:38

and furthermore
I've seen similar code for all methods.

CallSite[] arrayOfCallSite = $getCallSiteArray(); return "value1"; return
null; 

What is the purpose of the $getCallSiteArray() invocation?
Obviously, it is related to Callsite caching, but since its return value is
not referenced, I assume that it's called for its side effects?

Actually, when I decompiled the code $getCallSiteArray wasn't even in the
decompiled code so I sort of gave up.

--
View this message in context: http://groovy.329449.n5.nabble.com/Additional-dummy-return-tp5696182p5709783.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] Re: Dynamic dispatch/static type clarification

tnabe — 2012-05-15T08:00:07

With all due respect, groovyc and javac are not behaving the same in the case
of bar2.  javac removes the redundant cast as an optimization, and it is
free to do so /only because the semantics of the code remain the same/.
groovyc is not free to do so, because the semantics would then change.

Whether the behavior is coherent or not is a matter of taste I suppose.
The question arose because I was asked a rather straightforward question,
viz. "What is the effect of statically annotating a variable (or argument)
in groovy?"
I rather sheepishly realized I didn't have a good answer.

I don't want to belabor the point, but I think it is not unreasonable to
hold the view that "all method resolution in (dynamic) groovy uses double
dispatch"; clearly that matches any reasonable test for coherence.

As far as the developer's intent when doing a cast, I've always considered
it as a shorthand for 

bar3(String o)
{
   Object ob = o;
   foo(ob);
}

and nothing more (perhaps that was a bit woolly on my part).
  
But java

Re: [groovy-dev] Dynamic dispatch/static type clarification

Rémi Forax — 2012-05-15T07:18:50

javac works as Groovy (grumpy) here,
cast is considered as an intent from the developer and used to find the 
method to call,
but it will not be generated in the bytecode because javac knows it 
always succeed.

Rémi



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email