unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Matt Wette <matt.wette@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: ffi helper
Date: Mon, 20 Mar 2017 15:49:08 +0100	[thread overview]
Message-ID: <878to0dmvv.fsf@gmail.com> (raw)
In-Reply-To: <201FF019-FA10-4B35-A96D-BC0AD078F5DB@gmail.com> (Matt Wette's message of "Sun, 19 Mar 2017 10:23:14 -0700")

Matt Wette <matt.wette@gmail.com> writes:

>> On Mar 13, 2017, at 5:53 PM, Matt Wette <matt.wette@gmail.com> wrote:
>> 
>> 
>>> On Mar 8, 2017, at 6:06 PM, Matt Wette <matt.wette@gmail.com> wrote:
>>> 
>>> I’m now working on a FFI helper based on the nyacc C99 parser.   
>> 
>
> I am making some progress with some ragged prototype code.
>
> Here is a top-level program, just pulling out three declarations to start:
>
> (let* ((file "/opt/local/include/cairo/cairo-svg.h")
>        (defs '())
>        (incs '("/opt/local/include" "/opt/local/include/cairo" "/usr/include"))
>        (tree (my-parse defs incs file))
>        (file-decls (reverse (c99-trans-unit->udict tree #:filter cairo-filter)))
>        (udecl-dict (c99-trans-unit->udict/deep tree)))
>
>   (fold
>    (lambda (pair type-list)
>      (udecl->ffi-decl (cdr pair) type-list))
>    fixed-width-int-names
>    (filter
>     (lambda (e)
>       (member (car e)
> 	      '("cairo_matrix_t" "cairo_surface_t" "cairo_svg_surface_create")))
>     file-decls)))
>
> And here is the autogenerated output for the declarations:
>
> (define-std-pointer-wrapper cairo_surface_t*)
>
> (define cairo_matrix_t
>   (bs:struct
>     `(,(string->symbol "xx") ,double)
>     `(,(string->symbol "yx") ,double)
>     `(,(string->symbol "xy") ,double)
>     `(,(string->symbol "yy") ,double)
>     `(,(string->symbol "x0") ,double)
>     `(,(string->symbol "y0") ,double)))
>
> (define cairo_svg_surface_create
>   (let ((f (pointer->procedure
>              '*
>              (libcairo-func "cairo_svg_surface_create")
>              (list '* double double))))
>     (lambda (filename width_in_points height_in_points)
>       (let ((~filename (string->pointer filename))
>             (~width_in_points width_in_points)
>             (~height_in_points height_in_points)
>             (~result
>               (f ~filename ~width_in_points ~height_in_points)))
>         (wrap-cairo_surface_t* ~result)))))

Neat!

> I was not able to come up with a procedure that would take arguments
> “xx” and “double” and generate the bs:struct pattern `(xx ,double).
> Help is welcome.

You mean you get "xx" and "double" as strings?  For xx, string->symbol
as you already do is OK.  As for double, that's a bit tricky.  I see a
few possibilities:

- Turn the string into a symbol and eval it:

    (eval (string->symbol str)
          (resolve-module '(bytestructures guile numeric)))

- Use the reflective module API:

    (module-ref (resolve-module '(bytestructures guile numeric))
                (string->symbol str))

- Create an explicit mapping from name (string or symbol) to object:

    (import (bytestructures guile numeric))

    (define descriptor-mapping
      `(("double" . ,double)
        ("float" . ,float)
        ...))

(The so-far undocumented module (bytestructures guile numeric-metadata)
contains a mapping similar to this, but it only contains name with
explicit bit width so e.g. 'double' isn't in it, so I guess it's not the
right thing here.)

While 'eval' is normally discouraged, I think it's fine in this case,
since we use string->symbol.  I don't see anything bad resulting from
evaluating an arbitrary symbol.

However, the second option could be said to be a tad bit more "correct"
than using eval, so I'd go with that and only use the eval method if I
had to write standards-compliant code where eval is available but not
something like module-ref.

The third option gives you full control but it shouldn't be necessary.

Hope that helps,
Taylan



  reply	other threads:[~2017-03-20 14:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09  2:06 ffi helper Matt Wette
2017-03-11 11:38 ` Taylan Ulrich Bayırlı/Kammer
2017-03-11 19:55   ` David Pirotte
2017-03-14  0:53 ` Matt Wette
2017-03-19 17:23   ` Matt Wette
2017-03-20 14:49     ` Taylan Ulrich Bayırlı/Kammer [this message]
2017-03-21 22:40     ` Matt Wette
2017-04-18  2:26       ` Matt Wette
2017-05-13 16:19         ` Matt Wette
2017-03-23 17:43 ` Amirouche
2017-03-24  1:43   ` Matt Wette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878to0dmvv.fsf@gmail.com \
    --to=taylanbayirli@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=matt.wette@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).