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.
