It looks like there's an issue with caching methods -- the arguments aren't being taken into account. We're using the following as a temporary workaround version of invoke-find-method:
On 3/31/12 12:14 AM, Jonathan P. Bona wrote:
Filed as [ticket][#205]. As soon as I write some tests to convince myself of the right cases to implement we should have this working for you in a couple days. It vaguely smells like a problem left over from the graft from the jscheme arity matcher with a CL:APPLY._______________________________________________Alan pointed out a JSS issue with passing of immediate values that may
be related to the bug (report just sent) causing
(jss::invoke-find-method "substring" "this is a string" '(1)) to
return #<method public java.lang.String
java.lang.String.substring(int,int)>
Here are some of Alan's comments on this:
Previously, in the old version of JSS:
(new 'Boolean t) -> #<java.lang.Boolean true {19FD541}>
Now:
(new 'Boolean t) -> #<THREAD "interpreter" {4C4A0D}>: Debugger invoked
on condition of type JAVA-EXCEPTION
Java exception 'java.lang.NoSuchMethodException:
Boolean(org.armedbear.lisp.Symbol)'.
Restarts:
0: TOP-LEVEL Return to top level.
Notice that it has not translated the "t" to true as it used to. If
method lookup is also not doing this then it makes sense that the
method isn't found.
(#"booleanValue" +true+) -> t
(#"valueOf" 'Boolean +true+) -> t
(#"valueOf" 'Boolean t) -> error
So it is clear that t isn't being coerced to boolean, which is done in
method invoke-restargs in the old invoke.lisp:
(dolist (arg args)
(setf (jarray-ref argv (incf (the fixnum i)))
(if (eq arg t) true (if (eq arg nil) false arg))))
But I still don't understand why (#"valueOf" 'Boolean +true+) works.
Here's the declaration: public static java.lang.Boolean
java.lang.Boolean.valueOf(boolean)
Apparently the compiler will unbox the Boolean to boolean for a method
call. It doesn't for a method lookup I think. So they must have code
for checking for both Boolean and boolean in the method signature when
looking up the method.
Only theory I have is that lookup of static methods is different from
lookup of instance methods.
On Fri, Mar 30, 2012 at 5:36 PM, Jonathan P. Bona
<jonathanbona@gmail.com> wrote:
I'm working with Alan Ruttenberg to port LSW from the old version of
JSS to the JSS that is now part of abcl-contrib.
We've run into the following bug when using with-constant-signature:
; these first two work fine:
(#"substring" "some string" 2 4) ; "me"
(#"substring" "some string" 2) ; "me string"
; and so does this
(with-constant-signature ((substring "substring")) (substring "some
string" 2 4)) ; "me"
; but this breaks:
(with-constant-signature ((substring "substring")) (substring "some string" 2))
; Wrong number of arguments for public java.lang.String
java.lang.String.substring(int,int): expected 2, got 1
; [Condition of type PROGRAM-ERROR]
A problem seems to be in jss::invoke-find-method, which is finding the
two argument version of java.lang.String.substring no matter how many
arguments its given:
(jss::invoke-find-method "substring" "this is a string" '(1)) ;
should return the java.lang.String.substring method with one int arg
; #<method public java.lang.String java.lang.String.substring(int,int)>
(jss::invoke-find-method "substring" "this is a string" '(1 2) )
; #<method public java.lang.String java.lang.String.substring(int,int)>
(jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6
7 8) ) ; should be an error
; #<method public java.lang.String java.lang.String.substring(int,int)>
- Jonathan Bona
armedbear-devel mailing list
armedbear-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
At a minimum we should at least throw a condition with some args to inspect as to why we failed to match the plausible candidates which passed case insensitive string matching on the function names.
[#205]: http://trac.common-lisp.net/armedbear/ticket/205
--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."