[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Release goals for 3.6
From: |
John W. Eaton |
Subject: |
Release goals for 3.6 |
Date: |
Tue, 2 Aug 2011 12:50:24 -0400 |
On 2-Aug-2011, Jordi GutiƩrrez Hermoso wrote:
| This means that if we keep with this plan, we have one more month
| before we hit a feature freeze?
I would be mostly OK with that.
| > Next, I have a few projects that I would personally like to work on
| > (these might not all happen for 3.6, but they are things I'm
| > currently most interested in):
| >
| > * Improve textscan. I promised Ben Abbott that I would look at what
| > is needed to handle the textscan-specific format specifiers. I
| > started doing that, but never finished the job.
|
| This seems to be well underway.
But I think the changes I had in mind have not been made. I was
planning to write something similar to the *scanf function that would
handle the format specifiers used by textscan. The last time I looked
at this, it did not seem possible to map all of the formats used by
textscan to scanf.
| > * Look at whether octave idx type should be an unsigned type. See
| >
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-February/022980.html
| > for some motivation for a change like this.
|
| I haven't seen any work on this. Has there been any?
No, and I don't think it is urgent.
| > * Fix lsode, dassl, daspk, etc. to accept an options structure as
| > an argument instead of using a global option structure (losde
| > options, dassl options, etc.). If possible, this should be done
| > in a way that allows a smooth transition, so that code using the
| > options functions can be deprecated but will continue to work for
| > at least one release cycle.
|
| Same here, no work yet?
Right.
| > * Make the current FLTK+OpenGL plotting system work better so that
| > we can make it the default. For this to happen, there are a lot
| > of little bugs that need to be fixed, plus we need to make
| > printing reliable. If possible, we need to make printing work
| > even when a plot is not displayed on the screen.
|
| This one is a big release goal. Do we have a specific set of bugs that
| we should patch? We have several related to fltk in the bug tracker.
| Perhaps begin by prioritising those? This one looks like a very
| important user-visible change for 3.6.
I don't think we have had major changes, but we have had a number of
bug fixes.
| > * Integrate a GUI with the core Octave distribution. My preference
| > would be to start with OctaveDE since I think it is doing the
| > right thing by embedding Octave rather than communicating with
| > Octave using pipes. I'm willing to consider other alternatives,
| > but it is important to me that we have a way to interact with
| > Octave's command line without needing to completely reinvent
| > readline.
|
| Quint, or as Jacob Dawid has been calling it recently, simply "the
| Octave GUI", seems to be ready to at least be an experimental GUI for
| 3.6. It is doing readline and Jacob is doing a lot of work on it (plus
| he keeps recruiting more people to help). I'm going to try to
| integrate it with Octave's build system and push to Savannah on the
| default branch within a few weeks. We can spend time after September
| polishing it for release.
I haven't looked at it recently. I can help you with integration, but
I don't know that I have time to do the work myself, as I earlier
thought I would.
| > * Make a gtk+OpenGL graphics system. Or use wxWidgets, or
| > something (anything!) that looks better than FLTK (sorry, FLTK
| > fans).
|
| I don't think this is ready yet. Jacob expressed some interest in
| making this work with Qt, but I don't believe he's managed to
| understand how plotting works well enough to begin the Qt
| implementation.
I think all that is needed is to have the functional equivalent of the
__init_fltk__.cc file but that uses Qt instead. Similarly, we could
use something corresponding to __fltk_uigetfile__.cc.
| So, anyways, feature freeze in one month? Perhaps in two? Time to
| think about it?
I'd say a feature freeze in 2-3 months would be reasonable, regardless
of whether we have implemented many more of the above wish-list items.
We should be able to have a reasonably complete profiler for the 3.6
release, yes? That's a nice new feature for a release. Plus many bug
fixes, and I expect some improved Matlab compatibility.
jwe
- Re: Binary distributions (was: Re: Release goals for 3.6), (continued)
- Re: Binary distributions (was: Re: Release goals for 3.6), John W. Eaton, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), fork, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), PhilipNienhuis, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), fork, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), PhilipNienhuis, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), John W. Eaton, 2011/08/02
- Re: Binary distributions, Philip Nienhuis, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), Lukas Reichlin, 2011/08/02
- Re: Binary distributions (was: Re: Release goals for 3.6), fork, 2011/08/02
- Re: Binary distributions, Julien Salort, 2011/08/03
Release goals for 3.6,
John W. Eaton <=
Re: Release goals for 3.6, PhilipNienhuis, 2011/08/02
- strread.m (was: Re: Release goals for 3.6), John W. Eaton, 2011/08/02
- Re: strread.m, Philip Nienhuis, 2011/08/02
- Re: strread.m, John W. Eaton, 2011/08/02
- Re: strread.m, Philip Nienhuis, 2011/08/02
- Re: strread.m, John W. Eaton, 2011/08/02