[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.1 status report
From: |
John W. Eaton |
Subject: |
Re: 3.1 status report |
Date: |
Wed, 16 Jul 2008 16:03:51 -0400 |
On 16-Jul-2008, dbateman wrote:
| John W. Eaton wrote:
| >
| > Is anyone interested in helping to move the control, finance, and
| > quaternion functions into separate packages?
| >
|
| Sure I can take that one on. Is the goal to transfer these to octave-forge,
| or make them packages that just happen to be part of Octave itself? It would
| be easy to just transfer them to Octave as the machinery for packages is
| already in place there.
I think I'd rather have them as separate packages. Moving them to
Octave Forge would be fine with me, and it would be great if you could
do that.
| Though if we do this could we have a 3.0.2 release
| and then an octave-forge release
OK.
| and then we can convert octave-forge for a
| 3.1 release including
|
| * remove files like num2hex, imread, etc
| * 3.1 compatible mapper functions for user types
| *etc
|
| and at the same time move the packages fro Octave
Yes, that would be good.
| > Should we move the statistics, signal, and optimization functions to
| > separate packages?
| >
|
| I thought the consenus was if we do, we should be careful of what functions
| we move. Maybe we need to discuss all of the candidate functions to remove
| from Octave and the reasons to keep each of them in Octave itself.
I think we can delay this until later (maybe never).
| In any case the list looks a bit like a new feature list of the 3.2 NEWS
| file. In that case maybe the compound operators and single precision type
| should be mentioned as major new features. As for the single precision type
| there are 3 things still to do
Yes, we also need to update the NEWS file. In the future, I think we
should probably try to be more disciplined about adding NEWS entries
as changes are made (I'm definitely guilty of not adding entries for
the changes I make). Otherwise, creating the NEWS file for a release
is more difficult.
| + Treat conversion of NA values from single/double and R compatibility
| - Convert methods like extract_row from derived Array classes to Array<T>
| itself
| - single precision versions of fsolve, dasrt, etc
|
| I'll definitely address these before 3.2.0, but for now they can wait.
OK.
Thanks,
jwe