invokedynamic for Groovy

[René Scheibe]

Hi,

I was wondering about the current status of invokedynamic (=indy) for
Groovy. The 'dev' mailing list is somehow quiet about it.

I am interested in the JVM and Groovy is my language of choice on the
JVM since some years. I am not experienced in implementing languages on
the JVM and cannot make any promises how long my interest lasts and how
much time I will spend. But I definitely want to learn more about indy
and help progress indy for Groovy.

What I have done so far
- followed Charlie's posts on indy in JRuby
- checked out the 'indy' branch from groovy-core on github
- studied some articles and presentations about indy (mostly from John
Rose) but there isn't that much

1) How is indy discussed and worked at?
2) What's the current indy status and its roadmap?
3) Do you have suggestions how I can get up to speed with indy?
4) How can I contribute to indy in Groovy?

Cheers,
René Scheibe

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Am 04.12.2011 15:03, schrieb René Scheibe:
> Hi,
>
> I was wondering about the current status of invokedynamic (=indy) for
> Groovy. The 'dev' mailing list is somehow quiet about it.

I am currently implementing that

> I am interested in the JVM and Groovy is my language of choice on the
> JVM since some years. I am not experienced in implementing languages on
> the JVM and cannot make any promises how long my interest lasts and how
> much time I will spend. But I definitely want to learn more about indy
> and help progress indy for Groovy.

the current step is to make a guard that let's a new method being
selected once the meta class was changed or replaced, also missing is
the logic for groovy.lang.Interceptable. I have wrappers for forced
method selection and invocations on null... ah yes... 2 more are missing
actually... categories and the very basic check for the parameter and
receiver types, because once they change a new method selection might be
needed. And... well.. I didn't do anything for properties or fields yet,
that is also a task, but I think once methods work, this is fastly done.
Uh.. and I am not sure the logic is really respecting using invokeMethod
as methodMissing last resort... have to test that ;)

Well and of course the last step is to run all tests against the new
implementation.

> What I have done so far
> - followed Charlie's posts on indy in JRuby
> - checked out the 'indy' branch from groovy-core on github
> - studied some articles and presentations about indy (mostly from John
> Rose) but there isn't that much
>
> 1) How is indy discussed and worked at?

since I work more or less alone on it so far I discuss questions about
on the jvm-l list. But if there is a partner I would prefer to ask on
groovy-dev first ;)

> 2) What's the current indy status and its roadmap?

The status I gave.. well that is for the initial implementation. There
may be more things to improve performance later on. My roadmap so far
is, that I try to finish the initial implementation till end of the year
and then have a meeting with Remi in January to get the last questions
out of the way. That is if Remi has the time.

> 3) Do you have suggestions how I can get up to speed with indy?
> 4) How can I contribute to indy in Groovy?

I think the API takes a little bit to get used to. It is not really
complicated, just needs a certain way of thinking you have to get into
first. If you have that, then I would say to just try it out.

you could implement the logic for groovy.lang.Interceptable for
example.. I think I didn't push the newest version to github... I will
do so soon and then you could make a pull request there once you have
that implemented - if you want to work like that. But you know... I am
also grateful for a code review and if nothing goes, improving the
documentation goes always... but it is a boring task, I know ;)

Things like improving the speed and removing some performance bugs are
task once it works and in the worst case can still be done after the
next major version release in a maintainance release.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email

[Rémi Forax]

On 12/04/2011 11:10 PM, Jochen Theodorou wrote:

> Am 04.12.2011 15:03, schrieb René Scheibe:
>> Hi,
>>
>> I was wondering about the current status of invokedynamic (=indy) for
>> Groovy. The 'dev' mailing list is somehow quiet about it.
>
> I am currently implementing that
>
>> I am interested in the JVM and Groovy is my language of choice on the
>> JVM since some years. I am not experienced in implementing languages on
>> the JVM and cannot make any promises how long my interest lasts and how
>> much time I will spend. But I definitely want to learn more about indy
>> and help progress indy for Groovy.
>
> the current step is to make a guard that let's a new method being
> selected once the meta class was changed or replaced, also missing is
> the logic for groovy.lang.Interceptable. I have wrappers for forced
> method selection and invocations on null... ah yes... 2 more are
> missing actually... categories and the very basic check for the
> parameter and receiver types, because once they change a new method
> selection might be needed.

There are three tricks that works very well to avoid to check each argument,
if there is only one implementation, i.e. if the method is not
overloaded, then
you can call it directly.
If the class has a method methodMissing, it's a little bit more complex,
because you can now call two methods.

The second trick is to use types of the parameters found by the compiler
to restrict the overloads that are callable (applicable in JLS parlance).
By example, if you have
   Point p = ...
   System.out.println(p)
PrintStream defines a bunch of overloads but because the compiler find
that the method must takes a Point of a subclass of Point,
only println(Object) can be called.

The last trick is that there are maybe more than one
overload but you don't have to check all of them because the overloads
have the same parameter types at the same place.
By example,
   void m(int i, Object o)  { ... }
   void m(char c, Object o)  { ... }
here, there is no need to check the second parameter, only the first
will be used
to select the most specific method.

> And... well.. I didn't do anything for properties or fields yet, that
> is also a task, but I think once methods work, this is fastly done.
> Uh.. and I am not sure the logic is really respecting using
> invokeMethod as methodMissing last resort... have to test that ;)
>
> Well and of course the last step is to run all tests against the new
> implementation.
>
>> What I have done so far
>> - followed Charlie's posts on indy in JRuby
>> - checked out the 'indy' branch from groovy-core on github
>> - studied some articles and presentations about indy (mostly from John
>> Rose) but there isn't that much
>>
>> 1) How is indy discussed and worked at?
>
> since I work more or less alone on it so far I discuss questions about
> on the jvm-l list. But if there is a partner I would prefer to ask on
> groovy-dev first ;)
>
>> 2) What's the current indy status and its roadmap?
>
> The status I gave.. well that is for the initial implementation. There
> may be more things to improve performance later on. My roadmap so far
> is, that I try to finish the initial implementation till end of the
> year and then have a meeting with Remi in January to get the last
> questions out of the way. That is if Remi has the time.

If you offer beers, I will find time :)

>
>> 3) Do you have suggestions how I can get up to speed with indy?
>> 4) How can I contribute to indy in Groovy?
>
> I think the API takes a little bit to get used to. It is not really
> complicated, just needs a certain way of thinking you have to get into
> first. If you have that, then I would say to just try it out.
>
> you could implement the logic for groovy.lang.Interceptable for
> example.. I think I didn't push the newest version to github... I will
> do so soon and then you could make a pull request there once you have
> that implemented - if you want to work like that. But you know... I am
> also grateful for a code review and if nothing goes, improving the
> documentation goes always... but it is a boring task, I know ;)
>
> Things like improving the speed and removing some performance bugs are
> task once it works and in the worst case can still be done after the
> next major version release in a maintainance release.
>
> bye blackdrag
>

Rémi



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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Am 04.12.2011 15:03, schrieb René Scheibe:
[...]
> 4) How can I contribute to indy in Groovy?

I pushed the indy implementation version of yesterday to github. For the
build you will need a jdk7 and asm-all-4.0.0 installed in your local
maven repo. The build will still not complete, but it produces for me
enough classes to run groovy programs in my IDE.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email