Online Developer Meeting (2021-08-24)
Jump to navigation
Jump to search
- Date: Tuesday, August 24, 2021 @ 18:00 UTC
- Location: https://meet.jit.si/octave-dev-2021-08-24
Todays topics
- Meet and greet 5 minutes before meeting (audio testing).
Switch this meeting to more casual format
- In the future notes of the talks will be added to this wiki in a more sparse fashion.
liboctave
- 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.
Tips for Octave C++ code writers
Such as packages, toolboxes, etc.
- Prefer
OCTAVE_LOCAL_BUFFER
over heavy-weightArray
object to store results of (Fortran-) library calls. - Prefer
octave_value
type variables over internal data structures.- Examples: Function handle class and Range class.
For package maintainers
- 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.
octave namespace
- jwe made many breaking changes on the default branch moving symbols in the octave namespace, to keep the namespaces tidy.
Deprecations
- The operators
.+
,.-
, and**
https://octave.discourse.group/t/deprecating-fortran-style-exponent-operator/1516 will be deprecated.
Code sprints
- Wish for more code sprints, e.g.,
- "m_" convention https://octave.discourse.group/t/using-m-prefix-for-member-variables-in-c-classes/1517/17
- Close easy closable bugs Short_projects#Easy_Closes
Previous topics
- The following items were not discussed. Just some links to progress on those items are displayed.
Octave 6.3 released
- 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
- Contact Debian maintainers of the Octave package to maybe improve our communication.
Octave 6.4 / 7 / 8
- 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.
Octave 7 / 8
- 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.
See also
- Next meeting: Online Developer Meeting (2021-09-28)
- Last meeting: Online Developer Meeting (2021-07-27)