Re: JVM Language Summit (Europe)?
Hi! I am interested too, and I'd vote for an "opposite" summit. Cédric 2013/10/2 Martijn Verburg > Hi all, > > Hope this is the right mailing list to post on, apologies for the slight > OT post. > > A few people asked whether the LJC could/would host a JVM language summit > in Europe which would hopefully cover the EMEA based folks that can't make > the existing summit. > > I'd like to get an idea of whether there's appetite for this and if so > when it should be run: > > * At the same time and have some video-conferencing sessions? OR > * At a time almost 'opposite' to the existing summit so that there's a > summit roughly every 6-months. > > Ping me directly with your thoughts (unless this is the right mailing list > - in that case reply back here). > > Cheers, > Martijn > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JVM Language Summit (Europe)?
On Oct 4, 2013 5:50 PM, "George Marrows" wrote: > I'd suggest 'opposite' to the existing summit, so that we might get some of the key figures from that conf (Brian Goetz, John Rose, Charlie Nutter etc) over in Europe. Charlie has certainly said he'd be interested in coming to one in Europe, particularly if it preceded/followed another European conf he would like to attend. Absolutely! The FOSDEM Java room has kinda served that purpose but it has a broader focus. I would definitely like an official event. > On Wed, Oct 2, 2013 at 1:38 PM, Martijn Verburg wrote: >> >> Hope this is the right mailing list to post on, apologies for the slight OT post. This is a pretty good list. Also JVM-L (I will forward). >> * At the same time and have some video-conferencing sessions? OR >> * At a time almost 'opposite' to the existing summit so that there's a summit roughly every 6-months. Opposite for sure. I hate to stack another event on the FOSDEM+Jfokus schedule but that would maybe maximize the number of US folks that would be there. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JVM Language Summit (Europe)?
I would prefer a spring time event in Europe. I have seen quite enough of winter in Europe. regards mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JVM Language Summit (Europe)?
Hi Martijn, Yes, I'm interested, along with a couple of other people from work. I'd suggest 'opposite' to the existing summit, so that we might get some of the key figures from that conf (Brian Goetz, John Rose, Charlie Nutter etc) over in Europe. Charlie has certainly said he'd be interested in coming to one in Europe, particularly if it preceded/followed another European conf he would like to attend. Please let me know how plans progress and if there's anything I can do to help. Yours, George George Marrows General Electric Cambridge, UK On Wed, Oct 2, 2013 at 1:38 PM, Martijn Verburg wrote: > Hi all, > > Hope this is the right mailing list to post on, apologies for the slight > OT post. > > A few people asked whether the LJC could/would host a JVM language summit > in Europe which would hopefully cover the EMEA based folks that can't make > the existing summit. > > I'd like to get an idea of whether there's appetite for this and if so > when it should be run: > > * At the same time and have some video-conferencing sessions? OR > * At a time almost 'opposite' to the existing summit so that there's a > summit roughly every 6-months. > > Ping me directly with your thoughts (unless this is the right mailing list > - in that case reply back here). > > Cheers, > Martijn > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
On Oct 4, 2013, at 2:40 PM, John Rose wrote:
> Actually it's OK: The name "coll" is defined a couple lines up by the "A
> collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term
> "filter" is persistently applied to it. So I think it is intelligible as
> posted. — John
I'm fine with that.
>
> On Oct 4, 2013, at 11:34 AM, John Rose wrote:
>
>> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
>> also. — John
>>
>> On Oct 4, 2013, at 11:17 AM, Christian Thalinger
>> wrote:
>>
>>> You have renamed "coll" to "filter" but the documentation still references
>>> "coll" in multiple places, e.g.:
>>>
>>> + * If the filter method handle {@code coll} consumes one argument and
>>> produces
>>> + * a non-void result, then {@code collectArguments(mh, N, coll)}
>>> + * is equivalent to {@code filterArguments(mh, N, coll)}.
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
Actually it's OK: The name "coll" is defined a couple lines up by the "A
collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term
"filter" is persistently applied to it. So I think it is intelligible as
posted. — John
On Oct 4, 2013, at 11:34 AM, John Rose wrote:
> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
> also. — John
>
> On Oct 4, 2013, at 11:17 AM, Christian Thalinger
> wrote:
>
>> You have renamed "coll" to "filter" but the documentation still references
>> "coll" in multiple places, e.g.:
>>
>> + * If the filter method handle {@code coll} consumes one argument and
>> produces
>> + * a non-void result, then {@code collectArguments(mh, N, coll)}
>> + * is equivalent to {@code filterArguments(mh, N, coll)}.
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
also. — John
On Oct 4, 2013, at 11:17 AM, Christian Thalinger
wrote:
> You have renamed "coll" to "filter" but the documentation still references
> "coll" in multiple places, e.g.:
>
> + * If the filter method handle {@code coll} consumes one argument and
> produces
> + * a non-void result, then {@code collectArguments(mh, N, coll)}
> + * is equivalent to {@code filterArguments(mh, N, coll)}.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
src/share/classes/java/lang/invoke/MethodHandles.java:
You have renamed "coll" to "filter" but the documentation still references
"coll" in multiple places, e.g.:
+ * If the filter method handle {@code coll} consumes one argument and
produces
+ * a non-void result, then {@code collectArguments(mh, N, coll)}
+ * is equivalent to {@code filterArguments(mh, N, coll)}.
Otherwise this looks good.
On Sep 12, 2013, at 7:55 PM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
>
> Summary: promote an existing private method; make unit tests on all argument
> positions to arity 10 with mixed types
>
> The change is to javadoc and unit tests, documenting and testing some corner
> cases of JSR 292 APIs.
>
> Bug Description: Currently, a method handle can be transformed so that
> multiple arguments are collected and passed to the original method handle.
> However, the two routes to doing this are both limited to special purposes.
>
> (They are asCollector, which collects only trailing arguments, and only into
> an array; and foldArguments, which collects only leading arguments into
> filter function, and passes both the filtered result *and* the original
> arguments to the original.)
>
> MethodHandles.collectArguments(mh, pos, collector) should produce a method
> handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*,
> x, c*) }, where the span of arguments b* is located by pos and the arity of
> the collector.
>
> There is internal machinery in any JSR 292 implementation to do this. It
> should be made available to users.
>
> This is a missing part of the JSR 292 spec.
>
> Thanks,
> — John
>
> P.S. Since this is a change which oriented toward JSR 292 functionality, the
> review request is to mlvm-dev and core-libs-dev.
> Changes which are oriented toward performance will go to mlvm-dev and
> hotspot-compiler-dev.
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
