cffi-devel

cffi-devel@common-lisp.net

1113 discussions

Re: [cffi-devel] more compiler macro optimizations
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

Hi, here are more patches: - (too) few tests to verify left-to-right evaluation (side-effects) I remember UFFI/Corman once had a bug in this area. - with-foreign-object always inlines constant types - clisp %mem-set (thanks for all the patch) optimizer Now disassembly of some of the foreign-value tests look great: CFFI is almost completely compiled away! Still there's more work to do w.r.t. optimizations, but I'll talk about that next year (struct access, strings ...). NB You may wish not to apply the second %mem-set patch (where I introduce ffi::write-memory-as). It appears that, as a side effect of %MEM-SET only getting called from the MEM-REF setf-expander, that all values have already been saved in local variables, thus the low-level function cannot disturb order of evaluation (all it sees is (%MEM-SET #:G1000 #:G1001 #:1002 ...)). But relying on that is not proper engineering. It's just good to know. I didn't review compiler-macro forms in *.lisp for possibly breaking the left to right evaluation rule. Never mind a review, some tests should be added. Reviews happen once, tests remain. Regards, Jörg Höhle

1 0

[cffi-devel] DEFINE-TYPE-TRANSLATOR and EVAL-WHEN
by James Bielman 23 Dec '05

23 Dec '05

Luis, Can you think of any reasons why this would be a bad idea? (modulo the annoying STYLE-WARNINGs from SBCL about method redefinition I guess...) I added some type translators to the new examples I'm working on and got bitten by the fact that DEFINE-TYPE-TRANSLATOR doesn't make the translator available until load time. I think it's best for it to expand into an EVAL-WHEN like DEFCFUN, DEFCTYPE, etc, unless there's some problem I'm not thinking of: --- old-cffi/src/types.lisp 2005-12-23 03:04:40.000000000 -0800 +++ new-cffi/src/types.lisp 2005-12-23 05:47:58.000000000 -0800 @@ -685,7 +685,7 @@ (:to-c-dynamic (values 'to-c-dynamic-form nil))) (let ((type-spec `(,(gensym "TYPE") (eql ',type))) (args (delete nil (list value-arg var-arg body-arg)))) - `(progn + `(eval-when (:compile-toplevel :load-toplevel :execute) (defmethod ,form-method (,type-spec ,@args) ,@body) ,(when translate-method ; no method for to-c-dynamic James

1 0

Re: [cffi-devel] Re: Main CFFI Darcs Tree
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

Luis Oliveira wrote;: >I just edit the package's .asd file and make it :depend-on >:cffi-uffi-compat instead of :uffi On a Debian system, many packages are owned by root. There's really a need for a ready-to-use uffi.asd that uses cffi-compat. CFFI might also become a Debian package one day :) > or, for instance, #-clisp :uffi >#+clisp :cffi-uffi-compat (this is what's done in CL-GD). Interesting switch. I once had cl-gd running with my uffi own wrappers, but there definitively is a problem in UFFI with nested structs vs. pointers to structs. I think this is precisely why CFFI works better than UFFI with nested structs: since it's all pointers, a nested struct yields a pointer, similar to a pointer to a struct within the struct, so both are handled equally well. Regards, Jörg Höhle

1 0

Re: [cffi-devel] bits from a new tutorial
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

James Bielman wrote: >> Are you sure that is varargs or do you mean polymorphism, i.e. each >> different signature has a different entry point (address), but they >> are still refered under an identical name? >No, all Objective-C methods are called via the varargs function >objc_msgSend --- see: >http://developer.apple.com/documentation/Cocoa/Conceptual/Objec >tiveC/LanguageOverview/chapter_4_section_6.html I see. Hairy problem. I've never seen any of the CL FFI's deal with varargs (but it's >10 years last I looked and evaluated cmucl, Lucid, Allegro, akcl). I'll suggest the maintainer of the FFCALL package (Bruno Haible) look into this. Here's some other message about varargs vs. fully typed function calls that shows that I'm hopefully not spreading FUD when I say there can be problems: http://gcc.gnu.org/ml/gcc/2004-06/msg01019.html "It's assuming that the calling conventions for a varargs function and a non-varargs function are the same, and that's not necessarily true on all platforms." Maybe that's not a problem in practice, because the systems where it's used nevertheless (i.e. in your case it must be an Apple OSX with PowerPC) could behave regularly. But that's just a conjecture. Regarding objc_msgSend, the Python people have similar problems (all other languages will, e.g. .NET, Perl, Haskell), and I found a mention of NSInvocation which might be usable. But that's just 10 minutes reading into the subject, you certainly know all this. However, here's for 20 minutes of reading value: http://lists.ximian.com/pipermail/cocoa-sharp/2004-June/000083.html "C-style varargs that are not supported by .NET's pinvoke engine" "...better idea. There is a 'objc_msgSendV' that allows to send messages with a va_list, making it possible to forward the stack." Like I said in my previous post, don't attempt to interface to C varargs. Look out for *V (e.g. execv) functions instead! I suggest you interface to objc_msgSendV instead. I hope this helps, Jorg Hohle I also found http://camelbones.sourceforge.net/ : Cocoa programming in Perl, maybe that site could also give ideas. BTW, Sherm Pendley uses Bruno's libffcall :) http://www.codecomments.com/archive376-2005-6-504642.html http://hoc.sourceforge.net is Haskell <-> ObjC

1 0

[cffi-devel] more compiler macro optimizations
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

foreign-slot access gets inlined now (tested on clisp). fix foreign-struct-value-form thus enable foreign-slot-value optimization clisp: inline %mem-ref when given constant type fix foreign-struct-set-form & enable foreign-slot-set optimization Regarding darcs send -uo Joerg2.patch becoming larger than 40KB and not getting through to the mailing list: I just hand edited the bottom of the file and removed lots of this context information. I hope it can nevertheless be applied without problems!?! As an afterthought, it appears the low-level API would better not rely on SETF, and e.g. define %MEM-SET for writing. All these define-setf-expanders just to avoid piling up LET-rebindings to ensure correct order of evaluation yet still be able to optimize are not enjoyable. E.g. (setf MEM-REF) is still not optimized away in CLISP. I presume it does with cmucl, because cffi-cmucl has a suitable setf-expander. Some day I'll write the same for CLISP. All these compiler macros & ASDF-tests make that one should also asdf:load-source-op the testsuite so as to test code without compilation (i.e. the functional interface). Regards, Jörg Höhle.

3 4

Re: [cffi-devel] more compiler macro optimizations
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

Luis Oliveira wrote: >Ah, get yourself a common-lisp.net account then. :-) I think I couldn't use it because I can't ssh to the outside world from here. I can't even connect to the pserver port. And yesterday the proxy server & firewall even refused an HTTP conection to some web server listening on port 81. :-( If I can nevertheless make use of common-lisp.net, I'd be happy to hear. For example, I can use sourceforge developer access because they have a machine where the shell sits on oprt 443. The proxy lets through "HTTPS" to the standard https port. >Heh, it did come through but you sent the wrong patch. Btw, why don't >you gzip or bzip2 the patch? Silly me. Here it is, zipped. Maybe I liked cleartext so people can immediately read the patch upon reception of the mail (like James' %mem-set patch) and review it. Regards, Jörg.

2 1

Re: [cffi-devel] Main CFFI Darcs Tree
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

James Bielman wrote: >I[...] made 'cffi' a symlink to 'cffi-luis'. Excellent. Less confusion to users. BTW, do you have an idea how I can put your "try it out" %mem-set patch into darcs without getting upset by merge conflicts the day you'll push it onto the darcs repository? Thanks for being so fast at killing the setf expanders. It was just a comment after all. And thanks again for raising the attachment size limit. And thanks to you all for accepting my patches. Hey, it's not thanksgiving day :-) Here's another suggestion: I think the uffi-compat needs an ASDF definition file named uffi.asd, or at least a defsystem uffi in some file. So users can at least (load "cffi-as-uffi.asd") to make ASDF believe that uffi is there. Reason: packages using (depending on) UFFI will otherwise load the real uffi or error out when not available. Or how did you manage to load some UFFI-using package with CFFI instead? Happy new year, Jorg Hohle

2 1

[cffi-devel] Main CFFI Darcs Tree
by James Bielman 23 Dec '05

23 Dec '05

Hi all, I've moved the old, untouched-since-summer Darcs tree from '/darcs/cffi' to '/darcs/cffi-old' and made 'cffi' a symlink to 'cffi-luis'. I think it's time to start pointing people at 'cffi' instead of 'cffi-luis' since there's no need for a branch anymore. Once we commit to doing this, we can swap the real directory and the symlink around to keep the 'cffi-luis' branch around for backward compatibility... Comments? James

2 1

[cffi-devel] pushing ":cffi" into features?
by Surendra Singhi 23 Dec '05

23 Dec '05

Hello, Right now :cffi is not pushed into the *features* list, rather :cffi/no-long-long is. Is there any reason why this is done so? Because of this I am not able to write code which can conditionally depend on the presence of cffi, for example `#+cffi (do-something)'. I don't think conditionally compiling on `cffi/no-long-long' will be a good idea because it is something which might not be present in the future. Thanks. -- Surendra Singhi http://www.public.asu.edu/~sksinghi/index.html ,---- | Great wits are sure to madness near allied, | And thin partitions do their bounds divide. | | (John Dryden, Absalom and Achitophel, 1681) `----

4 6

Re: [cffi-devel] more compiler macro optimizations
by Luís Oliveira 23 Dec '05

23 Dec '05

On 2005-dec-22, at 17:55, Hoehle, Joerg-Cyril wrote: >> Hmmm, no. darcs didn't quite like that. Either James should remove >> that 40KB restriction, or you could publish your darcs tree >> somewhere? > I don't have any web space(!), so it's not online. Ah, get yourself a common-lisp.net account then. :-) > Luckily, the patch is below 38KB (maybe with base64, it'll be too > large and rejected again?), so I'll try once more with full > context, and CC to you directly. Heh, it did come through but you sent the wrong patch. Btw, why don't you gzip or bzip2 the patch? Not sure why that didn't occur to me before... doh. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 1

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