[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > Rob Browning <[EMAIL PROTECTED]> 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
