December 2009 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #65: UTF-32 strings support
by armedbear 11 Mar '13

11 Mar '13

#65: UTF-32 strings support ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- ABCL uses Java char[]s to represent its strings. However, the char type can only represent values in the BMP (Basic Multilingual Plane), because only the BMP can be represented using 16 bits. For supplementary characters (all Unicode chars outside the BMP), it uses a pair of surrogate characters (UTF-16). Common Lisp programs don't expect this and need strings to be represented using complete characters. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/65> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #73: "normalize-type" buffering
by armedbear 08 Aug '12

08 Aug '12

#73: "normalize-type" buffering -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: task | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: performance | -------------------------+-------------------------------------------------- Peter Graves points out that with his "canonicalize-type" buffering, he achieved measurable performance gain in XCL. We want to do the same in ABCL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/73> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #60: Implement USE-FAST-CALLS properly
by armedbear 29 Jul '12

29 Jul '12

#60: Implement USE-FAST-CALLS properly -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- USE-FAST-CALLS is implemented at the moment by flipping an essentially global variable. The proper implementation would be to make turn it into a ABCL-specific declaration, and making sure it affects its lexically enclosing code only. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/60> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #32: Modify the currently disabled runtime-class.lisp code to not require ASM
by armedbear 28 Jul '12

28 Jul '12

#32: Modify the currently disabled runtime-class.lisp code to not require ASM --------------------------------------------------------------------+------- Reporter: vvoutilainen | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: jvm bytecode compiler runtime dynamic class generation | --------------------------------------------------------------------+------- It's possible to define classes at runtime, by generating bytecode and loading it from the generated binary data, without ever writing it to a temporary file. runtime-class.lisp does that, but it requires an external bytecode library (ASM). ABCL has all the functionality for this to be done without ASM, so the task is to modify the runtime-class.lisp code so that ASM is no longer required and the code can be taken to be part of the build. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/32> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #55: Clearing LispThread.currentThread()._values more efficiently
by armedbear 28 Jul '12

28 Jul '12

#55: Clearing LispThread.currentThread()._values more efficiently -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- We currently clear _values all over the place; we could be more efficient some times. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/55> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 8

[armedbear-ticket] [armedbear] #34: adjust generated '*.cls' filenames
by armedbear 14 Jul '12

14 Jul '12

#34: adjust generated '*.cls' filenames ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- dmiles: it be nice to eventually name the coerce-666.cls coerce_666.cls as the same name of the way classpaths think about them (they'd continue to work).. one argument agaist is our autoloader at least gets a better whack at finding them in the right context apart from classloader -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/34> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #74: slow compilation test
by armedbear 06 May '12

06 May '12

#74: slow compilation test -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | -------------------------+-------------------------------------------------- (eval-when (:compile-toplevel :load-toplevel :execute) (defclass foo () ())) (defun quux (x) (case x (#. (find-class 'foo) :foo) (t :quux))) (flet ((test (x) (format t "~&(QUUX ~S) => ~S~%" x (quux x)))) (test 42) (test (find-class 'foo))) COMPILE-FILE'ing that takes over a second. No real life case, of course, still you may be interested. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/74> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #30: Lisp debugger, for both compiled and interpreted code
by armedbear 18 Nov '11

18 Nov '11

#30: Lisp debugger, for both compiled and interpreted code ----------------------------+----------------------------------------------- Reporter: vvoutilainen | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: Keywords: debug debugger | ----------------------------+----------------------------------------------- ABCL code can be debugged with normal java debuggers, but it is somewhat painful for the portions implemented in lisp(1). So we need a lisp debugger. (1) It's possible, although a bit tedious, to step through eval calls in a java debugger by examining the cars and cdrs of eval parameters when stepping the code. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/30> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #66: Support for DEFINE-METHOD-COMBINATION (long form)
by armedbear 11 Sep '11

11 Sep '11

#66: Support for DEFINE-METHOD-COMBINATION (long form) ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- ABCL does not support D-M-C. It should. Patches welcome. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/66> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 15

[armedbear-ticket] [armedbear] #56: Eliminate use of temporary files in COMPILE and COMPILE-FILE
by armedbear 02 Aug '11

02 Aug '11

#56: Eliminate use of temporary files in COMPILE and COMPILE-FILE -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- The functions COMPILE and COMPILE-FILE use temporary files for the class files generated by the compiler. However, COMPILE directly loads them back into memory and deletes the temp file, while COMPILE-FILE deletes the temp file after adding it to a ZIP archive. This ticket exists to indicate that infrastructure is required to better manage where output goes to, abstracting from the temp files. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/56> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #69: Gray stream compatibility
by armedbear 28 Apr '11

28 Apr '11

#69: Gray stream compatibility ---------------------------+------------------------------------------------ Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: compatibility | ---------------------------+------------------------------------------------ The last thing holding us back from being fully Gray stream compatible, is that TYPEP should return T for any fundamental-stream derived instance when tested against 'STREAM or (find-class 'STREAM). -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/69> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #67: initarg checking performance
by armedbear 13 Feb '11

13 Feb '11

#67: initarg checking performance -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: performance | -------------------------+-------------------------------------------------- Our initarg checking strictness has improved (used to be non-existent), but we've seen a rather large performance hit, amongst other things upon object instantiation (make-instance). Functions involved (?): ALLOCATE-INSTANCE INITIALIZE-INSTANCE REINITIALIZE-INSTANCE SHARED-INITIALIZE UPDATE-INSTANCE-FOR-DIFFERENT-CLASS UPDATE-INSTANCE-FOR-REDEFINED-CLASS -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/67> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #18: Incorporate 'invoke.lisp' dynamic classpath ability
by armedbear 23 Jan '11

23 Jan '11

#18: Incorporate 'invoke.lisp' dynamic classpath ability -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg's [invoke.lisp][1] has the ability to easily add additional Java JARs at runtime by using the [beanshell classloader][2]. With a few additions to the ASDF system, this allows one to easily specify "wrappings" of Java components which load JARs or find classfiles on the filesystem. The code in the Beanshell classmanager could be added to the ABCL src tree fairly easily to facilitate this behavior. [1]: http://svn.mumble.net:8080/svn/lsw/trunk/jss/invoke.lisp [2]: http://www.beanshell.org/home.html -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/18> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #51: Implement debugger option to retry/return from stack frame
by armedbear 04 Oct '10

04 Oct '10

#51: Implement debugger option to retry/return from stack frame -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | -------------------------+-------------------------------------------------- It would be very valuable to be able to retry a stack frame after changing some of the local variables / function arguments in it. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/51> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #57: Eliminate the use of writeToString for condition creation
by armedbear 04 Oct '10

04 Oct '10

#57: Eliminate the use of writeToString for condition creation ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- Due to the fact that the object being written may be recursive, we need to bind *print-level* and *print-circle* before writing objects to error strings. Possibly, these instances can be replaced by a format string and format arguments. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/57> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #24: Ability to load ASDF systems off JAR files in the classpath
by armedbear 04 Oct '10

04 Oct '10

#24: Ability to load ASDF systems off JAR files in the classpath -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg writes: I'd really like the ability to pop an asdf central registry directory into the abcl jar and have abcl be able to asdf load from there. Would really simplify packaging apps based on abcl. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/24> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #68: Extend Load.java to allow loading FASLs from arbitrary streams
by armedbear 04 Oct '10

04 Oct '10

#68: Extend Load.java to allow loading FASLs from arbitrary streams -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: enhancement | Status: new Priority: major | Milestone: 0.18 Component: libraries | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, Load.java inspects a file to find whether or not this file is a ZIP file. From there, it decides on a strategy to continue loading the file. However, in many circumstances in Java one has a stream of unknown origin. It's a requirement for good Java integration to be able to load FASLs off arbitrary streams (resource streams, e.g.). -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/68> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #29: Support loading system files off other paths (in a JAR) than the default one
by armedbear 04 Oct '10

04 Oct '10

#29: Support loading system files off other paths (in a JAR) than the default one -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg writes: In order to enable easy packaging of a system into a jar file, one that might even be usable as an applet, a small change is needed. Currently load-system-file can read an .abcl compiled file set from the abcl jar. Actually, it doesn't load the .abcl directly. That file is a zip file with a "top level" file with a "._" extension and a bunch of .cls files. The unpacked contents of these files live in the abcl jar, with the "._" file renamed to have the extension ".abcl". The loading happens by first loading the "._" file, a file of lisp forms, which when evaluated, in turn calls load-compiled-function on each of the component .cls files (plus does some other stuff). All of these files live in a single directory in the jar file: org/armedbear/ lisp/ I'd like to be able to load from a subdirectory of that, in which I would put my files. I can tell load-system-file to load the initial abcl file from the subdirectory, say, org/armedbear/lisp/util/, but then load-compiled-function wants to load the components from org/ armedbear/lisp. So the small change is to set *load-truename* in load- system-file, based on the supplied path, and then to use it as the pathname defaults when executing the call to load-compiled-function. It seems to do this for the case where it loads from the regular file system, but not when working with the jar file. Once this change is in place, to package up a system, one would unjar abcl.jar, move one's compiled files in to a subdirectory of org/ armedbear/lisp, unzip all of them, rename *._ to *.abcl, and jar them back up. One could them load a file from the jar with: (sys:load-system-file "mydir/foo.abcl") loadCompiledFunction is defined in Lisp.java and loadSystemFile in Load.java -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/29> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[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] #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] #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] #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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket December 2009