Mark Evenson | 1 Apr 19:33 2012
Picon

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

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:
>
(Continue reading)

Arnaud Bailly | 5 Apr 15:04 2012
Picon

[armedbear-devel] Cannot get abcl 1.0.1 working with slime

Hello,
I am trying to use ABCL 1.0.1 with slime under emacs and get the
following errors:

(progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp"
:verbose t) (funcall (read-from-string "swank-loader:init")) (funcall
(read-from-string "swank:start-server") "/tmp/slime.3985"
:coding-system "iso-latin-1-unix"))

Armed Bear Common Lisp 1.0.1-svn-13750-13751
Java 1.6.0_26 Sun Microsystems Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.297 seconds.
Startup completed in 0.935 seconds.
Type ":help" for a list of available commands.
CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ...
Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at
line 143 (offset 5611)
#<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of
type READER-ERROR
  The package "ASDF" can't be found.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] SWANK-LOADER(2):

Here is my .emacs:

(add-to-list 'load-path "/usr/share/emacs/site-lisp/slime")

;;(setq inferior-lisp-program "/usr/local/bin/sbcl")
(Continue reading)

Stas Boukarev | 5 Apr 15:14 2012
Picon

Re: [armedbear-devel] Cannot get abcl 1.0.1 working with slime

Arnaud Bailly <arnaud.oqube <at> gmail.com> writes:

> Hello,
> I am trying to use ABCL 1.0.1 with slime under emacs and get the
> following errors:
>
> (progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp"
> :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall
> (read-from-string "swank:start-server") "/tmp/slime.3985"
> :coding-system "iso-latin-1-unix"))
>
> Armed Bear Common Lisp 1.0.1-svn-13750-13751
> Java 1.6.0_26 Sun Microsystems Inc.
> Java HotSpot(TM) 64-Bit Server VM
> Low-level initialization completed in 0.297 seconds.
> Startup completed in 0.935 seconds.
> Type ":help" for a list of available commands.
> CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ...
> Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at
> line 143 (offset 5611)
> #<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of
> type READER-ERROR
>   The package "ASDF" can't be found.
> Restarts:
>   0: TOP-LEVEL Return to top level.
> [1] SWANK-LOADER(2):
The problem is caused by debian packaged slime, which, apparently, uses
ASDF to load slime. Use slime from Quicklisp instead.

--

-- 
(Continue reading)

Arnaud Bailly | 5 Apr 16:12 2012
Picon

[armedbear-devel] Calling java from lisp

Hello (again),
I am trying to invoke java code from lisp code following
http://common-lisp.net/project/armedbear/doc/abcl-user.html.
Here is the code I am trying to run:

CL-USER> (defun java-format (fmtstring &rest args)
           (let* ((string-class (jclass "java.lang.String"))
                  (array-of-objs (jclass "[Ljava.lang.Object;"))
                  (method (jmethod string-class "format" string-class
array-of-objs)))
             (jcall method fmtstring args)))

JAVA-FORMAT

And here is what I got when I try to run it:

> (java-format "" "%d %08.d %s" 1 2 3)

Wrong number of arguments for public static java.lang.String
java.lang.String.format(java.lang.String,java.lang.Object[]): expected
2, got 1
   [Condition of type PROGRAM-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread.

Backtrace:
  0: (#<FUNCTION {53C470B}> #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>)
(Continue reading)

Arnaud Bailly | 5 Apr 16:34 2012
Picon

Re: [armedbear-devel] Calling java from lisp

OK. I can see where my first error lies: jcall parameters are
incorrect. Here is a corrected version:

(defun java-format (fmtstring &rest args)
          (let* ((string-class (jclass "java.lang.String"))
                 (array-of-objs (jclass "[Ljava.lang.Object;"))
                 (method (jmethod string-class "format" string-class
array-of-objs)))
            (jcall method nil fmtstring args)))

But this does not work yet as I do not know how to convert a lisp list
to a java array. IS there any utility function  or should I do it "by
hand" ?

Arnaud

On Thu, Apr 5, 2012 at 4:12 PM, Arnaud Bailly <arnaud.oqube <at> gmail.com> wrote:
> Hello (again),
> I am trying to invoke java code from lisp code following
> http://common-lisp.net/project/armedbear/doc/abcl-user.html.
> Here is the code I am trying to run:
>
> CL-USER> (defun java-format (fmtstring &rest args)
>           (let* ((string-class (jclass "java.lang.String"))
>                  (array-of-objs (jclass "[Ljava.lang.Object;"))
>                  (method (jmethod string-class "format" string-class
> array-of-objs)))
>             (jcall method fmtstring args)))
>
> JAVA-FORMAT
(Continue reading)

Jonathan P. Bona | 5 Apr 21:38 2012
Picon

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

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

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Jonathan P. Bona | 5 Apr 22:52 2012
Picon

[armedbear-devel] Bug in abcl/contrib/jss/invoke.lisp - trying to call JScheme's jsint.Invoke.poke, jsint.Invoke.pokeStatic

An issue in invoke.lisp (below): set-java-field calls the poke and
pokeStatic methods from jscheme's jsint.Invoke class. This should be
replaced, right?

;;; http://svn.common-lisp.net/armedbear/tags/1.0.1/abcl/contrib/jss/invoke.lisp
(defun set-java-field (object field value &optional (try-harder
*running-in-osgi*))
  (if try-harder
      (let* ((class (if (symbolp object)
			(setq object (find-java-class object))
		      (if (equal "java.lang.Class" (jclass-name (jobject-class object)) )
			  object
			(jobject-class object))))
	     (jfield (if (java-object-p field)
			 field
		       (find field (#"getDeclaredFields" class) :key 'jfield-name
:test 'equal))))
	(#"setAccessible" jfield t)
	(values (#"set" jfield object value) jfield))
    (if (symbolp object)
	(let ((class (find-java-class object)))
	  (#"pokeStatic" 'invoke class field value))
      (#"poke" 'invoke object field value))))

- Jonathan Bona
Mark Evenson | 6 Apr 09:46 2012
Picon

Re: [armedbear-devel] Calling java from lisp


On Apr 5, 2012, at 4:34 PM, Arnaud Bailly wrote:

> OK. I can see where my first error lies: jcall parameters are
> incorrect. Here is a corrected version:
> 
> (defun java-format (fmtstring &rest args)
>          (let* ((string-class (jclass "java.lang.String"))
>                 (array-of-objs (jclass "[Ljava.lang.Object;"))
>                 (method (jmethod string-class "format" string-class
> array-of-objs)))
>            (jcall method nil fmtstring args)))
> 
> But this does not work yet as I do not know how to convert a lisp list
> to a java array. IS there any utility function  or should I do it "by
> hand" ?
> 

JAVA:JNEW-ARRAY-FROM-LIST should be what you want.

--
"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."
Alessio Stalla | 6 Apr 09:54 2012
Picon

Re: [armedbear-devel] Cannot get abcl 1.0.1 working with slime

On Thu, Apr 5, 2012 at 3:14 PM, Stas Boukarev <stassats <at> gmail.com> wrote:
> Arnaud Bailly <arnaud.oqube <at> gmail.com> writes:
>
>> Hello,
>> I am trying to use ABCL 1.0.1 with slime under emacs and get the
>> following errors:
>>
>> (progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp"
>> :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall
>> (read-from-string "swank:start-server") "/tmp/slime.3985"
>> :coding-system "iso-latin-1-unix"))
>>
>> Armed Bear Common Lisp 1.0.1-svn-13750-13751
>> Java 1.6.0_26 Sun Microsystems Inc.
>> Java HotSpot(TM) 64-Bit Server VM
>> Low-level initialization completed in 0.297 seconds.
>> Startup completed in 0.935 seconds.
>> Type ":help" for a list of available commands.
>> CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ...
>> Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at
>> line 143 (offset 5611)
>> #<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of
>> type READER-ERROR
>>   The package "ASDF" can't be found.
>> Restarts:
>>   0: TOP-LEVEL Return to top level.
>> [1] SWANK-LOADER(2):
> The problem is caused by debian packaged slime, which, apparently, uses
> ASDF to load slime. Use slime from Quicklisp instead.

Also, be aware that java -jar overrides any other user-provided
classpath options, so the -cp switch is ignored.

Alessio
--

-- 
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework
Arnaud Bailly | 6 Apr 11:04 2012
Picon

Re: [armedbear-devel] Cannot get abcl 1.0.1 working with slime

you are of course right. Thanks for pointing it.

On Fri, Apr 6, 2012 at 9:54 AM, Alessio Stalla <alessiostalla <at> gmail.com> wrote:
> On Thu, Apr 5, 2012 at 3:14 PM, Stas Boukarev <stassats <at> gmail.com> wrote:
>> Arnaud Bailly <arnaud.oqube <at> gmail.com> writes:
>>
>>> Hello,
>>> I am trying to use ABCL 1.0.1 with slime under emacs and get the
>>> following errors:
>>>
>>> (progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp"
>>> :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall
>>> (read-from-string "swank:start-server") "/tmp/slime.3985"
>>> :coding-system "iso-latin-1-unix"))
>>>
>>> Armed Bear Common Lisp 1.0.1-svn-13750-13751
>>> Java 1.6.0_26 Sun Microsystems Inc.
>>> Java HotSpot(TM) 64-Bit Server VM
>>> Low-level initialization completed in 0.297 seconds.
>>> Startup completed in 0.935 seconds.
>>> Type ":help" for a list of available commands.
>>> CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ...
>>> Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at
>>> line 143 (offset 5611)
>>> #<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of
>>> type READER-ERROR
>>>   The package "ASDF" can't be found.
>>> Restarts:
>>>   0: TOP-LEVEL Return to top level.
>>> [1] SWANK-LOADER(2):
>> The problem is caused by debian packaged slime, which, apparently, uses
>> ASDF to load slime. Use slime from Quicklisp instead.
>
> Also, be aware that java -jar overrides any other user-provided
> classpath options, so the -cp switch is ignored.
>
> Alessio
> --
> Some gratuitous spam:
>
> http://ripple-project.org Ripple, social credit system
> http://villages.cc Villages.cc, Ripple-powered community economy
> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
> http://code.google.com/p/tapulli my current open source projects
> http://www.manydesigns.com/ ManyDesigns Portofino, open source
> model-driven Java web application framework
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel <at> common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Gmane