octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

new snapshot?


From: John W. Eaton
Subject: new snapshot?
Date: Fri, 6 Feb 2009 13:48:25 -0500

I think I'm about as caught up on patches and bug reports as ever, so
now is probably a good time to start making snapshots again, and
seriously thinking about the 3.2 release.

Is anyone working on any major features that should go into 3.2?  If
not, then can we focus on stability for a few weeks?  Or is the only
way to make this acutally happen going to be making a separate
Mercurial archive for the 3.2 release?

Here is my latest list for 3.2:

  I've tagged completed items with an "X" and items for which some work
  has been done with an "+".

     +. Objects:
          X Merge object-branch
          X Implementation of superiorto/inferiorto
          - Operator overloading vs. constant folding

     +. Handle block comments.  This is not quite finished as block
        comments inside [] or {}, and also in the group of comments
        following a continuation character, etc., are not handled.  See
        the FIXME comments in lex.l.

     X. Eliminate __gnuplot_X__ functions from Octave

     +. Move code to external packages
          X control
          X finance
          - optimization?
          - signal?
          - statistics?
          X quaternions

     X. Move imread/imwrite functions from Octave Forge to Octave.

     X. 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.

     X. 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.

     X. Make mapper functions work like other built-in functions?

     X. Mapper functions like real, imag, and mod should preserve type
        (are there others?)

     X. Improve compatibility of fsolve
          X input/output args should be compatible
          X use optimset for options

     +. 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

  Other tasks that should be considered before the release:

    * Document the graphics changes made by Shai/Michael as needed.

    * Document the object oriented stuff in a new chapter.

    * Document the use of private directories.

    * Document other functions that were ported from octave-forge (eg
      imread, dlmwrite, etc)

    + Update the NEWS file.

  ----------

    12. Implement nested functions

    +?. 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.

     +. 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).

    +?. Rework subscripted assignment so that it simply uses subsasgn.
        Handle "end" index as a special octave_value (similar to the
        octave_magic_colon type) so that determining the object and
        index position values can be left to the subsasgn method.
        Disallow resizing in the octave_struct::subsref method.


  Remaining issues:

    * Generate doc cache and install it.

    * New diagonal matrix type can't be saved in HDF format.  No doubt
      some users will not be happy about this regression.

    * Reported bugs that have not been fixed.  I know there are some,
      but I don't know how to fix them.  Clearly, we need a bug tracker
      or these reports are far more likely to be dropped.  At this
      point, I think we should consider simply using the savannah
      tracker even if it is not ideal.  It will at least allow us to
      have a public archive of reports.  I could supply a list of bug
      reports that I know of which should be added to the bug tracker
      initially.

Comments?

jwe


reply via email to

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