JWE Project Ideas: Difference between revisions

From Octave
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
* Improve interface for communication between GUI and interpreter
=== Improve interface for communication between GUI and interpreter ===


Currently, communication between the GUI and the interpreter
Currently, communication between the GUI and the interpreter
Line 8: Line 8:
would be more flexible and reliable.
would be more flexible and reliable.


* GUI command window
=== GUI command window ===


The implementation of the GUI command window for Unix-like systems
The implementation of the GUI command window for Unix-like systems
Line 18: Line 18:
could be improved.
could be improved.


* Interrupt handling in the GUI
=== Interrupt handling in the GUI ===


This issue is related to the GUI command window.  Interrupt
This issue is related to the GUI command window.  Interrupt
Line 27: Line 27:
find a way to reliably interrupt the interpreter.
find a way to reliably interrupt the interpreter.


* Generating publication-quality figures
=== Generating publication-quality figures ===


Generating EPS or PDF versions of figures needs improvement.
Generating EPS or PDF versions of figures needs improvement.


* OpenGL graphics system issues
=== 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 program framework)
* Scaling plot data values/ranges to fit in single-precision OpenGL values
** Resolve remaining Matlab compatibility issues.
* Performance issues
** Make it possible to load and save classdef objects.
* Lack of WYSIWYG
** Improve and simplify the implementation.  Although the basic
* 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
   features that are implemented now appear to mostly work, the
   implementation seems overly complicated, making it difficult to
   implementation seems overly complicated, making it difficult to
Line 50: Line 52:
   improvement here.
   improvement here.


* String class
=== String class ===


** Matlab now uses "" to create string objects that behave
* Matlab now uses "" to create string objects that behave
differently from Octave double-quoted strings.
  differently from Octave double-quoted strings.


* Handle UTF-8 (or whatever) characters properly
=== Handle UTF-8 (or whatever) characters properly ===


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


* Handle single and integer values for ranges
=== Handle single and integer values for ranges ===


* Local functions
=== Local functions ===


The semantics for local functions in scripts is different from the
The semantics for local functions in scripts is different from the
Line 67: Line 69:
files.
files.


* Allow large files to be loaded and saved
=== Allow large files to be loaded and saved ===


Make the load and save commands compatible with Matlab's
Make the load and save commands compatible with Matlab's
Line 73: Line 75:
something like this to support large arrays anyway.
something like this to support large arrays anyway.


* Matlab packages (+DIR directories in the loadpath; relate classdef)
=== Matlab packages (+DIR directories in the loadpath; related to classdef) ===


Octave already searches for files in package directories and
Octave already searches for files in package directories and
Line 80: Line 82:
it efficiently and in a way that is compatible with Matlab.
it efficiently and in a way that is compatible with Matlab.


* Toolboxes
=== Toolboxes ===


Move some core toolboxes (communications, control systems, image
Move some core toolboxes (communications, control systems, image
Line 90: Line 92:
equations package have already been moved to Octave.
equations package have already been moved to Octave.


* General code quality improvements
=== General code quality improvements ===
** Use C++11 features where possible.
 
** Better and more complete use of C++ namespaces.
* Use C++11 features where possible.
** Better use of C++ features.  Especially standard library features
* Better and more complete use of C++ namespaces.
as their implementation becomes more widely available.  For
* Better use of C++ features.  Especially standard library features
example, we might be able to simplify some things in Octave by
  as their implementation becomes more widely available.  For
using the C++17 filesystem and special functions libraries, if
  example, we might be able to simplify some things in Octave by
they provide results that are at least as good what we are using
  using the C++17 filesystem and special functions libraries, if
now.
  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 ===


* GUI code editor
=== GUI code editor ===


Make it possible to use external editors such as Emacs, vim, or
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
others with the GUI in addition to Octave's built-in code editor


* Documentation
=== Documentation ===
** Continue to improve Doxygen documentation for Octave internals to
 
make it easier for new contributors to understand the Octave code
* Continue to improve Doxygen documentation for Octave internals to
base.
  make it easier for new contributors to understand the Octave code
  base.


* JIT compiler
=== JIT compiler ===


A proof-of-concept implementation was done several years ago by a
A proof-of-concept implementation was done several years ago by a
Line 124: Line 128:
and Octave internals.
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

Revision as of 15:23, 12 March 2018

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