Online Developer Meeting (2021-11-23): Difference between revisions
(→Octave 8 ideas: Add remarks from meeting) |
|||
Line 48: | Line 48: | ||
* OpenMP parallelization for trivial cases (e.g. initialize matrix with constant)? | * OpenMP parallelization for trivial cases (e.g. initialize matrix with constant)? | ||
** Ensure thread safeness of Array classes (especially GUI-interpreter communication) | ** Ensure thread safeness of Array classes (especially GUI-interpreter communication) | ||
* Other performance | ** Maybe based on <code>std:shared_ptr</code>? But they aren't guaranteed to be thread-safe by design either. | ||
** Idea: memory pools bug {{bug|57321}} | ** Eliminate <code>mutable</code> class data. | ||
** Idea: static_cast vs. dynamic_cast | * Other performance improvements: | ||
** Idea: memory pools: bug {{bug|57321}} | |||
** Idea: static_cast vs. dynamic_cast: patch {{patch|10139}} | |||
** General remark: Prefer standard features instead of "reinventing the wheel" by implementing intricate optimizations. | |||
== Previous topics == | == Previous topics == |
Revision as of 08:18, 24 November 2021
- Date: Tuesday, November 23, 2021 @ 18:00 UTC
- Location: https://meet.jit.si/octave-dev-2021-11-23
Todays topics
- Meet and greet 5 minutes before meeting (audio testing).
Octave 7
- Octave 7.1.0 release activities and timeline
- 7.1 Release Checklist
- Merge default to stable now
- No new features anymore (explain on Octave Discourse @jwe?)
- Focus on stabilization
- Bugs to be fixed marked on Savannah with "7.0.90" or "Octave 7" on https://octave.space/savannah/
- Go through "ready for test" list, close as much as possible
- Call for translations
- Approx. final release date (early 2022)
MXE Octave merge strategy
- When should the default branch of MXE Octave be merged to the release branch?
- * Around the same time as the merge of the default branch of Octave to its stable branch.
- Which branches should the buildbots use in the pre-release phase? Different for jwe's buildbots and octave.space?
- * Keep them running like they are. Evaluate if buildbot failures need action in the transition period before the major release.
UCRT version of Octave?
- Should we distribute an UCRT version of Octave for Windows?
- No big opposition to adding new versions if it doesn't become too many and they add value.
- Probably changes inside Octave necessary as well. Long time project. Maybe for Octave 8 (or later).
- See: Windows, UTF-8, and UCRT - yet another variant of Octave on Windows?
Bus factor
- Octave needs more documentation of release tasks.
- jwe updates Project Infrastructure page.
- Start an Octave Discourse thread about ideas how to ensure project continuity.
Octave 8 ideas
- jwe updated Category:Development#jwe_priorities and clean up outdated JWE Project Ideas.
- @jwe: shall I (Kai) merge and redirect JWE Project Ideas into the general Projects page??
- jwe wants to work on argument-list syntax.
- rik wants to consistently use
OCTAVE_LOCAL_BUFFER
in liboctave. - OpenMP parallelization for trivial cases (e.g. initialize matrix with constant)?
- Ensure thread safeness of Array classes (especially GUI-interpreter communication)
- Maybe based on
std:shared_ptr
? But they aren't guaranteed to be thread-safe by design either. - Eliminate
mutable
class data.
- Other performance improvements:
Previous topics
- The following items were not discussed. Just some links to progress on those items are displayed.
Progress of Octave 6.4.0 release
Start release process for Octave 6.4.0
- State of OpenBLAS compilation bug(?): bug #61246: matrix inversions give wrong results (inv, lu, mldivide)
- Ask for testing the release candidate (Markus)
pkg test sparsersb
crashes Octave (only when installed to read-only directory?).- Needs further investigation. See bug #61393.
- Which version numbers to update in which files on (minor) release? (CITATION file?)
- jwe will add rules for an automatic update.
- Update of merge date for Octave 7.x?
- Probably early November?
Importance of allowing Octave headers in C language sources
Some header files in Octave have been written to allow them to be compiled by a C compiler. It is not clear whether anyone really needs to do that and it adds somewhat to the cost of maintaining Octave to ensure that this goal is met, even for just a few of the public header files. Would it be OK to change Octave so that public header files require a C++ compiler? And would it be OK to make this change in version 7 without deprecating and preserving the current coding style for two release cycles?
See bug report bug #61370 and also comments 39 and 40 in this discourse discussion for some motivating examples of cases where it might be simpler to expect that Octave header files will be compiled by a C++ compiler.
- Go ahead and remove support for compiling these headers in C. jwe will go through the sources and evaluate uses of
#ifdef __cplusplus
.
spawn
with P_OVERLAY
works differently on POSIX and Windows
Markus' current understanding:
spawn
withP_OVERLAY
replaces the current process with a new one. On POSIX, another process waiting for the original process (like a terminal) will wait for the replacing process instead.- On Windows,
spawn
withP_OVERLAY
also replaces the current process. But each process has a distinct id on Windows. I.e., the new process gets a different process id from the original one. Another process (like a terminal) waiting for the original process id will resume once the original process terminates. (The same happens withexec
.) That leads to issues when trying to use theoctave.exe
wrapper on Windows. - Could we use
spawn
withP_WAIT
instead? IIUC, that would require passing the return code from the spawned process. What else?- [jwe] We have too many different ways of starting and interacting with subprocesses (popen, popen2, system, spawn, procbuf, procstream, etc.). Is it possible to use just one C++ function to provide all the public functions we need to support?
- [mmuetzel] Afaict, there is currently no standard C++ function that would do that. Maybe
std::process
could fill that gap once/if it makes it into the standard (maybe C++23?): P1750R1 A Proposal to Add Process Management to the C++ Standard Library
- [mmuetzel] Afaict, there is currently no standard C++ function that would do that. Maybe
- Long term: Get rid of the wrapper program on all platforms. That would require the new command line interface and the possibility to dynamically load the GUI (optionally). This will probably not happen before Octave 8.
- Short term: Test if the wrapper can be replaced with a link (or copy) of "octave-gui.exe" in MSYS2. See bug #61396: octave wrapper executable not working properly on Windows
- [jwe] We have too many different ways of starting and interacting with subprocesses (popen, popen2, system, spawn, procbuf, procstream, etc.). Is it possible to use just one C++ function to provide all the public functions we need to support?
Octave 7
In preparation of the next release, start preparing a list of blocking issues (from the bug tracker?).
- Created 7.1 Release Checklist.
Paths with spaces (on Windows)
Background: Short file names are de-activated in more and more Windows systems by default. It is no longer a viable workaround to use them to fix issues with spaces in paths.
- For Octave 7, still install to "Program Files" by default. Keep the workaround with conversion to short file names intact for released versions. Remove the conversion to short file names in nightly builds on https://octave.space when the first nightlies of Octave 7 will be built.
- Try to fix those issues where we find them or get reports.
See also
- Next meeting: Online Developer Meeting (2021-12-28)
- Last meeting: Online Developer Meeting (2021-10-26)