[Nickle] Currency conversion (foreign function interface)

Bart Massey bart at po8.org
Mon Dec 6 07:56:37 PST 2004

Huh.  I thought the FFI plan was to be able to do some
extern "C" equivalent...

In the Nickle code, something like
  namespace Lib extern "libfoo" {
    extern string getfoo(string s, int n, *char cp);
    public string mygetfoo(string s, string t) {
      return getfoo(s, String::length(t) + 1, &t);
and then you can just load the appropriate name from
libfoo.so directly.  Only problem is that now you have to
make some chunk of the Nickle compiler understand handling C-style
arguments.  Some of the machinery is already there from the
builtin stuff.

Obviously, your plan is way less work to get started with.
It just depends on how many shared libraries we expect to
amortize the work over.


In message <E1CbE9V-0001ff-Co at evo.keithp.com> you wrote:
> --===============1652121022==
> Content-Type: multipart/signed; boundary="==_Exmh_364314920P";
> 	micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
> --==_Exmh_364314920P
> Content-Type: text/plain; charset=utf-8
> I want to build a cairo interface in nickle, but I don't want nickle to be 
> always tied to X, cairo and a million other libraries.
> So, the obvious solution was to construct some kind of foreign function 
> interface.
> I've got something working, but wanted to see if anyone had ideas about 
> how it should really work before I commit to CVS.
> Because foreign libraries often include a wealth of new datatypes, I'd 
> like to hook them into the nickle memory allocator so that they get 
> destroyed when nickle is done with them.  I created a new primitive 
> datatype "foreign" which references a single datum.  Each foreign object 
> has a 'free' function and an 'id', which is a string that the foreign 
> library can use to do run-time typechecking.  I'd love static 
> typechecking, but I'm not sure how to manage that.  Suggestions for this 
> are welcome.
> Adding foreign functions was actually pretty easy; use dlopen to load a 
> shared library, then use dlsym to locate "nickle_init" and call that.
> nickle_init is expected to use the existing Builtin* calls to create
> and populate a namespace.  Of course, the functions must all be nickle 
> wrappers around the native ones.
> I'm currently using RTLD_LAZY, which avoids requiring all symbols be 
> resolved, but runs the risk of blowing up the whole nickle session if an 
> undefined symbol is ever used.  RTLD_NOW would switch that around; I'm not 
> sure that's better though.
> I tested things by making a tiny Xlib FFI; the three functions I added in
> that "work", but it's tedious to do a lot of calls this way.  Clearly some
> more efficient mechanism is required.  In an ideal world, we'd have a tool
> that took an existing .so/.h pair and constructed a wrapper .so that called
> everything in the .h with appropriate type and range checked arguments.
> -keith
> --==_Exmh_364314920P
> Content-Type: application/pgp-signature
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh version 2.3.1 11/28/2001
> iD8DBQFBtBb8Qp8BWwlsTdMRApE1AKCDIyqN3h0/BIlGCoMl6pkfSksmCQCaAgio
> KsSrar/EPNzHSoIXCHN62iU=
> =oXJc
> --==_Exmh_364314920P--
> --===============1652121022==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> _______________________________________________
> Nickle mailing list
> Nickle at nickle.org
> http://nickle.org/mailman/listinfo/nickle
> --===============1652121022==--

More information about the Nickle mailing list