On 3/31/12 12:14 AM, Jonathan P. Bona wrote:
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
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.
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