ralex at cs.colorado.edu
Wed Apr 14 14:58:38 UTC 2010
On Apr 13, 2010, at 7:41 PM, Gary Byers wrote:
> You (Alex) don't understand much about the details of object
> representation in CCL. (Even if that's poorly lip-synched and the
> subtitles are unreadable, that's not intended to be inflammatory:
> there are probably only a handful of people who do understand those
> details and not too many reasons for most people to want or need to
> understand them.)
One has to grow some pretty thick skin to hang with this rough CCL crowd ;-) I am happy to admit that there is much more to know. However, for the purposes that I would, and actually am, using methods such as SIZEOF I not only prefer, I actually need to ignore details of object representations in CCL. I think we really have two completely different use cases:
1) sizeof as method returning the total number of bytes used including all the Lisp/CCL meta information. This would provide a sense of total memory usage of objects but will depend heavily on implementation and is difficult to compute or interpret for shared data structures. Tag bits, headers, ... any kind of meta information is included here.
2) sizeof as C/C++/Ojective-C inspired sizeof operator returning the number of RAW bytes with no meta information (no headers, no tag bits, ...) typically used to deal with FFIs. Mostly used in the context of allocating raw memory and accessing it with (%get-byte ...) kinds of functions.This is what we need to interface with OpenGL/ Cocoa and other APIs on Macs and PCs.
While I am not usually looking at C as great source of inspiration I think for our discussion the sizeof method does have a pretty strong established low level meaning. I suggest that use case #2 is a better match for sizeof. One should, however, come up with a different method, or if you prefer function, name for use case #1. Both are useful things to have.
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel