guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.8 ‘send’ bug + re-engagement


From: Ludovic Courtès
Subject: Re: 1.8 ‘send’ bug + re-engagement
Date: Sat, 25 Aug 2012 16:24:26 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.1 (gnu/linux)

Hi Thien-Thi!

Thien-Thi Nguyen <address@hidden> skribis:

> Looking to move WIKID[0] out of the Guile 1.4.x ghetto (which is pretty
> cozy, i must say),

(Speaking of which, do let me know when rpx has left the ghetto, too. :-))

> i ran into a Guile 1.8 problem.  Apparently, ‘send’ gratuitously
> demands its MESSAGE arg (a string) be writable.  This loses if, e.g.,
> MESSAGE is the result of ‘symbol->string’.  Here is the fix:
>
>  libguile/socket.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Sounds great.  There are ‘sendto’ unit tests, but no ‘send’ tests.  As a
bonus, if you feel like adding a couple of these, you’re welcome.  :-)

> Since i've been graciously (re-)granted write privs, i'd like to apply
> the fix myself (in the savannah repo), onto ‘branch_release-1-8’.

Yes, please do!  Can you apply it to stable-2.0 as well?

> $ glog branch_release-1-8.. --reverse

“glog”?  :-)

> ee70ab6 2012-08-22 Rename configure.in to configure.ac, twice
> 04d7f4a 2012-08-22 configure, int: Add abstraction: CONFIG_SCRIPT
> 4bfdc6b 2012-08-23 Delete EOL whitespace; nfc
> 4099d14 2012-08-23 configure: Dose configure.ac w/ "proper" m4-quoting
> 037b7f6 2012-08-22 configure, int: Remove EOF "Local Variables" block; nfc
> b3ee840 2012-08-23 configure, int: Add more 'AC_LANG_PROGRAM' calls
> ccb98a3 2012-08-23 Delete EOL whitespace; nfc
> 60a29ff 2012-08-23 libguile: Fix bug: Don't expect 'send' string to be 
> writable
> d70f9c8 2012-08-23 Update years in copyright notice; nfc
>
> Note that the fix is the penultimate change (60a29ff).  How about i push
> this to ‘ttn-back-in-the-saddle’ for review?

Makes sense, yes.

> The branch name reflects a desire to start doing the 1.8 curation that
> Someone should be doing.

Good idea.  I think I once said we SHOULD release 1.8.9 RSN.  Would you
like to take care of that?

> The changes are done in a hybrid ttn-gnu maintainance style.

I’m not sure what you mean here.  :-)  I prefer a impersonal GNUish
style.

> I imagine if this particular fix goes smoothly, i will be motivated to
> continue w/ this kind of maintenance work, where the focus is on
> continuity and stability (perhaps likewise showing 1.6 and 1.4 some
> love, as well).

Hmm, I’d find it more important to help fix any issues that prevent
current 1.8 users from switching to 2.0, FWIW.

> I remain confused (and slightly put off) by the "we're worried you'll be
> cavalier" warnings mixed with what i perceive as cavalier design
> decisions and code changes by the warners, but anyway wish to reassure
> everyone that i will limit myself to cleanups (such as those above
> listed), bug fixes and doc improvements, all of which are far from
> (deep) design.
>
> What do the maintainers think?

I think this is excellent news, thank you!

Ludo’.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]