Re: g-wrap <gw-guile-wct> questions

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

>> - Since in this case I have control over the library's source, I could
>> modify it to have seperate "close" and "free" routines.  How would I
>> connect the "free" routine to be called at GC time?  Based on the
>> documentation, I would think I would subclass <gw-guile-wct> and
>> provide a destruct-value-cg for it, but I can't seem to figure out how
>> to do that.  I've tried:
>> 
>>      (define-class <gw:parport*> (<gw-guile-wct>))
>>      (define-method (destruct-value-cg (t <gw:parport*>)
>>                                   (value <gw-value>)
>>                                   status-var)
>>        (list "parport_free(" (var value) ");\n"))
>> 
>> but get "Unbound variable: <gw-guile-wct>" in the define-class.
>
> Hm. The unbound variable warning would be because (g-wrap guile) doesn't
> export the class. Perhaps that's an oversight, although in 1.3.4, WCT
> types were not extensible. Andreas?
>
Yes, WCT types are not yet meant to be extended. I've set this on the
TODO list.

> Regarding making a destroy-value-cg (s/destruct/destroy/ in 1.9.1), I
> think that's the correct solution. However, the current (g-wrap guile)
> doesn't pass a cleanup function to gw_wct_new, so such a function will
> never be called. However, the free function in guile-wct.c does free the
> data. You should probably change (g-wrap guile) to somehow hook the
> destroy-value function to the cleanup handler.
>
This hooking will happen, when WCT types have been made
extensible. Hope I get around to do this soonish and before 1.9.2.

> G-wrap makes my head hurt.
>
:-)

>> - I might prefer that the guile wrapping of the library's "constructor"
>> either return the wrapped-C-type object or throw an error, instead of
>> returning #f for NULL pointers as it seems to do when using
>> "wrap-as-wct!".  It looks like this might be doable by providing an
>> alternate wrap-value-cg for this particular wrapped type; is this the 
>> right approach?
>
> The exception approach is correct, I think, but I don't know about
> implementing it. Perhaps post-call-result-cg is what you want; see
> (gnome gw glib-spec) for an example (although it uses post-call-arg-cg,
> since GErrors are passed as arguments).
>
> This code seems to be generally useful. Perhaps NULL should only be
> allowed as a return value if (null-ok) is in the typespec options.
> Otherwise it would throw an exception. Andreas?
>
I've been thinking of validating arguments against (null-ok) lately,
since you might easily crash wrapped libraries that are not prepared
for taking null pointers. I might add machinery to do this for result
values also, if that is deemed a useful feature.

>> - I'd really like to have the guile version of this library construct and
>> use goops objects, so I can inherit from and extend it.
>> Do I have to wrap the C library into a module of non-goops guile procedures
>> and then write a goops-using module that builds the objects and methods
>> using the g-wrapped module?
>> Or can g-wrap help in creating goops classes, objects and methods with 
>> less intermediate glue required?
>> 
>> I suppose an alternate might be to rewrite the C library using gobject
>> and get into guile-gnome-gobject.  While that's on my list of things
>> to learn about, I might not want this little library's guile wrapping
>> to depend on guile-gnome.
>
Well, you'd depend only on the core of guile-gnome (the glib module),
so if you consider using gobject on the C side an option, using
guile-gnome on the guile side makes sense IMHO. I even use the
h2def.py and the build system of guile-gnome machinery for libs that
don't use glib at all, this lets you avoid the tedious work of
hand-wrapping each function and writing configure.ac. For a little
example, see the guile-taglib category in my archive[0]. If you need
help with tying your project guile-gnome's build system, just ask.

> on a base level, this could be possible. SMOB classes are given
> GOOPS classes, which can allow you to make methods with SMOB types in
> the arguments.
>
> However, g-wrap needs some fixing, as noted in guile-wct.c near
> gw_wct_create. In short, calling gw_wct_create should return a SMOB
> class. Right now it creates a new SMOB, holding the type data, instead
> of the SMOB class. This makes is-a? fail, IIRC.
>
Added to TODO list.

> If your needs go beyond the addition of methods, and *possibly*
> inheritance (can't remember if this works or not), you should change the
> library to be based around GObject. Otherwise, you will have to
> reimplement a subset of guile-gobject, which is tricky. Trust me ;)
>
>> Since the wrapped-C-pointer use of g-wrap isn't covered well in the g-wrap 
>> documentation, figuring this out might serve as a useful example. (hint)
>
> Good luck :-)
>
I general, the documentation covers only basic usage. It definitly
needs work...

Cheers,
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett