JWE Project Ideas: Difference between revisions

From Octave
Jump to navigation Jump to search
No edit summary
 
(29 intermediate revisions by the same user not shown)
Line 1: Line 1:
== GUI ==
<!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas -->


=== Improve interface for communication between GUI and interpreter ===
The following are projects that I would like to work on, roughly prioritized by my level of interest.  I intend to provide expanded explanations for each of these items.


Currently, communication between the GUI and the interpreter
== Comment parsing ==
mostly happens when the interpreter is otherwise idle and waiting
for user input at the command prompt and the implementation is
somewhat complicated.  We need to determine whether this is the
best we can do, or if there is some other implementation that
would be more flexible and reliable.


=== [[GUI terminal widget|GUI command window]] ===
Refactor comment handling in lexer and parser.


The implementation of the GUI command window for Unix-like systems
* [<span style="color:DarkGreen">Done</span>] Gather and attach all comments to tokens in the lexer, never in the parserThis change will allow us to simplify the grammar by eliminating the stash_comment nonterminal symbol in the parser.
is a completely separate implementations from the one used on
* [<span style="color:DarkOrange">In Progress - still need to handle some separator tokens</span>] Store tokens (with location info and comments attached) in the parse tree instead of imprecise data like "leading_comment" or "trailing_comment".  This change will allow better location info for error reporting and easier and more accurate access to comments so that we can more easily find documentation strings or test and demo blocks (some of that work is already done).
Windows systemsThere should be only one, and the GUI should be
* Recognize and tag comments that look like test or demo blocks.  Skip those when looking for doc strings.
completely in charge of user input and output.  This will probably
* Update the parse tree classes to provide access to the new information stored in them.
require implementing some kind of simple output pager internally
* Update the tree_print_code class to use the new info to provide better output.  Allow comments to be omitted from the output.
instead of using an external program, but overall user interaction
* Combine and simplify start_function, finish_function, and recover_from_parsing_function functions in the parser into a single make_function function. (This job is somewhat separate from the comment handling changes but now seems like a good time to do it.)
could be improved.
* Modify Octave's demo function to find demo comment blocks that are associated with classdef methods.


=== GUI code editor ===
== [<span style="color:DarkGreen">Done</span>] Location info in the parse tree ==


Make it possible to use external editors such as Emacs, vim, or
Once all tokens are stored in the parse tree, we can eliminate the separate storage of line and column info and eliminate two arguments from nearly every tree_* class constructor.  Any location info that is needed later for error messages, debugging, or code generation can be obtained from individual tokens.
others with the GUI in addition to Octave's built-in code editor


== Graphics ==
== MException object ==


=== Generating publication-quality figures ===
* Provide a mostly Matlab-compatible `MException` object.
* Make the `MException` constructor a built-in function (this job may require some changes to the classdef implementation).
* Fix the Octave interpreter to create an `MException` object when it throws an error and make that object available in `catch` blocks.


Generating EPS or PDF versions of figures needs improvement.
== FTLK graphics widget ==


=== OpenGL graphics system issues ===
Eliminate fltk graphics widget or move to external package.


* Scaling plot data values/ranges to fit in single-precision OpenGL values
== gnuplot graphics widget ==
* Performance issues
* Lack of WYSIWYG
* Duplication of effort with FLTK and Qt widgets.  With the rest of
* With the GUI using Qt widgets, we should eliminate the FLTK plotting widget.  It duplicates functionality and requires additional effort to maintain.  Maybe we no longer need the octave-cli binary (the one that is not linked with Qt libraries)?


=== Threading Issues for Qt Graphics Toolkit ===
Eliminate gnuplot graphics widget or move to external package.


It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
== Function objects ==


=== Use classdef for Graphics Objects ===
Refactor function objects.


This is a large project, but one that will likely have to be tackled at some point.
== arguments blocks ==


== Language ==
Finish implementation of Matlab-compatible argument validation blocks.


=== Improvements to classdef (the Matlab object-oriented programming framework) ===
== local functions ==


* Resolve remaining Matlab compatibility issues.
Implement Matlab-compatible local functions in script files.
* Make it possible to load and save classdef objects.
* Improve and simplify the implementation.  Although the basic features that are implemented now appear to mostly work, the implementation seems overly complicated, making it difficult to debug and modify.  There seems to be quite a bit of room for improvement here.


=== String class ===
== string object ==


Matlab now uses "" to create string objects that behave differently from Octave double-quoted strings.  We could start by creating a compatible string class, then hooking it up to the "" syntax.  No matter what, the transition will be difficult because Matlab's "" strings still treat "\n" as two characters (backslash and n) rather than a single character (newline).
== load_path class ==


=== Handle UTF-8 (or whatever) characters properly ===
Refactor (or rewrite) load_path class.


Try to do this in a Matlab-compatible way.
== Broadcasting ==


=== Handle single and integer values for ranges ===
* Refactor broadcasting.
* Make broadcasting work for sparse matrices.


This is a compatibility issue.
== GUI command widget ==


=== Eliminate Special Range, Diagonal Matrix, and Permutation Matrix Data Types
Make common command widget for Windows and Unixy systems work well enough to become the default command line interface for the GUI.


Although these data types in Octave require less memory than storing full matrices, they tend to cause trouble when people expect full compatibility or exactly the same results when performing arithmetic on Ranges vs. Matrices.  Now that we have broadcasting operators, the need for diagonal matrices is not as great.
== OpenGL graphics ==


=== Use Special Case Instead of Range for FOR loops ===
* Modernize our use of OpenGL graphics to use shader programs instead of the legacy OpenGL API.
* Scaling plot data values/ranges to fit in single-precision OpenGL values


Currently, "for i = 1:N ..." uses a Range object for the "1:N" loop bounds.  If we eliminate Ranges as a special space-saving type, then we should handle this syntax as a special case.  Even if we don't eliminate Ranges, that might be a good idea, as we could handle "for i = 1:Inf ..." easily without having to worry about how to deal with that in an ordinary Range object vs. FOR loop bounds.
== classdef ==


=== Local functions ===
Refactor (or rewrite) classdef implementation.


The semantics for local functions in scripts is different from the
== Qt graphics widget ==
way Octave currently handles functions that are defined in script
files.


=== Allow large files to be loaded and saved ===
Refactor (or rewrite) Qt graphics widget.


* Make the load and save commands compatible with Matlab's HDF5-based file format.  Matlab users expect this and we need something like this to support large arrays anyway.
== graphics properties ==
* Phase out Octave's own text and binary formats.  Too much effort is required to maintain the code to support all the various formats.


=== Matlab packages (+DIR directories in the loadpath; related to classdef) ===
Refactor graphics properties classes.


Octave already searches for files in package directories and
== graphics threading issues ==
understands the PKG.fcn syntax and functionality.  The big missing
piece is implementation of the "import" functionality and handling
it efficiently and in a way that is compatible with Matlab.


=== Broadcasting for Sparse Matrices ===
Fix handling of graphics properties to be properly thread safe.


This seems like a big missing feature.
== HDF5 load and save ==


=== Refactor Broadcasting ===
Implement Matlab compatible HDF5-based load and save functions.


Are there better ways to use templates to handle function calls rather than using macros to define a set of functions for array/array, array/scalar, and scalar/array ops as in DEFMXBINOP in mx-inlines.cc?
* Make the load and save commands compatible with Matlab's HDF5-based file format.  Matlab users expect this and we need something like this to support large arrays anyway.  As much as possible, the initial implementation should be written in Octave's scripting language and the proposed Low-level interface to HDF5 functions so that it can easily be updated and patched as needed while we are still working out the details.  Only later should we consider translating performance-critical parts to C++, and then, only if really necessary.
 
* Phase out Octave's own text and binary formats.  Too much effort is required to maintain the code to support all the various formats.
=== Compatibility of .^ for Sparse Matrices ===
* Low-level interface to HDF5 functionsCreate a thin wrapper for the HDF5 library.  As much as possible, make it compatible with the [https://www.mathworks.com/help/matlab/low-level-functions.html Matlab interface to HDF5]. However, we may support newer functions (as of 2020/10/30, the list of Matlab functions appears to correspond to an older version of the library than is presently available in the HDF5 library itself) and support for legacy functions has a low priority.
 
Octave currently skips structural zeros for most (all?) sparse matrix operationsMatlab returns a sparse matrix filled with NaNs for something like "sprand (5, 5, 0.1) .^ NaN".
 
=== etree for Sparse Logical ===
 
Matlab's etree function appears to handle sparse logical arrays.
 
=== Type Conversion for Indexed Sparse Assignment ===
 
In an assignment like Sparse_object(idx) = GrB_object(idx), Octave does not attempt to apply a conversion operator to transform the RHS type to the LHS type.  Is this also a problem for assignments of objects with conversion operators to full matrix objects?
 
=== 5th and 6th Outputs for dmperm ===
 
Octave doesn't support those.
 
=== graph and digraph Functions ===
 
Would it be difficult to provide these?
 
=== RandStream and Other RNG issues ===


This is likely a large project, but it would be nice to have updated, compatible interfaces.
== External editors ==


== Miscellaneous ==
Make it possible to use external editors such as Emacs, vim, or others with the GUI in addition to Octave's built-in code editor.


=== MEX Interface Changes ===
== who -file ==


Implement mxMakeReal and mxMakeComplex functions.
Fix who -file to just read file and list info, not create dummy scope.


=== Toolboxes ===
== import ==


Move some core toolboxes (communications, control systems, image
Make "import" work in a matlab-compatible way ==
processing, optimization, signal processing, and statistics), to
core Octave so development is managed along with Octave.  Core
Octave developers are already responsible for these packages
anyway, and users don't seem to understand why they need to
install them separately.  Core parts of the ordinary differential
equations package have already been moved to Octave.


=== General code quality improvements ===
== Code quality ==


* Use C++11 features where possible.
* Better and more complete use of C++ namespaces.
* Better and more complete use of C++ namespaces.
* Better use of C++ features. Especially standard library features as their implementation becomes more widely available. For example, we might be able to simplify some things in Octave by using the C++17 filesystem and special functions libraries, if they provide results that are at least as good what we are using now.
* Better use of C++ features. Especially standard library features as their implementation becomes more widely available. For example, we might be able to simplify some things in Octave by using the C++17 filesystem and special functions libraries, if they provide results that are at least as good what we are using now.
* Eliminate C preprocessor macros where possible
* Eliminate C preprocessor macros where possible.
 
* Use const in more parse tree functions.
=== Documentation ===
* remove, replace, or at least rename the "added static" concept in the symbol_record class.
 
* Should not expose symbol_record in call_stack functions if possible.
* Continue to improve Doxygen documentation for Octave internals to make it easier for new contributors to understand the Octave code base.
* Remove unused symbol_table/scope/record functions.
 
* Do recursive functions work properly with load/save now?
=== JIT compiler ===
* Use enums for options internally (typically to replace bool values).
 
* Audit global variables and eliminate them where possible.
A proof-of-concept implementation was done several years ago by a
* Audit use of panic_* functions and replace with calls to error where possible.
Google Summer of Code student. It was never complete and little
* Fix symbol visibility so we are mostly tagging namespace decls, not individual functions.
work has been done since. It also depends on an old version of
* Complete use of dispatch types for functions (search for "classes:" to find the few current examples).
LLVM. In addition to LLVM, we should consider the JIT library
* Tag for built-in functions to specify maxiumum number of inputs.
features of GCC.
 
This is probably the most difficult item (at least for me) since it
will require fairly advanced knowledge of compiler infrastructure
and Octave internals.


=== Windows distribution ===
== Windows distribution ==


Eliminate the following msys packages.  Some might be removed
Eliminate the following msys packages.  Some might be removed
Line 176: Line 130:
but the msys version of less depends on the msys termcap library.
but the msys version of less depends on the msys termcap library.


  bash       less       perl
* bash
  coreutils  libcrypt   regex
* coreutils
  diffutils  libiconv   sed
* diffutils
  dos2unix  libintl     tar
* dos2unix
  file      libmagic   termcap
* file
  findutils  libopenssl unzip
* findutils
  gawk      make       zip
* gawk
  grep      msys-core   wget
* grep
  gzip      patch      zlib
* gzip
* less
* libcrypt
* libiconv
* libintl
* libmagic
* libopenssl
* make
* msys-core
* patch
* perl
* regex
* sed
* tar
* termcap
* unzip
* wget
* zip
* zlib

Latest revision as of 05:12, 4 April 2024


The following are projects that I would like to work on, roughly prioritized by my level of interest. I intend to provide expanded explanations for each of these items.

Comment parsing

Refactor comment handling in lexer and parser.

  • [Done] Gather and attach all comments to tokens in the lexer, never in the parser. This change will allow us to simplify the grammar by eliminating the stash_comment nonterminal symbol in the parser.
  • [In Progress - still need to handle some separator tokens] Store tokens (with location info and comments attached) in the parse tree instead of imprecise data like "leading_comment" or "trailing_comment". This change will allow better location info for error reporting and easier and more accurate access to comments so that we can more easily find documentation strings or test and demo blocks (some of that work is already done).
  • Recognize and tag comments that look like test or demo blocks. Skip those when looking for doc strings.
  • Update the parse tree classes to provide access to the new information stored in them.
  • Update the tree_print_code class to use the new info to provide better output. Allow comments to be omitted from the output.
  • Combine and simplify start_function, finish_function, and recover_from_parsing_function functions in the parser into a single make_function function. (This job is somewhat separate from the comment handling changes but now seems like a good time to do it.)
  • Modify Octave's demo function to find demo comment blocks that are associated with classdef methods.

[Done] Location info in the parse tree

Once all tokens are stored in the parse tree, we can eliminate the separate storage of line and column info and eliminate two arguments from nearly every tree_* class constructor. Any location info that is needed later for error messages, debugging, or code generation can be obtained from individual tokens.

MException object

  • Provide a mostly Matlab-compatible `MException` object.
  • Make the `MException` constructor a built-in function (this job may require some changes to the classdef implementation).
  • Fix the Octave interpreter to create an `MException` object when it throws an error and make that object available in `catch` blocks.

FTLK graphics widget

Eliminate fltk graphics widget or move to external package.

gnuplot graphics widget

Eliminate gnuplot graphics widget or move to external package.

Function objects

Refactor function objects.

arguments blocks

Finish implementation of Matlab-compatible argument validation blocks.

local functions

Implement Matlab-compatible local functions in script files.

string object

load_path class

Refactor (or rewrite) load_path class.

Broadcasting

  • Refactor broadcasting.
  • Make broadcasting work for sparse matrices.

GUI command widget

Make common command widget for Windows and Unixy systems work well enough to become the default command line interface for the GUI.

OpenGL graphics

  • Modernize our use of OpenGL graphics to use shader programs instead of the legacy OpenGL API.
  • Scaling plot data values/ranges to fit in single-precision OpenGL values

classdef

Refactor (or rewrite) classdef implementation.

Qt graphics widget

Refactor (or rewrite) Qt graphics widget.

graphics properties

Refactor graphics properties classes.

graphics threading issues

Fix handling of graphics properties to be properly thread safe.

HDF5 load and save

Implement Matlab compatible HDF5-based load and save functions.

  • Make the load and save commands compatible with Matlab's HDF5-based file format. Matlab users expect this and we need something like this to support large arrays anyway. As much as possible, the initial implementation should be written in Octave's scripting language and the proposed Low-level interface to HDF5 functions so that it can easily be updated and patched as needed while we are still working out the details. Only later should we consider translating performance-critical parts to C++, and then, only if really necessary.
  • Phase out Octave's own text and binary formats. Too much effort is required to maintain the code to support all the various formats.
  • Low-level interface to HDF5 functions. Create a thin wrapper for the HDF5 library. As much as possible, make it compatible with the Matlab interface to HDF5. However, we may support newer functions (as of 2020/10/30, the list of Matlab functions appears to correspond to an older version of the library than is presently available in the HDF5 library itself) and support for legacy functions has a low priority.

External editors

Make it possible to use external editors such as Emacs, vim, or others with the GUI in addition to Octave's built-in code editor.

who -file

Fix who -file to just read file and list info, not create dummy scope.

import

Make "import" work in a matlab-compatible way ==

Code quality

  • Better and more complete use of C++ namespaces.
  • Better use of C++ features. Especially standard library features as their implementation becomes more widely available. For example, we might be able to simplify some things in Octave by using the C++17 filesystem and special functions libraries, if they provide results that are at least as good what we are using now.
  • Eliminate C preprocessor macros where possible.
  • Use const in more parse tree functions.
  • remove, replace, or at least rename the "added static" concept in the symbol_record class.
  • Should not expose symbol_record in call_stack functions if possible.
  • Remove unused symbol_table/scope/record functions.
  • Do recursive functions work properly with load/save now?
  • Use enums for options internally (typically to replace bool values).
  • Audit global variables and eliminate them where possible.
  • Audit use of panic_* functions and replace with calls to error where possible.
  • Fix symbol visibility so we are mostly tagging namespace decls, not individual functions.
  • Complete use of dispatch types for functions (search for "classes:" to find the few current examples).
  • Tag for built-in functions to specify maxiumum number of inputs.

Windows distribution

Eliminate the following msys packages. Some might be removed entirely if they are unnecessary for running Octave or building Octave Forge packages. Otherwise, we should be building them from source as we do all other tools and libraries that are distributed with Octave. The difficulty is that although the msys packges are typically based on old versions of these packages, they sometimes have fixes that are needed to allow them to run properly on Windows systems. Note also that we distribute a termcap library, but the msys version of less depends on the msys termcap library.

  • bash
  • coreutils
  • diffutils
  • dos2unix
  • file
  • findutils
  • gawk
  • grep
  • gzip
  • less
  • libcrypt
  • libiconv
  • libintl
  • libmagic
  • libopenssl
  • make
  • msys-core
  • patch
  • perl
  • regex
  • sed
  • tar
  • termcap
  • unzip
  • wget
  • zip
  • zlib