armedbear-ticket

armedbear-ticket@common-lisp.net

633 discussions

[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

[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

← Newer
1
...
27
28
29
30
31
32
33
...
64
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket