Hi Thien-Thi! Thien-Thi Nguyen <t...@gnuvola.org> 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’.