armedbear-ticket February 2013

armedbear-ticket@common-lisp.net

1 participants
28 discussions

[armedbear-ticket] [armedbear] #247: CFFI: $Proxy3 is not assignable to com.sun.jna.Pointer
by armedbear 03 Mar '13

03 Mar '13

#247: CFFI: $Proxy3 is not assignable to com.sun.jna.Pointer ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: cffi | ------------------------+--------------------------------------------------- Armed Bear Common Lisp 1.1.0-dev-svn-14181 Java 1.6.0_24 Sun Microsystems Inc. Remove ~/.cache/common-lisp/ to workaround ticket #246. {{{ (java:add-to-classpath "my-jna/jna.jar") (provide 'jna) (ql:quickload :drakma) ;; depends on CL+SSL (drakma:http-request "https://google.com/") WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated. WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated. WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated. WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated. #<THREAD "interpreter" {137E21A}>: Debugger invoked on condition of type TYPE-ERROR $Proxy3 is not assignable to com.sun.jna.Pointer Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/247> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #304: Stack abstraction inconsistency between Java and Lisp frames
by armedbear 01 Mar '13

01 Mar '13

#304: Stack abstraction inconsistency between Java and Lisp frames -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: needs-test | -------------------------+-------------------------------------------------- The stack abstraction maintained by LispThread.java can get very large, seemingly containing a frames that should long ago have been popped. I believe this is happening when we push "Java stack frames" via Lisp.pushJavaStackFrame() when some part of the implementation calls Lisp.error(). These frames are never cleaned up properly by an appropriate pop. Instead of pushing this information to the LispThread stack, the information could possibly be added to the appropriate Lisp frame to be output in a backtrace. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/304> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[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] #303: CL:LOAD ignores :EXTERNAL-FORMAT argument
by armedbear 26 Feb '13

26 Feb '13

#303: CL:LOAD ignores :EXTERNAL-FORMAT argument -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: | -------------------------+-------------------------------------------------- In [http://article.gmane.org/gmane.lisp.armedbear.devel/2774 Faré et. al.] point to failing tests within ASDF because CL:OPEN currently ignores a specified EXTERNAL-FORMAT. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/303> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #302: Symbols fail to autoload
by armedbear 25 Feb '13

25 Feb '13

#302: Symbols fail to autoload ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: other | Version: 1.2.0-dev Keywords: | ----------------------+----------------------------------------------------- In [http://article.gmane.org/gmane.lisp.armedbear.devel/2772 Xiaofeng Yang] reports that the following symbols are marked as autoloadable in the base system, yet fail to load. {{{ '("CLASS-DIRECT-SLOTS" "COMPUTE-CLASS-DIRECT-SLOTS" "MAKE-FORWARD- REFERENCED-CLASS" "%SET-STREAM-EXTERNAL-FORMAT" "%IMPORT" "%DELETE- PACKAGE")) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/302> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #301: Source locations should use a logical pathname
by armedbear 22 Feb '13

22 Feb '13

#301: Source locations should use a logical pathname ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: 1.2.0 Component: other | Version: 1.2.0-dev Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2764 On armedbear- develop] Xiaofeng Yang makes the reasonable request to not have the physical pathname recorded at build time in the symbol property lists. The first step to implement this would be to use the SYS:SRC logical pathname in the symbol plist, for which a value is already recorded in system.lisp at build time [source:trunk/abcl/src/org/armedbear/lisp /compile-system.lisp#L503 CREATE-SYSTEM-LOGICAL-PATHNAME]. At runtime, the user could override this value by setting the translation to a valid location. Using URL-PATHNAME we could possibly also fallback to a location available over the Internets. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/301> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #295: SWANK-BACKEND:SLIME-INSPECT assertion violation on symbol whose function is an Autoload object
by armedbear 18 Feb '13

18 Feb '13

#295: SWANK-BACKEND:SLIME-INSPECT assertion violation on symbol whose function is an Autoload object -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: autoload | -------------------------+-------------------------------------------------- Running swank:inspect-presentation on a symbol whose function is an Autoload object (like CL:MASK-FIELD) causes the following assertion to fail: {{{ ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:48) at org.armedbear.lisp.ArgumentListProcessor.match(ArgumentListProcessor.java:490) at org.armedbear.lisp.Closure.processArgs(Closure.java:230) at org.armedbear.lisp.pprint_145.execute(pprint.lisp:611) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:680) at org.armedbear.lisp.pprint_251.execute(pprint.lisp:1350) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.pprint_158.execute(pprint.lisp:763) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.LispThread.execute(LispThread.java:640) at org.armedbear.lisp.swank_abcl_80.execute(swank-abcl.lisp:654) at org.armedbear.lisp.clos_278.execute(clos.lisp:2585) at org.armedbear.lisp.clos_251.execute(clos.lisp:2249) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.LispThread.execute(LispThread.java:640) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/295> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[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] #296: SLIME fails to initialize with (SETF DOCUMENTATION) undefined
by armedbear 14 Feb '13

14 Feb '13

#296: SLIME fails to initialize with (SETF DOCUMENTATION) undefined -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: autoloader | -------------------------+-------------------------------------------------- A stock SLIME installation that attempts to load the asdf contrib will fail with a "(SETF DOCUMENTATION) undefined" error. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/296> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket February 2013