octave-maintainers
[Top][All Lists]
Advanced

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

Re: new snapshot?


From: Jaroslav Hajek
Subject: Re: new snapshot?
Date: Fri, 6 Feb 2009 21:40:15 +0100

On Fri, Feb 6, 2009 at 7:48 PM, John W. Eaton <address@hidden> wrote:
> 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?
>

Surely not all Fortran sources? Getting rid of BLAS & LAPACK would be
nice, especially as these two are commonly packaged, but it has one
important downside - Octave will no longer be compilable out-of-the
box with at least basic functionality.
Does anyone rely on this?

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

I don't see how this is easily doable. The thing is that in
multi-assignment, the list elements on LHS need to be counted to give
the rhs proper nargout if it's a function call. So, we would need an
element-counting code in any case.
I also considered putting off the evaluation of magic end; however,
given that it can be inside a relatively complex expression, I
realized that the current place is relatively appropriate.


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



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


reply via email to

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