armedbear-ticket March 2013

armedbear-ticket@common-lisp.net

1 participants
20 discussions

[armedbear-ticket] [armedbear] #309: Printer should obey package-local nicknames
by armedbear 08 Mar '13

08 Mar '13

#309: Printer should obey package-local nicknames -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: rschlatte Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | -----------------------+---------------------------------------------------- Currently, a symbol is printed with its home package name as package prefix. If the current package defines a local nickname for that package, the nickname should be printed instead. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/309> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #223: XP-STRUCTURE should be a proper subtype of STREAM
by armedbear 08 Mar '13

08 Mar '13

#223: XP-STRUCTURE should be a proper subtype of STREAM ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | ------------------------+--------------------------------------------------- An attempt has been made to create a proper "implementation super type of all streams" by making a "STREAM" structure (see boot.lisp). There's a design document. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/223> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #256: Compilation failure in com.informatimago
by armedbear 07 Mar '13

07 Mar '13

#256: Compilation failure in com.informatimago -------------------------------------------------------------+-------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: quicklisp com.informatimago.common-lisp.diagram | -------------------------------------------------------------+-------------- http://common-lisp.net/project/cl-test-grid/library/com.informatimago.html -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/256> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #274: (ql:quickload "com.informatimago.common-lisp.cesarum") hangs [> 10 minutes]
by armedbear 07 Mar '13

07 Mar '13

#274: (ql:quickload "com.informatimago.common-lisp.cesarum") hangs [> 10 minutes] ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | ------------------------+--------------------------------------------------- (ql:quickload "com.informatimago.common-lisp.cesarum") seems to hang forever. At least more that than 10 minutes. Was observed on abcl-1.1.0-dev-svn-14231-fasl39-linux-java, abcl-1.2.0-dev-svn-14270-fasl39-linux-x86. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/274> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #310: Invocation of tests from from build.xml broken
by armedbear 06 Mar '13

06 Mar '13

#310: Invocation of tests from from build.xml broken ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: build | Version: 1.2.0-dev Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2792 Rudi points out] that the invocation of tests from build.xml no longer works. Probably caused by ASDF no longer merging with *DEFAULT-PATHNAME-DEFAULTS* (i.e. the directory which "abcl.asd" is located in). Fix by pushing the directory containing "abcl.asd" to ASDF:*CENTRAL- REGISTRY*. Or better figured out the "new" programmatic way to do this without files on the filesystem. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/310> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #308: Hunchentoot fails redirection tests
by armedbear 04 Mar '13

04 Mar '13

#308: Hunchentoot fails redirection tests -----------------------------------+---------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: other | Version: 1.2.0-dev Keywords: quicklisp hunchentoot | -----------------------------------+---------------------------------------- The tests included with Hunchentoot as invoked by (asdf:test-system :hunchentoot) fail in the redirection test. If *print-pretty* is t, the test fails in the XP printer. If *print-pretty* is nil, the test fails with a stack overflow STORAGE- CONDITION. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/308> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[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] #306: Implement VARIABLE-INFORMATION
by armedbear 02 Mar '13

02 Mar '13

#306: Implement VARIABLE-INFORMATION -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: | -------------------------+-------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2788 James M. Lawrence asks for an implementation of VARIABLE-INFORMATION], namely "for a given environment I would like to know if a symbol is a lexical variable or a symbol macrolet." Description of VARIABLE-INFROMATION http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/306> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #305: Slow writing to binary streams
by armedbear 01 Mar '13

01 Mar '13

#305: Slow writing to binary streams -------------------------+-------------------------------------------------- Reporter: sboukarev | Owner: mevenson Type: enhancement | Status: new Priority: minor | Milestone: Component: streams | Version: Keywords: | -------------------------+-------------------------------------------------- Slow writing to binary streams {{{ (defun test () (with-open-file (stream "/dev/null" :direction :output :if-exists :overwrite :element-type '(unsigned-byte 8)) (time (loop repeat 10000000 do (write-byte 23 stream))))) }}} (test) 2.065 seconds real time 30000260 cons cells The problem boils down to write-byte doing (typep 23 '(unsigned-byte 8)), and typep calls normalize-type, which conses a new type each time: (list 'integer 0 (1- (expt 2 8))) http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/byte- io.lisp#L34 http://trac.common- lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/early- defuns.lisp#L155 Just changing that part to {{{ (UNSIGNED-BYTE (return-from normalize-type (if (or (null i) (eq (car i) '*)) '(integer 0 *) (case (car i) (8 '(integer 0 255)) (16 '(integer 0 65535)) (32 '(integer 0 4294967295)) (64 '(integer 0 18446744073709551615)) (t (list 'integer 0 (1- (expt 2 (car i))))))))) }}} gives (test) 1.682 seconds real time 45 cons cells But even better solution would be to assign efficient writing and reading routines to streams during a stream creation. When I change the body of write-byte to {{{ (defun write-byte (byte pstream) (declare (type stream stream)) (write-8-bits byte stream)) }}} I get (test) 0.521 seconds real time 12 cons cells And by extension this problem also affects TYPEP, (time (typep 23 '(unsigned-byte 8))) => 3 cons cells (time (typep #(a) '(simple-vector 2))) => 5 cons cells -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/305> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket March 2013