FFI additions

[GoogleCodeExporter]

The current FFI has a few missing bits:

- For callbacks, only int and void* arguments are supported. Return type is
limited to int and void.

- The FFI API seems to be written towards writing static bindings, and
using them to construct bindings based on information only available at
runtime is a bit cumbersome: for example, given a return type (a symbol)
and argument types (a list of symbols), constructing a corresponding
callout procedure requires jumping through a hoop first (by writing down
all possible `c-argument' variations, see [0] for an example).
Additionally, `c-argument' is not part of the FFI library interface
anymore. It would be nice if Ypsilon could provide (additionally) an API
that makes dynamic bindings easier; I think the Ikarus FFI[1] is nice in
that regard.

[0]
http://rottyforge.yi.org/cgi-bin/darcsweb.cgi?r=spells;a=headblob;f=/libraries/f
oreign/compat.ypsilon.sls
[1]
http://rottyforge.yi.org/~rotty/tmp/ikarus-scheme-users-guide-Z-H-30.html#node_s
ec_5.5

Original issue reported on code.google.com by rott...@gmail.com on 21 Jan 2009 at 12:42

[GoogleCodeExporter]

Thank you for your message and very nice information.
I will consider dynamic bindings. :)

BTW, I'm now writing Ypsilon API Reference (API not fixed yet).
Current draft is available at http://www.littlewing.co.jp/ypsilon/doc-draft/
Your comments are very welcome!
-- fujita

Original comment by y.fujita...@gmail.com on 21 Jan 2009 at 3:33

• Changed state: Accepted

[GoogleCodeExporter]

Hi

rotty also approached me about this, and what he says makes a lot of sense.

The solution I have to offer is simple though, and I would think it be similar 
in
Ypsilon.

(define (make-ffi-callout return-type arg-types)
  (eval `(ffi-callout ,return-type ,arg-types) 
         (environment '(ironscheme clr))))

Cheers

leppie

Original comment by xacc....@gmail.com on 24 Jan 2009 at 10:03

[GoogleCodeExporter]

Thank you for your message!
Yes, your solution is simple, portable, and easy to maintain. :)
However, because Ypsilon's eval is too slow for practical use (current version 
uses
fake library to implement eval), I have decided to implement it in the core 
library.
--fujtia

Original comment by y.fujita...@gmail.com on 27 Jan 2009 at 12:36

[GoogleCodeExporter]

I think the issues originally raised in these bug are adressed in
Ypsilon SVN now.

However, I'd like to add one request: it should be possible to
retrieve the shared object handle for the current process. One usecase
for this is the following:

I link ypsilon against libtcmalloc (from google-perftools) when
hunting for memory leaks. Now all DSOs I load will use malloc()/free()
from libtcmalloc, hence when I accept/pass dynamically allocated
memory from/to the DSOs and ownership of that memory is transferred, I
have to make sure I'm using the *right* malloc()/free() from Scheme
(i.e. the one of libtcmalloc). Hence code like this will break badly:

   (define libc (load-shared-object
                 (cond (on-linux "libc.so.6")
                       (else
                        (error 'libc "unsupported system")))))

   (define malloc (c-function libc "libc" void* malloc (size_t)))
   (define free (c-function libc "libc" void free (void*)))

I've attached a patch that allows one to retrieve the process's DSO
handle by calling `load-shared-object' with zero arguments (maybe the
name does not quite match the semantics then, as no shared object is
actually loaded in that case). Another possibility to fix this
*specific* use case would be to define malloc()/free() as subrs inside
the C++ code, but there might be other occasions where the feature
added by the attached patch is useful. Note that the patch is untested
on Windows.

Original comment by rott...@gmail.com on 22 Apr 2009 at 2:40

Attachments:

• t_ffi-tweaks.diff

[GoogleCodeExporter]

I have updated load-shared-object in revision 429 as you suggested. 
Thank you! :)

-- fujita

(I keep this issue open until I finish the next release version. Any 
suggestions and
comments are very welcome!)

Original comment by y.fujita...@gmail.com on 26 Apr 2009 at 2:23

• Changed state: Started

[GoogleCodeExporter]

It would be nice for symmetry to have `unsigned-long-long' and 
`signed-long-long'
types in the FFI. While these are most certainly synonymous to `uint64_t' and
`int64_t' on all platforms supported by Ypsilon, in theory they aren't always 
the same.

Original comment by rott...@gmail.com on 6 Jun 2009 at 4:17

[GoogleCodeExporter]

Thank you for your suggestion!
I have added 'long-long' and 'unsigned-long-long' to revision 488. :-)
-- fujita

Original comment by y.fujita...@gmail.com on 7 Jun 2009 at 2:28