July 2010 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #35: ABCL.Net.dll -- Using IKVM-patch to make ABCL run on .NET and MONO
by armedbear 04 Oct '10

04 Oct '10

#35: ABCL.Net.dll -- Using IKVM-patch to make ABCL run on .NET and MONO -------------------------+-------------------------------------------------- Reporter: dmiles | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: 0.13 Component: component1 | Version: 1.0 Keywords: ikvm | -------------------------+-------------------------------------------------- HOWTO: First Patch the ABCL sources: [root@titan abcl]# patch -p0 < svn11486-ikvm.patch (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/Complex.java (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/IkvmSite.java (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/Lisp.java (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/Load.java (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/Nil.java (Stripping trailing CRs from patch.) patching file src/org/armedbear/lisp/Pathname.java Clean: [root@titan abcl]# rm -rf build dist Build ABCL: [root@titan abcl]#ant abcl.dist .... Download the latest binaries from http://ikvm.net I use the "stable" ones: 0.36.0.11 Unzip the binaries to a $ABCL_HOME/bin/ Update MON_PATH: export MONO_PATH=.:bin Build the ABCL.Net.dll and abcl.exe alias ikvmc='mono bin/ikvmc.exe ' [root@titan abcl]# ikvmc -compressresources -recurse:build/classes/ -out:ABCL.Net.dll Note IKVMC0003: automatically adding reference to "/development/mirrors /ABCL-SVN/trunk/abcl/bin/IKVM.OpenJDK.ClassLibrary.dll" [root@titan abcl]# ikvmc -r:ABCL.Net.dll -main:org.armedbear.lisp.Main -out:abcl.exe Note IKVMC0003: automatically adding reference to "bin/IKVM.OpenJDK.ClassLibrary.dll" Run it: [root@titan abcl]# mono abcl.exe Armed Bear Common Lisp 0.13.0-dev (built Fri Dec 26 2008 19:15:42 PST) Java 1.6.0 Jeroen Frijters IKVM.NET Low-level initialization completed in 0.159 seconds. Startup completed in 3.067 seconds. Type ":help" for a list of available commands. CL-USER(1): *FEATURES* (:IKVM :X86 :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL) I use the following .dll in a C# project at http://code.google.com/p/opensim4opencog/source/detail?r=28 Have fun.. how soon can we just have this patch applied to ABCL src? -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/35> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #100: Pathname #P reader does not reliably deserialize PATHNAMEs across Windows/non-Windows
by armedbear 04 Oct '10

04 Oct '10

#100: Pathname #P reader does not reliably deserialize PATHNAMEs across Windows /non-Windows -----------------------------+---------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: pathname reader | -----------------------------+---------------------------------------------- The #P reader does not work very well for a PATHNAME serialized under Windows/non-Windows, and de-serialized on the other platform. See discussion on thread http://article.gmane.org/gmane.lisp.armedbear.devel/1272 NB abcl-bin-0.20.0 needs to be re-released as it was compiled under Windows, giving errors of the form {{{ Compilation failed: Not an absolute pathname #P"\\___jar___file___root___\\**\\*.*" }}} under non-Windows. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/100> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #58: Lisp-side introspection into java classes
by armedbear 04 Oct '10

04 Oct '10

#58: Lisp-side introspection into java classes -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | -------------------------+-------------------------------------------------- It'd be nice if ABCL would provide Lisp-side introspection into Java classes. Including ABCL's own datastructures like Readtable, Mutex, etc. So it can be used in Slime. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/58> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #43: Interface for API users to hook into debugging output
by armedbear 04 Oct '10

04 Oct '10

#43: Interface for API users to hook into debugging output -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: debug | -------------------------+-------------------------------------------------- Currently, we don't have ways to hook into debugging information in ABCL from higher-up API users. It would be nice to be able to offer such interfaces, since it would definitely offer developers better ways to integrate ABCL into deployed apps. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/43> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #91: Initial values of special bindings on thread startup
by armedbear 04 Oct '10

04 Oct '10

#91: Initial values of special bindings on thread startup ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- We don't set any special variables upon thread startup. This may or may not (to be determined) be fine, however, libraries can't specify their own, nor do we allow users to specify values. CCL uses an :INITIAL-BINDINGS argument for its thread creation function. Note: How to handle threads which aren't started from Lisp, but instead just get 'associated' with Lisp? Those should probably create a set of default bindings. This situation occurs when a thread is created outside the new LispThread() interface, but currentThread() is called as part of the code running on it. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/91> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #19: SLIME from CVS HEAD needs 'with-mutex.lisp'
by armedbear 04 Oct '10

04 Oct '10

#19: SLIME from CVS HEAD needs 'with-mutex.lisp' ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: ehuselmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: Keywords: SLIME | ------------------------+--------------------------------------------------- SLIME from CVS HEAD fails to load with r11371, as it apparently needs with-mutex.lisp. The attached patch adds 'with-mutex.lisp' to the ABCL jar. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/19> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #59: Add extensible sequences to ABCL
by armedbear 04 Oct '10

04 Oct '10

#59: Add extensible sequences to ABCL ----------------------------------------------+----------------------------- Reporter: astalla | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: other | Version: Keywords: extensible sequences collections | ----------------------------------------------+----------------------------- Implement the protocol described in http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf to allow users to provide new types of sequences working with the standard Common Lisp sequences API. Use this protocol to make Java collections first-class in abcl. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/59> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW
by armedbear 04 Oct '10

04 Oct '10

#33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW ----------------------------------------------------------------------+----- Reporter: vvoutilainen | Owner: somebody Type: task | Status: new Priority: minor | Milestone: unscheduled Component: component1 | Version: 1.0 Keywords: exception ConditionThrowable go return throw performance | ----------------------------------------------------------------------+----- Douglas R. Miles reported recently that java.lang.Throwable.fillInStackTrace() can be a very time consuming operation when instantiating Throwables or objects the class of which extends Throwable. A patch for overriding the fillInStackTrace() function with an empty implementation was created, it seems to be a performance gain, but a benchmark is required. ANSI tests test so many other things that it's difficult to compare the impact of the patch without a test that tests only GO/RETURN/THROW. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/33> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #80: REQUIRE should work with ASDF
by armedbear 04 Oct '10

04 Oct '10

#80: REQUIRE should work with ASDF --------------------------+------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: enhancement | Status: new Priority: major | Milestone: unscheduled Component: libraries | Version: 1.0 Keywords: asdf require | --------------------------+------------------------------------------------- SBCL has the convention that if REQUIRE does not resolve on the filesystem, the argument is passed off to ASDF to resolve. It would be nice to include this in ABCL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/80> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #63: Attempt to GO to tag whose dynamic extent has ended exits ABCL
by armedbear 04 Oct '10

04 Oct '10

#63: Attempt to GO to tag whose dynamic extent has ended exits ABCL ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Reported by Brian Mastenbrook: When attempting to GO to a tag whose dynamic extent has ended, ABCL quits and prints the name of the exception used for internally handling GO (org.armedbear.lisp.Go). I see the same behavior in compiled or interpreted code. {{{ CL-USER(1): (lisp-implementation-version) "0.16.0" CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo) (funcall f)) org.armedbear.lisp.Go abcl-src-0.16.0 chandler$ }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/63> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #62: CLOS with &key arguments after &rest fails
by armedbear 04 Oct '10

04 Oct '10

#62: CLOS with &key arguments after &rest fails ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- The problem can be tested by attempting to load an ASDF system defintion as follows: (asdf:operate 'asdf:load-op :abcl :verbose t) which produces the error Invalid initarg :VERBOSE. but probably can be reduced to a simpler test case involving functions with &key arguments after &rest. Introduced in r12067 -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/62> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #61: Compilation of THE with macros
by armedbear 04 Oct '10

04 Oct '10

#61: Compilation of THE with macros ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- As reported in http://article.gmane.org/gmane.lisp.armedbear.devel/152 by Eric Marsden, the recent work on THE forms has broken the compilation of THE forms involving macros as follows: #| COMPILE-FILE for this file fails with [svn r12114]. |# (defconstant +foo-OK+ (the (integer 0 10) 5)) (deftype foo () '(integer 0 10)) (defmacro assemble-foo (x) `(the foo ,x)) (defconstant +foo+ (assemble-foo 6)) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/61> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #46: Compilation failure from several numeric arguments to MIN
by armedbear 04 Oct '10

04 Oct '10

#46: Compilation failure from several numeric arguments to MIN ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuselmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- After the recent (JAN/FEB) changes to the compiler to support numeric types more efficiently, the following code fails to compile: {{{ (defun fail () (min 1 2 3)) }}} with a Failed AVER: "NIL" arising out of COMPILE-FORMS-AND-MAYBE-EMIT- CLEAR_VALUES failing to parse its arguments correctly. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/46> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #21: Compilation failure from stack inconsistency
by armedbear 04 Oct '10

04 Oct '10

#21: Compilation failure from stack inconsistency ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: 1.0 Keywords: | ------------------------+--------------------------------------------------- #| Eric Marsden on armedbear-j-devel |# (defun foo () (flet ((bar () (unwind-protect 1 2))) (declare (inline bar)) (undefined (bar)))) #| ; Compiling /Users/evenson/work/abcl/bugs/stack-inconsistency.lisp ... Stack inconsistency at index 24: found 3, expected 1. ; Compilation unit finished ; The following functions were used but not defined: ; UNDEFINED |# -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/21> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #26: Multi-thread safety
by armedbear 04 Oct '10

04 Oct '10

#26: Multi-thread safety -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alex Mizhari writes: multithread safety -- while perhaps not thoroughly checked, most stuff behaves fine with multiple threads, at least i don't remember having problems with it. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/26> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #97: (apropos "MAKE-THREAD") prints MAKE-THREAD twice
by armedbear 01 Oct '10

01 Oct '10

#97: (apropos "MAKE-THREAD") prints MAKE-THREAD twice ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/97> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #88: Predicate to distinguish between functions implemented directly in Java vs. Lisp
by armedbear 01 Oct '10

01 Oct '10

#88: Predicate to distinguish between functions implemented directly in Java vs. Lisp -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: nobody Type: enhancement | Status: new Priority: minor | Milestone: Component: java | Version: Keywords: | -------------------------+-------------------------------------------------- For Slime, we need a predicate to distinguish between functions implemented in Java, and functions compiled from Lisp. The reason is because we use different mechanism to get at the definition: for Java functions, we'll use TAGS, whereas for Lisp functions we will use source-location information stored by the ABCL compiler. Compiled Lisp functions also end up to be of type Primitive, so just making the Primitive class available to Lisp won't cut it. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/88> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 8

[armedbear-ticket] [armedbear] #102: Wrapper scripts should honor CLASSPATH environment variables.
by armedbear 29 Aug '10

29 Aug '10

#102: Wrapper scripts should honor CLASSPATH environment variables. -------------------------------------------+-------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 0.21 Component: other | Version: 1.0 Keywords: wrapper envrionment classpath | -------------------------------------------+-------------------------------- If the UNIX shell script 'abcl', or the DOS batch script 'abcl.bat' are executed in an envrionment where there is a variable named 'CLASSPATH' set, at least add the entries on the classpath. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/102> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #103: DOCUMENTATION doesn't seem to autoload properly
by armedbear 28 Aug '10

28 Aug '10

#103: DOCUMENTATION doesn't seem to autoload properly --------------------------+------------------------------------------------- Reporter: vvoutilainen | Owner: nobody Type: defect | Status: new Priority: minor | Milestone: 0.22 Component: libraries | Version: 0.21 Keywords: autoload | --------------------------+------------------------------------------------- Here's a transcript from my repl session: CL-USER(1): (documentation 'append 'function) #<THREAD "interpreter" {9260EE}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function DOCUMENTATION is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to DOCUMENTATION. 3: TOP-LEVEL Return to top level. [1] CL-USER(2): (documentation 'append 'function) NIL DOCUMENTATION seems to load after the initial error, but if it's the first function invoked in the REPL, it doesn't seem to quite work. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/103> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2