Re: Dico 2.0 fails to build with Guile 1.9

[ludo@xxxxxxx (Ludovic Courtès)]

Hi Sergey,

Sergey Poznyakoff <gray@xxxxxxxxxx> writes:

>>   guile.c:322: error: 'SCM_IM_QUOTE' undeclared (first use in this function)
>> 
>> Instead, you can either use scm_primitive_eval()
>
> I should try to find a backward-compatible way of doing that, to avoid
> disturbing compilation with Guile 1.8,

Sure.  But note that you shouldn’t be using ‘SCM_IM_*’ in the first
place: these things were really internal, although the headers were not
crystal-clear about this.  (We’ve had the convention that anything
prefixed by ‘scm_i_’ is internal, but like any convention, it hasn’t
always been followed.)

> which (as I suppose) will still be around for quite some time. Any
> hints?

Yes, we’ll probably keep maintaining it for some time, depending on
demand.  But of course, our hope is that 2.0 will provide enough
incentives to switch without looking back.  :-)

>> or compile the Scheme code to bytecode and then run it
>> (though there's not any C API to compile code currently.)
>
> Pity, but I hope it is planned, isn't it?

Yes, that’s not difficult to do.

>>   guile.c:724: error: 'SCM_DEVAL_P' undeclared (first use in this function)
>>   guile.c:725: error: 'SCM_BACKTRACE_P' undeclared (first use in this function)
>>   guile.c:726: error: 'SCM_RECORD_POSITIONS_P' undeclared (first use in this function)
>>   guile.c:727: error: 'SCM_RESET_DEBUG_MODE' undeclared (first use in this function)
>> 
>> In 1.9 none of these macros make sense (but we should probably add them
>> for backward compatibility and deprecate them.)  The VM will always
>> produce a backtrace with appropriate source location information when an
>> error occurs.  (I remember seeing the same thing in Mailutils, while
>> you're at it. ;-))
>
> The same thing is present also in Radius, and in Anubis, and perhaps in other
> projects I maintain... Looks like I've got quite some work to do :^)
> Unfortunately, Guile's API changes dramatically almost with each new version,
> which makes it quite hard to write portable interfaces with it. Are
> there any chances for a more-or-less stable API?

Yes.  The intent is to require few source code changes for programs that
use public APIs from 1.8.  Besides, we’ve worked on more cleanly
separating internal and public APIs, which should help in the future.

The macros above will probably be restored (but deprecated) by the time
2.0 is out.

Thanks,
Ludo’.