From cmucl-devel at common-lisp.net  Fri Aug 11 14:08:11 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Fri, 11 Aug 2006 14:08:11 -0000
Subject: [cmucl-ticket] #6: GCed items in weak hash tables are still
 accessible (with random junk)
Message-ID: <076.1ff77f3a8d4a0c2b0330ea18066a00fe@common-lisp.net>

#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

From cmucl-devel at common-lisp.net  Fri Aug 11 21:32:41 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Fri, 11 Aug 2006 21:32:41 -0000
Subject: [cmucl-ticket] Re: #1: prin1 and ~E produce different outputs.
In-Reply-To: <076.7db2c3e210ca4a70e65ce806121e729d@common-lisp.net>
References: <076.7db2c3e210ca4a70e65ce806121e729d@common-lisp.net>
Message-ID: <085.7ff26d96566f4499f8b8dfa925e73ad5@common-lisp.net>

#1: prin1 and ~E produce different outputs.
------------------------+---------------------------------------------------
  Reporter:  anonymous  |       Owner:  rtoy    
      Type:  defect     |      Status:  assigned
  Priority:  minor      |   Milestone:          
 Component:  Core       |     Version:  19c     
Resolution:             |    Keywords:  printing
------------------------+---------------------------------------------------
Old description:

> (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.

New description:

 {{{
 (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

From cmucl-devel at common-lisp.net  Mon Aug 14 18:15:02 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Mon, 14 Aug 2006 18:15:02 -0000
Subject: [cmucl-ticket] Re: #6: GCed items in weak hash tables are still
 accessible (with random junk)
In-Reply-To: <076.1ff77f3a8d4a0c2b0330ea18066a00fe@common-lisp.net>
References: <076.1ff77f3a8d4a0c2b0330ea18066a00fe@common-lisp.net>
Message-ID: <085.e8b9b3ea57f586c05bd4807c86c9dce4@common-lisp.net>

#6: GCed items in weak hash tables are still accessible (with random junk)
---------------------+------------------------------------------------------
  Reporter:  rtoy    |       Owner:  somebody
      Type:  defect  |      Status:  closed  
  Priority:  major   |   Milestone:          
 Component:  Core    |     Version:  19c     
Resolution:  fixed   |    Keywords:          
---------------------+------------------------------------------------------
Changes (by rtoy):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Fixed in snapshot 2006-08.

-- 
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/6>
cmucl <http://common-lisp.net/project/cmucl>
cmucl

From cmucl-devel at common-lisp.net  Mon Aug 14 18:15:58 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Mon, 14 Aug 2006 18:15:58 -0000
Subject: [cmucl-ticket] Re: #5: Hash table entry with key and value of
 :EMPTY is treated as an empty entry.
In-Reply-To: <076.1209ce90c30ae79b3e61c25cbbe81991@common-lisp.net>
References: <076.1209ce90c30ae79b3e61c25cbbe81991@common-lisp.net>
Message-ID: <085.7f2625246cb0909c99623f9b53553338@common-lisp.net>

#5: Hash table entry with key and value of :EMPTY is treated as an empty entry.
---------------------+------------------------------------------------------
  Reporter:  rtoy    |       Owner:  somebody
      Type:  defect  |      Status:  closed  
  Priority:  minor   |   Milestone:          
 Component:  Core    |     Version:  19c     
Resolution:  fixed   |    Keywords:          
---------------------+------------------------------------------------------
Changes (by rtoy):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Fixed in CVS.  Should be available for the September snapshot.

-- 
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/5>
cmucl <http://common-lisp.net/project/cmucl>
cmucl

From cmucl-devel at common-lisp.net  Thu Aug 17 22:25:01 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Thu, 17 Aug 2006 22:25:01 -0000
Subject: [cmucl-ticket] #7: Bug in read-vector
Message-ID: <076.579470d76989a9c21c27f35ec22338ec@common-lisp.net>

#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/67876101085aee82/05a20cfcd11f8fbe?hl=en#05a20cfcd11f8fbe>)
 ...................................................................
 "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

From cmucl-devel at common-lisp.net  Sun Aug 20 03:02:12 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Sun, 20 Aug 2006 03:02:12 -0000
Subject: [cmucl-ticket] Re: #7: Bug in read-vector
In-Reply-To: <076.579470d76989a9c21c27f35ec22338ec@common-lisp.net>
References: <076.579470d76989a9c21c27f35ec22338ec@common-lisp.net>
Message-ID: <085.f2ec66a7ba90c84180d52e1523dd98f0@common-lisp.net>

#7: Bug in read-vector
--------------------------+-------------------------------------------------
  Reporter:  jcunningham  |       Owner:  somebody   
      Type:  defect       |      Status:  new        
  Priority:  major        |   Milestone:             
 Component:  Core         |     Version:  19c        
Resolution:               |    Keywords:  read-vector
--------------------------+-------------------------------------------------
Old description:

> 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/67876101085aee82/05a20cfcd11f8fbe?hl=en#05a20cfcd11f8fbe>)
> ...................................................................
> "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

New description:

 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/67876101085aee82/05a20cfcd11f8fbe?hl=en#05a20cfcd11f8fbe>)
 ...................................................................
 "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

Comment (by rtoy):

 First I added a bit of markup so that the code bits are formatted better.

 Now for the bug report, there are a couple of issues here.  CMUCL has an
 extension, READ-VECTOR, which is similar to the SIMPLE-STREAM's READ-
 VECTOR, but not quite.  In particular, it produces the bug that you see.
 However, if you {{{(require 'simple-streams)}}}, READ-VECTOR will be
 replaced with the simple-stream version.  Then, the following snip of code
 works as Duane mentions:

 {{{
 (let ((vec (make-array 10 :element-type 'double-float)))
            (with-open-file (os "d10.bin" :class 'stream:file-simple-
 stream)
              (stream:read-vector vec os) (print vec)))
 }}}

 The important part is that you open the file with the appropriate class.

 Not sure what to do.  We can change READ-VECTOR to match simple-stream
 READ-VECTOR.
 (BTW, READ-VECTOR is much faster than STREAM:READ-VECTOR.)

-- 
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/7>
cmucl <http://common-lisp.net/project/cmucl>
cmucl

From cmucl-devel at common-lisp.net  Mon Aug 21 15:22:09 2006
From: cmucl-devel at common-lisp.net (cmucl)
Date: Mon, 21 Aug 2006 15:22:09 -0000
Subject: [cmucl-ticket] Re: #7: Bug in ext:read-vector
In-Reply-To: <076.579470d76989a9c21c27f35ec22338ec@common-lisp.net>
References: <076.579470d76989a9c21c27f35ec22338ec@common-lisp.net>
Message-ID: <085.2d3e692f21c92572a1683da420b3d051@common-lisp.net>

#7: Bug in ext:read-vector
--------------------------+-------------------------------------------------
  Reporter:  jcunningham  |       Owner:  somebody   
      Type:  defect       |      Status:  closed     
  Priority:  major        |   Milestone:             
 Component:  Core         |     Version:  19c        
Resolution:  fixed        |    Keywords:  read-vector
--------------------------+-------------------------------------------------
Changes (by rtoy):

  * resolution:  => fixed
  * summary:  Bug in read-vector => Bug in ext:read-vector
  * status:  new => closed

Comment:

 Change summary to include package qualifier.

 This should be fixed in the Sep snapshot.  A simple change to {{{*read-
 simple-array-recognized-types*}}}, adding {{{BASE-CHAR}}} and
 {{{CHARACTER}}} fixes this.

 Closing the report.

-- 
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/7>
cmucl <http://common-lisp.net/project/cmucl>
cmucl