Jump to navigation Jump to search

JWE Project Ideas

6,209 bytes added, 07:07, 12 March 2018
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..."
* 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

- 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

* 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

- 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

* 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

Navigation menu