Re: goals for 3.1

[Shai Ayal]

On Dec 20, 2007 8:31 PM, John W. Eaton <address@hidden> wrote:
> OK, after seeing the various comments in this thread, I've revised my
> list of goals for 3.1 and given each item a tentative priority rank
> (see below).
>
> Most of the first five items are fairly straightforward and I think
> should be done right after the 3.0 release.  Getting
> superiorto/inferriorto and some other OO features implemented
> "correctly" (i.e., in a compatible way) may turn out to be
> non-trivial, but merging the branch should at least be fairly quick.
>
> I've cut off the list at 11 because I think we need to have a
> manageable list so we can make the 3.1 release in 6-9 months rather
> than 6-9 years.  Other items are welcome of course, but I don't think
> we should allow a long wish list delay the next release for a long
> time.
>
>    1. Objects:
>         -- Merge object-branch
>         -- Implementation of superiorto/inferiorto
>         -- Operator overloading vs. constant folding
>
>    2. Handle block comments
>
>    3. Eliminate __gnuplot_X__ functions from Octave
>
>    4. Move code to external packages
>         -- control
>         -- finance
>         -- optimization?
>         -- signal?
>         -- statistics?
>         -- quaternions
>
>    5. Move imread/imwrite functions from Octave Forge to Octave.
>
>    6. Improve traceback error messages.  The messages should list the
>       exact line where an error occurred, then only print function
>       traceback info and not information about which
>       if/for/while/etc. statement includes the error.  That extra
>       information just seems to confuse users, and the current
>       messages don't always clearly describe the actual location of
>       the error.
>
>    7. Ensure that all operations which work on dimensions alone
>       (squeeze, numel, triu, etc.) work for all objects and preserve
>       type.  Should these functions all be built-in?  Possibly they
>       should all be provided by the octave_value class interface.
>
>    8. Make mapper functions work like other built-in functions?
>
>    9. Mapper functions like real, imag, and mod should preserve type
>       (are there others?)
>
>   10. Improve compatibility of fsolve
>         -- input/output args should be compatible
>         -- use optimset for options
>
>   11. Graphics:
>         -- 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

I would like to add some detail as to the feasibility of this last point:
I think writing the actual drawing code will be relatively easy and
can easily be accomplished even by me alone in the 6 month time-frame
(and I'm sure I'll have help). However today the gnuplot backend does
a lot more then drawing -- The first thing that comes to mind is
determining tick marks, but I'm sure that other things will pop-up.
For each of these things design decisions would have to be taken -- is
it the backend's responsibility or octave's responsibility. This might
slow things up a bit (a discussion on the mailing list is always
slower than frantic coding by a single person). All that being said I
still think that a 6-9 month milestone is reasonable for this point

Shai
> ----------
>
>   12. Implement nested functions
>
>   13. Eliminate explicit dispatch on type in various functions (for
>       example, the NATIVE_REDUCTION macro in data.cc, the if/else mess
>       in sort, or any other similar constructs) in favor of dispatch
>       via virtual functions in the octave_value class.
>
>   14. Write tree-walker evaluator class that can be used for profiling
>       and debugging evaluators, and maybe also as the basis for an
>       m-file to oct-file compiler
>
>   15. BLAS/LAPACK:
>         -- Stop distributing Fortran sources?  If we do this, should
>            we make it possible to compile Octave without any
>            BLAS/LAPACK library, or should BLAS/LAPACK be required?
>         -- Use cblas interface?
>
>   16. 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).
>
>
>
>
> Comments or suggestions?
>
> Thanks,
>
> jwe
>
>
>