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

[cmucl-ticket] [cmucl] #76: REPLACE on strings incorrect
by cmucl 06 Mar '13

06 Mar '13

#76: REPLACE on strings incorrect --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-03 Keywords: | --------------------+------------------------------------------------------- Consider: {{{ (defun zot (workspace s) (declare (simple-string workspace s)) (replace workspace s :start1 1 :end1 5 :start2 1 :end2 5)) (defparameter *r* (make-string 40 :initial-element #\A)) (compile 'zot) (zot *r* "a12345") }}} After executing this, {{{*r*}}} should contain "A1234AAAA.." but it actually contains "a1234AAAA..". The {{{start1}}} and {{{start2}}} indices were not honored. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/76> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

Re: [cmucl-ticket] [cmucl] #74: utf-8 bug in compile-file
by cmucl 27 Feb '13

27 Feb '13

#74: utf-8 bug in compile-file -------------------------+-------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: Unicode | Version: 20d Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by toy.raymond@…): * status: new => closed * resolution: => fixed Comment: commit e8f64b3f83455a82edad394c472481fadde6ccb5 Author: Raymond Toy <toy.raymond(a)gmail.com> Date: Tue Feb 26 20:44:18 2013 -0800 Fix ticket:74 When accounting for the octets left in the in-buffer that we haven't read (or converted to characters), we were subtracting the index from the total in-buffer length. This is wrong if the file is less than the total in-buffer length. We should have subtracted from the actual number of octets in the in-buffer. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/74#comment:2> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 0

Re: [cmucl-ticket] [cmucl] #74: utf-8 bug in compile-file
by cmucl 27 Feb '13

27 Feb '13

#74: utf-8 bug in compile-file ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Unicode | Version: 20d Keywords: | ------------------------+--------------------------------------------------- Comment(by rtoy): Thanks for the detailed report. It appears to be a bug in file-position. Unicode buffering is quite messy so it will take a bit of time to work this out. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/74#comment:1> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 0

[cmucl-ticket] [cmucl] #73: Signal errors when modifying the standard readtable or standard pprint dispatch table
by cmucl 24 Feb '13

24 Feb '13

#73: Signal errors when modifying the standard readtable or standard pprint dispatch table --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-02 Keywords: | --------------------+------------------------------------------------------- Fare requested that errors be signaled when modifying the standard readtable and pprint dispatch table. Conforming programs are forbidden to modify them anyway. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/73> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

[cmucl-ticket] [cmucl] #72: SIGFPE with no exceptions currently enabled?
by cmucl 01 Feb '13

01 Feb '13

#72: SIGFPE with no exceptions currently enabled? --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-01 Keywords: | --------------------+------------------------------------------------------- While I've seen this SIGFPE issue before, I never tracked it down. Here is a repeatable case (from Carl): {{{ (defun test (x y) (declare (optimize (speed 3) (safety 0)) (type (signed-byte 32) x y)) (the (signed-byte 32) (truncate x y))) }}} Although the code lies to the compiler (the asserted return type of {{{truncate}}} is incorrect), the point is that {{{(test #x-80000000 -1)}}} causes the SIGFPE exception. I believe {{{sigfpe-handler}}} was only expecting to handle FP exceptions. In this example, the division causes an overflow which generates the SIGFPE. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/72> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

[cmucl-ticket] [cmucl] #65: Different results for {{{expt}}} between compiled and interpreted code
by cmucl 25 Jan '13

25 Jan '13

#65: Different results for {{{expt}}} between compiled and interpreted code --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2012-12 Keywords: | --------------------+------------------------------------------------------- Consider {{{ (defun sqr (x) (declare (type (complex double-float) x)) (expt x 2)) }}} Compare the results: {{{ * (sqr #c(0d0 1d0)) #C(-1d0 0d0) * (expt #c(0d0 1d0)) #C(-1.0d0 1.2246467991473532d-16) }}} The difference is caused by a deftransform for {{{expt}}} that converts {{{(expt x 2)}}} to {{{(* x x)}}}. Perhaps the {{{expt}}} should be modified to do the same transformation when the power is one of the special values in the deftransform? (The deftransform handles 2, 3, 4, and 1/2.) -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/65> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 4

[cmucl-ticket] [cmucl] #71: NOT-MORE-CONTAGIOUS broken for double-double-floats
by cmucl 25 Jan '13

25 Jan '13

#71: NOT-MORE-CONTAGIOUS broken for double-double-floats --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-01 Keywords: | --------------------+------------------------------------------------------- Here is an example of the brokenness: {{{ (defun foo (x) (declare (type double-float x)) (expt x 2w0)) (compile 'foo) (foo 2d0) Invalid number of arguments: 1 [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] }}} This is a bug in {{{NOT-MORE-CONTAGIOUS}}} returning the wrong value. The power should cause result of {{{EXPT}}} to be a double-double-float, but the the deftransform just converts the call to a multiplication of two double-floats. This mismatch of the actual type and the derived type confuses the compiler and causes the weird error. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/71> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

[cmucl-ticket] [cmucl] #70: Source location error with a logical pathname default
by cmucl 24 Jan '13

24 Jan '13

#70: Source location error with a logical pathname default --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-01 Keywords: | --------------------+------------------------------------------------------- When ticket:69 is fixed, the same code will then generated the following error: {{{ Parse error in namestring: Illegal character for logical pathname: #\/ /tmp/bar.lisp ^ [Condition of type LISP::NAMESTRING-PARSE-ERROR] Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (LISP::LOGICAL-CHUNKIFY "/tmp/foo.lisp" 0 13) Source: Error finding source: Parse error in namestring: Illegal character for logical pathname: #\/ target:code/pathname.lisp ^ 0] }}} The first error message is ok. The error about finding the source happens again because the source information is stored as a namestring which the debugger uses to open the source file. However, it's merged with the logical pathname in {{{*default-pathname-defaults*}}}, causing another error because the search-list namestring is treated as a logical pathname namestring. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/70> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

[cmucl-ticket] [cmucl] #69: Error parsing ext-formats:unidata.bin
by cmucl 17 Jan '13

17 Jan '13

#69: Error parsing ext-formats:unidata.bin --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2013-01 Keywords: | --------------------+------------------------------------------------------- Consider the following: {{{ (setf (logical-pathname-translations "foo") '(("**;*.*.*" "/tmp/**/*.*"))) (let ((*default-pathname-defaults* #p"foo:")) (pathname "/tmp/bar.lisp")) }}} This causes an error: {{{ Unable to display error condition: File-error in function LISP::FIND-LOGICAL-HOST: Logical host not yet defined: "EXT-FORMATS" [Condition of type LISP::NAMESTRING-PARSE-ERROR] }}} This happens because CMUCL wants to look up some unicode property and needs to load the unicode database from ext-formats:unidata.bin. Because we use a namestring, this gets merged with {{{*default-pathname- defaults*}}} and is incorrectly parsed as a logical pathname namestring. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/69> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1

[cmucl-ticket] [cmucl] #68: bit-bash-copy can't handle very large objects
by cmucl 23 Dec '12

23 Dec '12

#68: bit-bash-copy can't handle very large objects --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2012-12 Keywords: | --------------------+------------------------------------------------------- {{{BIT-BASH-COPY}}} takes bit indices as offsets for copying random objects. This is very useful if we're copying bit-arrays or arrays with elements smaller than a byte. However, when copying strings or arrays with elements larger than a byte, the bit index exceeds 32 bits when the index is near {{{MOST-POSITIVE-FIXNUM}}}. {{{BIT-BASH-COPY}}} needs to be updated to handle this, or a {{{BYTE-BASH- COPY}}} should be added to handle the case where the element size is at least a byte in size. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/68> cmucl <http://common-lisp.net/project/cmucl> Cmucl is a high-performance, free Common Lisp implementation.

1 1