From: Marius Vollmer <mvo@zagadka.de>
Subject: Re: Branching for 1.8 on 2006-02-05
Date: Tue, 07 Feb 2006 02:18:20 +0200 [thread overview]
Message-ID: <877j88c983.fsf@zagadka.de> (raw)
In-Reply-To: <873biwsut8.fsf@laas.fr> (Ludovic Courtès's message of "Mon, 06 Feb 2006 10:25:23 +0100")
ludovic.courtes@laas.fr (Ludovic Courtès) writes:
> Hi,
>
> Rob Browning <rlb@defaultvalue.org> writes:
>
>> Also if we don't want to have people hold off on 1.9 only bits in the
>> trunk, then I'd say that now qualifies as "as late as possible" ;>
>
> There has been no 1.7.3, the CVS repository has been relatively
> quiet since 1.7.2, and applying patches has sometimes been, well,
> delayed. Therefore, I find it quite strange to branch in this
> moment of quietness and uncertainty.
I unfortunately can't find the time and/or concentration to do more
significant work on Guile right now. I have been wanting to make the
1.8 release for quite some time now, and it has become clear to me
that I need to stop procrastinating and to start giving myself some
strict deadlines if I want to make any progress at all.
The trunk is featurewise in a good shape for a release, and one point
of the branching is to actually remove uncertainty: it should be much
easier now to work freely on new things in the trunk; you don't have
to worry to mess up the 1.8 release.
> Also, it seems that there is no clear plan for the eventual integration
> of Unicode and to me, having at least a rough plan would be a
> prerequisite to the next stable release.
There is a rough plan. The new C-side array API in 1.8 is the
beginning of it and the (my) plan is to redo the underlying
implementation in a cleaner way and add uniform arrays of 8-bit,
16-bit, and 32-bit Unicode code points in the process. Then the
srfi-13 and srfi-14 functions will be extended to cover all of Unicode
and there will be scm_from_utf8_string functions, etc. This means
that strings remain vector-like. (If experience with that shows that
a more efficient representation for non-8-bit code points is needed,
we can start experimenting with it.)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
prev parent reply other threads:[~2006-02-07 0:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-28 15:26 Branching for 1.8 on 2006-02-05 Marius Vollmer
2006-01-29 9:13 ` Neil Jerram
2006-01-29 12:45 ` Han-Wen Nienhuys
2006-02-03 23:49 ` Kevin Ryde
2006-02-04 19:38 ` Rob Browning
2006-02-05 19:02 ` Marius Vollmer
2006-02-05 20:30 ` Rob Browning
2006-02-06 9:25 ` Ludovic Courtès
2006-02-07 0:18 ` Marius Vollmer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877j88c983.fsf@zagadka.de \
--to=mvo@zagadka.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).