Re: [PATCH] guile: fix smob exports

[George Barrett <bob@bob131.so>]

On Thu, Jun 03, 2021 at 10:22:54AM +0100, Andrew Burgess wrote:
> > +  SCM smob_type = scm_smob_type_class (result);
> 
> I don't know if we have a defined earliest supported version of guile,
> but I tried building again guile 2.0.14 with this patch applied and
> the build failed at the above line as scm_smob_type_class was not
> known.  Before this patch 2.0.14 would build fine.

Ouch, I forgot to even check! Sorry about that. As for an earliest supported
version, trying to build against 1.8 fails but Fedora still links against 2.0.
So 2.0 sounds about right.

This is a bit of a problem, though. Digging though the code/commit log,
options for accessing smob class values from outside libguile seems to break
down as follows:
 - <2.1.0: Export from (oop goops)
 - =2.1.0: N/A (!!!)
 - >2.1.0: scm_smob_type_class

IIUC Guile's odd minor versions are development/preview releases so the lack
of availability in the 2.1.0 case shouldn't have much impact, but it'll make
for a nice ifdef ladder.

> > +  SCM smob_type_name = scm_class_name (smob_type);
> > +  scm_define (smob_type_name, smob_type);
> 
> There's also scm_c_define which looks like it would do the same thing
> without us having to lookup the type name?  We could just pass name
> through directly.

The class name isn't the same as what gets passed to `scm_make_smob_type';
rather, the supplied name is implicitly enclosed in '<>'. Should I add a
comment saying as much?

> > +# Check that smob classes are exported properly
> 
> Missing '.' at the end here.

Ack.

> > +with_test_prefix "test exports" {
> > +    # For is-a? and <class>
> 
> Could you change this to 'Import (oop goops) for is-a? and <class>.',
> this comment really puzzled me for a while.

Sure. Reading it back, I'm not sure anyone could blame you for being confused
;)

Thanks