[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
- new snapshot?, John W. Eaton, 2009/02/06
- Re: new snapshot?, Jonathan Stickel, 2009/02/09
- Re: new snapshot?, John W. Eaton, 2009/02/09
- Re: new snapshot?, Jonathan Stickel, 2009/02/09
- Re: new snapshot?, Shai Ayal, 2009/02/09
- Re: FTGL dependency on Mac OS X (was: new snapshot?), Jonathan Stickel, 2009/02/09
- Re: FTGL dependency on Mac OS X (was: new snapshot?), Ben Abbott, 2009/02/09
- Re: FTGL dependency on Mac OS X, Thomas Treichl, 2009/02/09
- Re: FTGL dependency on Mac OS X, Ben Abbott, 2009/02/09
- Re: FTGL dependency on Mac OS X, Jonathan Stickel, 2009/02/09