cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[cffi-devel] ELS 2009 in Milan, Italy: Call for Participation
by Marco Antoniotti 15 Apr '09

15 Apr '09

Apologies for multiple postings.... ************************************************************************ 2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Universita` degli Studi di Milano-Bicocca www.european-lisp-symposium.org ************************************************************************ CALL FOR PARTECIPATION ********************** REGISTRATION IS NOW OPEN AT www.european-lisp-symposium.org. Take advantage of the early bird registration fee. Scope and Program Highlights: ***************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 program includes presentations of high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. Kent Pitman will give the keynote address on Thursday, May 28. The presentations will be divided into two categories. * Original contributions. * Work in progress describing ongoing work that will be discussed in the form of a "writers' workshop". The writers' workshops will take place at the symposium in Milan on May 28, 2008. Social Events: ************** Friday 29th evening, Conference Banquet Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in the center of Milan; 2009 marks the 100th anniversary of the Futurism Manifesto; stretching it, the harbinger of Lisp 50 years later. Program Chair: ************** * Antonio Leitao, Technical University of Lisbon, Portugal Local Chair: ************ * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy Program committee: ****************** * Giuseppe Attardi, Universita`† di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Universite` Bordeaux 1, France * Marc Feeley, Universit` de Montreal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, PTC, USA * Christian Queinnec, Universite` Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Universite` Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan Registration Fees: ****************** * Early registration before April 25, 2008: Students EU60, regular EU120. * Late registration before May 16, 2008: Students EU80, regular EU160. * Onsite registration: Students EU100, regular EU220. Registration will include the proceedings, coffee breaks, the symposium dinner and other amenities. Accommodation is not included.

1 0

[cffi-devel] Fwd: CFFI should defend itself against fragile handling of narrow return types in SBCL on x86!
by Jean-Claude Beaudoin 12 Apr '09

12 Apr '09

The mailer of common-lisp.net dropped to the floor the previous transmission of the following message, so here it is again. Cheers, Jean-Claude Beaudoin ---------- Forwarded message ---------- From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> Date: Wed, Mar 25, 2009 at 1:13 AM Subject: CFFI should defend itself against fragile handling of narrow return types in SBCL on x86! To: cffi-devel(a)common-lisp.net Recent versions of GCC appear to be leaving spurious bits in the %eax register used to return the value of a C function on x86 based platforms when the return type is narrower than 32 bits (ie: short or char). SBCL does not defend itself against such register pollution and will return an incorrect value made up of those spurious bits in addition to the intended value. A partial fix for "signed" short and char has appeared in SBCL 1.0.25 but the "unsigned" cases are still vulnerable. I suggest that CFFI should defend itself against that dangerously permissive handling of narrow return types in SBCL through the use of a few filtering functions to be applied in those relevant cases, at least until SBCL fixes the issue for good. Here is attached a patch against CFFI 0.10.4 with a version of the required code. I also attach a set of test files that can be used to illustrate the problem. Cheers, Jean-Claude Beaudoin

2 2

[cffi-devel] ahklisp: lisp on win32 with cffi, sbcl, autohotkey
by Naveen Garg 10 Apr '09

10 Apr '09

http://www.ahklisp.com to try it out, just download ahklisp.exe, autohotkey.dll, clinit.lisp, and run.lisp and do > ahklisp.exe --userinit clinit.lisp Programming is telling the computer to do what you would do. However, most programming languages don't treat the mouse, keyboard, gui widgets, other applications as first class citizens like structs and classes. And you cant do much without them. Ahklisp tries to make programming more fun and practical on windows. Would have been much harder with cffi. Thank you, Naveen Garg

2 1

Re: [cffi-devel] ahklisp
by Naveen Garg 10 Apr '09

10 Apr '09

oops, a little change to the instructions for trying it out: you need some more files, so just get the repository, its pretty small. > git clone git://github.com/tinku99/ahklisp.git and put ahklisp.exe and autohotkey.dll into the ahklisp directory and then from the shell do > ahklisp.exe --userinit clinit.lisp Naveen http://www.ahklisp.com

1 0

[cffi-devel] New patches: 6-Apr-2009
by Luis Oliveira 08 Apr '09

08 Apr '09

Tue Apr 7 15:02:03 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * Minor manual fixes. - Fixed one of the foreign-funcall-pointer examples. - Improved the defcallback description. Reported by Naveen Garg. M ./doc/cffi-manual.texinfo -5 +5 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090406.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] foreign-funcall-pointer documentation
by Naveen Garg 07 Apr '09

07 Apr '09

I was having trouble running the example in the documents: (foreign-funcall-pointer (foreign-symbol-pointer "abs") :int -42 :int) I got SIMPLE-ERROR: Unknown CFFI type: 4. I was going crazy, until i searched google code and found this working example: http://www.google.com/codesearch/p?hl=en#wVc2UuwHR3k/trunk/tree/resolve.lis… Retrying with an added "()" before the arg list works. foreign-funcall-pointer (foreign-symbol-pointer "abs") () :int -42 :int) works ! This allows one to call a defcallback function from lisp making the following unnecessary in the documentation of defcallback "The macro defcallback defines a Lisp function the can be called from C (but not from Lisp)." because the following works: (defcallback fx :int ((x :int)) (progn (print "test") 3)) (foreign-funcall-pointer (callback fx) () :int 4 :int) Thanks for the cffi, Naveen

2 1

[cffi-devel] Grovel compile failure on x86 Linux SBCL using darcs snapshot from today
by hylje 05 Apr '09

05 Apr '09

It seems pretty cryptic, and not due to external configuration errors for instance. External library conflicts, maybe, but if that's the case I'd appreciate insights as to how to tackle them. Here's the backtrace and exact error. Full output from the emacs buffer for the err, in fact. Thank you. p.s. Posting here since I'm not able to detect a user-related mailing list nor a bug tracker. I hope you got some appreciation for users! --- erred while invoking #<COMPILE-OP NIL {AA11E19}> on #<CL-SOURCE-FILE "package" {B2CAA31}> [Condition of type ASDF:COMPILE-FAILED] Restarts: 0: [TRY-RECOMPILING] Try recompiling package 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {AA11E19}> on #<ASDF:CL-SOURCE-FILE "package" {B2CAA31}>. 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {AA11E19}> on #<ASDF:CL-SOURCE-FILE "package" {B2CAA31}> as having been successful. 3: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP NIL {AA11E19}> #<ASDF:CL-SOURCE-FILE "package" {B2CAA31}>) 1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..) 2: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..) 3: ((LAMBDA ())) 4: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 5: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]508)) 6: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..) 7: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {ACD4825}>)[:EXTERNAL] 8: (ASDF:OPERATE ASDF:LOAD-OP :CFFI-GROVEL)[:EXTERNAL] 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS 'ASDF:LOAD-OP :CFFI-GROVEL) #<NULL-LEXENV>) 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (ASDF:OOS 'ASDF:LOAD-OP :CFFI-GROVEL)) #<NULL-LEXENV>) 11: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /home/hylje/.sbcl/systems/net.sockets.asd" {AA4EEE9}> NIL NIL) 12: ((FLET SB-FASL::LOAD-STREAM) #<SB-SYS:FD-STREAM for "file /home/hylje/.sbcl/systems/net.sockets.asd" {AA4EEE9}>) 13: (LOAD #P"/home/hylje/.sbcl/systems/net.sockets.asd")[:EXTERNAL] 14: (ASDF:FIND-SYSTEM "net.sockets" NIL) 15: ((SB-PCL::FAST-METHOD ASDF:FIND-COMPONENT ((EQL NIL) T)) #<unused argument> #<unused argument> #<unused argument> "net.sockets" NIL) 16: ((LABELS ASDF::DO-ONE-DEP) ASDF:COMPILE-OP :NET.SOCKETS NIL) 17: ((LABELS ASDF::DO-DEP) ASDF:COMPILE-OP (:NET.SOCKETS :IO.STREAMS :IO.MULTIPLEX :IOLIB.BASE)) 18: ((SB-PCL::FAST-METHOD ASDF::TRAVERSE (ASDF:OPERATION ASDF:COMPONENT)) #(3 NIL) #<unavailable argument> #<ASDF:COMPILE-OP NIL {AA468C9}> #<ASDF:SYSTEM "iolib" {AED4C11}>) 19: ((LABELS ASDF::DO-DEP) ASDF:COMPILE-OP ("iolib")) 20: ((SB-PCL::FAST-METHOD ASDF::TRAVERSE (ASDF:OPERATION ASDF:COMPONENT)) #(3 NIL) #<unavailable argument> #<ASDF:LOAD-OP NIL {AA3CDB1}> #<ASDF:SYSTEM "iolib" {AED4C11}>) 21: (ASDF:OPERATE ASDF:LOAD-OP IOLIB)[:EXTERNAL] 22: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS 'ASDF:LOAD-OP 'IOLIB) #<NULL-LEXENV>) 23: (INTERACTIVE-EVAL (ASDF:OOS 'ASDF:LOAD-OP 'IOLIB)) 24: (SB-IMPL::REPL-FUN NIL) 25: (SB-IMPL::REPL-FUN NIL)[:EXTERNAL] 26: ((LAMBDA ())) 27: ((LAMBDA ()))[:EXTERNAL] 28: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {A83B0B5}>) 29: (SB-IMPL::TOPLEVEL-REPL NIL) 30: (SB-IMPL::TOPLEVEL-INIT) 31: ((LABELS SB-IMPL::RESTART-LISP))

4 4

Re: [cffi-devel] Naming different things with the same symbol
by Luís Oliveira 31 Mar '09

31 Mar '09

[forwarding to the list] 2009/3/30 Kalyanov Dmitry <kalyanov.dmitry(a)gmail.com>: > What will happen when the same symbol is used for different things: function > name, foreign function name, callback name, cffi type name, lisp class name? > Does CFFI guarantee that such uses of name will not bother to each other? Yes, those are all separate namespaces. But notice that DEFINE-FOREIGN-TYPE defines a Lisp class. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] Naming different things with the same symbol
by Kalyanov Dmitry 30 Mar '09

30 Mar '09

What will happen when the same symbol is used for different things: function name, foreign function name, callback name, cffi type name, lisp class name? Does CFFI guarantee that such uses of name will not bother to each other? In particular, I have a class (defined with defclass) and cstruct and I want to reuse the same symbol to name them. And I have a callback and generic function that I would like to have the same name. Won't this cause problems with some definition overriding the other? My use case is that I am generating wrappers and I would like not to introduce redundant symbols.

1 0

[cffi-devel] Using the exec() family of functions
by Leslie P. Polzer 30 Mar '09

30 Mar '09

Hi, I have tried to use execv() from glibc in SBCL, but it's either not compatible with SBCL for some reason or I'm not calling it correctly. Perhaps one of you guys can spot mistakes here: CL-USER(2): (use-package :cffi) T CL-USER(3): (define-foreign-library libc (:unix "libc.so.6")) LIBC CL-USER(4): (use-foreign-library libc) #<CFFI::FOREIGN-LIBRARY {B277599}> CL-USER(7): (defcfun "execv" :int (path :string) (args :pointer)) EXECV CL-USER(14): (execv "/bin/chmod" (null-pointer)) zsh: segmentation fault rlwrap sbcl Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel