gmane.lisp.cffi.devel

Re: Groveler and HUGE_VAL

Stelian Ionescu — 2013-04-26T17:24:30

The groveler can only deal with compile-time constants. What Martin
means, I suppose, is that HUGE_VAL could be defined as a function call
to a compiler intrinsic, for instance. See
http://cvsweb.netbsd.org/bsdweb.cgi/src/include/math.h?rev=1.62



To do what exactly ?



That too is an issue. There's another ASDF component in cffi-grovel,
named wrapper-file, that can help with automatically generating a shared
library that contains functions that wrap values which cannot be
portably grovelled, so your best choice might be to generate a wrapper
that returns an uint64_t which you then pass to
nlopt_set_lower_bounds(), completely avoiding the use of Lisp floats.

Re: Groveler and HUGE_VAL

Zach — 2013-04-26T14:40:12

Thanks Martin, that's just what I'll do.

However, isn't the entire point of a groveler to build a little C program
that gathers information like this for later use?  If one were to write a
general purpose way to do this, wouldn't the logical place to put that code
be in cffi-groveler?  Is the main hurdle here the fact that HUGE_VAL
doesn't necessarily have a representation as a Lisp interger or
double-float, the only two types that cvar allows?  Even though some of
these sound a bit rhetorical, these are honest questions.

Zach



On Fri, Apr 26, 2013 at 8:25 AM, Martin Simmons <martin< at >lispworks.com>wrote:

Re: Groveler and HUGE_VAL

Martin Simmons — 2013-04-26T14:25:06

That's not the only problem -- on some platforms, HUGE_VAL is not a
compile-time constant.  It looks like the only portable way to get the value
is to write a C helper function to return it.

Re: Groveler and HUGE_VAL

Zach — 2013-04-26T02:55:38

I have also been thinking along these lines.  The only thing I worry about
is whether this is strictly correct or just correct in practice.  Is there
a guarantee that a double float is always the same size as a uint64.  It's
true on every platform I have ever programmed for (I think), but will it
always be true?  Back when I programmed in C more often, hard coding data
type sizes into a program just seemed wrong so I didn't do it, so I guess I
wouldn't know.  Perhaps I am sweating a non-issue...

Thanks for the advice.

Re: Mailing list Issues

Drew C — 2013-04-26T02:54:28

Hey,

So you do not want to subscribe, or you _do_ want to subscribe but not get
any mails at all? The former is simple. The latter should be as well (the
nomail version).

What I did was add the subscribers to the list, but it is a new software,
so a lot of the goodies are not quite transferred.

cffi-devel+help< at >common-lisp.net is the address to send to receive the help
from the mailing lists,

cffi-devel+subscribe-nomail< at >common-lisp.net may be what you want.
Otherwise, the +help should explain things.

Sorry about the issues, and if there are any problems at all, please email
me and they will be taken care of.

 -- drewc





On Thu, Apr 25, 2013 at 7:40 PM, Barry Fishman <barry_fishman< at >acm.org>wrote:

Mailing list Issues

Barry Fishman — 2013-04-26T02:40:01

The references to the cffi-devel mailing list on the web page are broken.

I had disabled receiving mail from the list.  However, I have suddenly
started receiving mail from the list.  How do I stop it?

Re: Problems with nested structs and the newer cffi

Liam Healy — 2013-04-26T02:23:09


I had thought about doing something like this when looking into Willem's
problems. I like it, but I think the "*" in the name is unnecessary. It is
upwardly compatible with the current with-foreign-slots, isn't it? That is,
if it were to replace with-foreign-slots, it would expand correctly for
current usage (to values).  I think we should replace that macro with this.

Liam

Re: Groveler and HUGE_VAL

Stelian Ionescu — 2013-04-26T02:23:00




Remember that CFFI is untyped, so every (de)reference is an implicit
cast. As long as you're careful about the type sizes, you can do
something like this:

(with-foreign-object (huge :uint64)
  (setf (mem-ref huge :uint64) (expt 2 63))
  (mem-ref huge :double))

When defining the binding to nlopt_set_lower_bounds, the second argument
will be a (generic) pointer and you can pass a pointer to anything.

(constant (+huge-val+ "HUGE_VAL") :type integer)

then

(with-foreign-object (huge-ptr :uint64)
  (setf (mem-ref huge-ptr :uint64) +huge-val+)
  (nlopt-set-lower-bound opts huge-ptr))

Re: Problems with nested structs and the newer cffi

Liam Healy — 2013-04-26T02:20:00

On Thu, Apr 25, 2013 at 2:51 AM, Willem Rein Oudshoorn
<woudshoo< at >xs4all.nl>wrote:


That seems to be an oversight. Luis?

Liam

Groveler and HUGE_VAL

Zach — 2013-04-25T22:31:48

I am trying to grovel the value of HUGE_VAL from math.h.  This:

(constant (huge-val "HUGE_VAL") :type double-float)

doesn't work, presumably because HUGE_VAL isn't a proper float on my system
(but rather some special positive infinity double float).  I get this error:

The value NLOPT::INF is not of type REAL.

I need to use HUGE_VAL in the arguments in my NLOpt bindings (hence the
package name in NLOPT::INF, though I don't think I even typed INF into the
system).  I believe that I can't use, say, most-positive-double-float, as
there is special behavior when the value HUGE_VAL is used, i.e. it isn't
just a large number.

Interestingly, I can grovel HUGE_VAL as an integer with value
18446744073709551615 which, presumably, if I used the ieee-floats system:

(ieee-floats:decode-float64 18446744073709551615) == HUGE_VAL

However, I'm not sure of that and that form naturally produces an overflow
error.  This is a value that cannot actually be represented as a float,
after all.  Anyway, I'm not sure that this he

Re: Problems with nested structs and the newer cffi

Willem Rein Oudshoorn — 2013-04-25T07:05:26


Filed bug, with reproduction scenario as Bug #1172592 on launchpad.
I probably do something silly :-(

Kind regards,
Wim Oudshoorn

Re: Problems with nested structs and the newer cffi

Willem Rein Oudshoorn — 2013-04-25T06:51:43


Thank you for the clarification


Yes, indeed that makes sense.  

Thank you for your explanation.
BTW, is it correct that the documentation is not completely up to date
yet?  The copy I looked at did not decument the :class option to
defcstruct.   I am probably looking at the wrong place :-)

Kind regards,
Wim Oudshoorn.

Re: Problems with nested structs and the newer cffi

Chris Bagley — 2013-04-25T08:33:43

I ran into similar issues to Willem and have taken to using the following
macro:

(defmacro with-foreign-slots* ((vars ptr type) &body body)
  "Create local symbol macros for each var in VARS to reference
foreign slots in PTR of TYPE. Similar to WITH-SLOTS.
Each var can be of the form: slot-name - in which case slot-name will
be bound to the value of the slot or: (:pointer slot-name) - in which
case slot-name will be bound to the pointer to that slot."
  (let ((ptr-var (gensym "PTR")))
    `(let ((,ptr-var ,ptr))
       (symbol-macrolet
           ,(loop :for var :in vars :collect
                 (if (listp var)
                     (if (eq (first var) :pointer)
                         `(,(second var) (foreign-slot-pointer
                                          ,ptr-var ',type ',(second var)))
                         (error "Malformed var names must be:~%name~% -or-
~%(:pointer name)"))
                     `(,var (foreign-slot-value
                             ,ptr-var ',type ',var))))
         ,< at >bod

Re: Problems with nested structs and the newer cffi

Liam Healy — 2013-04-24T19:44:02

On Wed, Apr 24, 2013 at 4:35 AM, Willem Rein Oudshoorn
<woudshoo< at >xs4all.nl>wrote:


Well, there's a bit of unwritten convention being used, so confusion is
understandable (and I had to think about it and infer what
with-foreign-slots is intended to do). Before we introduced
structures-by-value, this wasn't an issue.




The documentation to
foreign-slot-pointer<http://common-lisp.net/project/cffi/manual/html_node/foreign_002dslot_002dpointer.html>
 says
" ptr
A pointer to a structure.
type
A foreign structure type. "

so it makes sense to me the that first argument is a pointer to a
structure, and the second argument is the type of that structure (and not
the type of the first argument, i.e., the pointer type).


No, that seems like a CFFI error. Per Luis, a bug report would be helpful.

Liam

Re: Problems with nested structs and the newer cffi

Luís Oliveira — 2013-04-24T10:15:23

On Wed, Apr 24, 2013 at 9:35 AM, Willem Rein Oudshoorn
<woudshoo< at >xs4all.nl> wrote:

Your expectations are correct. That should work. If you could open a
launchpad bug with a small test case that'd be very helpful.

Cheers,

--
Luís Oliveira
http://r42.eu/~luis/

Re: Problems with nested structs and the newer cffi

Willem Rein Oudshoorn — 2013-04-24T08:35:27

Thank you for all your work and the time to answer my questions.

Liam Healy <lnp< at >healy.washington.dc.us> writes:


Ah, ok, I am a bit struggling to convert the old way to the new way.  It
probably has nothing to do with (with-foreign-slots ...), but just my 
mis understanding and trying to quickly convert old code to new.


Ah, I do not have an issue with passing it to the c library.
What I meant was that in my mind the following confused me:

     (let ((c-oid (foreing-alloc '(:struct git-oid))))
        ;;; I think of c-oid, conceptually as type
        ;;;  (:pointer (:struct git-oid))
        ;;;; later:

           (foreign-slot-pointer c-oid '(:struct git-oid) 'id)
           ;;; I thought that because c-oid is of type
           ;;; (:pointer (:struct git-oid))
           ;;; I thought I needed to put here
           ;;;   '(:pointer (:struct git-oid)) instead of
           ;;;   '(:struct git-oid)

Does this make sense?
           


Now I have a small additional question.

I have a struct like:

(

Re: Problems with nested structs and the newer cffi

Liam Healy — 2013-04-22T17:25:27

Willem,

Thanks for the report.

My thinking is that with-foreign-slots is intended to expose the value (and
not the pointer), and therefore, expands to foreign-slot-value, so the
behavior you're seeing is correct. Your fix to your code is the correct way
to access the pointer. I think with-foreign-slots is provided as a
convenient shortcut to get all the values; since it doesn't do what you
need, you need to use the actual access form (foreign-slot-pointer in your
case).

For your second question: if the argument is actually a pointer to the
structure, :pointer is the right thing to use. Are you sure it is a pointer
argument? Check the .h file where it is defined.

Liam


On Sat, Apr 20, 2013 at 4:40 AM, Willem Rein Oudshoorn
<woudshoo< at >xs4all.nl>wrote:

Problems with nested structs and the newer cffi

Willem Rein Oudshoorn — 2013-04-20T08:40:17

I am encountering some problems with trying to upgrade my old cffi code
to the new version from quicklisp.  
If I use the old code, I get lots of warnings about my structs, that I
should use either (:struct ...) or (:pointer (:struct ...))

However whateer I try, I do not seem to get it to work, and I am
starting to think there is some issue between me and the new cffi.


The main issue is a nested struct definition like this:

```
(defcstruct timeval
  (time %time)
  (offset :int))

(defcstruct (git-signature)
  (name :string)
  (email :string)
  (time (:struct timeval)))
```

With type definitions

```
(define-foreign-type time-type ()
  nil
  (:actual-type :int64)
  (:simple-parser %time))

(define-foreign-type git-signature-type ()
  nil
  (:actual-type :pointer)
  (:simple-parser %git-signature))
```

I encounter problems when I am trying to update the 
`translate-to-foreign` for the `git-signature-type`.
The implementation boils down to:

```
(defmethod translate-to-foreign ((value list) (type git-sign

Re: Error on web page

Luís Oliveira — 2013-04-14T12:53:23

The webpage makes use of Apache's server-side includes which Drew neglected
to enable after migrating c-l.net's servers somewhere else. I hope it's
re-enabled soon.

Cheers,

Error on web page

Liam Healy — 2013-04-14T12:20:58

Under "Getting Started", the home page now says.

The latest version is , released on (release notes).

Liam

2013年,企业薪酬还需保密吗

vincent.Cheng — 2013-04-11T16:02:37