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

[cmucl-ticket] [cmucl] #1: prin1 and ~E produce different outputs.
by cmucl 03 Oct '07

03 Oct '07

#1: prin1 and ~E produce different outputs. ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: printing | ------------------------+--------------------------------------------------- (let ((x (random 1d-3))) (values (prin1-to-string x) (format nil "~E" x))) will produce different significant digits. I think the problem is in ~E which calls lisp::scale-exponent to scale the number between 0.1 and 1. I think we could just call flonum-to-digits which will give us the digits and the exponent. We can massage that into the desired digits and exponent as in scale-exponent, but we won't have the round-off problem. Maybe. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/1> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 4

[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