Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-09 Thread Chris Mueller

On 09.09.2013 00:07, Kristian Lein-Mathisen wrote:

Ah, of course, John! I got them mixed up.

In that case Chris, I think your color struct might fit quite nicely
into a make-s32vector. I did not test the code below, but something like
it might work:


(define-foreign-type color* s32vector
   (lambda (a) (assert (= 4 (s32vector-length a))) a))

(define color s32vector)
(define (rgb-to-hsl color)
   (let ((return (make-s32vector 3)))
 ((foreign-lambda*
   void ((color input) (color output))
   rgb_to_hsl((struct color*)input, output[0], output[1],
output[2])) color return)
 return))

(rgb-to-hsl (color 0 255 0 0)) ;; -- should in theory return a
;; 3-element s32vector with your hue,
;; sat and lum.


Note the cast from s32vector (int*) to struct color*.

Cheers,
K.


Thanks for this extensive example. I've managed it exactly this way :) 
with the usage of srfi-4.






On Sat, Sep 7, 2013 at 4:33 PM, John Cowan co...@mercury.ccil.org
mailto:co...@mercury.ccil.org wrote:

Kristian Lein-Mathisen scripsit:

  Because size of an int can generally be either 32 or 64-bit
depending
  on your architecture, the srfi-4 vectors are possible better suited
  for floats and doubles where the sizes are all set. It's worth
knowing
  about them though.

Actually, there are essentially no architectures on which int is
anything but 32 bits: unless you have an ancient Cray running Unicos
(modern ones run Linux), a (now-defunct) HAL Systems port of Solaris,
or an IBM PC/AT, you don't have to worry about that.  What does vary is
long, which is 32 bits on 32-bit systems and Win64, and 64 bits on
non-Windows 64-bit systems.

--
John Cowan http://ccil.org/~cowan co...@ccil.org mailto:co...@ccil.org
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings Ding dong, the
witch is dead.  --Elliotte Rusty Harold on xml-dev





___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-08 Thread Kristian Lein-Mathisen
Ah, of course, John! I got them mixed up.

In that case Chris, I think your color struct might fit quite nicely into a
make-s32vector. I did not test the code below, but something like it might
work:


(define-foreign-type color* s32vector
  (lambda (a) (assert (= 4 (s32vector-length a))) a))

(define color s32vector)
(define (rgb-to-hsl color)
  (let ((return (make-s32vector 3)))
((foreign-lambda*
  void ((color input) (color output))
  rgb_to_hsl((struct color*)input, output[0], output[1],
output[2])) color return)
return))

(rgb-to-hsl (color 0 255 0 0)) ;; -- should in theory return a
   ;; 3-element s32vector with your hue,
   ;; sat and lum.


Note the cast from s32vector (int*) to struct color*.

Cheers,
K.


On Sat, Sep 7, 2013 at 4:33 PM, John Cowan co...@mercury.ccil.org wrote:

 Kristian Lein-Mathisen scripsit:

  Because size of an int can generally be either 32 or 64-bit depending
  on your architecture, the srfi-4 vectors are possible better suited
  for floats and doubles where the sizes are all set. It's worth knowing
  about them though.

 Actually, there are essentially no architectures on which int is
 anything but 32 bits: unless you have an ancient Cray running Unicos
 (modern ones run Linux), a (now-defunct) HAL Systems port of Solaris,
 or an IBM PC/AT, you don't have to worry about that.  What does vary is
 long, which is 32 bits on 32-bit systems and Win64, and 64 bits on
 non-Windows 64-bit systems.

 --
 John Cowanhttp://ccil.org/~cowanco...@ccil.org
 SAXParserFactory [is] a hideous, evil monstrosity of a class that should
 be hung, shot, beheaded, drawn and quartered, burned at the stake,
 buried in unconsecrated ground, dug up, cremated, and the ashes tossed
 in the Tiber while the complete cast of Wicked sings Ding dong, the
 witch is dead.  --Elliotte Rusty Harold on xml-dev

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-07 Thread Kristian Lein-Mathisen
Hey Chris,

I though I'd mention the srfi-4 unit and it's u32vector. This may come in
handy for your particular struct. While make-blobs are great for allocating
managed memory for arbitrary structs, you can sometimes use make-s32vector,
for example, where the struct is basically an array like yours.

Note that this may not be a good idea if your struct members are just using
int because you wouldn't know if it's a s32vector or a s64vector. Also,
your foreign-type would go from (pointer (struct color)) to a
u32vectorwhich means you may have to cast it to a (struct
color*) in C. However, it does make extracting the individual
color-components much easier than having to work with raw blobs.

Because size of an int can generally be either 32 or 64-bit depending on
your architecture, the srfi-4 vectors are possible better suited for floats
and doubles where the sizes are all set. It's worth knowing about them
though.

Cheers,
K.


On Fri, Sep 6, 2013 at 12:23 PM, Chris Mueller ruunsm...@gmail.com wrote:

 On 06.09.2013 09:07, Peter Bex wrote:

 On Fri, Sep 06, 2013 at 08:52:08AM +0200, Chris Mueller wrote:

 Hope its not too basic for you. :)


 Never, user questions are what this mailing list is for!  I hope my
 answers make a little sense.


 Definitely! This is very helpful. I will immediately check and use this.

 Now it also makes sense for me what's one of the intensions behind blobs
 in the documentation/wiki. Never thought it can be used for
 memory allocation in C interfaces :)

 Thanks

 Chris


 __**_
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/**mailman/listinfo/chicken-usershttps://lists.nongnu.org/mailman/listinfo/chicken-users

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-07 Thread Peter Bex
On Sat, Sep 07, 2013 at 12:48:27PM +0200, Kristian Lein-Mathisen wrote:
 Note that this may not be a good idea if your struct members are just using
 int because you wouldn't know if it's a s32vector or a s64vector. Also,
 your foreign-type would go from (pointer (struct color)) to a
 u32vectorwhich means you may have to cast it to a (struct
 color*) in C. However, it does make extracting the individual
 color-components much easier than having to work with raw blobs.
 
 Because size of an int can generally be either 32 or 64-bit depending on
 your architecture, the srfi-4 vectors are possible better suited for floats
 and doubles where the sizes are all set. It's worth knowing about them
 though.

Good call!  There's also the bitstring egg which makes destructuring
blobs into component values pretty easy as well.

Cheers,
Peter
-- 
http://www.more-magic.net

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-07 Thread John Cowan
Kristian Lein-Mathisen scripsit:

 Because size of an int can generally be either 32 or 64-bit depending
 on your architecture, the srfi-4 vectors are possible better suited
 for floats and doubles where the sizes are all set. It's worth knowing
 about them though.

Actually, there are essentially no architectures on which int is
anything but 32 bits: unless you have an ancient Cray running Unicos
(modern ones run Linux), a (now-defunct) HAL Systems port of Solaris,
or an IBM PC/AT, you don't have to worry about that.  What does vary is
long, which is 32 bits on 32-bit systems and Win64, and 64 bits on
non-Windows 64-bit systems.

-- 
John Cowanhttp://ccil.org/~cowanco...@ccil.org
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings Ding dong, the
witch is dead.  --Elliotte Rusty Harold on xml-dev

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-06 Thread Peter Bex
On Fri, Sep 06, 2013 at 08:52:08AM +0200, Chris Mueller wrote:
 Hi,

Hi!

 i've currently started experimenting with the FFI interface provided by 
 the chicken compiler and have some principle questions about its common 
 usage.

Sure, no problem.  One important thing to remember is that there are
many, many ways to accomplish the same task using the FFI.  Which way
you choose depends on the C API you're binding to, your personal
preferences, performance concerns and your/your users' convenience.

 Assume the given C Code:
 
 struct color {
   int red;
   int green;
   int blue;
   int alpha;
 };
 
 struct color* alloc_new_color(int red, int green, int blue, int alpha);
 
 1) How do you interface allocation methods in generell with avoidance of 
 memory leaks?
 
 From the documentation i know, you can write:
 
 (define-foreign-type color* (pointer (struct color
 
 (define alloc_new_color (foreign-lambda color* alloc_new_color integer 
 integer integer integer))
 
 But this expects the user have to free the memory manually.
 
 Is there an uncomplicated way to register some automechanism?

Yes, look into register-finalizer! which is documented here:
https://wiki.call-cc.org/man/4/Unit%20library#set-finalizer

However, finalizers incur quite a performance penalty.  It may be
wiser to simply make-blob for registering the memory used by a
color struct.  This will be managed by the garbage collector directly.
Example:

(make-blob (foreign-value sizeof(struct color) int))

If you want to expose this outside of your module, it's wise to wrap
it in a unique record type, so that you don't accidentally mix up blobs
of different types:

(define-record color blob)
(define alloc-color (make-color (make-blob (foreign-value sizeof(struct 
color) int

Depending on how the colors are used you can also decide never to work
with C color objects directly, but decode them yourself like in

(define-record color red green blue)

and then pass this around, converting to struct color when needed.

 2) How can i solve this problem:
 
 void rgb_to_hsl(struct color* rgb, float* hue, float* sat, float* lum);
 
 This is simple conversation method that uses multiple return values 
 (hue, sat, lum).
 
 How can i write a ffi define that accepts an argument of type color*
 and returns a scheme-vector with three elements?

As a small sidenote: it's possibly more idiomatic Scheme to return three
separate values instead of a compound vector type containing the three
values.  ie, (values 1 2 3) versus (vector 1 2 3)

If you go with the blob approach I sketched above, you can do something
like

(define (color-hsl color-blob)
  (let-locations ((hue float) (sat float) (lum float))
((foreign-lambda void rgb_to_hsl scheme-pointer
(c-pointer float) (c-pointer float) (c-pointer float))
  color-blob (location hue)(location sat)(location lum))
(values hue sat lum)))

Possibly this may not compile cleanly, in that case you'd have to use a
foreign-lambda* and cast the scheme-pointer type to a color struct
pointer.

The idea is that locations allow you to locally define variables which
correspond to foreign types, for which you can request the memory
location so that you can use them when pointers are required.
The scheme-pointer type accepts various Scheme objects which have a
data section.  This includes blobs, strings and a few other types.

For more info about locations, see https://wiki.call-cc.org/man/4/Locations
For more info about scheme-pointer, see
https://wiki.call-cc.org/man/4/Foreign%20type%20specifiers#scheme-objects

 Hope its not too basic for you. :)

Never, user questions are what this mailing list is for!  I hope my
answers make a little sense.

Cheers,
Peter
-- 
http://www.more-magic.net

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Basic FFI Principle in Chicken

2013-09-06 Thread Chris Mueller

On 06.09.2013 09:07, Peter Bex wrote:

On Fri, Sep 06, 2013 at 08:52:08AM +0200, Chris Mueller wrote:

Hope its not too basic for you. :)


Never, user questions are what this mailing list is for!  I hope my
answers make a little sense.


Definitely! This is very helpful. I will immediately check and use this.

Now it also makes sense for me what's one of the intensions behind 
blobs in the documentation/wiki. Never thought it can be used for

memory allocation in C interfaces :)

Thanks

Chris

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users