From marcoxa at cs.nyu.edu Wed Feb 1 05:16:27 2012 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Wed, 1 Feb 2012 14:16:27 +0100 Subject: [cffi-devel] ELS 2012, Zadar, Croatia Message-ID: <32AC18D7-4F67-4F33-B199-5D768F99C876@cs.nyu.edu> Apologies for the multiple postings. PAPER SUBMISSION DEADLINE EXTENDED European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 http://european-lisp-symposium.org The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2012 European Lisp Conference is "Interoperability: Systems, Libraries, Workflows". Lisp based and functional-languages based systems have grown a variety of solutions to become more and more integrated with the wider world of Information and Communication Technologies in current use. There are several dimensions to the scope of the solutions proposed, ranging from "embedding" of interpreters in C-based systems, to the development of abstractions levels that facilitate the expression of complex context dependent tasks, to the construction of exchange formats handling libraries, to the construction of theorem-provers for the "Semantic Web". The European Lisp Symposium 2012 solicits the submission of papers with this specific theme in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: February 15th 2012: submission deadline (extended deadline) March 7th 2012: acceptance results April 30th 2012: Conference opens Program Commitee. Chair: Marco Antoniotti, Universit? degli Studi di Milano Bicocca, Milan, ITALY Local organizers: Damir Cavar, Eastern Michigan University Franjo Pehar, University of Zadar Damir Kero, University of Zadar Members: Giuseppe Attardi, Universit? degli Studi di Pisa, Pisa, ITALY Pascal Costanza, Intel, Bruxelles, BELGIUM Marc Feeley, Universit? de Montreal, Montreal, CANADA Scott McKay, Google, U.S.A. Kent Pitman, U.S.A. Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM Robert Strandh, LABRI, Universit? de Bordeaux, Bordaux, FRANCE Didier Verna, EPITA / LRDE, FRANCE Taiichi Yuasa, Kyoto University, JAPAN -- Marco Antoniotti From lhealy at common-lisp.net Sat Feb 11 13:20:25 2012 From: lhealy at common-lisp.net (Liam Healy) Date: Sat, 11 Feb 2012 16:20:25 -0500 Subject: [cffi-devel] First stab at reviewing cffi-fsbv In-Reply-To: References: Message-ID: Luis, I've managed to go through this list and make all the changes that I knew how to do and didn't require much research for me. Here is a summary of what I have done, with the git commit to the fsbv branch: 9d1d5b5 Rename system to cffi-libffi, add restart to default *foreign-structures-by-value* 95052e5 Use hash table for libffi-type-pointer 4b5d7fb Moved slots-in-order after foreign-struct-type, clean up libffi-*.lisp 953fbaf Fix conditionalization syntax in cffi-fsbv.asd cc73a6f Add Windows grovel file 1ff74af Eliminate package cffi-fsbv, put :sizet in keyword package Do these changes address your concerns? Can you test? Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhealy at common-lisp.net Sun Feb 12 08:11:54 2012 From: lhealy at common-lisp.net (Liam Healy) Date: Sun, 12 Feb 2012 11:11:54 -0500 Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: References: Message-ID: I have updated the example in tests/struct.lisp, (defcfun "alloc_pair" (:pointer (:struct struct-pair)) (a :int) (b :int)) and when I call alloc-pair, I get a pointer back: (alloc-pair 1 2) #.(SB-SYS:INT-SAP #X00668E70) I am not sure how you are seeing the problems you describe. Can you please send complete example(s) and describe what you see and what you expect? If you use the definitions already in the test system, that will make it a little bit easier. Thank you. On Wed, Feb 8, 2012 at 2:28 PM, Ryan Pavlik < reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > wrote: > I've been using this, and while it works great for by-value, there no > longer seems to be a way to iterate struct arrays and get pointers back. > This is bad, because I _don't_ always want a struct parsed. Parsing is > slow and conses a lot. > > However, neither `(mem-aref ptr (:pointer (:struct foo)) n)` nor > `(mem-aref ptr (:struct foo) n)` give the same thing as the function > `(mem-aref ptr 'foo n)` does. Additionally, the compiler-macro form sets > `*PARSE-BARE-STRUCTS-AS-POINTERS*`, so this results in incorrect iteration > as well. I know at least a few existing codebases depend on the old > behavior. > > For instance, I have a cstruct `POINT` which consists of two `:short`. > The `foreign-type-size` is 4. However, with the compiler macro: > > ``` > (with-foreign-object (ptr 'point 2) > (mem-aref ptr 'point 1)) ;; -> ptr+8 > ``` > > This is identical to using `(mem-aref ptr '(:pointer (:struct point)) 1)`, > and wrong. If the *function* gets called with the old parsing style, you > get `ptr+4`, which is the only way to do so beyond using `mem-ref` and > `foreign-type-size` manually. This breaks a lot of existing code. > > If I use `(mem-aref ptr '(:struct point) 1)`, I get values returned, not > pointers, which is no good if I need the pointer itself. > > --- > Reply to this email directly or view it on GitHub: > https://github.com/cffi/cffi/pull/2#issuecomment-3874222 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetmonk at gmail.com Tue Feb 14 12:20:30 2012 From: jetmonk at gmail.com (JTK) Date: Tue, 14 Feb 2012 10:20:30 -1000 Subject: [cffi-devel] pathnames and libraries Message-ID: <820FC90B-4417-4FCD-82EB-E56BBF7193BF@gmail.com> When trying to install GSLL (the gnu scientific library lisp package) using quicklisp, I noticed that it failed because the library name was a pathname rather than a string. I fixed it by changing cffi's src/libraries.lisp as described below, putting pathnames into the etypecase. Is there some reason why this isn't done normally? John ;; from src/libraries.lisp (defun load-foreign-library-helper (name thing &optional search-path) (etypecase thing (string (load-foreign-library-path name thing search-path)) (pathname ;; #### MAKE IT HANDLE PATHNAMES (load-foreign-library-path name (namestring thing) search-path)) ;; JTK (cons (ecase (first thing) (:framework (load-darwin-framework name (second thing))) (:default (unless (stringp (second thing)) (fl-error "Argument to :DEFAULT must be a string.")) (let ((library-path (concatenate 'string (second thing) (default-library-suffix)))) (load-foreign-library-path name library-path search-path))) (:or (try-foreign-library-alternatives name (rest thing))))))) From martin at lispworks.com Thu Feb 16 09:42:54 2012 From: martin at lispworks.com (Martin Simmons) Date: Thu, 16 Feb 2012 17:42:54 GMT Subject: [cffi-devel] pathnames and libraries In-Reply-To: <820FC90B-4417-4FCD-82EB-E56BBF7193BF@gmail.com> (message from JTK on Tue, 14 Feb 2012 10:20:30 -1000) References: <820FC90B-4417-4FCD-82EB-E56BBF7193BF@gmail.com> Message-ID: <201202161742.q1GHgsaH022563@higson.cam.lispworks.com> >>>>> On Tue, 14 Feb 2012 10:20:30 -1000, JTK said: > > When trying to install GSLL (the gnu scientific library lisp package) using quicklisp, > I noticed that it failed because the library name was a pathname rather than a string. > > I fixed it by changing cffi's src/libraries.lisp as described below, putting pathnames into > the etypecase. > > Is there some reason why this isn't done normally? Version 0.10.6 already has a case for pathname in load-foreign-library-helper. Which version of cffi are you using? Perhaps you need to update quicklisp? __Martin From lhealy at common-lisp.net Sat Feb 18 09:53:17 2012 From: lhealy at common-lisp.net (Liam Healy) Date: Sat, 18 Feb 2012 12:53:17 -0500 Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: References: Message-ID: The new syntax is as follows. If you want the structure itself, use (:struct foo). If you want a pointer to it, use (:pointer (:struct foo)). The latter should be identical to the old style bare struct specification, except for the annoying deprecation warning, of course. The issues I can identify, with their resolutions: 1) Using mem-aref with the (:pointer (:struct ...)) spec gives the wrong pointer. I have fixed an error which should now return the correct pointer for an offset of 0. For an offset of 1, it returns the base pointer +8 bytes, which is not what the old style gives (+ 4 bytes), but it seems to me correct, as I understand the index to refer to the number of whole structures. Pull ee90bfd517 and try. 2) The plist form representing the structure is not desirable. You can have any CL representation of the structure you like; you need to define a method cffi:translate-from-foreign for your type class. You are getting the default, a plist translation, because no such method is defined. See for example how I translate complex numbersto CL complex numbers. You can even return a pointer if you want, but this probably isn't the specification to use if you want the pointer. On Mon, Feb 13, 2012 at 10:22 AM, Ryan Pavlik < reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > wrote: > I've pulled the latest and it appears the semantics have changed for > mem-aref, but there is still no way to get the old behavior. Here is a > complete example, though it doesn't use the test system definitions because > actual foreign calls and definitions aren't really the problem: > > ``` > (asdf:load-system :cffi) > > (cffi:defcstruct my-struct > (x :short) > (y :short)) > > (defun test-old-ref () > (declare (notinline cffi:mem-ref cffi:mem-aref)) > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > (format t "~&Old-ref style:~%ptr : ~A~%aref: ~A~%" > ptr (cffi:mem-aref ptr 'my-struct 1)))) > > (defun test-new-ref () > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > (format t "~&New-ref style:~%ptr : ~A~%aref: ~A~%" > ptr > (cffi:mem-aref ptr '(:struct my-struct) 1)))) > > (defun test-new-ptr-ref () > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > (format t "~&New-ref with :pointer style:~%ptr : ~A~%aref: ~A~%" > ptr > (cffi:mem-aref ptr '(:pointer (:struct my-struct)) 1)))) > > (progn > (test-old-ref) > (test-new-ref) > (test-new-ptr-ref)) > ``` > > The output I get, sans style-warnings about bare structs: > > ``` > Old-ref style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > aref: #.(SB-SYS:INT-SAP #X7FFFEEFCFFF4) > New-ref style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > aref: (Y 0 X 0) > New-ref with :pointer style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > aref: #.(SB-SYS:INT-SAP #X00000000) > ``` > > Note that in the first example, with the original semantics, if you > mem-aref a pointer to an array of `my-struct`, you get a pointer to the > array element. In the new style, with `(:struct my-struct)`, you get the > values parsed into a list, which is not particularly useful; it conses, and > you almost certainly have to re-parse a possibly long list for a single > element. In the new style with `:pointer`, it appears to dereference the > Nth element in an *array of pointers to my-struct*, which is not at all > what we want. > > The latter differs from the behavior before I updated, which seemed to > return a *pointer* to the Nth element in an array-of-pointers. None of the > above are like the old behavior. > > --- > Reply to this email directly or view it on GitHub: > https://github.com/cffi/cffi/pull/2#issuecomment-3941718 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at lispworks.com Mon Feb 20 07:38:23 2012 From: martin at lispworks.com (Martin Simmons) Date: Mon, 20 Feb 2012 15:38:23 GMT Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: (message from Liam Healy on Sat, 18 Feb 2012 12:53:17 -0500) References: Message-ID: <201202201538.q1KFcNpH008751@higson.cam.lispworks.com> This looks wrong to me -- a pointer is not an aggregate type. Also, I think your test-new-ptr-ref and test-generic-ptr-ref tests are bogus because the type in mem-aref doesn't match the type of ptr. Have you tried it with a struct containing 20 bytes? Testing it with an array of two 4 byte structs leads to confusion about the size of a pointer v.s. the size of one struct v.s. the size of the array. In fact, I don't understand what mem-aref is supposed to do for an aggregate type. Making it return a pointer to the first byte of the aggregate is inconsistent with how it treats other types and IMHO leads to the current confusion. __Martin >>>>> On Sat, 18 Feb 2012 12:53:17 -0500, Liam Healy said: > > The new syntax is as follows. If you want the structure itself, use > (:struct foo). If you want a pointer to it, use (:pointer (:struct > foo)). The latter should be identical to the old style bare struct > specification, except for the annoying deprecation warning, of course. > > The issues I can identify, with their resolutions: > > 1) Using mem-aref with the (:pointer (:struct ...)) spec gives the wrong > pointer. > > I have fixed an error which should now return the correct pointer for an > offset of 0. For an offset of 1, it returns the base pointer +8 bytes, > which is not what the old style gives (+ 4 bytes), but it seems to me > correct, as I understand the index to refer to the number of whole > structures. Pull ee90bfd517 and try. > > 2) The plist form representing the structure is not desirable. > > You can have any CL representation of the structure you like; you need to > define a method cffi:translate-from-foreign for your type class. You are > getting the default, a plist translation, because no such method is > defined. See for example how I translate complex > numbersto > CL complex numbers. You can even return a pointer if you want, but > this > probably isn't the specification to use if you want the pointer. > > > On Mon, Feb 13, 2012 at 10:22 AM, Ryan Pavlik < > reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > > wrote: > > > I've pulled the latest and it appears the semantics have changed for > > mem-aref, but there is still no way to get the old behavior. Here is a > > complete example, though it doesn't use the test system definitions because > > actual foreign calls and definitions aren't really the problem: > > > > ``` > > (asdf:load-system :cffi) > > > > (cffi:defcstruct my-struct > > (x :short) > > (y :short)) > > > > (defun test-old-ref () > > (declare (notinline cffi:mem-ref cffi:mem-aref)) > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > (format t "~&Old-ref style:~%ptr : ~A~%aref: ~A~%" > > ptr (cffi:mem-aref ptr 'my-struct 1)))) > > > > (defun test-new-ref () > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > (format t "~&New-ref style:~%ptr : ~A~%aref: ~A~%" > > ptr > > (cffi:mem-aref ptr '(:struct my-struct) 1)))) > > > > (defun test-new-ptr-ref () > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > (format t "~&New-ref with :pointer style:~%ptr : ~A~%aref: ~A~%" > > ptr > > (cffi:mem-aref ptr '(:pointer (:struct my-struct)) 1)))) > > > > (progn > > (test-old-ref) > > (test-new-ref) > > (test-new-ptr-ref)) > > ``` > > > > The output I get, sans style-warnings about bare structs: > > > > ``` > > Old-ref style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > aref: #.(SB-SYS:INT-SAP #X7FFFEEFCFFF4) > > New-ref style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > aref: (Y 0 X 0) > > New-ref with :pointer style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > aref: #.(SB-SYS:INT-SAP #X00000000) > > ``` > > > > Note that in the first example, with the original semantics, if you > > mem-aref a pointer to an array of `my-struct`, you get a pointer to the > > array element. In the new style, with `(:struct my-struct)`, you get the > > values parsed into a list, which is not particularly useful; it conses, and > > you almost certainly have to re-parse a possibly long list for a single > > element. In the new style with `:pointer`, it appears to dereference the > > Nth element in an *array of pointers to my-struct*, which is not at all > > what we want. > > > > The latter differs from the behavior before I updated, which seemed to > > return a *pointer* to the Nth element in an array-of-pointers. None of the > > above are like the old behavior. > > > > --- > > Reply to this email directly or view it on GitHub: > > https://github.com/cffi/cffi/pull/2#issuecomment-3941718 > > > From lhealy at common-lisp.net Mon Feb 20 08:40:32 2012 From: lhealy at common-lisp.net (Liam Healy) Date: Mon, 20 Feb 2012 11:40:32 -0500 Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: <201202201538.q1KFcNpH008751@higson.cam.lispworks.com> References: <201202201538.q1KFcNpH008751@higson.cam.lispworks.com> Message-ID: I'm not sure how to address Ryan's case (what I identified as (1)). I am (effectively) scrapping the changes I have made by redefining defmethod aggregatep ((type foreign-pointer-type)) to give nil, because I found having it T seriously broke GSLL. I acknowledge your points and Ryan's in his last email but I don't understand pointers and aggregates and structures in C and how they should map to CL enough to understand what to do. Any thoughts appreciated (Luis? anyone?). Liam On Mon, Feb 20, 2012 at 10:38 AM, Martin Simmons wrote: > This looks wrong to me -- a pointer is not an aggregate type. Also, I > think > your test-new-ptr-ref and test-generic-ptr-ref tests are bogus because the > type in mem-aref doesn't match the type of ptr. > > Have you tried it with a struct containing 20 bytes? Testing it with an > array > of two 4 byte structs leads to confusion about the size of a pointer v.s. > the > size of one struct v.s. the size of the array. > > In fact, I don't understand what mem-aref is supposed to do for an > aggregate > type. Making it return a pointer to the first byte of the aggregate is > inconsistent with how it treats other types and IMHO leads to the current > confusion. > > __Martin > > > > >>>>> On Sat, 18 Feb 2012 12:53:17 -0500, Liam Healy said: > > > > The new syntax is as follows. If you want the structure itself, use > > (:struct foo). If you want a pointer to it, use (:pointer (:struct > > foo)). The latter should be identical to the old style bare struct > > specification, except for the annoying deprecation warning, of course. > > > > The issues I can identify, with their resolutions: > > > > 1) Using mem-aref with the (:pointer (:struct ...)) spec gives the wrong > > pointer. > > > > I have fixed an error which should now return the correct pointer for an > > offset of 0. For an offset of 1, it returns the base pointer +8 bytes, > > which is not what the old style gives (+ 4 bytes), but it seems to me > > correct, as I understand the index to refer to the number of whole > > structures. Pull ee90bfd517 and try. > > > > 2) The plist form representing the structure is not desirable. > > > > You can have any CL representation of the structure you like; you need to > > define a method cffi:translate-from-foreign for your type class. You are > > getting the default, a plist translation, because no such method is > > defined. See for example how I translate complex > > numbers< > http://repo.or.cz/w/antik.git/blob/1ee407c69525b84b441f8cf7b48ac590e78bd635:/foreign-array/complex-types.lisp#l50 > >to > > CL complex numbers. You can even return a pointer if you want, but > > this > > probably isn't the specification to use if you want the pointer. > > > > > > On Mon, Feb 13, 2012 at 10:22 AM, Ryan Pavlik < > > > reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > > > wrote: > > > > > I've pulled the latest and it appears the semantics have changed for > > > mem-aref, but there is still no way to get the old behavior. Here is a > > > complete example, though it doesn't use the test system definitions > because > > > actual foreign calls and definitions aren't really the problem: > > > > > > ``` > > > (asdf:load-system :cffi) > > > > > > (cffi:defcstruct my-struct > > > (x :short) > > > (y :short)) > > > > > > (defun test-old-ref () > > > (declare (notinline cffi:mem-ref cffi:mem-aref)) > > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > > (format t "~&Old-ref style:~%ptr : ~A~%aref: ~A~%" > > > ptr (cffi:mem-aref ptr 'my-struct 1)))) > > > > > > (defun test-new-ref () > > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > > (format t "~&New-ref style:~%ptr : ~A~%aref: ~A~%" > > > ptr > > > (cffi:mem-aref ptr '(:struct my-struct) 1)))) > > > > > > (defun test-new-ptr-ref () > > > (cffi:with-foreign-object (ptr '(:struct my-struct) 2) > > > (format t "~&New-ref with :pointer style:~%ptr : ~A~%aref: ~A~%" > > > ptr > > > (cffi:mem-aref ptr '(:pointer (:struct my-struct)) 1)))) > > > > > > (progn > > > (test-old-ref) > > > (test-new-ref) > > > (test-new-ptr-ref)) > > > ``` > > > > > > The output I get, sans style-warnings about bare structs: > > > > > > ``` > > > Old-ref style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > > aref: #.(SB-SYS:INT-SAP #X7FFFEEFCFFF4) > > > New-ref style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > > aref: (Y 0 X 0) > > > New-ref with :pointer style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0) > > > aref: #.(SB-SYS:INT-SAP #X00000000) > > > ``` > > > > > > Note that in the first example, with the original semantics, if you > > > mem-aref a pointer to an array of `my-struct`, you get a pointer to the > > > array element. In the new style, with `(:struct my-struct)`, you get > the > > > values parsed into a list, which is not particularly useful; it > conses, and > > > you almost certainly have to re-parse a possibly long list for a single > > > element. In the new style with `:pointer`, it appears to dereference > the > > > Nth element in an *array of pointers to my-struct*, which is not at all > > > what we want. > > > > > > The latter differs from the behavior before I updated, which seemed to > > > return a *pointer* to the Nth element in an array-of-pointers. None > of the > > > above are like the old behavior. > > > > > > --- > > > Reply to this email directly or view it on GitHub: > > > https://github.com/cffi/cffi/pull/2#issuecomment-3941718 > > > > > > > _______________________________________________ > cffi-devel mailing list > cffi-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhealy at common-lisp.net Mon Feb 20 09:12:44 2012 From: lhealy at common-lisp.net (Liam Healy) Date: Mon, 20 Feb 2012 12:12:44 -0500 Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: References: Message-ID: Ryan - I am forwarding this to CFFI-devel and Martin directly (though I'm pretty sure he's subscribed to cffi-devel). Can you please send future messages to cffi-devel? I'm not sure many people read the github mailing list; this issue should get wider visibility. Thanks. Liam On Mon, Feb 20, 2012 at 12:02 PM, Ryan Pavlik < reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > wrote: > I'm not sure what you mean. It doesn't really matter that a pointer is > aggregate or not. The goal is to get at the Nth member of an > array-of-something. In the case of scalar C types, you're getting the > value; in the case of structs it's far more useful to get a pointer, > because you probably only want a single value out of the struct, or to > **put a value into the struct**. (The `setf` form works for scalars in the > latter case, but not for "member-of-struct-of-index-N"... you most likely > want the pointer in these cases.) > > It also occurred to me after posting that there is no difference between > `(mem-aref ptr '(:pointer (:struct foo)) N)` and just simply `(mem-aref ptr > :pointer N)` ... both return a pointer value as if `ptr` is a `void > *ptr[k]`. > > A struct of more bytes works the same way: > > ``` > (cffi:defcstruct my-struct > (x :long) > (y :long) > (x :long) > (t :long)) > > ... > > Old-ref style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > aref: #.(SB-SYS:INT-SAP #X7FFFEEFC7FD8) > New-ref style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > aref: (T 0 Y 0 X 0) > New-ref with :pointer style: > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > aref: #.(SB-SYS:INT-SAP #X00000000) > ``` > > Note that on my system, a pointer is 8 bytes, not 4. This is why I > initially found the problem, when trying to access an array of points > defined by 2 short; each member is 4 bytes, and it was giving offsets to > `sizeof(void*)`. > > --- > Reply to this email directly or view it on GitHub: > https://github.com/cffi/cffi/pull/2#issuecomment-4057418 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at lispworks.com Fri Feb 24 04:34:34 2012 From: martin at lispworks.com (Martin Simmons) Date: Fri, 24 Feb 2012 12:34:34 GMT Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: (message from Liam Healy on Mon, 20 Feb 2012 12:12:44 -0500) References: Message-ID: <201202241234.q1OCYYQd012679@higson.cam.lispworks.com> To answer Ryan's point, I think there should be a different function to get a pointer to an element of an array, called something like mem-aptr. It should work for all element types, not just aggregates. That allows mem-aref to have "value" semantics for all types. For aggregates, converting to a plist is one possible way to representing it. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ >>>>> On Mon, 20 Feb 2012 12:12:44 -0500, Liam Healy said: > > Ryan - > > I am forwarding this to CFFI-devel and Martin directly (though I'm pretty > sure he's subscribed to cffi-devel). Can you please send future messages > to cffi-devel? I'm not sure many people read the github mailing list; this > issue should get wider visibility. Thanks. > > Liam > > On Mon, Feb 20, 2012 at 12:02 PM, Ryan Pavlik < > reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com > > wrote: > > > I'm not sure what you mean. It doesn't really matter that a pointer is > > aggregate or not. The goal is to get at the Nth member of an > > array-of-something. In the case of scalar C types, you're getting the > > value; in the case of structs it's far more useful to get a pointer, > > because you probably only want a single value out of the struct, or to > > **put a value into the struct**. (The `setf` form works for scalars in the > > latter case, but not for "member-of-struct-of-index-N"... you most likely > > want the pointer in these cases.) > > > > It also occurred to me after posting that there is no difference between > > `(mem-aref ptr '(:pointer (:struct foo)) N)` and just simply `(mem-aref ptr > > :pointer N)` ... both return a pointer value as if `ptr` is a `void > > *ptr[k]`. > > > > A struct of more bytes works the same way: > > > > ``` > > (cffi:defcstruct my-struct > > (x :long) > > (y :long) > > (x :long) > > (t :long)) > > > > ... > > > > Old-ref style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > aref: #.(SB-SYS:INT-SAP #X7FFFEEFC7FD8) > > New-ref style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > aref: (T 0 Y 0 X 0) > > New-ref with :pointer style: > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > aref: #.(SB-SYS:INT-SAP #X00000000) > > ``` > > > > Note that on my system, a pointer is 8 bytes, not 4. This is why I > > initially found the problem, when trying to access an array of points > > defined by 2 short; each member is 4 bytes, and it was giving offsets to > > `sizeof(void*)`. > > > > --- > > Reply to this email directly or view it on GitHub: > > https://github.com/cffi/cffi/pull/2#issuecomment-4057418 > > > From evenson at panix.com Fri Feb 24 09:16:06 2012 From: evenson at panix.com (Mark Evenson) Date: Fri, 24 Feb 2012 18:16:06 +0100 Subject: [cffi-devel] Patch for ABCL to dynamically load CFFI JNA requirement Message-ID: <4F47C5D6.2030605@panix.com> Please consider the referenced patch for inclusion in cffi-0.10.7. Comments towards improvments solicited. Improvements to ABCL CFFI implementation: o autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev) o initial implementation of callbacks Needs ABCL specific tests, but I can load CL+SSL with this patch. [1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff Cheers, easyE -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From rpavlik at gmail.com Mon Feb 27 06:58:21 2012 From: rpavlik at gmail.com (Ryan Pavlik) Date: Mon, 27 Feb 2012 08:58:21 -0600 Subject: [cffi-devel] [cffi] FSBV (#2) In-Reply-To: <201202241234.q1OCYYQd012679@higson.cam.lispworks.com> References: <201202241234.q1OCYYQd012679@higson.cam.lispworks.com> Message-ID: On Fri, Feb 24, 2012 at 06:34, Martin Simmons wrote: > To answer Ryan's point, I think there should be a different function to get a > pointer to an element of an array, called something like mem-aptr. ?It should > work for all element types, not just aggregates. > > That allows mem-aref to have "value" semantics for all types. ?For aggregates, > converting to a plist is one possible way to representing it. This is actually what I'm doing as an interim workaround. If this was official functionality it would be great. I've been assuming that it was more desirable to have this represented notationally. For backward compatibility it might be nice for the deprecated (bareword) behavior to retain the old semantics, though. (Default representation for dereferenced aggregates doesn't matter to me, just that you currently must.) -- Ryan Pavlik 425.220.9585