Re: Error-Handling; adding dependency on guile-lib

[Andreas Rottmann]

Rob Browning <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> g-wrap could really use better error handling, and I'd like to
>> implement that using said SRFI-35 (conditions). Since getting code
>> into Guile is not as easy as one would like to, it probably will
>> take some time before my SRFI-35 implementation is shipped with
>> Guile (if ever).
>>
>> G-Wrap 2.0 will thus depend on the Guile Library[0]; I've already
>> filed an Debian ITP for Guile-Lib and have a package ready for upload.
>>
>> [0] http://yi.org/rotty/GuileLib
>
> A couple of questions:
>
>   - What kind of trouble are you having getting stuff into Guile, or
>     is it just that it takes a while for things getting in to Guile to
>     make it into a release?  (Regardless of what we decide for g-wrap,
>     I'd like to have srfi-35 in Guile, and I'd also prefer that Guile
>     minimize any unnecessary hassles for contributors.)
>
Well, I provided the code for review and got some positive response,
but no request e.g. for a patch against Guile or somesuch.

>   - If the code required isn't that great, would there be any benefit
>     (and would it make any sense) to instead include a copy of the
>     code in g-wrap and conditionally integrate it based on a configure
>     test?
>
Yep, that would be an option.. I've already done so with srfi-34,
which is in Guile 1.7, but not 1.6.

> On the one hand, it's nice not to have any more deps than we need to,
> but I'd guess that Guile lib is fine as long as it's easy to get hold
> of and easy for people to install under various relevant Guile
> versions.
>
I can include srfi-35, and when guile-lib is installed it won't be
used because it's already there. Sounds good.

Andy
-- 
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

Python is executable pseudocode, Perl is executable line-noise.