[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] What's on my plate for Pika...
From: |
Andreas Rottmann |
Subject: |
Re: [Pika-dev] What's on my plate for Pika... |
Date: |
Wed, 14 Jan 2004 07:17:35 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Matthew Dempsky <address@hidden> writes:
> * Porting Pika's FFI - I haven't actually started this yet, but I
> talked with Scott Miller (aka FoxFire; SISC developer) and he
> expressed interest in having Pika available as a C FFI. To quote:
>
> "That would be fantastic. I would almost certainly add it to
> the official distribution. [...] We don't have a C FFI, so
> it would be good to have until there is a decent FFI SRFI (50
> doesn't yet count)."
>
> I have zero familiarity with JNI so this will have to be held off
> for a little while, but it might serve as a proof of concept and
> add weight to Pika as a standard for a C FFI.
>
If I get you right, they want to use the Pika C interface (i.e. FFI)
for SISC. This would mean Pika and FFI can share C extensions, right?
> I also wanted to look at Guile's FFI to see if it would be
> possible to wrap easily, but because Pika and Guile both use the
> scm_ prefix, there'd have to be some magical way of doing it. For
> example, both define scm_make_complex but in Guile it's
> prototyped as:
>
> extern SCM scm_make_complex (SCM real, SCM imag);
>
> while in Pika we have:
>
> extern t_scm_error scm_make_complex (t_scm_word * result,
> t_scm_arena arena,
> t_scm_word * a,
> t_scm_word * b);
>
> Maybe one of our resident Guile experts could give some insight?
>
[ Disclaimer: Being far from a Guile expert, I'm much lesser a Pika expert ;-) ]
I guess your intent is to re-use Guile extensions written in C for
Pika. The most significant problem I see is that Guile has no concept
of 'arenas'. So given a C function written for Guile's C interface
(and exposing a Guile-like prototype), you probably would have to
parse the function code and quite heavily munch it to spit out a
function that exposes a Pika-style prototype.
Munching would at least include extending the orignal prototype with
an arena, doing likewise for all scm_*() calls in the function body
and deal with SCM vs. 't_scm_word *'. This seems not like an easy
undertaking.
The other way round (i.e. making code written using the Pika-style FFI
usable from guile) should be easier (but probably not as useful, given
the amount of Guile C code vs. Pika C code).
Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
It's *GNU*/Linux dammit!