Online Developer Meeting (2022-01-25): Difference between revisions

Jump to navigation Jump to search
→‎C++17 features in Octave API?: Add experiment on MXE Octave
(→‎C++17 features in Octave API?: Add experiment on MXE Octave)
 
(3 intermediate revisions by 2 users not shown)
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
*** Will probably be reverted before Octave 7.
*** 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
*** Issue if Octave is compiled with C++17, while the mex file not. @jwe checks on this.
*** Probably caused by changes for more efficient data interface for .mex files.  @jwe will check this.
*** maybe also: <code>malloc</code>-<code>delete[]</code> combination in the .mex interface
** 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?
*** Lower priority, only conditionally reproducible.
*** 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
*** Needs reproducible example without interval package. Similar bug {{bug|61843}} reported.   
*** No decision made. Maybe leave as is?
* 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)
** bug {{bug|61821}}: segfault using tree_parameter_list in oct file
** Should those changes be applied to the "release" branch?  -YES.
*** 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 31: Line 36:
* 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 ===
* In this wiki [[GSoC]] (landing page) and [[Summer of Code]] (past projects).


* [https://developers.google.com/open-source/gsoc/timeline GSOC 2022 Timeline] (Feb 7-21 is Org application window, acceptances announced Mar 7.)
* [https://developers.google.com/open-source/gsoc/timeline GSOC 2022 Timeline] (Feb 7-21 is Org application window, acceptances announced Mar 7.)
Line 39: Line 47:
* Past projects at other orgs ranged quite widely in scope, especially with change to smaller projects in 2021:
* 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 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 clasess/functions' or 'unimplemented image package functions related to feature recognition' or ...  
** 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?)  
** "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 - [https://developers.google.com/season-of-docs/docs/participants 2021] [https://developers.google.com/season-of-docs/docs/2020/participants 2020] [https://developers.google.com/season-of-docs/docs/2019/participants 2019]
* 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 - [https://developers.google.com/season-of-docs/docs/participants 2021] [https://developers.google.com/season-of-docs/docs/2020/participants 2020] [https://developers.google.com/season-of-docs/docs/2019/participants 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...


== Previous topics ==
== Previous topics ==
214

edits

Navigation menu