armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

[armedbear-devel] Passing lisp objects from java to lisp
by Blake McBride 24 Jan '10

24 Jan '10

Greetings, If I have a lisp function as follows: (defun myfun (a b) (+ a b)) I want to be able to call it from lisp or java. In other words I don't want the lisp side to have to use jobject-lisp-value. Therefore, from the java side, how do I take a java object and translate into a lisp object so that when I call the execute method the lisp function doesn't need jobject-lisp-value? Thanks. Blake McBride

1 1

[armedbear-devel] trouble with Maxima test suite
by Robert Dodier 21 Jan '10

21 Jan '10

Hello, I have updated ABCL from svn and rebuilt it and updated Maxima and rebuilt it with ABCL. It seems to mostly work except that in a new instance of Maxima launched via (require 'asdf) (asdf:operate 'asdf:load-op :maxima) (run) I find that run_testsuite(); pretty soon runs into some errors and grinds to a halt at rtest14 (pretty early in the test suite). However I find that load(orthopoly); before run_testsuite(); seems to avoid the problem. I don't remember that this work-around was necessary in previous versions of ABCL; I probably last updated ABCL a couple of months ago. orthopoly is a Lisp package which is supposed to be loaded automatically when any of the functions in the package are called for the first time, e.g. $hermite has the 'autoload property. Another clue? When I enter quit(); after the unsuccessful run_testsuite(); I get a Java exception as follows. quit(); java.lang.IllegalStateException: Current state = CODING_END, new state = CODING at java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:951) at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:537) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:261) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:249) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:227) at org.armedbear.lisp.Stream._readChar(Stream.java:1683) at org.armedbear.lisp.Stream.readChar(Stream.java:1513) at org.armedbear.lisp.Stream$16.execute(Stream.java:2393) at org.armedbear.lisp.Symbol.execute(Symbol.java:798) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.mdebug_20.execute(mdebug.lisp:282) (etc ... I've suppressed the rest of the stack trace.) If you can suggest some additional info I could try to gather to aid debugging, I'll be glad to do so. Thanks for your help, and all your terrific work. Robert Dodier

2 2

[armedbear-devel] class-direct-subclasses has duplicates
by Alan Ruttenberg 18 Jan '10

18 Jan '10

It should be a set according to http://www.alu.org/mop/dictionary.html *Generic Function* *class-direct-subclasses* *class* Returns a set of the direct subclasses of *class*. The elements of this set are class metaobjects that all mention this class among their direct superclasses. The empty set is returned if *class* has no direct subclasses. This value is maintained by the generic functions *add-direct-subclass*<http://www.alu.org/mop/dictionary.html#add-direct-subclass> and *remove-direct-subclass*<http://www.alu.org/mop/dictionary.html#remove-direct-subclass> . (map nil 'print (system:class-direct-subclasses (find-class 'ido-pathway-block))) #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> -Alan

2 2

[armedbear-devel] patch for ensure-directories-exist
by Alan Ruttenberg 18 Jan '10

18 Jan '10

ensure-directories-exist fails when passed a logical pathname. (defun ensure-directories-exist (pathspec &key verbose) - (let ((pathname (pathname pathspec)) + (let ((pathname (translate-logical-pathname (pathname pathspec))) (created-p nil)) (when (wild-pathname-p pathname) ....

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.18.1 released
by Erik Huelsmann 18 Jan '10

18 Jan '10

> On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to > be able to announce the 0.18.0 release. Because of some regressions which had gone undetected during testing for the release, we have released ABCL 0.18.1. Anyone using 0.18.0 should consider updating to 0.18.1 because the .0 release may exhibit seemingly random behavior. In addition, some enhancements have been included which were developed on user request. Bye, Erik.

1 0

[armedbear-devel] resend [ANNOUNCE] ABCL 0.18.0 released
by Erik Huelsmann 15 Jan '10

15 Jan '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.18.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - faster initial startup, faster special variable lookup and portable fasl files. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.18.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip.asc This time with the correct url to the release notes. Bye, Erik.

3 2

[armedbear-devel] [ANNOUNCE] ABCL 0.18.0 released
by Erik Huelsmann 13 Jan '10

13 Jan '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.18.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - faster initial startup, faster special variable lookup and portable fasl files. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.17.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip.asc

1 0

[armedbear-devel] Folding Lisp application code into a JAR file in the Java CLASSPATH
by Olsen, Peter C. 13 Jan '10

13 Jan '10

Ladies and Gentlemen, Is there an elegant way to have ABCL load Lisp code from a JAR file in the Java CLASSPATH? I'm helping build an application to run under ABCL and I'd like to take all the code and roll it up into a JAR file in the CLASSPATH when I start the interpreter. If possible I'd then like to have ABCL find the file as though it were in the current directory. I know that ABLC is finding its system files in abcl.jar and I can load Lisp code from a local JAR file, but I haven't figured out how to put the two together and load Lisp elegantly from a JAR file in the CLASSPATH. I can do it inelegantly by getting the CLASSPATH from the Java System class, inspecting all its JAR files, then loading the right ones manually, but that seems awkward for a customer application. I'd appreciate any pointers. Finally, please let me apologize in advance if there's some simple answer that I should have found but haven't. Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Performance and cost must be considered as well as functionality. (RFC 1958)

3 5

[armedbear-devel] Fwd: [Bug] Identically named gensymed coalesced into same object in fasl file
by Erik Huelsmann 12 Jan '10

12 Jan '10

Sent the response below to Tobias privately by accident. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Mon, Jan 11, 2010 at 11:40 PM Subject: Re: [armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file To: "Tobias C. Rittweiler" <tcr(a)freebits.de> Hi Tobias, Thanks for your report. This issue has long been in ABCL and it's not fixed yet. I have known about this problem for a while, but was kind of hoping it wouldn't show up in practice. I guess it did. This is what happens: when reading, the fasl loader creates an anonymous package in which it interns uninterned symbols. It "has" to do that, because ABCL doesn't store references to the actual unique objects everywhere; instead it stores the textual representation in some places. These symbols get coalesced by use of the anonymous package. So, generally the system of coalescing is something inherent to this idea. The idea is wrong enough for you to run into and get bitten by it. We'll have to come up with a better idea. Can you add the mail message below to our issue tracker? BTW: Did you happen to find this issue by accident? How did you find it? Bye, Erik. On Mon, Jan 11, 2010 at 10:35 PM, Tobias C. Rittweiler <tcr(a)freebits.de> wrote: > > I'm currently running an old checkout ("0.17.0-dev"), so the issue may > have been fixed meanwhile. > > ### /tmp/foo.lisp > (eval-when (:load-toplevel :execute) > (let ((a '#:foo) > (b '#:foo)) > (setf (fdefinition 'foo) (lambda () (values a b))))) > > (eval-when (:load-toplevel :execute) > (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" > (multiple-value-call #'eq (foo)))) > ### > > CL-USER> (compile-file "/tmp/foo.lisp") > ; Compiling /tmp/foo.lisp ... > ; (LET (# #) ...) > ; (FORMAT T ...) > > ; Compilation unit finished > ; The following functions were used but not defined: > ; FOO > > ; Wrote /tmp/foo.abcl (0.034 seconds) > #P"/tmp/foo.abcl" > NIL > NIL > > That warning is bogus. There some work in this area so this bit may be > fixed already. > > The actual issue of my mail is this one, though: > > CL-USER> (load *) > (multiple-value-call #'eq (foo)) => T > T > > As you can see, ABCL coalesces the two identical named gensyms into the > same object in the fasl file. > > While 3.2.4.2.2 does specify that > > Two apparently uninterned symbols S and C are similar if their names > are similar. > > ABCL's behavior is still wrong because 3.2.4.1 says > > If two literal objects appearing in the source code for a single file > processed with the file compiler are the [sic] identical, the > corresponding objects in the compiled code must also be the > identical. __With the exception of symbols and packages__, any two > literal objects in code being processed by the file compiler may be > coalesced if and only if they are similar; __if they are either both > symbols or both packages, they may only be coalesced if and only if > they are identical__. > > -T. > > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >

2 1

[armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file
by Tobias C. Rittweiler 11 Jan '10

11 Jan '10

I'm currently running an old checkout ("0.17.0-dev"), so the issue may have been fixed meanwhile. ### /tmp/foo.lisp (eval-when (:load-toplevel :execute) (let ((a '#:foo) (b '#:foo)) (setf (fdefinition 'foo) (lambda () (values a b))))) (eval-when (:load-toplevel :execute) (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" (multiple-value-call #'eq (foo)))) ### CL-USER> (compile-file "/tmp/foo.lisp") ; Compiling /tmp/foo.lisp ... ; (LET (# #) ...) ; (FORMAT T ...) ; Compilation unit finished ; The following functions were used but not defined: ; FOO ; Wrote /tmp/foo.abcl (0.034 seconds) #P"/tmp/foo.abcl" NIL NIL That warning is bogus. There some work in this area so this bit may be fixed already. The actual issue of my mail is this one, though: CL-USER> (load *) (multiple-value-call #'eq (foo)) => T T As you can see, ABCL coalesces the two identical named gensyms into the same object in the fasl file. While 3.2.4.2.2 does specify that Two apparently uninterned symbols S and C are similar if their names are similar. ABCL's behavior is still wrong because 3.2.4.1 says If two literal objects appearing in the source code for a single file processed with the file compiler are the [sic] identical, the corresponding objects in the compiled code must also be the identical. __With the exception of symbols and packages__, any two literal objects in code being processed by the file compiler may be coalesced if and only if they are similar; __if they are either both symbols or both packages, they may only be coalesced if and only if they are identical__. -T.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel