Online Developer Meeting (2021-08-24)

Todays topicsEdit

In the future notes of the talks will be added to this wiki in a more sparse fashion.

Make more use of STL
Not all liboctave components can be replaced by STL containers, as the ND-indexing is not supported.
string_vector class probably replaceable by STL containers.

Such as packages, toolboxes, etc.

Prefer OCTAVE_LOCAL_BUFFER over heavy-weight Array object to store results of (Fortran-) library calls.
Prefer octave_value type variables over internal data structures.
- Examples: Function handle class and Range class.

Do not use error_state anymore! https://octave.discourse.group/t/eliminating-use-of-error-state-in-octave-code/1515
Do not suppress compiler warnings about deprecated features today, those are the bug reports of tomorrow, when it is too late.

jwe made many breaking changes on the default branch moving symbols in the octave namespace, to keep the namespaces tidy.

In case of trolling behavior of users, please mark the thread, thus a Discourse admin can close the threat and mute the user.
- DO NOT FEED THE TROLL: Any further answer or conversation is most likely a waste of emotions and time.
Any user violating the usage conditions https://octave.discourse.group/tos#heading--conditions will be muted or removed from the forum entirely.

The following items were not discussed. Just some links to progress on those items are displayed.

No "official" announcement happened. Maybe reuse abandoned mailing-lists to announce important events, such as releases.
How do distribution maintainers get to know about Octave releases?
- Contact Debian maintainers of the Octave package to maybe improve our communication.
  - Done, already answered: https://lists.gnu.org/archive/html/octave-maintainers/2021-07/msg00001.html

Discussion how to continue with the development.
- jwe wants to introduce breaking changes (see below).
Octave should stick with the ~yearly major release cycle
- Probably no Octave 6.4 (only if severe bugs occur).
- Octave 7 (default branch)
  - Should no longer receive "very" breaking changes (e.g. String-class for Octave 8)
  - Has about 305 bugs fixed (not 100% reliable figure) and should not wait another year until many bigger outstanding changes happen (will be deferred to Octave 8)
  - Tentative plan:
    - November 2021 merge default to stable.
    - End of 2021 release of Octave 7
- Octave 8 (new default branch)
  - No clear decision how to handle very breaking changes until November 2021 merge default to stable. Depends on future needs.

Function argument parsing (introduced in Matlab R2019b, rather new)
- jwe will continue to work on this feature on Octave 7 (default branch)
- If feature cannot be completed by the end of the year, it will be disabled on parser-level (error), and introduced in Octave 8 one year later.
New GUI command widget
- Possible to introduce it as user opt-in in Octave 7
- Pending issues:
  - Command-widget does not look like the previous one (textbox for command input)
  - jwe needs better looking widget (avoid developing a new one)
  - No possibility to run external applications (like emacs, pager), which is already partially broken now. Need to implement own paging strategy (scroll bars, etc.)
Deprecation of Octave operators
- Improve Matlab compatibility
- Some extensions make it painful to implement Matlab compatible command-style function calls? See also the discussion about this topic.
  - Remove rarely used extensions like "**" power.
  - Discussion about removal of "+=", "++", etc. No final decision made.
  - Often used extensions must probably stay (like "!" or "!=" used in place of "~" or "~=").

jwe had a look at Octave own reference counting
Wish to replace it with C++ shared pointers
Expert knowledge wanted! jwe opened a discussion thread
jwe identified "copy expensive" inefficiency about mxArray to octave_value conversion? Root of the trouble lies in historical handling of complex data? See this discussion.