Branching for 1.8 on 2006-02-05

Branching for 1.8 on 2006-02-05

[Marius Vollmer]

Hi,

I need to kick myself to get going with the 1.8 release, and want to
do it by just branching for 1.8 soon and thus get out of the way of
the devlopment happening on the trunk.

I want to branch next weekend, on Sunday, 5. Feb.  Before that, the
following things should be settled in trunk, I'd say:

  Inlining `scm_is_pair ()'
  `try-module-autoload' and `current-reader'
  API naming bugs (the "frame" name issue)
  Backtrace and enhanced catch

I'll take care that this happens.

(What we have in the 1.8 branch is not immediately the 1.8.0 release,
but should be very close.)

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

Re: Branching for 1.8 on 2006-02-05

[Neil Jerram]

Marius Vollmer <mvo@zagadka.de> writes:

> Hi,
>
> I need to kick myself to get going with the 1.8 release, and want to
> do it by just branching for 1.8 soon and thus get out of the way of
> the devlopment happening on the trunk.
>
> I want to branch next weekend, on Sunday, 5. Feb.  Before that, the
> following things should be settled in trunk, I'd say:
>
>   Inlining `scm_is_pair ()'
>   `try-module-autoload' and `current-reader'
>   API naming bugs (the "frame" name issue)
>   Backtrace and enhanced catch

Sounds good to me.

       Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Han-Wen Nienhuys]

In article <87fyn8xtj3.fsf@zagadka.de>, Marius Vollmer  <mvo@zagadka.de> wrote:
>Hi,
>
>I need to kick myself to get going with the 1.8 release, and want to
>do it by just branching for 1.8 soon and thus get out of the way of
>the devlopment happening on the trunk.
>
>I want to branch next weekend, on Sunday, 5. Feb.  Before that, the
>following things should be settled in trunk, I'd say:
>
>  Inlining `scm_is_pair ()'
>  `try-module-autoload' and `current-reader'
>  API naming bugs (the "frame" name issue)
>  Backtrace and enhanced catch
>
>I'll take care that this happens.
>
>(What we have in the 1.8 branch is not immediately the 1.8.0 release,
>but should be very close.)

YAY!




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> I want to branch next weekend, on Sunday, 5. Feb.  Before that, the
> following things should be settled in trunk,

There's also an error

	Non-pair accessed with SCM_C[AD]R: `#<<class> <foo> b7a0eae0>'

thrown up by goops.test under debug cell acesses.  Dunno what it means.

> (What we have in the 1.8 branch is not immediately the 1.8.0 release,
> but should be very close.)

Do you really want to branch at all?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

>> (What we have in the 1.8 branch is not immediately the 1.8.0 release,
>> but should be very close.)
>
> Do you really want to branch at all?

For what it's worth, I'd say there a benefit to branching as late as
possible.  If there aren't any items waiting to be committed to the
upcoming 1.9 tree, then the longer we can continue working (toward the
release) on the main branch, the fewer commits will have to be applied
to two branches.

(Oh, and I still have at least one outstanding bit that needs to go
into 1.7.  I need to add the slib changes.  I hope to get to that
later today or sometime tomorrow.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Kevin Ryde <user42@zip.com.au> writes:
>
>>> (What we have in the 1.8 branch is not immediately the 1.8.0 release,
>>> but should be very close.)
>>
>> Do you really want to branch at all?
>
> For what it's worth, I'd say there a benefit to branching as late as
> possible.

Hehe, it is already very late. :-)

I really want to get this thing done now, and I don't want to 'waste'
time and try to find the optimal point for branching.  I am in my
'what the heck' mode right now, and maybe I will regret it later, but
what the heck!

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

Re: Branching for 1.8 on 2006-02-05

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> Hehe, it is already very late. :-)
>
> I really want to get this thing done now, and I don't want to
> 'waste' time and try to find the optimal point for branching.  I am
> in my 'what the heck' mode right now, and maybe I will regret it
> later, but what the heck!

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" ;>

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Ludovic Courtès]

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.

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.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Branching for 1.8 on 2006-02-05

[Marius Vollmer]

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