- cmucl-ticket - mailman3.common-lisp.net

[cmucl-ticket] [cmucl] #42: read-sequence vs unicode
by cmucl 22 Oct '10

22 Oct '10

#42: read-sequence vs unicode --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 20b Keywords: | --------------------+------------------------------------------------------- Cmucl has been able to use {{{READ-SEQUENCE}}} to read octets (and other integers types) from character streams. With the introduction of Unicode support, this no longer works correctly in general. The data that is read is not done from the last position, and the data that is read is not necessarily reflected in the next {{{READ-CHAR}}}. That is, {{{READ- CHAR}}} might re-read the data that {{{READ-SEQUENCE}}} already read. (This depends on how much data has been read, and the internal stream buffering.) However, if the external format is :iso8859-1, then {{{READ-SEQUENCE}}} behaves as it used to. Hence, as a workaround, the user can set the external format to :iso8859-1 before {{{READ-SEQUENCE}}} and set it back afterwards. This works as expected. Perhaps {{{READ-SEQUENCE}}} should do that itself? (Appropriately wrapping everything in {{{UNWIND-PROTECT}}} so that the stream external format isn't unexpected modified.) -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/42> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 2

[cmucl-ticket] [cmucl] #41: empty unwind-protect
by cmucl 15 Aug '10

15 Aug '10

#41: empty unwind-protect -------------------------+-------------------------------------------------- Reporter: heller | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: Core | Version: 20a Keywords: | -------------------------+-------------------------------------------------- For simple code like: {{{ (defun foo () (unwind-protect nil)) }}} the compiler produces awful lots of code. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/41> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #36: file-position broken for utf16 and utf32
by cmucl 15 Aug '10

15 Aug '10

#36: file-position broken for utf16 and utf32 --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19f Keywords: | --------------------+------------------------------------------------------- Consider this code: {{{ (defun bug (&optional (format :utf16)) (with-open-file (s "/tmp/bom.txt" :direction :output :if-exists :supersede :external-format format) (format s "Hello~%")) (with-open-file (s "/tmp/bom.txt" :direction :input :external-format format) (print (read-char s)) (print (file-position s))) (values)) }}} Running {{{(bug :utf16)}}} produces {{{ #\H 2 }}} {{{(bug :utf32)}}} produces {{{ #\H 4 }}} In both cases, the actual position is wrong. For utf16, the position should 4; utf32, 8. The BOM has been ignored. This is caused by {{{STRING-ENCODE}}} outputting the BOM for these formats. {{{STRING-ENCODE)}}} is used to figure out how many octets have not yet been processed but have been read from the file. If the BOM was not output, the position would be correct. This bug (will) occur in the 2010-02 snapshot and later. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/36> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 4

[cmucl-ticket] [cmucl] #40: incorrect lexical environment for deftype
by cmucl 01 Jun '10

01 Jun '10

#40: incorrect lexical environment for deftype --------------------+------------------------------------------------------- Reporter: heller | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 20a Keywords: | --------------------+------------------------------------------------------- When compiling this: {{{ (macrolet ((foo () `'fixnum)) (deftype footype () (foo))) (defun bar (x) (etypecase x (footype (logand x 255)))) }}} CMUCL complains that: {{{ Error in kernel:%coerce-to-function: the function foo is undefined. [Condition of type undefined-function] }}} -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/40> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #39: non-standard lexical syntax
by cmucl 19 Apr '10

19 Apr '10

#39: non-standard lexical syntax --------------------+------------------------------------------------------- Reporter: heller | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2010-04 Keywords: | --------------------+------------------------------------------------------- When I first heard about the i18n stuff, piglatin, and Google translated Korean I thought this was an April Fool's joke. But apparently it's serious. Now I get this: {{{ CMU Common Lisp Snapshot 2010-04 (20A Unicode), running on ix * '(_"x") ((INTL:GETTEXT "x")) * }}} Can you please fix the initial readtable so that it's free of such silliness? I'm also disappointed that this (mis)feature was added in such an intrusive way: essentially every file was changed and is now riddled with non standard reader macros. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/39> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 2

[cmucl-ticket] [cmucl] #38: Inlining loses declarations
by cmucl 22 Mar '10

22 Mar '10

#38: Inlining loses declarations --------------------+------------------------------------------------------- Reporter: heller | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 20a Keywords: | --------------------+------------------------------------------------------- I'd like to write a function fx+ which is like + but only accepts fixnums as arguments and never conses, i.e. it's considered an error if the sum is not a fixnum. Arguments and return value should be checked. Essentially this {{{ (declaim (inline fx+)) (defun fx+ (x y) (declare (fixnum x y) (values fixnum)) (+ x y)) }}} is what I want. If called as (fx+ 1 most-positive-fixnum) the error is detected as it should be. But after inlining {{{ (defun foo (x y) (fx+ x y)) }}} and using it like (foo 1 most-positive-fixnum) it returns -536870912. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/38> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #37: Debugger misses some variables
by cmucl 28 Feb '10

28 Feb '10

#37: Debugger misses some variables -------------------------+-------------------------------------------------- Reporter: heller | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: Core | Version: 2010-02 Keywords: | -------------------------+-------------------------------------------------- Evaluating code like this: {{{ (progn (defun foo (x) (flet ((bar () (break "x=~s" x) (print x))) #'bar)) (compile 'foo) (funcall (foo '(1 2 3)))) }}} brings up the debugger: {{{ x=(1 2 3) [Condition of type simple-condition] Restarts: 0: [continue] Return from BREAK. 1: [abort ] Return to Top-Level. }}} But list-locals doesn't show anything: {{{ 0] list-locals All variables currently have invalid values. 0] }}} That's odd, since at that point the variable x is still needed by print and so the debugger should be able to display it. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/37> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 0

Re: [cmucl-ticket] [cmucl] #22: sun4_solaris_sunc config uses gcc to build motif
by cmucl 02 Feb '10

02 Feb '10

#22: sun4_solaris_sunc config uses gcc to build motif ----------------------+----------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: closed Priority: trivial | Milestone: Component: Core | Version: 2008-09 Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Changes (by rtoy): * status: new => closed * resolution: => fixed Comment: Fixed. Available in 2010-03. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/22#comment:1> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 0

[cmucl-ticket] [cmucl] #35: test
by cmucl 01 Oct '09

01 Oct '09

#35: test --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19f Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: <http://common-lisp.net:8000/cmucl/ticket/35> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #33: get-dispatch-macro-character doesn't signal errors in compiled code
by cmucl 28 Sep '09

28 Sep '09

#33: get-dispatch-macro-character doesn't signal errors in compiled code --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19f Keywords: | --------------------+------------------------------------------------------- This example is from the clisp mailing list {{{ * (defun dispatch-macro-char-p (char rt) (handler-case (prog1 t (get-dispatch-macro-character char #\x rt)) (error () nil))) DISPATCH-MACRO-CHAR-P * (dispatch-macro-char-p #\$ (copy-readtable nil)) NIL * (compile 'dispatch-macro-char-p) DISPATCH-MACRO-CHAR-P NIL NIL * (dispatch-macro-char-p #\$ (copy-readtable nil)) T }}} I think this is because {{{get-dispatch-macro-character}}} is declared to be flushable. I think that's wrong since {{{get-dispatch-macro-character}}} is supposed to signal errors. -- Ticket URL: <http://127.0.0.1:8000/cmucl/ticket/33> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1