JWE Project Ideas

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

• Interrupt handling in the GUI

 - This issue is related to the GUI command window.  Interrupt
   signals (typically generated by typing Control-C at the command
   prompt) cause some trouble with the GUI and when multiple threads
   are active, particularly inside of library code like the BLAS.
   There are a number of bug reports for this problem.  We need to
   find a way to reliably interrupt the interpreter.

• 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 the GUI using Qt widgets, we should eliminte the FLTK plotting
   widget.  To do that, we will need to make the Qt plotting widget
   work when Octave is started with --no-gui and ensure that all
   features in the FLTK widget are also present in the Qt widget.

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

• Handle UTF-8 (or whatever) characters properly

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

• Handle single and integer values for ranges

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

• Matlab packages (+DIR directories in the loadpath; related to classdef)

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

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

• 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

• 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