Re: after 3.2

[Jaroslav Hajek]

On Thu, Mar 12, 2009 at 8:55 PM, John W. Eaton <address@hidden> wrote:
> Here's a list of possible projects for after 3.2.
>
> I've tagged completed items with an "X" and items for which some work
> has been done with an "+".
>
>  * Namespace(s) for Octave sources.

Should this include renaming the classes? IIRC you agreed that using
CamelCasing for Array & Stuff is unfortunate.

I add:

* Simplify array class inheritance tree. Probably to something like
Array (indexing, sorting) --> MArray (type-generic elem-by-elem ops,
reductions) --> *NDArray (type-specific ops, fft & such stuff) -->
*Matrix (multiplication, solving, etc) --> *RowVector, *ColumnVector
That should quite simplify writing templatized code using the array
classes and should also remove a lot of code duplication.

>  * Objects:
>      - Operator overloading vs. constant folding

I think overloading built-in operators is quite useless. Constant
folding is much better.

>      - Overloading built-in classes (double, etc.)
>
>  * Profiler.
>
>  * Nested functions.
>
>  * Graphics:
>      + Fonts and text objects
>      + Refactor base_properties
>      + Specific types for properties with improved property value
>        checking
>      + Implement the addprops function allow additional properties
>        to objects
>      + add the hggroup object that has no fixed properties for use
>        by barseries, etc.
>      + Add callback DeleteFcn/CreateFcn to objects
>      + Allow listener functions to be added to objects
>      + Clean separation of backend from property database
>      + Implement experimental backend based on OpenGL and GUI
>        toolkit
>
>  * Avoid segfault problem when clearing dynamically linked functions
>    that create user-defined types.
>
>  * Move code to external packages
>      - optimization?



>      - signal?
>      - statistics?
>
>  * Handle block comments inside [] or {} and also in the group of
>    comments following a continuation character, etc.  See the FIXME
>    comments in lex.l.
>
>  + Mixed sparse x diagonal matrix operations (may be included in 3.2).

will be

>  * Use templates instead of macros where possible.

Agreed. Maybe we can also optionally (based on configure check)
attempt to use some more advanced commonly supported features.
Restrict pointers are an example.

>
>  * Update the configure script and make checks for header files and
>    libraries more consistent (maybe we could recruit an autoconf
>    expert to help with this job).
>
>  * Rewrite Makefiles to avoid recursive make (see
>    http://miller.emu.id.au/pmiller/books/rmch/ for some ideas).
>
> For me, the first six items above have a fairly high priority.
> Especially graphics and the profiler.
>
> If you have comments, suggestions, or additions, please send them to
> me or to the list for discussion, and I'll update the list and
> repost.
>
> At this point, it can be something of a wish list, but the items
> should be things that we have some chance of implementing before the
> next release (after 3.2).  By the time we make the 3.2 release, we
> should have this list narrowed down to maybe the top 10 items as
> prioity projects.
> I'd still like to see us reduce the interval
> between stable releases to something like 6-9 months, so I think doing
> that will require focusing on a smaller list of projects for each
> release, then making the release and moving on instead of allowing the
> list of projects to continually expand (this is something I need to
> work on as much as anyone else).
>
> jwe
>

After 6 months of being a stable branch release manager, I can now
summarize my feelings:
It was fairly obvious that as time passed,  the development and stable
codebases started to
divert significantly, and patches ceased to apply smoothly, it was
often hard or impossible to transplant them and 3.0.x-specific patches
were necessary.
This is probably not avoidable, but the effect was pretty magnified by
the fact that there was a single person (me) responsible for
transplanting the patches, and that person didn't understand every
part of Octave enough to be always sure what needs to be transplanted.
I especially mean the graphics patches. Now add my 3 weeks off in that
time.
Right now, 3.0.x is suspended because of some show-stopping graphics
bugs and unless someone supplies a patch for those, 3.0.4 will never
exist.

I think it will be better if more people are able to transplant
patches to the stable series, because often you can simultaneously
apply a fix to both development and stable series. Unless Savannah
allows a project to have more than one repo, the easiest way I see is
to again introduce branches within the main repo.

comments?

cheers



-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz