[armedbear-devel] JSS issues: bug in jss::with-constant-signature, jss::invoke-find-method?

[Jonathan P. Bona]

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 at 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 at 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 at common-lisp.**net <armedbear-devel at 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120405/0751e01a/attachment.html>