headers
Ben | 12 Aug 2004 19:24

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)

Permalink | Reply | 0 comments |
headers
Marco Baringer | 19 Aug 2004 12:21
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)

Permalink | Reply | 2 comments |
headers
Marco Baringer | 19 Aug 2004 13:38
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
Permalink | Reply | 1 comment |
headers
Kevin Rosenberg | 19 Aug 2004 21:30
Favicon

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@...
Permalink | Reply | 0 comments |
headers
Marco Baringer | 20 Aug 2004 17:27
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
Permalink | Reply | 1 comment |
headers
Kevin Rosenberg | 20 Aug 2004 19:31
Favicon

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@...
Permalink | Reply | 0 comments |
headers
Marco Baringer | 24 Aug 2004 15:17
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
Permalink | Reply | 1 comment |
headers
Kevin Rosenberg | 24 Aug 2004 15:46
Favicon

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@...
Permalink | Reply | 0 comments |
headers
Marco Baringer | 25 Aug 2004 16:27
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)

Permalink | Reply | 2 comments |
headers
Kevin Rosenberg | 27 Aug 2004 02:49
Favicon

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)

Permalink | Reply | 1 comment |

Gmane