unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Re: Passing C pointers through guile
@ 2008-07-09 19:58 Kjetil S. Matheussen
  0 siblings, 0 replies; 13+ messages in thread
From: Kjetil S. Matheussen @ 2008-07-09 19:58 UTC (permalink / raw)
  To: guile-devel


Ludovic Courtès:
>> kjetil <at> ttleush ~/guile-1.8.5 $ gcc -Iinclude/ -Llib lib/libguile.a test.c
> > /tmp/ccMcEAxd.o: In function `main':
> > test.c:(.text+0x1b): undefined reference to `scm_from_uintptr'
> > test.c:(.text+0x2c): undefined reference to `scm_to_uintptr'
> > collect2: ld returned 1 exit status
> 
> Normally, there's no such thing as `lib/libguile.a'.  The thing is under
> `libguile/.libs/libguile.{so,a}'.  Alternatively, it might be the case
> that `SCM_HAVE_T_UINTPTR' is not defined.

Normally, yes, but I installed in the same directory as the source. :-)

Anyway, I have no idea why the above didn't work, but it works now.
I haven't changed any of the files since the last time:

kjetil@ttleush ~/guile-1.8.5 $ gcc test.c -Iinclude lib/libguile.a -lgmp -lm -lltdl -lcrypt
lib/libguile.a(posix.o): In function `scm_tmpnam':
posix.c:(.text+0x14b0): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
kjetil@ttleush ~/guile-1.8.5 $ ./a.out
main: 0x804cd54, p: 804cd54
kjetil@ttleush ~/guile-1.8.5 $





^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Passing C pointers through guile
@ 2008-07-09 20:09 Kjetil S. Matheussen
  2008-07-09 20:43 ` Ludovic Courtès
  2008-07-11 13:05 ` Greg Troxel
  0 siblings, 2 replies; 13+ messages in thread
From: Kjetil S. Matheussen @ 2008-07-09 20:09 UTC (permalink / raw)
  To: guile-devel


Ludovic Court?s:
>> I gave it a try. Unfortunately, I was completely unable to create
>> the configure file right now, so the patch is against 1.8.5 (sorry
>> if this creats trouble against git repository), and
>> it's also untested, since I couldn't build configure.
>
>You have to make sure you are on the `branch_release-1-8', and then
>"autoreconf -vfi" should suffice to produce everything.  Autoconf 2.61,
>Automake 1.10 and Libtool 1.5.26 is all you need.

Thanks. It would be nice if that information was in the source 
too...


> > The only thing I'm not too sure about is whether
> > the new SCM_I_GSC_T_UINTPTR type in configure.in will actually be
> > optional or not. I just copied the checking code for the optional
> > SCM_I_GSC_T_UINT64 type though:
>
> I think this type shouldn't be optional, because there will always be a
> pointer-sized integer type (whereas there could be platform without
> 64-bit integers).

But isn't the only way to make sure that an integer size
is big enough to hold a pointer, to use uintptr_t from
stdint.h ?

It does get a little bit complicated if Guile is compiled 
on a platform without stdint.h


>>> That said, using a Scheme integer to represent a pointer wouldn't be
>>> efficient (pointers would likely translate to bignums).
>>
>> I think cleaner code would usually be more important in this case,
>> but at least there will be a choice.
>
>I'm not sure how much cleaner this is.  Usually, you'll want disjoint
>Scheme types, which means you'll end up enclosing the pointer-as-bignum
>in a structure or SRFI-9 record or similar.  This leads to even more
>overhead.  Conversely, using an opaque field in a Guile struct has the
>same effect but with much less overhead.

It's cleaner because it requires a magnitude less code.

>Another issue is that of memory management.  When using
>pointers-as-bignums, all the GC will see is a collection of bignums, not
>knowing that these are actually pointers to C objects that should not be
>GC'd unless the integer is no longer used---as opposed to "no longer
>referenced"!  This actually makes it mandatory to enclose the integer in
>a structure or similar, and then to have a guardian on that structure to
>allow the C object's destructor to be called when that structure is no
>longer referenced.

That's true. But at least my experience is that using guardians
is cleaner than smurf's. For example, I think the use of guardians for 
faust objects in http://snd.cvs.sourceforge.net/snd/cvs-snd/rt-faust.scm
is very simple, it's just one line: "(add-finalizer (-> faust 
get-c-object) cleanup-faust-object)".

Also, various types of non-gc pointers are stored in integers in
all of the rt-*.scm files in http://snd.cvs.sourceforge.net/snd/cvs-snd/
and many others (xg.c, etc.). It would be horribly idiotic
to write smurf's for all of those, or at least a common smurf, when a 
single integer is enough.




>PS: You'll have to assign copyright to the FSF so that your code can be
>    integrated.  We can discuss it off-line if you want.

Okay, just tell me what to do.





^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Passing C pointers through guile
@ 2008-07-10 12:49 Kjetil S. Matheussen
  2008-07-10 13:01 ` Ludovic Courtès
  0 siblings, 1 reply; 13+ messages in thread
From: Kjetil S. Matheussen @ 2008-07-10 12:49 UTC (permalink / raw)
  To: guile-devel


Ludovic Court?s:
>
> Well, `configure.in' has an `AC_PREREQ' call, 1.10(.1) is the latest
> Automake, and 1.5.26 is the latest Libtool of the 1.x series, it's
> easy.

Thanks, I didn't know that.


>No.  `configure' checks the size of a number of (integer) types.  The
>idea here would be to have a check for `void *' (if there isn't one
>already); then in `numbers.h', you'd add something along the lines of:
>
>  #if SCM_SIZEOF_VOID_P == 4
>  #define scm_to_uintptr scm_to_uint32
>  [...]
>  #elif SCM_SIZEOF_VOID_P == 8
>  #define scm_to_uintptr scm_to_uint64
>  [...]
>  #else
>  #error "strange `void *'"
>  #endif
>
> IOW, don't rely on <stdint.h> or <inttypes.h>.

Good idea. Much better. I'll do that.



>> That's true. But at least my experience is that using guardians
>> is cleaner than smurf's.
>
>Smurf?  Smurf's what?

Oops. :-)
I ment SMOB.



>If so, the deallocation routine that's called from the guardian (which
>is necessarily written in C) is roughly the same as the one you'd pass
>to `scm_set_smob_free ()'.

Point is that you very often don't need any kind of free functionality.
For example, if you create a gui widget, you probably have a callback
function which is called if the gui is closed. That callback
function can free any allocated memory. Another example from snd
is creating ladspa plugins (audio plugins in linux). Handlers
from those, plus variuos configuration stuff, is alive througout
the whole session and will be automatically freed when the program
closes.





^ permalink raw reply	[flat|nested] 13+ messages in thread
[parent not found: <cmu-lmtpd-26382-1215792388-9@mail-imap1.uio.no>]
end of thread, other threads:[~2008-07-11 17:22 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <cmu-lmtpd-29205-1215446748-1@mail-imap1.uio.no>
2008-07-09 16:50 ` Passing C pointers through guile Kjetil S. Matheussen
2008-07-09 18:32   ` Kjetil S. Matheussen
2008-07-09 19:37     ` Ludovic Courtès
2008-07-09 19:35   ` Ludovic Courtès
2008-07-09 19:58 Kjetil S. Matheussen
  -- strict thread matches above, loose matches on Subject: below --
2008-07-09 20:09 Kjetil S. Matheussen
2008-07-09 20:43 ` Ludovic Courtès
2008-07-11 13:05 ` Greg Troxel
2008-07-11 13:12   ` Kjetil S. Matheussen
2008-07-11 14:42     ` Ludovic Courtès
2008-07-10 12:49 Kjetil S. Matheussen
2008-07-10 13:01 ` Ludovic Courtès
     [not found] <cmu-lmtpd-26382-1215792388-9@mail-imap1.uio.no>
2008-07-11 17:22 ` Kjetil S. Matheussen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).