1,847
edits
(Create page.) |
(→Todays topics: Add notes and memory of Kai) |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
* Meet and greet 5 minutes before meeting (audio testing). | * Meet and greet 5 minutes before meeting (audio testing). | ||
=== Release process of Octave 7.1 === | |||
* Blocking issues: 8 open bugs targeting 7.0.90, 3 marked as "ready for test" (see [https://octave.space/savannah/# Savannah overview on octave.space]) | |||
* Good progress on some of the blocking issues by jwe. Most important remaining ones: | |||
** 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. | |||
*** Image package had trouble with this change (bug {{bug|61815}}). These changes should be reviewed with the next Octave 7 release candidate. | |||
*** jwe summarized options for the release in comment #18 of the bug report. | |||
*** jwe will revert most changes on "stable" (Octave 7) and continue developing on "default". | |||
** bug {{bug|61813}}: memory management bug when calling MEX that returns an output | |||
*** @jwe check in a fix that will also revert to copying data in the .mex interface (less efficient, but also the way it has always been done until now) unless Octave is compiled with C++17 pmr. | |||
*** This also avoids the <code>malloc</code>-<code>operator delete[]</code> mismatch. | |||
*** Confirmed fixed now. | |||
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file | |||
*** Lower priority, only 32-bit (only on Windows?). Maybe a compiler bug? | |||
*** Not a blocker. | |||
** bug {{bug|61898}}: subsref: Error when field syntax is used on non-scalar @class object | |||
*** Not a bug in Octave core. Recent changes to output argument validation uncovered an issue in interval package. | |||
** Similar bug {{bug|61843}}: Regression with subscripted assignments with arrays of objects | |||
*** Older regression. | |||
** Use suffix for API string when it requires C++17 pmr? | |||
*** Should indicate if Octave was compiled with C++17 support or not. | |||
*** Need to recompile packages. | |||
*** Agreed to avoid suffix. Leave things as is. | |||
** bug {{bug|61687}}: Ignore not updated translations. Open new bug report for further translations. | |||
** '''There will be soon a second release candidate.''' | |||
=== Minimum Qt5 version for Octave 8? === | |||
* No real conclusion. Wait for progress with Linux distributions. | |||
* See [https://octave.discourse.group/t/qt5-15-already-unsupported-upstream-except-commercial-license/737/15 Qt5.15 already unsupported upstream (except commercial license)?] | |||
=== libinterp === | |||
* suggestion to prefer <code>std::copy_n</code> instead of for-loop to duplicate data | |||
** try to avoid making too many copies anyways! | |||
* rik updated about the progress on bug {{bug|61753}} (https://octave.discourse.group/t/project-to-review-and-replace-c-assert-with-error-calls/2043) | |||
** jwe suggest to use [https://en.cppreference.com/w/cpp/language/exceptions proper C++ exceptions] in some future release of Octave, instead of error function pointers. | |||
=== dynamic loader (oct-files) === | |||
* jwe worked on refactoring dynamic code loading with <code>std::shared_ptr</code>, also for reference counting. | |||
* Not clear if there is a portable "standard" way of loading code dynamically (oct-file). Ideas are welcome. | |||
=== (Not discussed) Where to announce package updates now? === | |||
* See [https://octave.discourse.group/t/2246 Do we still announce new OF package releases and if yes, where?] | |||
== Previous topics == | == Previous topics == | ||
Line 15: | Line 61: | ||
* 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. | ||
** 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. | ||
** | ** Possible issues if Octave is compiled with C++17 (<code>--enable-pmr-polymorphic-allocator</code>), while .oct files are not. | ||
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file | *** Maybe change the API string if Octave is configured with polymorphic allocators? | ||
*** | *** Leave that option in. But disable it by default. (That is already the current state.) | ||
** bug {{bug|61898}}: subsref: Error when field syntax is used on non-scalar @class object | ** <code>malloc</code>-<code>delete[]</code> combination in the .mex interface | ||
*** | *** No decision made. Maybe leave as is? | ||
* A few package releases with fixes for Octave 7 were pushed to | ** bug {{bug|61821}}: segfault using tree_parameter_list in oct file | ||
** Should those changes be | *** Check if we are doing something wrong for 32bit. Probably not a blocker. | ||
** 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. | ** Improving the caching strategy is the way to go (see e.g. bug {{bug|54636}}). | ||
** 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 87: | ||
* 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 === |