armedbear-ticket June 2009

armedbear-ticket@common-lisp.net

1 participants
26 discussions

[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] #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] #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] #38: CLOS :metaclass support
by armedbear 07 May '10

07 May '10

#38: CLOS :metaclass support ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Blake McBride reports: Running the code: (defclass meta-class1 (standard-class) (cv1 cv2 cv3) (:metaclass standard-class)) (defclass class1 (standard-object) (iv1 iv2 iv3) (:metaclass meta-class1)) The second object returns: #<STANDARD-CLASS CLASS1 {F673CC}> It should be: #<META-CLASS1 CLASS1 {F673CC}> Not only is it reporting the wrong class of class1 but it doesn't work either. I suppose ABCL doesn't support the :metaclass option. It just ignores it. The problem is that without that option ABCL's CLOS is severely limited. Any plans to fix this? Thanks. Blake McBride -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/38> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 10

[armedbear-ticket] [armedbear] #45: Support for passing unboxed arguments to local functions
by armedbear 15 Mar '10

15 Mar '10

#45: Support for passing unboxed arguments to local functions -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- It would save a great deal of boxing/unboxing, if local functions and self-calling recursive functions could pass and return unboxed values. Although passing unboxed values from the outside world is generally considered 'dependency on implementation details', recursive calls and calls to local functions should be able to depend on this: they get recompiled upon function redefinition anyway. One of the reasons for this ticket: with the improved type-derivations in Jan/Feb 2009, the cl-bench TAK test deteriorated: more boxing was performed. With this change, the (un)boxing can be eliminated, except for the first call (from the outside world). -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/45> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket June 2009