I will put together a duby-complete.jar that includes my bootstrap and requires you to provide Attila's dynalang stuff. I also posted a blog entry on how to build your own duby-complete; the missing piece is just additionally compiling and linking in src/org/jruby/duby/DynalangBootstrap.java:
http://blog.headius.com/2010/04/getting-started-with-duby.html On Mon, Apr 5, 2010 at 6:16 PM, John Rose <[email protected]> wrote: > The sources are changing rapidly at this point; I'm working on invokeGeneric. > If you send me a JAR which which can run stand-alone, I can use it as a > regression test. > > -- John > > On Apr 2, 2010, at 2:36 PM, Attila Szegedi wrote: > >> On 2010.03.25., at 3:17, Charles Oliver Nutter wrote: >> >>> For Attila: I had to remove a spreadArguments handle you used for >>> re-binding the method...not sure why. Here's the diff: >> >> Turns out, now the MethodHandle.invokeVarargs() actually does the whole >> convert-to-generic-and-invoke-as-vararg, so I committed the definitive >> solution for it now, which is simply: >> >> Index: DynamicLinkerImpl.java >> =================================================================== >> --- DynamicLinkerImpl.java (revision 233) >> +++ DynamicLinkerImpl.java (revision 228) >> @@ -111,6 +111,12 @@ >> // Invoke the method. Note we bypass the guard, as the assumption is >> // that the current arguments will pass the guard (and there actually >> // might be no guard at all). >> - return guardedInvocation.getInvocation().invokeVarargs(arguments); >> + final MethodHandle invocation = guardedInvocation.getInvocation(); >> + final MethodType genericType = invocation.type().generic(); >> + final MethodHandle genericizedInvocation = >> + MethodHandles.convertArguments(invocation, genericType); >> + final MethodHandle spreadInvocation = MethodHandles.spreadArguments( >> + genericizedInvocation, SPREAD_GENERIC_INVOCATION); >> + return MethodHandles.invoke(spreadInvocation, arguments); >> } >> } >> >> (Mind you, this is a reverse diff, but I'm too sleepy now to fix it; just >> swap + and -) >> >> I think the problem was in the fact that the (now deprecated) >> MethodHandles.invoke() used to behave as "invokeExact" in the last August's >> builds (so that's why I had to genericize + spread explicitly), while now it >> maps to MethodHandle.invokeVarargs(), so in addition to it being deprecated, >> its behaviour was also changed in the past half a year and that broke >> things, as you have yourself experienced :-). >> >> Should be good now. >> >> BTW, Stephen Bannasch's MLVM build works completely okay - I abandoned the >> attempt to now build my own as it didn't work out quickly and I didn't want >> to waste a lot of time; his version + Java sources from Mercurial seem >> sufficient for debugging. >> >> I'm still not back to the old 6 unit test errors, but this patch reduced >> them from 18 to 8; seems there are still two genuine new issues. >> >> Attila. >> >>> >>> Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java >>> =================================================================== >>> --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (revision 232) >>> +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (working copy) >>> @@ -115,8 +115,6 @@ >>> final MethodType genericType = invocation.type().generic(); >>> final MethodHandle genericizedInvocation = >>> MethodHandles.convertArguments(invocation, genericType); >>> - final MethodHandle spreadInvocation = >>> MethodHandles.spreadArguments( >>> - genericizedInvocation, SPREAD_GENERIC_INVOCATION); >>> - return MethodHandles.invoke(spreadInvocation, arguments); >>> + return MethodHandles.invoke(genericizedInvocation, arguments); >>> } >>> } >>> >>> I committed a built version with this hack...no tests, etc yet for >>> Duby's "dynamic" type, but that will come soon. >>> >>> BTW, what's the current state of the art for emitting .java with an >>> invokedynamic in it? Duby also has a .java backend, so I'll need to >>> add indy support there as well (somehow). >>> >>> - Charlie >> _______________________________________________ >> mlvm-dev mailing list >> [email protected] >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
