First, I apologize for not being able to submit a diff
against CVS. I have neither access to networked CVS nor
ssh because of a firewall. I don't even have a usable
UNIX box any more. Maybe towards the middle of the
year, if you all want to wait that long.
What is appended is a step by step description of what
needs to be done to incorporate the changes.
Regards,
Jörg Höhle.
Logged In: YES
user_id=5735
I don't like the names "simple-calloc" and "complex-malloc"
(complex is a type in CL).
I don't see why they are needed at all.
besides, your doc for simple-calloc is not in sync with the
implementation.
I propose removing these 2 macros.
PS. don't you have internet at home?!
Logged In: YES
user_id=377168
Oops:doc (SIMPLE-CALLOC c-type &KEY :COUNT :READ-ONLY)
[Remove contents]
Maybe a better name would be DEEP-MALLOC
I want to stress the fact that this function is more
powerful that people know from other Lisp's FFI or C. It
recursively allocates memory, thus even
(DEEP-MALLOC 'C-string "foo") does more than one might
expect. The example also serves to stress this.
I expect users to forget about this, hence the name.
For instance, Lispworks has allocate-foreign-object with an
initform, yet I believe it performs a single allocation.
simple-Calloc (instead of -Malloc) was choosen as a hint to
C programmers about the zeroing.
The macros need be there so that PARSE-C-TYPE can be mixed
in. An optimizing DEFINE-COMPILER-MACRO on PARSE-C-TYPE has
yet to be written by me, after considering all scenarios.
The interface was choosen this way to let the user continue
using the external type representation (as long as I can).
The low-level section of the doc need not be included now. A
better time will be the day I'll rename all those %offset
etc. to offset*. I'll only do this when I'll have CVS,
because of the many places that need to be changed, so
please don't hold your breath. Then, people will be able to
make sense of FOREIGN-VARIABLE. (+ a few macros yet to be
written).
Logged In: YES
user_id=5735
I checked this in.
why doesn't foreign-free mark the object as invalid?!
what operation can be permitted on this object?
should I just make VALIDP setfable?