Difference between revisions of "JWE Project Ideas"

From Octave
Jump to navigation Jump to search
(Created page with "* Improve interface for communication between GUI and interpreter - Currently, communication between the GUI and the interpreter mostly happens when the interpreter is...")
 
m (→‎GUI command window: Add wiki link)
 
(6 intermediate revisions by one other user not shown)
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
    mostly happens when the interpreter is otherwise idle and waiting
+
mostly happens when the interpreter is otherwise idle and waiting
    for user input at the command prompt and the implementation is
+
for user input at the command prompt and the implementation is
    somewhat complicated.  We need to determine whether this is the
+
somewhat complicated.  We need to determine whether this is the
    best we can do, or if there is some other implementation that
+
best we can do, or if there is some other implementation that
    would be more flexible and reliable.
+
would be more flexible and reliable.
  
* GUI command window
+
=== [[GUI terminal widget|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
    is a completely separate implementations from the one used on
+
is a completely separate implementations from the one used on
    Windows systems.  There should be only one, and the GUI should be
+
Windows systems.  There should be only one, and the GUI should be
    completely in charge of user input and output.  This will probably
+
completely in charge of user input and output.  This will probably
    require implementing some kind of simple output pager internally
+
require implementing some kind of simple output pager internally
    instead of using an external program, but overall user interaction
+
instead of using an external program, but overall user interaction
    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
    signals (typically generated by typing Control-C at the command
+
signals (typically generated by typing Control-C at the command
    prompt) cause some trouble with the GUI and when multiple threads
+
prompt) cause some trouble with the GUI and when multiple threads
    are active, particularly inside of library code like the BLAS.
+
are active, particularly inside of library code like the BLAS.
    There are a number of bug reports for this problem.  We need to
+
There are a number of bug reports for this problem.  We need to
    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
+
* 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.
  
  - Performance issues
+
=== Improvements to classdef (the Matlab object-oriented programming framework) ===
  
  - Lack of WYSIWYG
+
* 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.
  
  - Duplication of effort with FLTK and Qt widgets.  With the rest
+
=== String class ===
    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
+
Matlab now uses "" to create string objects that behave differently from Octave double-quoted strings.
  framework)
 
  
  - Resolve remaining Matlab compatibility issues.
+
=== Handle UTF-8 (or whatever) characters properly ===
  
  - Make it possible to load and save classdef objects.
+
Try to do this in a Matlab-compatible way.
  
  - Improve and simplify the implementation.  Although the basic
+
=== Handle single and integer values for ranges ===
    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
+
=== Local functions ===
  
  - Matlab now uses "" to create string objects that behave
+
The semantics for local functions in scripts is different from the
    differently from Octave double-quoted strings.
+
way Octave currently handles functions that are defined in script
 +
files.
  
* Handle UTF-8 (or whatever) characters properly
+
=== Allow large files to be loaded and saved ===
  
  - Try to do this in a Matlab-compatible way.
+
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.
  
* Handle single and integer values for ranges
+
=== Matlab packages (+DIR directories in the loadpath; related to classdef) ===
  
* Local functions
+
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.
  
  - The semantics for local functions in scripts is different from the
+
=== Toolboxes ===
    way Octave currently handles functions that are defined in script
 
    files.
 
  
* Allow large files to be loaded and saved
+
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.
  
  - Make the load and save commands compatible with Matlab's
+
=== General code quality improvements ===
    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)
+
* 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
  
  - Octave already searches for files in package directories and
+
=== GUI code editor ===
    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
+
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
  
  - Move some core toolboxes (communications, control systems, image
+
=== Documentation ===
    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
+
* Continue to improve Doxygen documentation for Octave internals to make it easier for new contributors to understand the Octave code base.
  
  - Use C++11 features where possible.
+
=== JIT compiler ===
  
- Better and more complete use of C++ namespaces.
+
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.
  
  - Better use of C++ features.  Especially standard library features
+
This is probably the most difficult item (at least for me) since it
    as their implementation becomes more widely available.  For
+
will require fairly advanced knowledge of compiler infrastructure
    example, we might be able to simplify some things in Octave by
+
and Octave internals.
    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.
+
=== Windows distribution ===
  
* GUI code editor
+
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.
  
   - Make it possible to use external editors such as Emacs, vim, or
+
   bash      less        perl
    others with the GUI in addition to Octave's built-in code editor
+
  coreutils  libcrypt    regex
 
+
  diffutils  libiconv    sed
* Documentation
+
  dos2unix  libintl    tar
 
+
  file      libmagic    termcap
  - Continue to improve Doxygen documentation for Octave internals to
+
  findutils  libopenssl  unzip
    make it easier for new contributors to understand the Octave code
+
  gawk      make        zip
    base.
+
  grep      msys-core  wget
 
+
  gzip      patch      zlib
* 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.
 
<pre>
 
      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
 
</pre>
 

Latest revision as of 06:02, 9 June 2019

Improve interface for communication between GUI and interpreter[edit]

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[edit]

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[edit]

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[edit]

Generating EPS or PDF versions of figures needs improvement.

OpenGL graphics system issues[edit]

  • 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)[edit]

  • 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[edit]

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

Handle UTF-8 (or whatever) characters properly[edit]

Try to do this in a Matlab-compatible way.

Handle single and integer values for ranges[edit]

Local functions[edit]

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[edit]

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)[edit]

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[edit]

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[edit]

  • 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[edit]

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[edit]

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

JIT compiler[edit]

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[edit]

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