View source for JWE Project Ideas

<!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas -->

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.

* [<span style="color:DarkGreen">Done</span>] 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.
* [<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).
* 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.

== [<span style="color:DarkGreen">Done</span>] 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 [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.

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