Ben | 12 Aug 19:24 2004
Picon

def-function :out

retrying this now that i'm subscribed to the list.....

i've written preliminary support for :out arguments for def-function.
on cmucl, scl, sbcl, and lispworks, it delegates to their underlying
mechanisms.  for allegro, mcl, et al it creates wrapper functions.
(perhaps some inline declarations are in order.)

caveats:

1) this hasn't been tested on anything other than cmucl since i don't
have access!  the wrapper functions should work, though.

2) i'm not so good with patch.  i'm sending the full source to my
modified functions.lisp.

3) this is not very pretty, sorry.  as you can see i've grafted it on
top of your def-function (now %def-function.)  comments / revisions
would be appreciated.

thanks for the nice package, take care, B

;;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10; Package: UFFI -*-
;;;; *************************************************************************
;;;; FILE IDENTIFICATION
;;;;
;;;; Name:          function.lisp
;;;; Purpose:       UFFI source to C function definitions
;;;; Programmer:    Kevin M. Rosenberg
;;;; Date Started:  Feb 2002
;;;;
(Continue reading)

Marco Baringer | 19 Aug 12:21 2004
Picon

uffi:def-struct on openmcl


in uffi 1.4.24 the def-struct macro doesn't define a foreign type as
it should.

This (in aggregates.lisp):

(defmacro def-struct (name &rest fields)
  ...
  #+openmcl
  `(ccl::def-foreign-type
    nil
    (:struct ,name , <at> (process-struct-fields name fields)))
  )

should be:

(defmacro def-struct (name &rest fields)
  #+openmcl
  `(ccl::def-foreign-type
    ,name
    (:struct ,name , <at> (process-struct-fields name fields)))
  )

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
(Continue reading)

Marco Baringer | 19 Aug 13:38 2004
Picon

Re: uffi:def-struct on openmcl

Marco Baringer <mb@...> writes:

> in uffi 1.4.24 the def-struct macro doesn't define a foreign type as
> it should.

of course it does you fool. RTFM. 

p.s. - where is the (:struct struct-type) form documented?

p.p.s. - sorry for the noise.

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
Kevin Rosenberg | 19 Aug 21:30 2004
Picon

Re: uffi:def-struct on openmcl

Marco Baringer wrote:
> p.s. - where is the (:struct struct-type) form documented?

It's not well documented at all. Looks like
http://uffi.b9.com/manual/def-struct.html is as close to actual
documentation using uffi to define a structure as exists.

--

-- 
Kevin Rosenberg
kevin@...
Marco Baringer | 20 Aug 17:27 2004
Picon

get-slot-value on openmcl


the current implementation of get-slot-value for openmcl loses symbol
name case, i'd suggest this:

(defmacro get-slot-value (obj type slot)
  ...
  #+mcl
  `(ccl:pref ,obj ,(intern (concatenate 'string (symbol-name type) "." (symbol-name slot)) :keyword))
  )

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
Kevin Rosenberg | 20 Aug 19:31 2004
Picon

Re: get-slot-value on openmcl

Marco Baringer wrote:
> (defmacro get-slot-value (obj type slot)
>   ...
>   #+mcl
>   `(ccl:pref ,obj ,(intern (concatenate 'string (symbol-name type) "." (symbol-name slot)) :keyword))
>   )

Okay, change committed and will be in the next release. Thanks!

--

-- 
Kevin Rosenberg
kevin@...
Marco Baringer | 24 Aug 15:17 2004
Picon

(convert-from-uffi-type ... :struct) under mcl


i have what, i think, is a bug:

FFIGEN> (uffi::convert-from-uffi-type '(:* (:* :double)) :struct)
(:* (:* :DOUBLE-FLOAT))
FFIGEN> (uffi::convert-from-uffi-type '(* (* :double)) :struct)
(:* (:ADDRESS :DOUBLE-FLOAT))
FFIGEN> 

the second form isn't a valid openmcl ffi typespec and the first form
errors on sbcl.  is this a bug (then i'll go ahead and fix it) or am i
just missing something?

just out of curiosity, since there will never be no c type named "*",
why is CL:* used and not :*?

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
Kevin Rosenberg | 24 Aug 15:46 2004
Picon

Re: (convert-from-uffi-type ... :struct) under mcl

Marco Baringer wrote:
> the second form isn't a valid openmcl ffi typespec and the first form
> errors on sbcl.  is this a bug (then i'll go ahead and fix it) or am i
> just missing something?

The first form is invalid uffi syntax. The second is correct.

> just out of curiosity, since there will never be no c type named "*",
> why is CL:* used and not :*?

It's what allegro uses.

I don't currently have a powerpc box for testing on openmcl. But, I'll
accept patches as long as the test suite runs as well on openmcl as it
currently does.

--

-- 
Kevin Rosenberg
kevin@...
Marco Baringer | 25 Aug 16:27 2004
Picon

more get-slot-value issues


what the various implementations do with the arguments passed to
get-slot-value:

allegro: uses and evals both the type and slot arguments.

lispworks: ignores type, evals (afaict) and uses the slot argument.

cmucl: ignores type, evals slot.

sbcl: ignores type, evals slot.

mcl: uses type and slot, evals _neither_.

all is not well in get-slot-value land.

i'd like to change get-slot-value for sbcl so that it uses the type
information (currently ignored) and avoids sap-alien allocation where
possible, i'd like to change get-slot-value for mcl so that it evals
all of its arguments. hopefully this should allow the same
uffi:get-slot-value form to work everywhere, however:

1) on sbcl we'd only use the type argument when it was a constant and
   we'd eval it at compile time.

2) on mcl we'd do the eval'ing at compile time if both args are
   constants, otherwise we'll take the speed penatly and do the
   eval'ing (and intern'ing) at runtime.

any issues with this? how often are non constant type and slot
(Continue reading)

Kevin Rosenberg | 27 Aug 02:49 2004
Picon

Re: more get-slot-value issues

Marco Baringer wrote:
> i'd like to change get-slot-value for sbcl so that it uses the type
> information (currently ignored) and avoids sap-alien allocation where
> possible, i'd like to change get-slot-value for mcl so that it evals
> all of its arguments. hopefully this should allow the same
> uffi:get-slot-value form to work everywhere, however:

On platforms where type information is ignored, the type is embedded in
the object. I've not found sap-alien allocation on SBCL or CMUCL using
CLSQL which makes intensive use of get-slot-value to extract data out
of foreign structions.

> 1) on sbcl we'd only use the type argument when it was a constant and
>    we'd eval it at compile time.

I'm not convinced this is necessary. But, if you supply a patch and
both the UFFI and CLSQL tests suites continue to pass all tests, I'll
certainly consider it for inclusion.

> 2) on mcl we'd do the eval'ing at compile time if both args are
>    constants, otherwise we'll take the speed penatly and do the
>    eval'ing (and intern'ing) at runtime.

That may be possible. I'm least familiar with openmcl's FFI.

> any issues with this? how often are non constant type and slot
> specifiers used with get-slot-value?

I don't use them in any of my UFFI applications. 

(Continue reading)


Gmane