From rayiner at gmail.com Mon Jun 27 21:14:16 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 27 Jun 2005 17:14:16 -0400 Subject: [fetter-devel] Project Proposal for Fetter Message-ID: Here is (most of) the project proposal for Fetter. I'm posting this here mainly so Luis can get an idea of the details of what I'm doing, and what kind of timeline I'm operating on. --- Start Paste --- Synopsis: A program will be created to automatically generate foreign function interface (FFI) bindings directly from C++ header files. The program will implement this functionality using GCC-XML to parse C++ header files, giving it the ability to support a wide range of C++ features. The top priorities of the program will robust handling of C++ header files, followed by ease of use, then simplicity of maintenance. It will support multiple FFI back ends, but the first target will be UFFI on CMUCL. Justification: The inability to access modern C++ libraries from Lisp code is an inconvenience for programmers. C++ is the most-used language on SourceForge, featured in 15,607 projects. Among these are premier Open Source platforms like Mozilla and KDE. All of this C++ code is inaccessible from Lisp and represents not only lost opportunities for sharing, but in the case of Mozilla and KDE, large platforms with large user bases that cannot be targeted by Lisp applications. A system that would allow Lisp code to access C++ libraries would thus be quite beneficial to Lisp programmers, particularly to those targeting Open Source platforms. It would not only ease development, but it would widen the potential audience for Lisp applications. Now, it is reasonable to question the need for another program to automate the generation of FFI declarations. After all, many such programs already exist. However, most of these existing programs do not even attempt to handle C++ header files. Indeed, only a single system, the Simplified Wrapper and Interface Generator (SWIG), offers anything resembling proper support for C++ features. However, even SWIG cannot handle C++ header files that require correct and complete template parsing semantics. In any case, there are no SWIG back ends available for free Common Lisp implementations, and the single Common Lisp back end that does exist, for Allegro Common Lisp (ACL), lacks C++ support entirely. Part of the reason why SWIG back ends for Lisp and Lisp-like languages are so uncommon is that writing a SWIG back end requires quite a bit of knowledge about the SWIG system itself, as well as a deep understanding of the C++ type system. Further, SWIG back ends must be written in C++,! making them less palatable projects for Lisp programmers. For these reasons, a creation of a new program seems justified. Development Process: An incremental development model will be used to create the program. This decision is driven by the author's preference for this model when developing in dynamic languages and by the desire to make several stages of intermediate results available to demonstrate progress. It will be developed with much hindsight, as the author implemented a proof-of-concept of a similar system in 2004. The previous system was written in Python, targeted the Functional Developer Dylan FFI, and was complete enough to generate declarations for C libraries like SDL and OpenGL. Development on the concept was stopped largely because of job-related time pressures. Project Details: The basic structure and operation of the program can be likened to that of a compiler. It will be run with a simple input file specifying the C++ header files and some configuration options. A front end will use GCC-XML to parse the header files, run several transformations on the resulting information, then pass the results via an intermediate file to a specified back end. The back end will then process the output and generate a Lisp package containing the FFI declarations and stub routines required to access the original header files. The front end will be responsible for processing the input file, generating an IR from the specified header files, and transforming the IR to make it readily digestible by the back ends. Generating the IR is fairly simple. When invoked on a header file, GCC-XML generates an XML file containing the header file's class and field declarations. This XML file can then be parsed into an object tree with the same structure. Since the GCC-XML format is very close to a proper semantic representation of the header file, this object tree can be used directly as the IR. Having parsed the XML files and generated the IR, the front end must then simplify the IR before it is passed to the back ends. It must perform transformations such as collapsing namespace hierarchies and nested structures, assigning names to anonymous types, and filling in values for default arguments. These transformations all exist to minimize the complexity of the back ends. After the simplification passes, the objec! t tree can be written to an output XML file and the back end can be started. The back end will be responsible for taking the simplified IR and generating from it FFI declarations and stub routines. Multiple back ends can exist, each targeting a different FFI. The back ends can be very simple recursive-descent code generators. The front end does most of the work of lowering the IR to an appropriate level of abstraction. This simplicity is an important trait, as it is desired that back ends eventually be written for languages such as Dylan and Scheme. A survey of various FFIs suggests that not all will be able to offer the same level of access to C++ features. Three levels of support have been identified: L0, L1, and L2. L0 access will feature standard C access plus the ability to call methods in C++ classes. L1 access will feature the additional ability to override virtual functions in C++ classes. L2 access will feature the ability to integrate C++ classes into the native object system. A survey of existing FFIs suggests that UFFI can support L0 acce! ss by itself, or L1 access with compiler-specific workarounds for specifying callbacks. Sophisticated FFIs like the one in ACL or Functional Developer can support L2 access. The runtime library will be a small C support library specific to each C++ compiler. It is necessary because existing Lisp FFIs have no understanding of C++ virtual function tables. The runtime library will encapsulate all the compiler-specific knowledge of virtual table formats, allowing Lisp programs to make virtual function calls and to generate virtual function tables that can be called from the C++ code. Project Time Line: The project shall be divided into three phases, with a milestone at the end of each phase. The phases are outlined below: Phase 1 (Mid-June to July 1): Research the target FFI and the IA64 C++ ABI (the C++ ABI for most compilers on *NIX/x86). Milestone 1 (July 1): The creation of a detailed design document specifying the structure of the program, the format of the IR, the IR transformations in the front end, the precise semantics of the various levels of access, and the IR to FFI mapping. Phase 2 (July 1 to July 15): Create an initial implementation of the front-end and a back end implementation capable of performing L0 access. Milestone 2 (July 15): The creation of a Lisp demo using the SDL C++ API. Phase 3 (July 16 to August 15): Improve the implementation of the front end and create a back end capable of supporting L1 access. Milestone 3 (August 15): The creation of a Lisp demo using the KDE C++ API. While this plan is a bit aggressive, experience with the previous concept suggests that it is realistic. The previous concept, as described, was implemented in two weeks. Project Deliverables: As a proof of completion, the following items will be delivered: 1) A front end capable of parsing input from GCC-XML 0.60. 2) A back end capable of allowing L1 access through UFFI on CMUCL. 3) A runtime library for GCC 3.x on Linux/x86. --- End Paste --- Sincerely, Rayiner Hashem From ktilton at nyc.rr.com Mon Jun 27 22:58:47 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 27 Jun 2005 18:58:47 -0400 Subject: [fetter-devel] Re: some FFFI, some sockets In-Reply-To: References: <6c6712adb7e93430e48ebdcb1ebd810c@gmail.com> <42BF2A33.3040301@nyc.rr.com> <4dcb4bab99b23d73ad41d415ae55a95b@gmail.com> <42C0203E.30407@nyc.rr.com> <12edc9d4c8373b9cfb4e0271dbbdab47@gmail.com> <42C03CCF.4070505@nyc.rr.com> Message-ID: <42C084A7.2090402@nyc.rr.com> Rayiner Hashem wrote: >>Getting back to your original concern, Rayiner likewise first will >>produce the Fetter IR (intermediate representation?) and then worry >>about generating the bindings in some FFI or another. And Rayiner will >>care only about the API supported by that FFI, not who is underneath. >> >> > >In the next few days I'd like to complete the initial design document, >which is my first milestone. I can leave the FFI bit a little floaty, >but while writing the design spec, I'll be looking at UFFI (it's >better documented). It's not a big deal (to me, yet) what Hello-C >ultimately ends up looking like, though. > Yep. UFFI is a good bootstrap target, a good starting point to eyeball in developing Fetter. As work proceeds, any deficiency in UFFI gets cure in CFFI and eventually that becomes the target of Fetter. kt From jlr at mpq.mpg.de Wed Jun 29 17:35:11 2005 From: jlr at mpq.mpg.de (Juan Jose Garcia Ripoll) Date: Wed, 29 Jun 2005 19:35:11 +0200 Subject: [fetter-devel] ECL Message-ID: <42C2DBCF.1050705@mpq.mpg.de> Hi, my understanding is that this mailing list is devoted to both the FFI autogenerator "Fetter" and the "Hello-C" FFI. If I am not wrong, then let me now introduce myself. My name is Juanjo and I currently develop a Common-Lisp implementation called ECL (http://ecls.sf.net). This implementation belongs to the Kyoto Common-Lisp family, much like GCL, and supports compilation to both bytecodes and C/C++. In the last months Michael Goffiou and myself have extended ECL's FFI and in the process we modeled it after the UFFI specification. This has been quite a success, with minor projects that include several parts of ECL (BSD-SOCKETS, and a Win32-bridge to name two), SDL bindings, etc. The next logical step for us will be to implement callbacks, and motivated by our previous success it would be nice to fix on some interface which is at least compatible with what people use, let it be UFFI, CFFI, Hello-C or whatever. In general, we are willing to extend ECL in any appropiate direction, even if it means revamping the core of the lisp implementation itself. Regards, Juanjo -------------- next part -------------- A non-text attachment was scrubbed... Name: jlr.vcf Type: text/x-vcard Size: 389 bytes Desc: not available URL: From rayiner at gmail.com Thu Jun 30 02:43:36 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Wed, 29 Jun 2005 22:43:36 -0400 Subject: [fetter-devel] ECL In-Reply-To: <42C2DBCF.1050705@mpq.mpg.de> References: <42C2DBCF.1050705@mpq.mpg.de> Message-ID: Hi, welcome to the list! > In the last months Michael Goffiou and myself have extended ECL's FFI > and in the process we modeled it after the UFFI specification. This has > been quite a success, with minor projects that include several parts of > ECL (BSD-SOCKETS, and a Win32-bridge to name two), SDL bindings, etc. > The next logical step for us will be to implement callbacks, and > motivated by our previous success it would be nice to fix on some > interface which is at least compatible with what people use, let it be > UFFI, CFFI, Hello-C or whatever. > > In general, we are willing to extend ECL in any appropiate direction, > even if it means revamping the core of the lisp implementation itself. That's great. I think right now hello-c is in conceptual development, so implementors will have to wait a little bit to see what it looks like. Perhaps Luis can chime in on any comments he has? Speaking for myself, I know I'd appreciate any comments you'd have on the design of fetter. An initial design document should be appearing in a couple of days, so after that's out, perhaps you'd like to comment on it? Sincerely, Rayiner Hashem > Regards, > > Juanjo > > > _______________________________________________ > fetter-devel mailing list > fetter-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel > > > > From ktilton at nyc.rr.com Thu Jun 30 03:57:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 29 Jun 2005 23:57:58 -0400 Subject: [fetter-devel] Re: CFFI progress In-Reply-To: <55e3b745aa12e271ddcb05424a812c84@gmail.com> References: <55e3b745aa12e271ddcb05424a812c84@gmail.com> Message-ID: <42C36DC6.1080203@nyc.rr.com> Luis Oliveira wrote: > Hello, > > So, here's my (well mostly James') list of ideas and todo items > for CFFI: > > -> Port to more implementations. > -> Callbacks. > -> Foreign globals. Sounds reasonable. I just never encountered that. This means, however, an autogenerated C DLL to create a C interface? > > -> Pushing things like #+cffi/callbacks onto *features*. > -> FOREIGN-SLOT-VALUE: let it take multiple "indices" for directly > accessing structs inside structs, arrays inside structs, etc... Hmm, not appearing clearly in my mind's eye. But I get the drift/value if feasible. > > -> Type-checking pointer interface. OK, interesting. I went the other way: one type-trusting interface, one autoconverting interface. > > -> well.. and a high-level interface, like CLISP's :-) > -> Complete uffi-compat. Irrelevant, but see below. > > -> Documentation. > -> More tests/examples. > > The uffi-compat thing is very interesting. We don't have to worry > about backwards compatibility at all. CFFI has 0 users. Yet > uffi-compat will allow automatic access to what has already been > uffi-ized. "automatic access" has practically zero value. We will not diverge from UFFI gratuitously, so if it was a good interface it will survive largely unchanged even with the new underpinnings. If it was a sucky interface, we /want/ to kill it. If the latter obtains, automatic access will not fly. If, however, the UFFI API survives largely intact, a set of UFFI bindings can be transformed in a few hours. This equals "practically zero value" for backward compatibility. -- Kenny Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page From luismbo at gmail.com Thu Jun 30 02:42:12 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Thu, 30 Jun 2005 03:42:12 +0100 Subject: [fetter-devel] ECL In-Reply-To: <42C2DBCF.1050705@mpq.mpg.de> References: <42C2DBCF.1050705@mpq.mpg.de> Message-ID: <085e506782f4543c73cdcc98de3d66d9@gmail.com> On 29/jun/2005, at 18:35, Juan Jose Garcia Ripoll wrote: > my understanding is that this mailing list is devoted to both the FFI > autogenerator "Fetter" and the "Hello-C" FFI. Yes. :-) I just read your post on cll about Hello-C and UFFI vs. CFFI. You mention UFFI has more features than CFFI and that is true. I would like to mention, though, that the CFFI approach is very different from that of UFFI. UFFI tries to normalize/wrap/etc the FFI's of the various lisps. CFFI on the other hand requests a few low-level operators from the lisp and implements (or will implement) a FFI on top of that, bypassing the lisp's FFI. For example, on SBCL CFFI doesn't use sb-alien, it uses system-area-pointer's directly. I like this approach. I'm of course very interested in your views regarding the CFFI approach vs. UFFI approach and FFI's in general. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt From lisp at arrakis.es Thu Jun 30 07:53:41 2005 From: lisp at arrakis.es (Juan Jose Garcia Ripoll) Date: Thu, 30 Jun 2005 09:53:41 +0200 Subject: [fetter-devel] Sorry Message-ID: <42C3A505.2030608@arrakis.es> I am sorry if my previous two posts are causing a lot of troubles to the list administrators -- I am using mozilla, and I always forget to use the email address with which I subscribed and rather post with the address from other accounts. I will pay more attention next time :-) Juanjo From jamesjb at jamesjb.com Thu Jun 30 07:56:29 2005 From: jamesjb at jamesjb.com (James Bielman) Date: Thu, 30 Jun 2005 00:56:29 -0700 Subject: [fetter-devel] Re: CFFI progress In-Reply-To: <42C36DC6.1080203@nyc.rr.com> (Kenny Tilton's message of "Wed, 29 Jun 2005 23:57:58 -0400") References: <55e3b745aa12e271ddcb05424a812c84@gmail.com> <42C36DC6.1080203@nyc.rr.com> Message-ID: [Hi Kenny, I guess we should have talked about FFIs at ILC too, eh?] I'm just entering this discussion, so I'm not quite sure what you guys are planning to do with Hello-C / CFFI / etc. (Stop me if you know all this already, just making sure since I've never really officially announced this library or anything...) As I understand it, the goal of Hello-C is to add callbacks and support for additional Lisp implementations to a fork of UFFI. CFFI is a pretty different animal, in that it tries to define an low-level interface for frobbing memory and foreign functions, then implement the remainder of the foreign type system in portable code. Check out the CFFI-SYS draft specification available at http://common-lisp.net/project/cffi for details on the system interface. CFFI can also be more efficient than UFFI on CMUCL and SBCL since it uses system area pointers directly instead of consing up alien objects that carry around redundant type information at run-time (and require lots of type/inline declarations to optimize away). However, it's also less mature than UFFI. In fact, it's only 3 weeks old, and doesn't support as many Lisp implementations, because CFFI is asks a bit more of the Lisp implementor (providing the low-level operations to implement the CFFI-SYS interface). Anyway, I'll elaborate a little on this list of open issues: Kenny Tilton writes: > Luis Oliveira wrote: >> >> [ideas for things to work on in cffi] >> >> -> Foreign globals. > > Sounds reasonable. I just never encountered that. This means, however, > an autogenerated C DLL to create a C interface? UFFI does this already with DEF-FOREIGN-VAR. I think all Lisps supported by UFFI can do this without generating any sort of C stubs. >> -> FOREIGN-SLOT-VALUE: let it take multiple "indices" for directly >> accessing structs inside structs, arrays inside structs, > > Hmm, not appearing clearly in my mind's eye. But I get the drift/value > if feasible. The idea here is to make FOREIGN-SLOT-VALUE sort of like AREF: (defcstruct timeval (tv-secs :long) (tv-usecs :long)) (defcstruct employee (name :char 255) (hire-date timeval)) (with-foreign-object (emp employee) ;; obj type slot-1 slot-2... (setf (foreign-slot-value emp 'employee 'hire-date 'tv-secs) 10204242) ;; This is like 'emp.hire_date.tv_secs' in C... ...) >> -> Type-checking pointer interface. > > OK, interesting. I went the other way: one type-trusting interface, > one autoconverting interface. Indeed, I don't really care too much about the type-checking, but others might. One of reasons I like defining the bulk of the foreign type system in terms of low-level memory operations is that we can experiment with different foreign type systems in a portable way. This is certainly not a high priority for me though. > "automatic access" has practically zero value. We will not diverge > from UFFI gratuitously, so if it was a good interface it will > survive largely unchanged even with the new underpinnings. If it was > a sucky interface, we /want/ to kill it. If the latter obtains, > automatic access will not fly. If, however, the UFFI API survives > largely intact, a set of UFFI bindings can be transformed in a few > hours. This equals "practically zero value" for backward > compatibility. I'm not really sure what you mean here. In CFFI, I've pretty much thrown out the UFFI interface and written my own. In particular, everything that can conceivably be a function is a function, in contrast to UFFI which consists almost entirely of macros (many of which can be confusing WRT what gets evaluated on which Lisp). CFFI-UFFI-COMPAT maps the thrown-out UFFI interface back to my new interface (minus some lossage currently with arrays, CFFI does arrays quite differently from UFFI). CFFI-UFFI-COMPAT has quite a bit of value to me because I can build existing libraries like CLSQL, get a performance boost on SBCL, and not have to change the code (and indeed I've successfully built the CLSQL-SQLite3 backend using CFFI-UFFI-COMPAT). James From ktilton at nyc.rr.com Thu Jun 30 15:40:29 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 30 Jun 2005 11:40:29 -0400 Subject: [fetter-devel] Re: CFFI progress In-Reply-To: References: <55e3b745aa12e271ddcb05424a812c84@gmail.com> <42C36DC6.1080203@nyc.rr.com> Message-ID: <42C4126D.1050504@nyc.rr.com> James Bielman wrote: >[Hi Kenny, I guess we should have talked about FFIs at ILC too, eh?] > yes, who knew? i was delighted to discover who was behind cffi. :) > >I'm just entering this discussion, so I'm not quite sure what you guys >are planning to do with Hello-C / CFFI / etc. > >(Stop me if you know all this already, just making sure since I've >never really officially announced this library or anything...) > >As I understand it, the goal of Hello-C is to add callbacks and >support for additional Lisp implementations to a fork of UFFI. > Well, no, the goal is a truly universal FFI, in both functionality (adding callbacks) and Lisps supported. We /thought/ that would mean extending UFFI, but CFFI has us wondering if a better approach is possible. And let's not forget the possibility of a hybrid approach. I know UFFI on CMUCL has a history of performance problems. Maybe we go the CFFI route with CMUCL and let other Lisps' FFIs handle things themselves? > >CFFI is a pretty different animal, in that it tries to define an >low-level interface for frobbing memory and foreign functions, then >implement the remainder of the foreign type system in portable code. >Check out the CFFI-SYS draft specification available at >http://common-lisp.net/project/cffi for details on the system >interface. > Good lord, man, you wrote a spec?! I do not even document things when they are released to the public! :) > >CFFI can also be more efficient than UFFI on CMUCL and SBCL since it >uses system area pointers directly instead of consing up alien objects >that carry around redundant type information at run-time (and require >lots of type/inline declarations to optimize away). > OK. > >However, it's also less mature than UFFI. In fact, it's only 3 weeks >old, and doesn't support as many Lisp implementations, because CFFI is >asks a bit more of the Lisp implementor (providing the low-level >operations to implement the CFFI-SYS interface). > I see two concerns: - will every Lisp support CFFI with the necessary low-level ops - are the low-level ops exported / stable / reliable / supported? - will CFFI sometimes be less effective than the implementation FFI? For example, Franz indicates their native sockets package works better with their MP code, so in MP situations would run better than a generic solution using winsock or native BSD sockets via the FFI. Again, a hybrid approach means not every Lisp must support CFFI. > >Anyway, I'll elaborate a little on this list of open issues: > >Kenny Tilton writes: > > > >>Luis Oliveira wrote: >> >> >>>[ideas for things to work on in cffi] >>> >>> -> Foreign globals. >>> >>> >>Sounds reasonable. I just never encountered that. This means, however, >>an autogenerated C DLL to create a C interface? >> >> > >UFFI does this already with DEF-FOREIGN-VAR. I think all Lisps >supported by UFFI can do this without generating any sort of C stubs. > Doh! Actually, this reminds me: I have done a lot of FFI work, but I have managed to get by with a subset of FFI capablities, so I have some blind spots. > > > >>> -> FOREIGN-SLOT-VALUE: let it take multiple "indices" for directly >>> accessing structs inside structs, arrays inside structs, >>> >>> >>Hmm, not appearing clearly in my mind's eye. But I get the drift/value >>if feasible. >> >> > >The idea here is to make FOREIGN-SLOT-VALUE sort of like AREF: > >(defcstruct timeval > (tv-secs :long) > (tv-usecs :long)) > >(defcstruct employee > (name :char 255) > (hire-date timeval)) > >(with-foreign-object (emp employee) > ;; obj type slot-1 slot-2... > (setf (foreign-slot-value emp 'employee 'hire-date 'tv-secs) 10204242) > ;; This is like 'emp.hire_date.tv_secs' in C... > ...) > Gotcha. Again, I have gotten by with merely functional FFI, never hack data structures. Looks like some introspection is needed, but nothing serious. > > > >>> -> Type-checking pointer interface. >>> >>> >>OK, interesting. I went the other way: one type-trusting interface, >>one autoconverting interface. >> >> > >Indeed, I don't really care too much about the type-checking, but >others might. One of reasons I like defining the bulk of the foreign >type system in terms of low-level memory operations is that we can >experiment with different foreign type systems in a portable way. > >This is certainly not a high priority for me though. > > > >>"automatic access" has practically zero value. We will not diverge >>from UFFI gratuitously, so if it was a good interface it will >>survive largely unchanged even with the new underpinnings. If it was >>a sucky interface, we /want/ to kill it. If the latter obtains, >>automatic access will not fly. If, however, the UFFI API survives >>largely intact, a set of UFFI bindings can be transformed in a few >>hours. This equals "practically zero value" for backward >>compatibility. >> >> > >I'm not really sure what you mean here. > That was just a long argument against worrying about backward compatibility. > In CFFI, I've pretty much >thrown out the UFFI interface and written my own. In particular, >everything that can conceivably be a function is a function, in >contrast to UFFI which consists almost entirely of macros (many of >which can be confusing WRT what gets evaluated on which Lisp). > Yep. I think KMR realizes this and would cure in UFFI2. > >CFFI-UFFI-COMPAT maps the thrown-out UFFI interface back to my new >interface (minus some lossage currently with arrays, CFFI does arrays >quite differently from UFFI). > Yep, this is a fine approach. Forget UFFI, then recover it later as an optional, alternative API. > >CFFI-UFFI-COMPAT has quite a bit of value to me because I can build >existing libraries like CLSQL, get a performance boost on SBCL, and >not have to change the code (and indeed I've successfully built the >CLSQL-SQLite3 backend using CFFI-UFFI-COMPAT). > Yep. Was that no changes at all, or "just a few" tweaks? Up above I was saying that, if and only if we had to break backward compatibility with UFFI, that that would not be the end of the world if we kept the breakage to a minimum. -- Kenny Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page From jlr at mpq.mpg.de Thu Jun 30 07:50:29 2005 From: jlr at mpq.mpg.de (Juan Jose Garcia Ripoll) Date: Thu, 30 Jun 2005 09:50:29 +0200 Subject: [fetter-devel] ECL In-Reply-To: <085e506782f4543c73cdcc98de3d66d9@gmail.com> References: <42C2DBCF.1050705@mpq.mpg.de> <085e506782f4543c73cdcc98de3d66d9@gmail.com> Message-ID: <42C3A445.20008@mpq.mpg.de> Luis Oliveira wrote: > UFFI tries to normalize/wrap/etc the FFI's of the various lisps. CFFI > on the other hand requests a few low-level operators from the lisp and > implements (or will implement) a FFI on top of that, bypassing the > lisp's FFI. For example, on SBCL CFFI doesn't use sb-alien, it uses > system-area-pointer's directly. I like this approach. > I'm of course very interested in your views regarding the CFFI > approach vs. UFFI approach and FFI's in general. Well, right now I have only two thoughts because I did not have much time to think about it, but they are: 1) Your handling of pointers is like the low-level layer we have for implementing UFFI. ECL has an object type which is called "foreign", which is basically a pointer to some memory. It may have been allocated by ECL or not. These objects are more than just SBCL's system areal pointers because they are not plain integers: they are a structure with a pointer, the size of the pointed area if known and a flag for the garbage collector. All other primitives, such as foreign type sizes and alignments are there, too, since our interface for accessing structures and other C objects is built almost entirely in lisp. Furthermore, we also have primitives for storing/retreiving typed objects from pointers, although not the vectorized versions. 2) I have seen you have a single primitive, "%foreing-function-call", which can call a pointer with any number of types. Even though this may be implementable even in C (with a type cast), I do not very much like the idea. Personally I prefer wrappers. The reason is that, unlike other lisps, ECL can link its code against that of the C libraries. Currently, there is redundancy because we use not only the type declarations provided by the user in the FFI, but also those of the C headers of the code we are to link against. This means the C compiler can double-check the declarations made by the lisper and ensure everything will go right. Juanjo -------------- next part -------------- A non-text attachment was scrubbed... Name: jlr.vcf Type: text/x-vcard Size: 389 bytes Desc: not available URL: From jlr at mpq.mpg.de Thu Jun 30 07:51:27 2005 From: jlr at mpq.mpg.de (Juan Jose Garcia Ripoll) Date: Thu, 30 Jun 2005 09:51:27 +0200 Subject: [fetter-devel] ECL In-Reply-To: References: <42C2DBCF.1050705@mpq.mpg.de> Message-ID: <42C3A47F.4040107@mpq.mpg.de> Rayiner Hashem wrote: >>In general, we are willing to extend ECL in any appropiate direction, >>even if it means revamping the core of the lisp implementation itself. >> >> >That's great. I think right now hello-c is in conceptual development, >so implementors will have to wait a little bit to see what it looks >like. Perhaps Luis can chime in on any comments he has? Speaking for >myself, I know I'd appreciate any comments you'd have on the design of >fetter. An initial design document should be appearing in a couple of >days, so after that's out, perhaps you'd like to comment on it? > Very much indeed! Please keep me informed. Juanjo -------------- next part -------------- A non-text attachment was scrubbed... Name: jlr.vcf Type: text/x-vcard Size: 389 bytes Desc: not available URL: