a return to struct madness?

Hi.

First of all, my thanks to Kevin Rosenberg and everyone involved with
UFFI, which is, for the most part, a completely excellent piece of
software.

I was wondering if the issues/patches that Marco Baringer was discussing
on this list were ever resolved, because I think I am pulling my hair
out over similar issues.

In a mail to this list from September, Kevin cited mysql-api.lisp in
CLSQL for an example of heavy structure use, but it doesn't seem to
cover the one problem case, for me: structures that should be stack
allocated when possible.

It's possible that I'm just missing something obvious, but on CMUCL, I'd
hope that this:

(defun foo ()
  (with-foreign-object (my-struct 'my-struct)
    (declare (dynamic-extent my-struct))
    (some-foreign-call my-struct)
    (do-something (get-slot-value my-struct 'my-struct 'some-slot))))

would become this:

(defun foo ()
  (alien:with-alien (my-struct my-struct)
    (declare (dynamic-extent my-struct))
    (some-foreign-call (alien:alien-sap my-struct))
    ...

When I do this by hand, things work wonderfully.  By default, UFFI ends
up sticking a call to alien:addr into the works, which seems to force
CMUCL/SBCL to allocate the structure on the heap.  Having this structure
allocated on the stack is absolutely essential to performance of several
applications of mine.  The upside is that with-foreign-object works just
great on OpenMCL; no excess consing.

Also, I noticed that the OpenMCL inconsistency with get-slot-value still
seems to be in place; I have to use reader conditionals on whether to
quote the type name.

I'm happy to hack out my own solution to this stuff, but I was hoping
someone would have some useful comments that might allow me to do
something that fixes it for everyone.

Cheers.

-- 
Julian Squires