octave-maintainers
[Top][All Lists]
Advanced

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

Re: moving toward a 3.0 release


From: Sebastien Loisel
Subject: Re: moving toward a 3.0 release
Date: Wed, 27 Sep 2006 17:40:45 -0400

I think Octave needs a new, stable release.

On graphics and Windows versions: the reason I've vanished for the last while was because my chosen platform (Windows + MinGW) was too buggy.

Finally, someone recently noted that Matlab has fast loops. Let me just add: holy matrices, Batman! Pointwise operations in Matlab are faster in loop style than in vector style. There's bound to be more Matlab code that won't work in Octave, not because of language incompatibility, but because of huge performance differences. For instance, my loop-style implementation of the Game of Life is faster than my matrix-style implementation.

Sebastien Loisel

On 9/27/06, John W. Eaton <address@hidden> wrote:
On 27-Sep-2006, David Bateman wrote:

| I see this as a pity as I feel there are two things needed for wide
| acceptance of octave; these being a good windows installer (ie an exe
| and one that doesn't suffer from the cygwin sjlj exception issue), and
| graphic handles. I'd like to eventually see classes but think that can wait.

I would also like to have improved graphics, but I should also say
that I'm not expecting 3.0 to have everything or be perfect.  But I
think the current 2.9.x is much better than 2.1.73, so it would be
good to have a real release relatively soon.

Or, we could just declare 2.9.x as a "testing" version and continue on
with snapshots until we have integrated all the features we want.

If others think that my timing for this release is bad, then I'd be
willing to consider having someone else take over the job of "release
manager" for Octave.  That person would then have the job of keeping
things more or less on schedule, deciding what projects are merged for
which releases, merging bug fixes into released versions while
development continues on the main branch, when to have feature freezes
and make release branches in the CVS archive, etc.  We could follow
the model of the GCC project (or some other, as long as it works).

jwe


reply via email to

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