Subject: [clisp-list] :malloc-free allocation (was: FFI guru/wizard award to be rewarde d)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Apr 9 03:59:06 2003

Hi,

Aurelio Bignoli wrote:
> > Using (setf (slot (element DBT-pool 0) 'data) "foobar")
> > invokes malloc(). We can free() that memory using
> > (setf (slot (element DBT-pool pool-index) 'data) nil)
Furthermore, if you (setf (slot ...) "bar") the previous contents are free()'d (if not NULL), and a new string is malloc()'ed and installed.
That's useful for DB->put()

But note that this does not work for C-POINTER. Only the pointer types mentioned in impnotes.html on def-c-var (i.e. those for which a conversion Lisp<->C actually occurs).

>I also wrote a thin C wrapper around DB functions, since it is almost
Do you believe you would have written a CLISP module if you had known about my article earlier?
One of my points is that writing FFI+C code is half the way of a writing module, *and* writing modules prevents you from the CAST/TYPECASE madness.
OTOH, you need to be more confident with CLISP's C-level functions, e.g. allocate_string() etc.

>impossible to use DB structure and its function pointers from Lisp:
I guess one of your points is that the functions to be called are like db->get(), i.e. there's nothing with a fixed name like "BDB_get()". This looks like instance methods -- not impossible, but possibly impractical.
I never thought about these, but they are conceptually close to shared-library functions: they hang of the library, here the DB pointer.

Is there anything else which makes you feel that it's impossible?

>IMHO, this solution is quite simple and intuitive. Probably
Yes, it seems straightforwand and it looks like it's easier to port to other Lisps than if you had written a CLISP module and interfaced to CLISP's C-level functions.

Again, if you now know about my article on modules, would writing a module seem as straightforward to you now as your current approach?

>performances can be improved, but for my needs they are accetable.
Yes. One way would be to move even more stuff to the portable C wrappers. It may not become much larger or complex from doing so.

>  (typecase value
>    (fixnum (values 'int sizeof-int))
Why don't you use something along
 (typecase
  ((unsigned-int 32)
   (values 'int/uint32 (FFI:sizeof 'int-or-uint32))
  ((signed-int 32) (values 'sint32 (sizeof 'sint32))
  ... Constant-folding by hand?
Fixnum can be pretty small (i.e. only 24 bits).

Regards,
	Jorg Hohle.

---

From: Aurelio Bignoli <[email-masked]>
Date: Fri Apr 11 11:45:07 2003

Hoehle, Joerg-Cyril writes:

 > >I also wrote a thin C wrapper around DB functions, since it is

well, I have written a module!

 > One of my points is that writing FFI+C code is half the way of a
 > writing module, *and* writing modules prevents you from the
 > CAST/TYPECASE madness.

why? OK, if it is explained in your article I'll try to find it.

 > e.g. allocate_string() etc.

which are not documented :(

 > I guess one of your points is that the functions to be called are
 > like db->get(), i.e. there's nothing with a fixed name like
 > "BDB_get()". This looks like instance methods -- not impossible,
 > but possibly impractical.  I never thought about these, but they
 > are conceptually close to shared-library functions: they hang of
 > the library, here the DB pointer.
 > 

no. Initially my idea was to define a Lis DB type using def-c-struct
and faithfully translate all the C struct members into Lisp slots. A
nightmare: DB has tens of members! Furthermore, it is probably better
to keep DB and other BDB C structures opaque to Lisp. There is no need
to make implementation details, such as structure members, available
at Lisp level.

 > Fixnum can be pretty small (i.e. only 24 bits).

yes, I know. I'm going to add more integer subtypes later.