new snapshot?

John W. Eaton jwe at octave.org
Fri Feb 6 12:48:25 CST 2009


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


More information about the Octave-maintainers mailing list