Editing Online Developer Meeting (2022-01-25)

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 10: Line 10:
* Blocking issues: 9 bugs targeting 7.0.90 (see [https://octave.space/savannah/# Savannah overview on octave.space])
* Blocking issues: 9 bugs targeting 7.0.90 (see [https://octave.space/savannah/# Savannah overview on octave.space])
* Most important ones (in no particular order):
* Most important ones (in no particular order):
** bug {{bug|61788}}: arrays of type int16 contain wrong numbers
** bug {{bug|61788}}: arrays of type int16 contain wrong numbers]
*** The <code>:</code>-operator will probably be changed to return an array (instead of a range object) before Octave 7.
*** Will probably be reverted before Octave 7.
** bug {{bug|61813}}: memory management bug when calling MEX that returns an output
** bug {{bug|61813}}: memory management bug when calling MEX that returns an output]
*** Probably caused by changes for more efficient data interface for .mex files.  @jwe will check this.
*** Issue if Octave is compiled with C++17, while the mex file not. @jwe checks on this.
** Possible issues if Octave is compiled with C++17 (<code>--enable-pmr-polymorphic-allocator</code>), while .oct files are not.
*** maybe also: <code>malloc</code>-<code>delete[]</code> combination in the .mex interface
*** Maybe change the API string if Octave is configured with polymorphic allocators?
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file]
*** Leave that option in. But disable it by default. (That is already the current state.)
*** Lower priority, only conditionally reproducible.
** <code>malloc</code>-<code>delete[]</code> combination in the .mex interface
** bug {{bug|61898}}: subsref: Error when field syntax is used on non-scalar @class object]
*** No decision made. Maybe leave as is?
*** Needs reproducible example without interval package. Similar bug {{bug|61843}} reported.   
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file
* A few package releases with fixes for Octave 7 were pushed to mxe default, e.g. https://hg.octave.org/mxe-octave/rev/d601436d29f2 (ga, control, communications)
*** Check if we are doing something wrong for 32bit. Probably not a blocker.
** Should those changes be applied to the "release" branch?  -YES.
** bug {{bug|61898}}: subsref: Error when field syntax is used on non-scalar @class object
*** Try finding a minimal reproducer (without interval package). Similar bug {{bug|61843}} reported.   
* A few package releases with fixes for Octave 7 were pushed to the default branch of MXE Octave, e.g. https://hg.octave.org/mxe-octave/rev/d601436d29f2 (ga, control, communications)
** Should those changes be grafted to the "release" branch?  -YES.
* Revisit load path caching: https://octave.discourse.group/t/rfc-remove-faulty-load-path-caching/2136
* Revisit load path caching: https://octave.discourse.group/t/rfc-remove-faulty-load-path-caching/2136
** Improving the caching strategy is the way to go (see e.g. bug {{bug|54636}}).
** Improving the caching strategy is the way to go.
** Long-term: A complete overhaul of the load path caching implementation is probably necessary.


=== C++17 features in Octave API? ===
=== C++17 features in Octave API? ===
Line 36: Line 31:
* Should we announce that possible requirement for some time in the future with the release of Octave 7?
* Should we announce that possible requirement for some time in the future with the release of Octave 7?
* See also: [https://octave.discourse.group/t/should-octave-switch-to-c-17-if-so-when/2114 Should Octave switch to C++17? If so, when?] on Discourse.
* See also: [https://octave.discourse.group/t/should-octave-switch-to-c-17-if-so-when/2114 Should Octave switch to C++17? If so, when?] on Discourse.
* We'll start an experiment by enabling polymorphic allocators for default Octave on the default branch of MXE Octave. We'll evaluate if the necessary changes to dependent packages are trivial.


=== GSOC 2022 opening soon ===
=== GSOC 2022 opening soon ===
Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Template used on this page: