Difference between revisions of "Online Developer Meeting (2021-08-24)"

(Create page.)
 
 
(5 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
* Meet and greet 5 minutes before meeting (audio testing).
 
* Meet and greet 5 minutes before meeting (audio testing).
  
=== First topic to discuss ===
+
=== 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.
 +
* <code>string_vector</code> class probably replaceable by STL containers.
 +
 
 +
=== Tips for Octave C++ code writers ===
 +
 
 +
Such as packages, toolboxes, etc.
 +
 
 +
* Prefer <code>OCTAVE_LOCAL_BUFFER</code> over heavy-weight <code>Array</code> object to store results of (Fortran-) library calls.
 +
* Prefer <code>octave_value</code> type variables over internal data structures.
 +
** Examples: Function handle class and Range class.
 +
 
 +
=== For package maintainers ===
 +
 
 +
* Do not use <code>error_state</code> 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 <code>.+</code>, <code>.-</code>, and <code>**</code> https://octave.discourse.group/t/deprecating-fortran-style-exponent-operator/1516 will be deprecated.
 +
 
 +
=== Trolling ===
 +
 
 +
* 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.
 +
 
 +
=== 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 ==
 
== Previous topics ==
Line 14: Line 55:
 
* No "official" announcement happened.  Maybe reuse abandoned mailing-lists to announce important events, such as releases.
 
* 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?
 
* How do distribution maintainers get to know about Octave releases?
** Contact Debian maintainers of the Octave package to maybe improve our communication (Kai).
+
** 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
  
 
=== Octave 6.4 / 7 / 8 ===
 
=== Octave 6.4 / 7 / 8 ===
Line 34: Line 76:
 
** jwe will continue to work on this feature on Octave 7 (default branch)
 
** 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.
 
** 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
+
* [https://octave.discourse.group/t/new-command-window-widget/501? New GUI command widget]
 
** Possible to introduce it as user opt-in in Octave 7
 
** Possible to introduce it as user opt-in in Octave 7
 
** Pending issues:
 
** Pending issues:
Line 42: Line 84:
 
* Deprecation of Octave operators
 
* Deprecation of Octave operators
 
** Improve Matlab compatibility
 
** Improve Matlab compatibility
** Some extensions make it painful to implement Matlab compatible command-style function calls? (some clarification needed)
+
** Some extensions make it painful to implement Matlab compatible command-style function calls? See also the [https://octave.discourse.group/t/parsing-command-style-function-call-syntax/1414/7 discussion] about this topic.
 
*** Remove rarely used extensions like "**" power.
 
*** Remove rarely used extensions like "**" power.
 
*** Discussion about removal of "+=", "++", etc.  No final decision made.
 
*** Discussion about removal of "+=", "++", etc.  No final decision made.
*** Often used extensions like "!" == "~" must probably stay.
+
*** Often used extensions must probably stay (like "!" or "!=" used in place of "~" or "~=").
  
 
=== C++ shared pointer / liboctave ===
 
=== C++ shared pointer / liboctave ===
 
* jwe had a look at Octave own reference counting
 
* jwe had a look at Octave own reference counting
 
* Wish to replace it with C++ shared pointers
 
* Wish to replace it with C++ shared pointers
* Expert knowledge wanted!
+
* Expert knowledge wanted! jwe opened a [https://octave.discourse.group/t/using-std-shared-ptr-t-to-implement-copy-on-write-objects-in-octave/1436 discussion thread]
** jwe will reach out on Discourse about the exact problems.
+
* jwe identified "copy expensive" inefficiency about mxArray to octave_value conversion? Root of the trouble lies in historical handling of complex data? See this [https://octave.discourse.group/t/improving-performance-of-data-transfer-to-and-from-mex-functions/1437 discussion].
* jwe identified "copy expensive" inefficiency about mxArray to octave_value conversion? (some clarification needed)
 
** Root of the trouble lies in historical handling of complex data?? (some clarification needed)
 
  
 
== See also ==
 
== See also ==

Latest revision as of 22:12, 24 August 2021

Todays topicsEdit

  • Meet and greet 5 minutes before meeting (audio testing).

Switch this meeting to more casual formatEdit

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

liboctaveEdit

  • 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 writersEdit

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.

For package maintainersEdit

octave namespaceEdit

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

DeprecationsEdit

TrollingEdit

  • 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.

Code sprintsEdit

Previous topicsEdit

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

Octave 6.3 releasedEdit

Octave 6.4 / 7 / 8Edit

  • 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 / 8Edit

  • 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 "~=").

C++ shared pointer / liboctaveEdit

  • 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 alsoEdit