cffi-devel February 2007

cffi-devel@common-lisp.net

17 participants
19 discussions

[cffi-devel] Documentation Feature Request
by Heiko Schröter 28 Feb '07

28 Feb '07

Hello list, sorry if this has been asked before. I've been trying to interface sbcl to the gsl library especially passing vectors and/or matrices. The docs state that there is no :array type. Is it somehow possible to interface to the gsl library to do e.g. spline or matrix ops ? If it is possible it would be nice to have one or two examples in the docs. Thanks and Regards Heiko Schroeter

3 2

[cffi-devel] Get 1000's of Highly Targeted visitors to your web site or affiliate web site overnight
by Instant＠common-lisp.net 27 Feb '07

27 Feb '07

1 0

[cffi-devel] How would you like 2 Million Sites linking to your ad ?
by BlogBlaster＠common-lisp.net 25 Feb '07

25 Feb '07

1 0

[cffi-devel] Foreign string encodings
by Luís Oliveira 24 Feb '07

24 Feb '07

Hello, Just letting this list know that the cffi-newtypes branch at <http://common-lisp.net/~loliveira/darcs/cffi-newtypes/> includes, in addition to the new type system, a forward port of James' cffi-encodings branch. In addition to CLISP and SBCL support already provided by the cffi-encodings patches, cffi-newtypes includes support for OpenMCL, Lispworks and Allegro. The original discussion can be found here: Subject: a thought on string encodings <http://thread.gmane.org/gmane.lisp.cffi.devel/292> -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

Re: [cffi-devel] Messing with foreign types some more
by Luís Oliveira 23 Feb '07

23 Feb '07

[hmm, it seems my previous message didn't go to the list by mistake] On 22/02/07, Luís Oliveira <luismbo(a)gmail.com> wrote: > There's no rush. We should get this right. I put my changes here: > <http://common-lisp.net/~loliveira/darcs/cffi-newtypes/>. It includes > some updated documentation. Here are some random thoughts after a few days of using this. - There's no direct way of doing inheritance with enum, bitfield, union or struct types. One can use composition, of course, so it's not too terrible. - No inheritance for define-parse-method either. One way to minimize the effects of this would be to make the :simple-parser option smarter that would, for instance, look at the class' initargs and automatically add those to the parser's lambda list as keyword arguments. - I'm not sure I like the name :simple-parser. Maybe :default-parser. - The common case of defining new types with translations but no arguments got slightly more verbose. Not sure if it's worth worrying about this. - I suppose we should export foreign-string-type, foreign-boolean-type, foreign-pointer-type, etc, so the users can extend these. - That reminds that :actual-type might be misleading coming from the previous system. Specifying :actual-type :string won't inherit any of foreign-string-type's translators, for instance. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] New patches: 21-Feb-2007
by loliveira＠common-lisp.net 22 Feb '07

22 Feb '07

Wed Feb 21 19:52:13 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * New file: uffi-compat/uffi.asd A ./uffi-compat/uffi.asd Wed Feb 21 19:49:17 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Update TODO list Removed some stuff that's already been implemented, etc... M ./TODO -15 +4 Wed Feb 21 19:08:28 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Simplify load-foreign-library-error. M ./src/libraries.lisp -5 +4 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-070221.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Summary of junk emails blocked
by Admin Junk Summary 21 Feb '07

21 Feb '07

Junk Box Summary for: cffi-devel(a)common-lisp.net The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 7 days. To retrieve any of these messages, visit your Junk Box at: <http://apollo.qtlc.it> Login using your standard username/password combination. Junk Box Summary --------------------------------------------------------------------- oiweybajg(a)netflash.com.br 500.- start bonus, play 1 hour for free and keep all wins --------------------------------------------------------------------- Junk blocking by MailFrontier, Inc.

1 0

Re: [cffi-devel] Messing with foreign types some more
by Luís Oliveira 19 Feb '07

19 Feb '07

On 18/02/07, Robert Goldman <rpgoldman(a)real-time.com> wrote: > I was just looking at this and wondering if it would bust my port of > mcclim's freetype from SBCL-specific aliens to CFFI. It won't, because AFAICT you don't use type translation at all in that code. The gtkcairo bindings should have no problems either. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] Messing with foreign types some more
by Luís Oliveira 17 Feb '07

17 Feb '07

Hello, I just had another go at simplifying the type system. Here's an overview of what changed: 1 - (DEFCTYPE new-type base-type) becomes just a simple way of defining an alias. The user cannot define translations for new-type and there will be no translation overhead unless base-type already has translations. This removes the need for the :TRANSLATE-P optimization option. 2 - The new macro (DEFINE-FOREIGN-TYPE new-type supers slots &rest options) becomes the canonical way of defining complex types with translations. This is a thin wrapper around DEFCLASS. 2a - The new macro (DEFINE-PARSE-METHOD type-name lambda-list &body body) will be used to parse the type specifications (e.g. '(:string :encoding :utf-8)) and should return an instance of a subclass of FOREIGN-TYPE. 2b - Translator/expander methods should now specialize on type instead of using EQL specializers. So now the type specifications can easily take options through the above parse-method, save them in some slot (defined through DEFINE-FOREIGN-TYPE) and -- here's the big advantage -- the translators can have a look at those options and take appropriate action. 2c - For the simple case where the user wants to define a translation but doesn't need to parse options, DEFINE-FOREIGN-TYPE takes a (:SIMPLE-PARSER name) option that will automatically generate: (define-parse-method name () (make-instance 'some-type)) 3 - The translator generic functions no longer have that ad-hoc method combination. If the user wants to chain the translations of her type's superclasses then she should invoke CALL-NEXT-METHOD explicitly. I believe this method combination of ours was crippling inheritance. Compare the new :string+ptr type definition with the previous one for an example of what I mean. A side-effect of these changes is that we no longer need two separate mechanisms for dealing with real types (instances of FOREIGN-TYPE) and user types (plain symbols). That translates into ~100 less lines of code. Here's the patch: <http://common-lisp.net/~loliveira/patches/more-foreign-types.diff> This is heavily backwards incompatible wrt the type system interface so I'll wait and see if there any objections before I commit it. Comments and suggestions are welcome, as usual. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] CLisp finalizers
by Marco Gidde 15 Feb '07

15 Feb '07

Hi, as mentioned on this list CLisp has some problems with the finalization code provided by CFFI. I guess this is due to accessing the weak hash table within the finalizer. The following code works around this problem by closing the "main finalizer" over the list of the "sub finalizers". (in-package :cffi-sys) (defvar *finalizers* (make-hash-table :test 'eq :weak :key) "Weak hashtable that holds registered finalizers.") (defun finalize (object function) "Pushes a new FUNCTION to the OBJECT's list of finalizers. FUNCTION should take no arguments. Returns OBJECT. For portability reasons, FUNCTION should not attempt to look at OBJECT by closing over it because, in some lisps, OBJECT will already have been garbage collected and is therefore not accessible when FUNCTION is invoked." (multiple-value-bind (finalizers present-p) (gethash object *finalizers* (cons 'finalizers nil)) (unless present-p (setf (gethash object *finalizers*) finalizers) (ext:finalize object (lambda (obj) (declare (ignore obj)) (mapc #'funcall (cdr finalizers))))) (push function (cdr finalizers))) object) (defun cancel-finalization (object) "Cancels all of OBJECT's finalizers, if any." (multiple-value-bind (finalizers present-p) (gethash object *finalizers*) (when present-p (setf (cdr finalizers) nil))) (remhash object *finalizers*)) While this code isn't as short and elegant as the original code, at least it works ;-) Regards, Marco

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel February 2007