JWE Project Ideas
GUI
Improve interface for communication between GUI and 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 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
Generating publication-quality figures
Generating EPS or PDF versions of figures needs improvement.
OpenGL graphics system issues
- Scaling plot data values/ranges to fit in single-precision OpenGL values
- 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
It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
Use classdef for Graphics Objects
This is a large project, but one that will likely have to be tackled at some point.
Language
Improvements to classdef (the Matlab object-oriented programming framework)
- Resolve remaining Matlab compatibility issues.
- 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
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).
Handle UTF-8 (or whatever) characters properly
Try to do this in a Matlab-compatible way.
Handle single and integer values for ranges
This is a compatibility issue.
=== Eliminate Special Range, Diagonal Matrix, and Permutation Matrix Data Types
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.
Use Special Case Instead of Range for FOR loops
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.
Local functions
The semantics for local functions in scripts is different from the way Octave currently handles functions that are defined in script files.
Allow large files to be loaded and saved
- 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.
- Phase out Octave's own text and binary formats. Too much effort is required to maintain the code to support all the various formats.
Octave already searches for files in package directories and 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
This seems like a big missing feature.
Refactor Broadcasting
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?
Compatibility of .^ for Sparse Matrices
Octave currently skips structural zeros for most (all?) sparse matrix operations. Matlab 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.
Miscellaneous
MEX Interface Changes
Implement mxMakeReal and mxMakeComplex functions.
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.
General code quality improvements
- 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
Documentation
- Continue to improve Doxygen documentation for Octave internals to make it easier for new contributors to understand the Octave code base.
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.
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 less perl coreutils libcrypt regex diffutils libiconv sed dos2unix libintl tar file libmagic termcap findutils libopenssl unzip gawk make zip grep msys-core wget gzip patch zlib