octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

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