Online Developer Meeting (2022-02-22): Difference between revisions

From Octave
Jump to navigation Jump to search
(Add some topics for upcoming meeting)
(→‎Todays topics: Add notes and memory of Kai)
 
(6 intermediate revisions by 2 users not shown)
Line 8: Line 8:
=== Release process of Octave 7.1 ===
=== Release process of Octave 7.1 ===


* Blocking issues: 9 bugs targeting 7.0.90, 3 marked as "ready for test" (see [https://octave.space/savannah/# Savannah overview on octave.space])
* 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:
* Good progress on some of the blocking issues by jwe. Most important remaining ones:
** 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. Not started yet.
*** 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]
*** Image package had trouble with this change (bug {{bug|61815}}).  These changes should be reviewed with the next Octave 7 release candidate.
*** @jwe provided an initial changeset. That will also revert to copying from the .mex interface unless Octave is compiled with C++17 pmr.
*** jwe summarized options for the release in comment #18 of the bug report.
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file]
*** jwe will revert most changes on "stable" (Octave 7) and continue developing on "default".
*** Lower priority, only 32-bit (only on Windows?). Probably not a blocker.
** 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
** 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.
*** 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
** Similar bug {{bug|61843}}: Regression with subscripted assignments with arrays of objects
*** Older regression.
*** 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? ===
=== 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)?]
* 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 ==

Latest revision as of 04:47, 24 February 2022

Todays topics[edit]

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

Release process of Octave 7.1[edit]

  • Blocking issues: 8 open bugs targeting 7.0.90, 3 marked as "ready for test" (see Savannah overview on octave.space)
  • Good progress on some of the blocking issues by jwe. Most important remaining ones:
    • bug #61788: arrays of type int16 contain wrong numbers
      • The :-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 #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 #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 malloc-operator delete[] mismatch.
      • Confirmed fixed now.
    • 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 #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 #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 #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?[edit]

libinterp[edit]

dynamic loader (oct-files)[edit]

  • jwe worked on refactoring dynamic code loading with std::shared_ptr, 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?[edit]

Previous topics[edit]

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

Release process of Octave 7.1[edit]

  • Blocking issues: 9 bugs targeting 7.0.90 (see Savannah overview on octave.space)
  • Most important ones (in no particular order):
    • bug #61788: arrays of type int16 contain wrong numbers
      • The :-operator will probably be changed to return an array (instead of a range object) before Octave 7.
    • 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 (--enable-pmr-polymorphic-allocator), while .oct files are not.
      • 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.)
    • malloc-delete[] combination in the .mex interface
      • No decision made. Maybe leave as is?
    • bug #61821: segfault using tree_parameter_list in oct file
      • Check if we are doing something wrong for 32bit. Probably not a blocker.
    • bug #61898: subsref: Error when field syntax is used on non-scalar @class object
      • Try finding a minimal reproducer (without interval package). Similar 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
    • Improving the caching strategy is the way to go (see e.g. bug #54636).
    • Long-term: A complete overhaul of the load path caching implementation is probably necessary.

C++17 features in Octave API?[edit]

  • Timeframe?
    • When qt6 is distributed? - Probably bad strategy (Debian/Ubuntu and even Arch have trouble with qt6).
    • Regarding stable=stale Linux distributions.
  • Should we announce that possible requirement for some time in the future with the release of Octave 7?
  • See also: 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[edit]

  • GSOC 2022 Timeline (Feb 7-21 is Org application window, acceptances announced Mar 7.)
  • 2022 changes - after shifting to shorter projects in 2021, GSOC now allows flexible project/time commitments from 10-22 wks (12 standard, org/mentor flexibility on milestone dates).
  • GSOC FAQ (took note that the organization does get a small stipend for participating... helping a bit to offset yearly infrastructure costs)
  • Past projects at other orgs ranged quite widely in scope, especially with change to smaller projects in 2021:
    • some were often a part of big tasks. Are there bigger octave goals that could be parted out for a GSOC task? parts of classdef, or graphics handles, or a new command window, or dare we suggest JIT?
    • Some amounted to "tackle all the bugs related to X". Are there bug categories or unimplemented function categories (that might require particular coding or mathematical knowledge) worth directing particular focus on? 'the unimplemented interpolant classes/functions' or 'unimplemented image package functions related to feature recognition' or ...
    • "complete this unfinished thing" tasks (prior gsoc? pkg related? the 'did you mean' feature?)
  • Thinking ahead, 'Google Season of Docs' has typically announced/opened their program in Feb-March. Are there small/large doc projects worth getting into GSOD so a paid freelance technical writer/coder can take it on for 6-9 months? Successful examples ranging from document creation to doc infrastructure - 2021 2020 2019
  • Please find small / partial contributions (also m-files) that help you with your current projects on Octave.
    • HDF5 project?
    • Time to specify the task lacks...

See also[edit]