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: (defun invoke-find-method (method object args) (let ((jmethod nil)); (get-jmethod method object))) (unless jmethod (setf jmethod (if (symbolp object) ;;; static method (apply #'jmethod (lookup-class-name object) method (mapcar #'jobject-class args)) ;;; instance method (apply #'jresolve-method method object args))) (if (null jmethod) (error "There's no method ~A with the signature ~A" method (cons object args))) (jcall +set-accessible+ jmethod +true+)) ;;(set-jmethod method object jmethod)) jmethod)) On Sun, Apr 1, 2012 at 1:33 PM, Mark Evenson <evenson@panix.com> wrote:

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 <armedbear-devel@common-lisp.net> http://lists.common-lisp.net/**cgi-bin/mailman/listinfo/**armedbear-devel<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<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."

On Wed, May 16, 2012 at 8:16 AM, Mark Evenson <evenson@panix.com> wrote:

On Apr 5, 2012, at 21:38 , Jonathan P. Bona wrote:

...

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: …

This should be fixed in [r13937][1].  From looking at the original version of JSS, I apparently badly misunderstood the macrology involved in WITH-CONSTANT-SIGNATURE, mistakenly trying to implement an unnecessary (and broken) method cache.

what, me broken? ;-) -Alan ps. thanks!

[1]: http://trac.common-lisp.net/armedbear/changeset/13937 _______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel