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

[cffi-devel] How to get free quality visitors to your website!?
by Hit-Booster＠common-lisp.net 14 Apr '07

14 Apr '07

No Matter what you are selling - Hit-Booster will send targeted visitors to your website! Within 15 minutes you will have your own website traffic generator that will bring in an ever increasing amount of hits to your websites! Automatically This software is perfect for bringing real traffic to your site... even if... it's an affiliate link where you have no control over the website content! I guarantee that you will be receiving hits to your website 15 minutes from now or I will refund every single dime of your order! Using this brand new marketing software increasing website traffic has never been easier - I never shared this method & software with anyone else before. Each and every day im receiving tons of traffic to my own sites using this software. I have designed this marketing tool to be as easy as 1-2-3 so anyone can profit from it you will too! Let me tell you that more targeted traffic means more sales - no matter how good your products or websites are - the more targeted visitors you can send to them - the more potential customers you will have! Use Hit-Booster now and you will be receiving more hits than ever and profiting from it within in a few minutes! For Full details please download the attached .html file To unsubscribe send a blank email to: sorin691(a)rdslink.ro

1 0

[cffi-devel] Re: [Openmcl-devel] Problems with CFFI and Openmcl on Mac/Intel
by Henry Irvine 12 Apr '07

12 Apr '07

On Apr 11, 2007, at 10:38 PM, Gary Byers wrote: > Are you trying to load a 32-bit foreign library in a 64-bit lisp ? > (I don't know what "libtest.so" is, but the value of CFFI::ARGUMENTS > in frame 0 makes me wonder about that.) > > If this is the problem, I imagine that the CFFI test suite has options > to generate 64-bit test libraries; I seem to remember a similar issue > with ppc64. > > In the shell, > > shell> file /path/to/libtest.so > > or > > shell> lipo /path/to/libtest.so -info > > might help to determine the architecture of the library. How right you are... ~/lisp/Lisp_Sources/site/cffi/tests $ file libtest.so libtest.so: Mach-O bundle i386 ~/lisp/Lisp_Sources/site/cffi/tests $ file libtest2.so libtest2.so: Mach-O bundle i386 ~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest.so -info Non-fat file: libtest.so is architecture: i386 ~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest2.so -info Non-fat file: libtest2.so is architecture: i386 I added a -m64 flag to the makefile for the test libs, now they are ~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest2.so -info Non-fat file: libtest2.so is architecture: x86_64 ~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest.so -info Non-fat file: libtest.so is architecture: x86_64 ~/lisp/Lisp_Sources/site/cffi/tests $ file libtest2.so libtest2.so: Mach-O 64-bit bundle x86_64 CFFI-tests now infini-loops with cpu usage at 100% while compiling the file calbacks.lisp (that is a problem for another night...), however if I interrupt and do the following... CL-USER> (asdf:oos 'asdf:load-op 'cffi-tests) ; loading system definition from /Users/hirvine/lisp/Lisp_Sources/ systems/cffi-tests.asd into #<Package "ASDF0"> ; registering #<SYSTEM CFFI-TESTS #x30004114729D> as CFFI-TESTS ; loading system definition from /Users/hirvine/lisp/Lisp_Sources/ systems/rt.asd into #<Package "ASDF0"> ; registering #<SYSTEM :RT #x30004119034D> as RT ; loading system definition from /Users/hirvine/lisp/Lisp_Sources/ systems/cffi.asd into #<Package "ASDF0"> ; registering #<SYSTEM CFFI #x3000411AB2CD> as CFFI ; $ cd /Users/hirvine/lisp/Lisp_Sources/site/cffi/tests/; make make: Nothing to be done for `shlibs'. Invoking restart: Skip compiling #P"/Users/hirvine/lisp/Lisp_Sources/ site/cffi/tests/callbacks.lisp" Invoking restart: Continue, treating #<COMPILE-OP NIL #x300040FFF4FD> on #<CL-SOURCE-FILE "callbacks" #x3000410048FD> as having been successful. Invoking restart: Skip loading #P"/Users/hirvine/lisp/Lisp_Sources/ compiled/.fasls/openmcl-unix-x86-64-1.1/Users/hirvine/lisp/ Lisp_Sources/site/cffi/tests/callbacks.dx64fsl" NIL CL-USER> (asdf:oos 'asdf:test-op 'cffi-tests) How many times shall we run the tests (uncompiled)? [1]: Doing 182 pending tests of 182 tests total. --- snip --- No tests failed. ;;; Finished running tests (uncompiled) 1 times. How many times shall we run the tests (compiled)? [1]: Doing 182 pending tests of 182 tests total. --- snip --- No tests failed. ;;; Finished running tests (compiled) 1 times. NIL Thanks Gary!

2 1

[cffi-devel] Problems with Openmcl on Mac/Intel
by Henry Irvine 12 Apr '07

12 Apr '07

Hello, (cross posted to openmcl devel and cffi devel) I am running into difficulties getting the CFFI tests to run on a mac pro (darwin X8664). Openmcl is up to date, and I am using darcs to stay current with CFFI. The problem is that CFFI can't load a foreign library. CFFI itself compiles, but any time a call to load-foreign-library is made, the results below occur. The same source with sbcl on the same machine runs all tests w/o failures. I don't understand what is supposed to be happening well enough to troubleshoot it further. Any insight or suggestions appreciated. Backtrace: 0: (CFFI::FL-ERROR "Unable to load any of the alternatives:~% ~S") Locals: CFFI::CONTROL = "Unable to load any of the alternatives:~% ~S" CFFI::ARGUMENTS = (("libtest.so" "libtest32.so")) 1: (CFFI:LOAD-FOREIGN-LIBRARY 'CFFI:LOAD-FOREIGN-LIBRARY) Locals: #:USE-VALUE = #<RESTART USE-VALUE #x421706D> #:RETRY = #<RESTART CFFI::RETRY #x421701D> CCL::%RESTARTS% = ((#<RESTART CCL::RETRY-LOAD #x42172AD> #<RESTART CCL::SKIP-LOAD #x42172FD> #<RESTART CCL::LOAD-OTHER #x421734D>) (#<RESTART ASDF:RETRY #x42174CD> #<RESTART ASDF:ACCEPT #x421751D>) (#<RESTART ABORT #x421799D>) (#<RESTART ABORT-BREAK #x4217B5D> #<RESTART ABORT #x4217BAD>)) Catch-tags: (:RESTART CFFI::RETRY) 2: (CFFI-TESTS::LOAD-TEST-LIBRARIES) Locals: CFFI:*FOREIGN-LIBRARY-DIRECTORIES* = NIL 3: (#<Anonymous Function #x3000400AA37F> #<FASLSTATE #x421713D>) Locals: CCL::S = #<FASLSTATE #x421713D> CCL::FUN = #<Anonymous Function #x300041230CEF> 4: (CCL::%FASLOAD "/Users/hirvine/lisp/Lisp_Sources/ compiled/.fasls/openmcl-unix-x86-64-1.1/Users/hirvine/lisp/ Lisp_Sources/site/cffi/tests/bindings.dx64fsl") Locals: STRING = "/Users/hirvine/lisp/Lisp_Sources/compiled/.fasls/ openmcl-unix-x86-64-1.1/Users/hirvine/lisp/Lisp_Sources/site/cffi/ tests/bindings.dx64fsl" CCL::TABLE = #(#<Anonymous Function #x3000400A98CF> #<Anonymous Function #x3000400AD0FF> CCL::%BAD-FASL #<Anonymous Function #x3000400A9ECF> #<Anonymous Function #x3000400AA37F> #<Anonymous Function #x3000400AA4DF> #<Anonymous Function #x3000400AA5DF> #<Anonymous Function #x3000400AA6FF> #<Anonymous Function #x3000400AAABF> #<Anonymous Function #x3000400AD36F> ...) CCL::BUFFER = #<A Foreign Pointer [stack-allocated] #xB0B01690> CCL::PARSE-STRING = "LOAD-TEST- LIBRARIESRECTORIES* " CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 CCL::NBLOCKS = 1 CCL::POS = 12 CCL::I = 0 CCL::VERSION = 65357 Catch-tags: NIL 5: (CCL::ATTEMPT-LOAD)

1 0

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

09 Apr '07

1 0

[cffi-devel] cffi-clisp.lisp multiple-value-bind usage of variable "error" conflicts with another package
by Reini Urban 01 Apr '07

01 Apr '07

>I am attempting to use cffi on a Clisp 2.41 build running under Cygwin. >I can get cffi to load using asdf, but when I loaded a package that uses >cffi, I got an error message "ERROR is a constant: may not be used as a >variable". >In cffi-clisp.lisp, around line 234; > (multiple-value-bind (ff error) ... >is causing the problem. I patched this to: > (multiple-value-bind (ff fferror) >and also corrected the subsequent two references to error on lines 249 >and 250 and managed to get past this particular problem. >In trying to localize the source of the name conflict, it appears that >one of the optional modules that I have included in Clisp is the source >of the conflit. These would include GDI, PCRE, RAWSOCK, LDAP, FASTCGI or >ZLIB. The BASE build without the optional modules didn't have the name >conflict, while the FULL build does. I have not determined which of the >modules above was defining the constant "error". I found the culprit. Of course it was me who introduced it. GDI.lisp defines it. Will be fixed asap. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/

1 0

[cffi-devel] load-foreign-library on LispWorks 5.0.1
by Jack Unrue 29 Mar '07

29 Mar '07

I believe there is a problem with how fli:register-module is called (this is on LispWorks 5.0.1) when the application uses load-foreign-library. The short story is that this is causing load-foreign-library to throw an error on LispWorks. Long story...assume that I haven't added anything to *foreign-library-directories* and consider the following (cffi:load-foreign-library "user32.dll") This causes cffi::load-foreign-library-helper to be called because I'm passing a string rather than a symbol. Thus we call cffi:load-foreign-library-path, passing nil for the library parameter, which calls the LW-specific %load-foreign-library function. That ends up calling fli:register-module which apparently wants a non-nil value for its first argument. Like so: CL-USER 5 > (fli:register-module nil :connection-style :immediate :real-name "user32.dll") NIL CL-USER 6 > (fli:register-module 'mylib :connection-style :immediate :real-name "user32.dll") MYLIB The latter is effectively what happens when the application uses define-foreign-library and then use-foreign-library, and I confirmed that this latter approach works where load-foreign-library doesn't. I'm not sure what the proper fix is (i.e., creating a symbol out of the path string might not be such a hot idea), otherwise I'd offer a patch. BTW, I think this may be a behavioral change going from LW 5.0 to 5.0.1, because I don't remember having this problem on 5.0. -- Jack Unrue

2 2

[cffi-devel] newtypes compile error with LispWorks 5.0.1
by Jack Unrue 28 Mar '07

28 Mar '07

Hello. I'm getting the following compile errors in cffi-lispworks.lisp from the newtypes branch under LW 5.0.1 (WinXP): **++++ Error in CFFI-SYS:%FOREIGN-STRING-LENGTH: Undefined operator CONVERT-FOREIGN-TYPED-AREF-TYPE in form (CONVERT-FOREIGN-TYPED-AREF-TYPE TYPE). **++++ Error in CFFI-SYS:%LISP-STRING-INTO-FOREIGN: Undefined operator CONVERT-FOREIGN-TYPED-AREF-TYPE in form (CONVERT-FOREIGN-TYPED-AREF-TYPE TYPE). I see that there are compiler macros defined for %MEM-REF and %MEM-SET which call CONVERT-FOREIGN-TYPED-AREF-TYPE. With a copy&paste into the REPL, I'm able to define that function manually. Also (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") returns T on my machine. And that's about where my expertise with compiler macros drops off into the abyss. Any idea what's going wrong? Thanks. -- Jack Unrue

2 2

[cffi-devel] cffi-tests coverage report
by Luis Oliveira 20 Mar '07

20 Mar '07

Hello, Juho Snellman recently[1] posted a very useful SBCL-specific coverage tool. I did this for CFFI to test the coverage of cffi-tests. The report can be found here: <http://common-lisp.net/~loliveira/tmp/cffi-tests-coverage/> The results seem pretty good to me: 80.5% code coverage. It does reveal some missed spots so if someone feels like writing some tests, look at this report for picking where to start. :-) A significant percentage of these missed spots are a result of compiler macros (or type expansions) kicking in or error branches not being exercised. [1] http://thread.gmane.org/gmane.lisp.steel-bank.devel/8721 -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

2 1

[cffi-devel] Mac OS X / intel support
by Carlos Lenz 19 Mar '07

19 Mar '07

Hi The "implementation support" section of the CFFI manual lists darwin/ppc as being supported for several lisps, but says nothing about darwin/intel. Nevertheless I have tried to install it in CLISP - Mac OS X and got several errors. Is it supported? Do you want to see the errors? Regards Carlos

2 2

[cffi-devel] how to revise foreign type translators to work with cffi-newtypes
by Jack Unrue 15 Mar '07

15 Mar '07

Hi there. I'm looking into some compile errors that are reported by SBCL when compiling Graphic-Forms using the cffi-newtypes branch. I have a number of foreign types defined, and for a couple of these, I also declare aliases for :pointer such that I am then able to implement type translators. Here's an example (assume there are existing CL structures called RECTANGLE, SIZE, and POINT, and it is instances of RECTANGLE which are to be translated into and out of the foreign struct RECT that I'm defining below): (cffi:defctype rect-pointer :pointer) (cffi:defcstruct rect (left :long) (top :long) (right :long) (bottom :long)) (defmethod cffi:free-translated-object (ptr (name (eql 'rect-pointer)) param) (declare (ignore param)) (cffi:foreign-free ptr)) (defmethod cffi:translate-from-foreign (ptr (name (eql 'rect-pointer))) (if (cffi:null-pointer-p ptr) (make-rectangle) (cffi:with-foreign-slots ((left top right bottom) ptr rect) (let ((pnt (make-point :x left :y top)) (size (make-size :width (- right left) :height (- bottom top)))) (make-rectangle :location pnt :size size))))) (defmethod cffi:translate-to-foreign ((lisp-rect rectangle) (name (eql 'rect-pointer))) (let ((ptr (cffi:foreign-alloc 'rect)) (pnt (location lisp-rect)) (size (size lisp-rect))) (cffi:with-foreign-slots ((left top right bottom) ptr rect) (setf left (gfs:point-x pnt) top (gfs:point-y pnt) right (+ (gfs:point-x pnt) (gfs:size-width size)) bottom (+ (gfs:point-y pnt) (gfs:size-height size)))) ptr)) Can anyone make suggestions as to what I should change to be compatible with the cffi-newtypes branch? Second question -- do the WITH-FOREIGN-SLOTS and WITH-FOREIGN-OBJECT macros work the same way on cffi-newtypes as they did before? I imagine so, but it's worth asking just to be sure. Thanks in advance. -- Jack Unrue

2 1