February 2006 - cffi-devel - mailman3.common-lisp.net

[cffi-devel] Unexpected return
by N. Raghavendra 23 Feb '06

23 Feb '06

I hope this is not OT. I am trying to learn to use CFFI. Following the CFFI manual, I wrote the following functions, which call some basic C time functions. According to gmtime(3), the function `gmtoff' below should always return 0. However, I consistently get TIMEZONE-FFI> (gmtoff) 672421260 I would appreciate any hints as to where I am erring. In case it is relevant, the environment is CMUCL 19c on FreeBSD 6.0-STABLE. TIA, Raghavendra. --- code follows --- (defpackage #:timezone-ffi (:use #:common-lisp #:cffi)) (in-package #:timezone-ffi) (defcstruct tm (sec :int) (min :int) (hour :int) (mday :int) (mon :int) (year :int) (wday :int) (yday :int) (isdst :boolean) (zone :string) (gmtoff :long)) (defctype time :int) (defcfun ("time" %time) time (tp :pointer)) (defcfun (gmtime %gmtime) :pointer (tp :pointer)) ;; Should return 0 always. (defun gmtoff () (with-foreign-object (tp 'time) (setf (mem-ref tp 'time) (%time (null-pointer))) (foreign-slot-value (%gmtime tp) 'tm 'gmtoff))) -- N. Raghavendra <raghu(a)mri.ernet.in> | See message headers for contact Harish-Chandra Research Institute | and OpenPGP details.

2 2

Re: [cffi-devel] CFFI 0.9.0 Release
by Hoehle, Joerg-Cyril 23 Feb '06

23 Feb '06

James Bielman wrote: >I've released the current darcs version of CFFI as 0.9.0. The darcs >tree has been tagged and checkpointed You should do that more often, because it creates shorter patch files. Previously, a tiny 10 line patch had 40KB worth of context. That is gone since you tagged cffi recently. Context is now much smaller. >I consider this the "beta" release leading up to a real 1.0 version. Of course, you're free to tag any version with any number you like. Here are points I'd like to see addressed: 1. IMHO CFFI should not go 1.0 prior to acknowledging that there's a relationship between functions and libraries (i.e. UFFI's :module keyword). Arseny has a case on MS-Windows where there are two versions of sprintf in different MS .dlls. One does not pass some tests, the other does. So far, CFFI does not allow the user to control which functions gets loaded from there. I consider this a *huge* misfeature. 2. I suggest you add the block operations API with my suggestions (from monthes ago). It's trivial to implement naively, and it would do users good to be able to use it (even CFFI code can benefit from it, there currently are a few block loops here and there). Later CVS versions may then add optimized versions for special cases. 3. (trivial): provide a uffi.asd file in a subdirectory, so people can load that and play with programs using ASDF and UFFI. A system named uffi-compat is IMHO useless, because these programs have ASDF look for a system named #:uffi. Regards, Jorg

3 3

[cffi-devel] New TopUSAJobs Best Job offer jT
by MakeUSA-Job 23 Feb '06

23 Feb '06

1 0

[cffi-devel] New CareerBuilder.com Job opportunity OV
by Career-Builder 23 Feb '06

23 Feb '06

1 0

[cffi-devel] A somewhat trollish idea
by Attila Lendvai 21 Feb '06

21 Feb '06

Hi! Recently i've made a project to use graphviz from lisp code through cffi (cl-graphviz at http://common-lisp.net) In the process i used the cffi generator of SWIG. It was not perfect so i've taken a look at the source which is in c++. Then i gave up early... :) And the idea: the CFFI/SWIG integration could be done in a different philosophy, where SWIG were used only as a c++ parser and the CFFI generator would be lisp code walking the C side parsed representation (using CFFI). The idea is trollish, because i did not invest enough time to see the big picture, but the generated file had serious trouble with statements like #define FOO (1<<2)|(1<<3). The generator (written in C++) was trying to interpret it with not so much luck. It would be simpler in lisp, and then you could also generate the project specific lisp-side API right on. The problem in general is not simple, because the value in a #define is a plain string, and it's sci-fi to start a C++ parser on that sniplet and walk the AST. In normal circumstances (c++ compiler) that define would go away in the preprocessor stage, but in an FFI you want to use the named values from lisp. Enough trolling for now, and thanks for all the work on CFFI, it's great! - attila (alias 101 on irc &no 'its not lisp code :)

2 1

[cffi-devel] New patches: 19-Feb-2006
by loliveira＠common-lisp.net 20 Feb '06

20 Feb '06

Sun Feb 19 22:48:13 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Make CLISP not throw an error on undefined functions - Catch the error in %foreign-funcall and throw a warning instead. - Regression test: DEFCFUN.UNDEFINED. (CMUCL fails) M ./src/cffi-clisp.lisp -5 +11 M ./tests/defcfun.lisp +11 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060219.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Status of the ECL Backend
by James Bielman 19 Feb '06

19 Feb '06

Hi, I tried to compile and test the CFFI backend for ECL using the latest CVS and ran into problems related to type translators and the ECL fasl dumper apparently not respecting MAKE-LOAD-FORM. I don't know if anyone is using the ECL backend for CFFI, but I'll try to prepare a proper bug report for the ECL folks... James

1 0

[cffi-devel] New patches: 17-Feb-2006
by loliveira＠common-lisp.net 18 Feb '06

18 Feb '06

Fri Feb 17 14:44:57 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Fix LOOP indentation in backends. - Thanks for Luís for showing me how to configure Emacs to get this right. M ./src/cffi-allegro.lisp -3 +3 M ./src/cffi-clisp.lisp -1 +1 M ./src/cffi-cmucl.lisp -15 +12 M ./src/cffi-ecl.lisp -1 +1 M ./src/cffi-lispworks.lisp -3 +3 M ./src/cffi-openmcl.lisp -12 +9 M ./src/cffi-sbcl.lisp -15 +12 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060217.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

Re: [cffi-devel] New patches: 3-Feb-2006: x86-64
by Hoehle, Joerg-Cyril 17 Feb '06

17 Feb '06

James, >Sorry... here's my train of thought: I wanted to support long long on >CLISP either based on the version or whether it is built for a 64-bit >target (amd64). I'm not sure this makes sense. I'd try this: o if it's a 64bit machine, assume longlong has always worked (since it's equal to long). o otherwise, check it's >2.38 (you cannot AFAIK detect the CVS number, so this check would currently fail...) Maybe this would work for the first test? (= (ffi:sizeof 'ffi:long) (sizeof 'ffi:int64)) In fact, that should be the precise test to detect whether longlong worked in the past: when long was used instead, there was no problem. Regards, Jorg Hohle

1 0

[cffi-devel] [ANN] SWIG Release - 1.3.28 - with CFFI
by efuzzyone＠netscape.net 17 Feb '06

17 Feb '06

The SWIG Development team has released SWIG 1.3.28, which now supports CFFI. http://www.swig.org/download.html Full Announcement: *** ANNOUNCE: SWIG 1.3.28 (February 12, 2006) *** http://www.swig.org We're pleased to announce SWIG-1.3.28, the latest installment in the SWIG development effort. SWIG-1.3.28 includes a number of bug fixes and large number of enhancements throughout. What is SWIG? ------------- SWIG is a software development tool that reads C/C++ header files and generates the wrapper code needed to make C and C++ code accessible from other languages including Perl, Python, Tcl, Ruby, PHP, Java, Scheme (Guile, MzScheme, CHICKEN), Ocaml, Lua, Pike, C#, Modula-3, and Common Lisp (CLISP, Allegro CL, CFFI, UFFI). SWIG can also export its parse tree in the form of XML and Lisp s-expressions. Major applications of SWIG include generation of scripting language extension modules, rapid prototyping, testing, and user interface development for large C/C++ systems. Availability: ------------- The release is available for download on Sourceforge at http://prdownloads.sourceforge.net/swig/swig-1.3.28.tar.gz A Windows version should also be available at http://prdownloads.sourceforge.net/swig/swigwin-1.3.28.zip What's New? =========== SWIG-1.3.28 summary: - More powerful renaming (%rename) capability. - More user friendly warning handling. - Add finer control for default constructors and destructors. We discourage the use of the 'nodefault' option, which disables both constructors and destructors, leading to possible memory leaks. Use instead 'nodefaultctor' and/or 'nodefaultdtor'. - Automatic copy constructor wrapper generation via the 'copyctor' option/feature. - Better handling of Windows extensions and types. - Better runtime error reporting. - Add the %catches directive to catch and dispatch exceptions. - Add the %naturalvar directive for more 'natural' variable wrapping. - Better default handling of std::string variables using the %naturalvar directive. - Add the %allowexcept and %exceptionvar directives to handle exceptions when accessing a variable. - Add the %delobject directive to mark methods that act like destructors. - Add the -fastdispatch option to enable smaller and faster overload dispatch mechanism. - Template support for %rename, %feature and %typemap improved. - Add/doc more debug options, such as -dump_module, -debug_typemaps, etc. - Unified typemap library (UTL) potentially providing core typemaps for all scripting languages based on the recently evolving Python typemaps. - New language module: Common Lisp with CFFI. - Python, Ruby, Perl and Tcl use the new UTL, many old reported and hidden errors with typemaps are now fixed. - Initial Java support for languages using the UTL via GCJ, you can now use Java libraries in your favorite script language using gcj + swig. - PHP4 module update, many error fixes and actively maintained again. - Allegrocl support for C++, also enhanced C support. - Ruby support for bang methods. - Ruby support for user classes as native exceptions. - Perl improved dispatching in overloaded functions via the new cast and rank mechanism. - Perl improved backward compatibility, 5.004 and later tested and working. - Python improved backward compatibility, 1.5.2 and later tested and working. - Python can use the same cast/rank mechanism via the -castmode option. - Python implicit conversion mechanism similar to C++, via the %implicitconv directive (replaces and improves the implicit.i library). - Python threading support added. - Python STL support improved, iterators are supported and STL containers can use now the native PyObject type. - Python many performance options and improvements, try the -O option to test all of them. Python runtime benchmarks show up to 20 times better performance compared to 1.3.27 and older versions. - Python support for 'multi-inheritance' on the python side. - Python simplified proxy classes, now swig doesn't need to generate the additional 'ClassPtr' classes. - Python extended support for smart pointers. - Python better support for static member variables. - Python backward compatibility improved, many projects that used to work only with swig-1.3.21 to swig-1.3.24 are working again with swig-1.3.28 - Python test-suite is now 'valgrinded' before release, and swig also reports memory leaks due to missing destructors. - Minor bug fixes and improvements to the Lua, Ruby, Java, C#, Python, Guile, Chicken, Tcl and Perl modules. Release numbers --------------- With SWIG-1.3, we are adopting an odd/even version numbering scheme for SWIG. Odd version numbers (1.3, 1.5, 1.7, etc...) are considered to be development releases. Even numbers (1.4,1.6,1.8) are stable releases. The current 1.3 effort is working to produce a stable 2.0 release. A stable 2.0 release will not be made until it can accompanied by fully updated documentation. In the meantime, we will continue to make periodic 1.3.x releases. We need your help! ------------------ Even if you are perfectly happy with SWIG-1.1, we can still use your feedback. First, we like to know about compilation problems and other issues concerning the building of SWIG. Second, if SWIG-1.3 is unable to compile your old interface files, we would like to get information about the features you are using. This information will help us find bugs in the SWIG-1.3 release, develop techniques for supporting backwards compatibility, and write documentation that addresses specific issues related to migrating from SWIG-1.1 to SWIG-1.3. We are also looking for volunteers who would like to work on various aspects of SWIG development. SWIG is an unfunded project that would not exist without volunteers. We are also looking for the developers of other SWIG language modules. If you have developed a SWIG module and would like to see it incorporated into the new release, please contact us to obtain SWIG-CVS access. We are also more than willing to help port your module from SWIG-1.1 to SWIG-1.3. Please send email to beazley(a)cs.uchicago.edu for further information. Please report problems with this release to the swig-dev mailing list, details at http://www.swig.org/mail.html. --- The SWIG Developers

1 0