JWE Project Ideas: Difference between revisions

From Octave
Jump to navigation Jump to search
No edit summary
Line 101: Line 101:
** Complete use of dispatch types for functions (search for "classes:" to find the few current examples).
** 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.
** Tag for built-in functions to specify maxiumum number of inputs.
== GUI ==
=== Communication with interpreter ===
Currently, communication between the GUI and the interpreter
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]] ===
The implementation of the GUI command window for Unix-like systems
is a completely separate implementations from the one used on
Windows systems.  There should be only one, and the GUI should be
completely in charge of user input and output.  This will probably
require implementing some kind of simple output pager internally
instead of using an external program, but overall user interaction
could be improved.
=== GUI code editor ===
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
== Graphics ==
=== Publication-quality figures ===
Generating EPS or PDF versions of figures needs improvement.
=== OpenGL graphics ===
* Scaling plot data values/ranges to fit in single-precision OpenGL values
* Performance issues
* Lack of WYSIWYG
=== FLTK widget ===
With the rest of 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)?
=== Qt toolkit threading ===
It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
=== classdef graphics objects ===
This is a large project, but one that will likely have to be tackled at some point.
== Miscellaneous ==
=== Handle UTF-8 ===
We need to handle UTF-8 (or whatever) characters properly in all parts of Octave.  Try to do this in a Matlab-compatible way.
=== Load / Save ===
* 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.
Also as of 2020/10/30, [[User:jwe|jwe]] is working on this project.  Help is welcome!
=== RNG issues ===
RandStream and Other RNG issues
This is likely a large project, but it would be nice to have updated, compatible interfaces.
=== MEX Interface ===
Implement mxMakeReal and mxMakeComplex functions.
=== JIT compiler ===
A proof-of-concept implementation was done several years ago by a
Google Summer of Code student.  It was never complete and little
work has been done since.  It also depends on an old version of
LLVM.  In addition to LLVM, we should consider the JIT library
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.
=== loadlibrary ===
This feature might be nice to have but it has a low priority.
=== Complex integers ===
Should we support this feature?  Should we refactor the implementation of array objects to make this job easier?
=== who -file option ===
Should just read file and list info, not create dummy scope.  Likewise for whos function.
== Maintenance and packaging ==
=== General code quality ===
* Use C++11 features where possible.
* 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
* added_static must go! (not sure about this now)
* Should not expose symbol_record in call_stack functions if possible
* Remove unused symbol_table/scope/record functions
* Use const in more parse tree 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
=== Symbol visibility ===
We really should be tagging the functions that we wish to export from shared libraries.
=== Dispatch types for functions ===
Search for "classes:" in sources to find the few current examples.
=== min/max nargin values ===
Should we do this, and allow the interpreter to automatically error when a function is given too few/many arguments?
=== Toolboxes ===
Move some core toolboxes (communications, control systems, image
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.
=== Documentation ===
* Docs for call stack with examples and illustrations
* Docs for lexer and parser with examples and illustrations
* Docs for fcn_info object
* Docs for load_path object
* Docs for classdef internals
* Docs for Qt graphics toolkit internals
* Docs for Qt GUI and communication with interpreter
* Improve other Doxygen docs for internals to make it easier for new contributors to understand the Octave code base.
=== 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

Revision as of 17:46, 27 March 2024


2021-11-19: This page is out of date -- jwe

Project Ideas

The following are projects that I'm interested in working on, roughly prioritized by my level of interest. I intend to provide expanded explanations of each project.

Comment parsing

Refactor comment handling in lexer and parser.

MException object

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

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.

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.