JWE Project Ideas: Difference between revisions

Jump to navigation Jump to search

JWE Project Ideas (view source)

Revision as of 15:19, 12 March 2018

363 bytes removed ,  12 March 2018
no edit summary
(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...")
 
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
    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 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
** 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.


  - Scaling plot data values/ranges to fit in single-precision OpenGL values
* Improvements to classdef (the Matlab object-oriented program framework)
 
** Resolve remaining Matlab compatibility issues.
  - Performance issues
** Make it possible to load and save classdef objects.
 
** Improve and simplify the implementation.  Although the basic
  - Lack of WYSIWYG
  features that are implemented now appear to mostly work, the
 
  implementation seems overly complicated, making it difficult to
  - Duplication of effort with FLTK and Qt widgets.  With the rest
  debug and modify.  There seems to be quite a bit of room for
    of the GUI using Qt widgets, we should eliminte the FLTK plotting
  improvement here.
    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
* 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
Line 71: Line 63:
* 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
    way Octave currently handles functions that are defined in script
way Octave currently handles functions that are defined in script
    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
    HDF5-based file format.  Matlab users expect this and we need
HDF5-based file format.  Matlab users expect this and we need
    something like this to support large arrays anyway.
something like this to support large arrays anyway.


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


  - Octave already searches for files in package directories and
Octave already searches for files in package directories and
    understands the PKG.fcn syntax and functionality.  The big missing
understands the PKG.fcn syntax and functionality.  The big missing
    piece is implementation of the "import" functionality and handling
piece is implementation of the "import" functionality and handling
    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
    processing, optimization, signal processing, and statistics), to
processing, optimization, signal processing, and statistics), to
    core Octave so development is managed along with Octave.  Core
core Octave so development is managed along with Octave.  Core
    Octave developers are already responsible for these packages
Octave developers are already responsible for these packages
    anyway, and users don't seem to understand why they need to
anyway, and users don't seem to understand why they need to
    install them separately.  Core parts of the ordinary differential
install them separately.  Core parts of the ordinary differential
    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.
** 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.


  - Use C++11 features where possible.
* Eliminate C preprocessor macros 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
* 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
base.


  - Continue to improve Doxygen documentation for Octave internals to
* JIT compiler
    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.


  - A proof-of-concept implementation was done several years ago by a
This is probably the most difficult item (at least for me) since it
    Google Summer of Code student.  It was never complete and little
will require fairly advanced knowledge of compiler infrastructure
    work has been done since.  It also depends on an old version of
and Octave internals.
    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
* Windows distribution
    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.


   - Eliminate the following msys packages.  Some might be removed
   bash      less        perl
    entirely if they are unnecessary for running Octave or building
  coreutils  libcrypt    regex
    Octave Forge packages.  Otherwise, we should be building them from
  diffutils  libiconv    sed
    source as we do all other tools and libraries that are distributed
  dos2unix  libintl    tar
    with Octave.  The difficulty is that although the msys packges are
  file      libmagic    termcap
    typically based on old versions of these packages, they sometimes
  findutils  libopenssl  unzip
    have fixes that are needed to allow them to run properly on
  gawk      make        zip
    Windows systems.  Note also that we distribute a termcap library,
  grep      msys-core  wget
    but the msys version of less depends on the msys termcap library.
  gzip      patch      zlib
<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>
Retrieved from "https://wiki.octave.org/Special:MobileDiff/10700"

Navigation menu