armedbear-ticket December 2012

armedbear-ticket@common-lisp.net

1 participants
53 discussions

[armedbear-ticket] [armedbear] #282: Spurious macros redefinition warnings
by armedbear 26 Feb '13

26 Feb '13

#282: Spurious macros redefinition warnings -----------------------+---------------------------------------------------- Reporter: sboukarev | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | -----------------------+---------------------------------------------------- Compiling and loading a file with {{{ (defmacro foo ()) }}} {{{ CL-USER(1): (compile-file "foo") #P"/tmp/foo.abcl" NIL NIL CL-USER(2): (load *) STYLE-WARNING: redefining COMMON-LISP-USER::FOO in #P"/tmp/foo.lisp" (previously defined in #P"/tmp/foo.lisp") T }}} But it's the same file, turns out, the old source is different because it has :host :unspecific. The place where it does comparison http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/fdefinition.li… And where it sets *source* http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/compile- file.lisp#L723 So, it does TRUENAME. truename sets :unspecific on non-windows platforms for pathname-host. http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/Pathname.java#… And the compiler saves the source patname as just (setq *source* #"path"), so :unspecific is lost when read: http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/compile- file.lisp#L685 -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/282> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #152: ql:closer-mop doesn't work
by armedbear 14 Feb '13

14 Feb '13

#152: ql:closer-mop doesn't work --------------------------------+------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 0.26 Component: CLOS | Version: 1.0 Keywords: clos quicklisp mop | --------------------------------+------------------------------------------- [http://common-lisp.net/project/closer/closer-mop.html CLOSER-MOP] fails to load via [http://quicklisp.org QuickLisp]. As part of resolving this ticket, it would be nice to produce a summary of what is incomplete in ABCL wrt. MOP. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/152> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 16

[armedbear-ticket] [armedbear] #228: Need to implement autoloader facility for SETF functions
by armedbear 14 Feb '13

14 Feb '13

#228: Need to implement autoloader facility for SETF functions -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: enhancement | Status: new Priority: major | Milestone: 1.2.0 Component: java | Version: Keywords: | -------------------------+-------------------------------------------------- The subject says it all: we currently have infrastructure for normal functions, but we need infrastructure for SETF functions as well. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/228> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #266: PSETF.47 ANSI regression
by armedbear 14 Feb '13

14 Feb '13

#266: PSETF.47 ANSI regression -----------------------------+---------------------------------------------- Reporter: mevenson | Owner: nobody Type: defect | Status: new Priority: blocker | Milestone: 1.1.0 Component: java | Version: 1.1.0-dev Keywords: ansi-regression | -----------------------------+---------------------------------------------- According to a bisect caused by http://trac.common- lisp.net/armedbear/changeset/14035, but this looks wrong as r14035 merely adds an additional REQUIRE to format.lisp. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/266> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #212: ABCL crash when running test suites of many libraryies
by armedbear 13 Feb '13

13 Feb '13

#212: ABCL crash when running test suites of many libraryies ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=aitoawmcq6mzgezjmpqv2tjhvs6isymf6t… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: 1.0.1 Keywords: | ----------------------------------------------------------------------------------------------+ I encountered crash of ABCL 1.0.1 when running tests of many libraries. (Some work may be done to isolate the problem by experimenting with the set of libraries used, but I didn't find time for this during the last 2 month, so decided to just submit an exact way to reproduce the bug). I supposed it may be a memory issue, and increased memory by JVM options (as shown below), but it doesn't help. To ensure the problem is reproducible I've created a branch of my project and create a script which load particular version of quicklisp (quicklisp is bootstrapped in local directory to avoid interference with the quickips installation user may have on his computer). The steps to reproduce: git clone git://github.com/cl-test-grid/cl-test-grid.git cd cl-test-grid git checkout abcl-crash-reproduce java -Xmx2048M -XX:ThreadStackSize=12048 -XX:MaxPermSize=256m -jar C:\Users\anton\unpacked\abcl\abcl-bin-1.0.1\abcl.jar --noinit --nosystem --batch --load crash-abcl.lisp > crash-abcl.log 2>&1 [ ... lot of output, and after ~20 mins ABCL crashed ] crash-abcl.log is attached. The stacktrace of interest is at the bottom. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/212> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 10

[armedbear-ticket] [armedbear] #278: closer-mop:class-finalized-p returns t without ever running finalize-inheritance method
by armedbear 02 Jan '13

02 Jan '13

#278: closer-mop:class-finalized-p returns t without ever running finalize- inheritance method ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.1 Component: (A)MOP | Version: Keywords: | ------------------------+--------------------------------------------------- Report by stassats on IRC. He's drawing up a testcase as we speak. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/278> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #279: default-initargs not respected for funcallable-standard-class
by armedbear 31 Dec '12

31 Dec '12

#279: default-initargs not respected for funcallable-standard-class -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: rschlatte Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | -----------------------+---------------------------------------------------- Report by Pascal Costanza: Here is a test case: {{{ CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-method (standard-method) ()) #<STANDARD-CLASS MY-METHOD {1EE9DE5F}> CL-USER(3): (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class) (:default-initargs :method-class (find-class 'my-method))) #<FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION {6E06D676}> CL-USER(4): (defgeneric my-function () (:generic-function-class my-generic-function)) #<MY-GENERIC-FUNCTION MY-FUNCTION {2EA1569}> CL-USER(5): (generic-function-method-class #'my-function) #<STANDARD-CLASS STANDARD-METHOD {4E513D61}> }}} The reason is that the defaulting happens in the keyword arguments for ensure-generic-function (in clos.lisp), which thus overrides any default initargs. However, the defaulting should be left to the class. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/279> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #280: Additional slots in function classes screw up std-compute-discriminating-function
by armedbear 23 Dec '12

23 Dec '12

#280: Additional slots in function classes screw up std-compute-discriminating- function -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: rschlatte Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | -----------------------+---------------------------------------------------- Report by Pascal Costanza Here is a test case: {{{ CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-function (standard-generic-function) ((a-slot :initarg :a-slot :accessor a-slot)) (:metaclass funcallable-standard-class)) #<FUNCALLABLE-STANDARD-CLASS MY-FUNCTION {24DF7EA4}> CL-USER(3): (defgeneric test (x y z) (:generic-function-class my-function)) #<THREAD "interpreter" {14BAAEA8}>: Debugger invoked on condition of type TYPE-ERROR The value TEST is not of type LIST. }}} The reason is that std-compute-discriminating-function is also called for subclasses of standard-generic-function that don't override compute- discriminating function. The specialization in std-compute-discriminating- function should only occur if the passed function is _extactly_ a standard-generic-function (or if it doesn't add any slots on top of standard-generic-function). By the way, we're getting closer (ha!). More and more test cases in my test suites work. I'm pretty confident that I can add full support for ABCL in Closer to MOP for the next version of ABCL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/280> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #283: (pathname-host (open #p"/dev/null")) => NIL
by armedbear 20 Dec '12

20 Dec '12

#283: (pathname-host (open #p"/dev/null")) => NIL ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/283> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #281: cancel-finalization on an non-finalized object causes null pointer exception
by armedbear 19 Dec '12

19 Dec '12

#281: cancel-finalization on an non-finalized object causes null pointer exception -----------------------+---------------------------------------------------- Reporter: sboukarev | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | -----------------------+---------------------------------------------------- (ext:cancel-finalization 1) {{{ java.lang.NullPointerException at org.armedbear.lisp.util.Finalizer.clearFinalizers(Finalizer.java:165) at org.armedbear.lisp.Primitives$pf_cancel_finalization.execute(Primitives.java:5851) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/281> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket December 2012