[Openmcl-devel] make-heap-buffer question
ch-openmcl at bobobeach.com
Mon Sep 20 01:49:45 EDT 2004
While we're on the subject, we probably need a decent story for freeing
this thing. Is %dispose-heap-vector the way to go?
On Sep 19, 2004, at 9:31 PM, Gary Byers wrote:
> On Sun, 19 Sep 2004, Cyrus Harmon wrote:
>> So I'm not sure exactly how to use the make-heap-buffer,
>> make-heap-ivector stuff, or why it's in streams, for that matter, but
>> this seems a bit odd:
> Those functions are in l1-streams.lisp because the stream code is the
> only code that uses them. They aren't particularly useful or general.
>> (multiple-value-bind (buf p)
>> (ccl::make-heap-buffer '(unsigned-byte 32) 256)
>> (print (array-dimensions buf))
>> (setf (aref buf 0) #x7f7f7f7f)
>> (setf (aref buf 1) #xaabbccdd)
>> (setf (aref buf 1023) #xdeadbeef)
>> (let ((*print-base* 16))
>> (print (aref buf 0))
>> (print (aref buf 1))
>> (print (aref buf 1023)))
>> (print p))
>> gives the following results:
>> #<A Mac Pointer #x10A2CC>
>> I can understand buf beingg 1024 _bytes_ (in the normal 8-bit sense)
>> long, but it looks to me like it's 1024 unsigned-byte 32's long. Is
>> this a bug or am I missing something?
> Sometimes, to avoid confusion (or possibly to introduce it) the term
> "octet" is used to mean "8-bit byte".
> CCL::MAKE-HEAP-BUFFER accepts an array-element-type specifier and
> an element-count as arguments; it returns 4 values
> 1) a vector of the indicated type, with the indicated number of
> 2) a pointer, which happens to share storage with the vector
> 3) the number of usable octets in the buffer (the product of the number
> of elements in the vector and the size of each element in octets,
> at least in simple cases. Bitvectors and some floating-point types
> may not be simple.)
> 4) the internal typecode of the vector.
> For a number of reasons, I'd discourage use of CCL::MAKE-HEAP-BUFFER;
> it only tries to handle a few element-type specifiers (not
> the ones that the stream-buffer-creating code might call it with), and
> doesn't even do that in a very reasonable way.
> CCL::%MAKE-HEAP-IVECTOR is even lower-level and less general.
> I mailed out yet another variant a month or two ago; this version
> tries to be a bit more reasonable, and actually does a little bit
> of error/sanity-checking:
> (defun make-heap-ivector (element-count element-type)
> (let* ((subtag (ccl::element-type-subtype element-type)))
> (unless (= (logand subtag target::fulltagmask)
> (error "~s is not an ivector subtype." element-type))
> (let* ((size-in-bytes (ccl::subtag-bytes subtag element-count)))
> (ccl::%make-heap-ivector subtag size-in-bytes element-count))))
> Note that (gratuitously) this function takes the same arguments as
> CCL::MAKE-HEAP-BUFFER, but takes them in the opposite order.
> I'd be willing to export MAKE-HEAP-IVECTOR, document it, commit to not
> changing it without advance notice, address any remaining bugs,
> etc. (The same would be true for any complementary functions that
> would free the storage involved, etc.) I'm less inclined to commit to
> making CCL::MAKE-HEAP-BUFFER or CCL::%MAKE-HEAP-IVECTOR behave like
> they were anything other than murky components of the implementation
> layer, that might change or disappear for murky, implentation-dependent
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
More information about the Openmcl-devel