cmucl-ticket

cmucl-ticket@common-lisp.net

97 discussions

[cmucl-ticket] #9: parse-time mishandles invalid number of days in a month
by cmucl 02 May '07

02 May '07

#9: parse-time mishandles invalid number of days in a month --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- {{{ (format-universal-time t (parse-time "Feb 31 2000")) -> Thursday, 3/2/00 12:00:00 am EST }}} {{{parse-time}}} doesn't check to see if the day number makes sense for the given month. If this is fixed, don't forget that the number of days in February depends on if it's a leap year or not. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/9> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #8: 2-arg log function can't compute some logs
by cmucl 19 Jan '07

19 Jan '07

#8: 2-arg log function can't compute some logs ------------------------------------+--------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19c Keywords: log, special functions | ------------------------------------+--------------------------------------- Consider the following snip of code. CMUCL should really be able to compute all of these. CMUCL fails mostly because it cannot convert some bignum to a double-float. {{{ (defun test-log () (dolist (base (list nil 2 2.0 2d0 (ash 1 99) (ash 1 3000) 8/7 (/ (ash 1 3000) 7))) (dolist (number (list 100 100.0 100d0 (ash 1 100) (ash 1 3500) 50/7 (/ (ash 1 3500) 7))) (multiple-value-bind (result cond) (ignore-errors (if base (log number base) (log number))) (unless result (format t "(log ~A ~A) ->~% ~S~%" number base cond)))))) }}} -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/8> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #7: Bug in read-vector
by cmucl 21 Aug '06

21 Aug '06

#7: Bug in read-vector -------------------------+-------------------------------------------------- Reporter: jcunningham | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19c Keywords: read-vector | -------------------------+-------------------------------------------------- I have been trying to read large binary files of floating point data using CMUCL (19c). I thought I would have to do it using some form of FFI and went to comp.lang.lisp for help getting that working. I succeeded. But Duane Rettig at Allegro suggested it would be easier to use 'read-vector. So I tried that as follows: (let ((vec (make-array 10 :element-type 'double-float))) (with-open-file (os "d10.bin") (read-vector vec os) (print vec))) where "d10.bin" is a double-float binary file containing 10 elements. When I try to read the file it produces the following error: Type-error in KERNEL::OBJECT-NOT-DOUBLE-FLOAT-ERROR-HANDLER: #\Null is not of type DOUBLE-FLOAT Here is the C-code code I used to produce the file: #include <iostream> #include <fstream> #include <complex> using namespace std; int main() { int n=10; double *d = new double[n]; for (int i=0; i<n; i++) d[i] = i; FILE *of = fopen("d10.bin", "wb"); fwrite(f,8,n,of); fclose(of); return 0; } Here is Duane's sample code that he says works in Allegro along with comments: (copied from <http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/67876101…>) ................................................................... "You must be using a simple-streams implementation from another lisp. Allegro CL doesn't have a KERNEL package. What you're seeing above is a bug; you should report it to that lisp's support team. It works fine in Allegro CL (for which you can download the Express Edition for free): [edited formating for readability on Trac - jkc] (defvar *x* (make-array 10 :element-type 'double-float :initial-contents (loop for i from 0.0d0 to 9.0d0 collect i))) #(0.0d0 1.0d0 2.0d0 3.0d0 4.0d0 5.0d0 6.0d0 7.0d0 8.0d0 9.0d0) (with-open-file (s "z.dat" :direction :io :if-exists :overwrite :if-does-not-exist :create) (write-vector *x* s)) 80 (defvar *y* (make-array 10 :element-type 'double-float :initial-element 10.0d0)) (with-open-file (s "z.dat") (read-vector *y* s)) *y* #(0.0d0 1.0d0 2.0d0 3.0d0 4.0d0 5.0d0 6.0d0 7.0d0 8.0d0 9.0d0) -- Duane Rettig" Further correspondence with Raymond Toy corroborates this is a bug: "Yes, this does appear to be a bug in the implementation of read-vector. You can, however, achieve what you want by opening the file with an element-type of, say, (unsigned-byte 8), instead of the default 'character. I'll have to read some more to understand how read-vector interacts with the stream element type. It seems, though, that the element-type of the vector overrides the element-type of the stream, more or less. Currently, a stream element type of character basically causes the code to read in characters. Ray" If you need more information, let me know and I'll see what I can do. -jeff -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/7> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 2

[cmucl-ticket] #5: Hash table entry with key and value of :EMPTY is treated as an empty entry.
by cmucl 14 Aug '06

14 Aug '06

#5: Hash table entry with key and value of :EMPTY is treated as an empty entry. --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19c Keywords: | --------------------+------------------------------------------------------- {{{ (defvar *h* (make-hash-table)) (setf (gethash :empty *h*) :empty) (maphash #'(lambda (k v) (format t "~A -> ~A~%" k v)) *h*) }}} produces no output, but printing *h* indicates the hash table has one entry in it. This is a bug in how the hash tables indicate an empty slot. The key- value vector uses a key and value of :EMPTY to indicate an empty slot. A possible solution: The second slot in the key-value vector is the symbol :EMPTY, but is otherwise not used for anything. So, instead of putting :EMPTY there, we can put a gensym'ed symbol there instead, and initialize all the remaining slots of the kv vector to be this symbol. I don't think there's any impact on GC, because if the GC code needs the empty symbol, it uses kv_vector![1] to get it. The Lisp code needs to change to initialize the kv-vector appropriately. maphash and with-hash- table-iterator need to use kv_vector![1] instead of :EMPTY to determine if a slot is empty or not. I think this should work. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/5> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #6: GCed items in weak hash tables are still accessible (with random junk)
by cmucl 14 Aug '06

14 Aug '06

#6: GCed items in weak hash tables are still accessible (with random junk) --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19c Keywords: | --------------------+------------------------------------------------------- Consider this simple transcript: {{{ * (defvar *ht* (make-hash-table :weak-p t)) *HT* * (setf (gethash (list 1) *ht*) (list 2)) (2) * *ht* #<EQL hash table, 1 entry> * (prog1 t (make-list 1000000)) T * (gc :full t) NIL * *ht* #<EQL hash table, 0 entries> * (maphash #'(lambda (k v) (format t "~S -> ~S~%") k v) *ht*) (7 . :INSTANCE) -> (#<Function "DEF-STREAM-CLASS SIMPLE-STREAM">) }}} This is totally bogus. I think the problem is that when GC cleans up the weak entry, it doesn't fill in the entry in the table with the empty value. Instead it remains, and ends up pointing to random objects in memory. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/6> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #3: without-package-locks doesn't work with defmacro
by cmucl 21 Jul '06

21 Jul '06

#3: without-package-locks doesn't work with defmacro --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19c Keywords: | --------------------+------------------------------------------------------- Reported in cmucl-help, 2006/04/30: {{{ (in-package "CL-USER") (ext:without-package-locks (defmacro mp::with-process-lock ((lock) &body body) `(mp:with-lock-held (,lock) ,@body))) }}} The above produces an error about a locked package, even though there's a without-package-locks. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/3> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] [cmucl] #4: symbol-macrolet + ignorable causes internal compiler error.
by cmucl 21 Jul '06

21 Jul '06

#4: symbol-macrolet + ignorable causes internal compiler error. --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19c Keywords: | --------------------+------------------------------------------------------- The following causes an internal type error in the compiler because the compiler was expecting some kind of list: {{{ * (symbol-macrolet ((a 42)) (declare (ignorable a)) 4711) Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: (SYSTEM:MACRO . 42) is not of type C::LAMBDA-VAR [Condition of type TYPE-ERROR] }}} Reported on cmucl-imp, 2006/05/20. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/4> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cmucl-ticket