On Wed, 4 Jan 2006, Peter Graves wrote:
> On Mon, 2 Jan 2006 at 08:11:08 -0800, Peter Graves wrote:
>> On Sun, 1 Jan 2006 at 17:59:22 +0100, Andras Simon wrote:
>>> On Sun, 1 Jan 2006, Peter Graves wrote:
>>>> Can you provide a complete test case? (Complete and minimal would be
>>>> even better, but I'd settle for just complete.)
>>> There's one here:
>>> It's not minimal, but short and almost complete. If you wrap any
>>> method definition (in the call to java::%jnew-proxy) in (compile nil
>>> ..), you'll get the "Wrong number of arguments" error.
>> OK, I'll try to take a look at this later this week.
> This is now fixed in CVS.
> The problem was that LispHandler.invoke() was calling a compiled
> function with 8 or fewer (i.e., <= CALL_REGISTERS_MAX) arguments by
> passing the arguments in an array. Fixed-arity compiled functions
> (other than builtins) expect calls with fewer than CALL_REGISTERS_MAX
> arguments to pass the arguments directly. For the gory details, take a
> look at evalCall() in Lisp.java.
> For now, I've fixed LispHandler.invoke() by simply making it use
> evalCall(). This might not be the best approach, performance-wise, but
> it has the advantage that I'm certain to notice when evalCall() breaks.
One of these days, I'll try to apply the same changes to the classes
that JNEW-RUNTIME-CLASS creates.
> Your original message notes that %JNEW-PROXY is "unexported, because
> it"s experimental and because it needs a better syntax". It's
> definitely experimental, but I don't think the syntax is really that
> bad. Overall, I like the approach, but I'm not really a very good judge
> of how useful it might be in the wild. Anyone want to offer an opinion
> or suggest a better approach?
I'm glad you like the syntax, because it lives on in
JINTERFACE-IMPLEMENTATION (defined in java.lisp), which is the
exported "front-end" to %JNEW-PROXY.
> [If we're going to keep it, it should probably be made to validate its
> arguments: we should require the names to be real strings, to avoid
> case confusion, but the function arguments should accept function
JINTERFACE-IMPLEMENTATION now checks that the method names are strings
and the method definitions are functions; is that what you meant?