Online Developer Meeting (2021-10-26): Difference between revisions

From Octave
Jump to navigation Jump to search
 
(13 intermediate revisions by 3 users not shown)
Line 11: Line 11:


* State of OpenBLAS compilation bug(?): [https://savannah.gnu.org/bugs/index.php?61246 bug #61246: matrix inversions give wrong results (inv, lu, mldivide)]
* State of OpenBLAS compilation bug(?): [https://savannah.gnu.org/bugs/index.php?61246 bug #61246: matrix inversions give wrong results (inv, lu, mldivide)]
* <code>pkg test sparsersb</code> crashes Octave (only when installed to read-only directory?). Needs further investigation.
** Ask for testing the release candidate (Markus)
* <code>pkg test sparsersb</code> crashes Octave (only when installed to read-only directory?).
** Needs further investigation. See [https://savannah.gnu.org/bugs/index.php?61393 bug #61393].
* Which version numbers to update in which files on (minor) release? (CITATION file?)
* 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?
* Update of merge date for Octave 7.x?
** Probably early November?


=== Importance of allowing Octave headers in C language sources ===
=== Importance of allowing Octave headers in C language sources ===
Line 19: Line 23:
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?
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 [https://savannah.gnu.org/bugs/?61370 61370] and also comments 39 and 40 in [https://octave.discourse.group/t/using-m-prefix-for-member-variables-in-c-classes/1517 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.
See bug report [https://savannah.gnu.org/bugs/?61370 bug #61370] and also comments 39 and 40 in [https://octave.discourse.group/t/using-m-prefix-for-member-variables-in-c-classes/1517 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.


=== Fallback topic: <code>spawn</code> with <code>P_OVERLAY</code> works differently on POSIX and Windows ===
* Go ahead and remove support for compiling these headers in C. jwe will go through the sources and evaluate uses of <code>#ifdef __cplusplus</code>.


(Only if there is nothing else to talk about.)
=== <code>spawn</code> with <code>P_OVERLAY</code> works differently on POSIX and Windows ===


Markus' current understanding:
Markus' current understanding:
Line 29: Line 33:
* On Windows, <code>spawn</code> with <code>P_OVERLAY</code> 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 with <code>exec</code>.) That leads to issues when trying to use the <code>octave.exe</code> wrapper on Windows.
* On Windows, <code>spawn</code> with <code>P_OVERLAY</code> 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 with <code>exec</code>.) That leads to issues when trying to use the <code>octave.exe</code> wrapper on Windows.
* Could we use <code>spawn</code> with <code>P_WAIT</code> instead? IIUC, that would require passing the return code from the spawned process. What else?
* Could we use <code>spawn</code> with <code>P_WAIT</code> 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 <code>std::process</code> could fill that gap once/if it makes it into the standard (maybe C++23?): [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1750r1.pdf P1750R1 A Proposal to Add Process Management to the C++ Standard Library]
** '''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 [https://savannah.gnu.org/bugs/?61396 bug #61396: octave wrapper executable not working properly on Windows]
=== 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: [https://en.wikipedia.org/wiki/8.3_filename 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.


== Previous topics ==
== Previous topics ==

Latest revision as of 08:26, 2 November 2021

Todays topics[edit]

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

Progress of Octave 6.4.0 release[edit]

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?).
  • 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[edit]

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[edit]

Markus' current understanding:

  • spawn with P_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 with P_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 with exec.) That leads to issues when trying to use the octave.exe wrapper on Windows.
  • Could we use spawn with P_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?
    • 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

Octave 7[edit]

In preparation of the next release, start preparing a list of blocking issues (from the bug tracker?).

Paths with spaces (on Windows)[edit]

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.

Previous topics[edit]

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

Octave 6.4.0?[edit]

  • Last(?) Octave 6 release?
  • Background: 12 changes on the stable branch (~10 on the release branch of MXE Octave) since the last release. Most important ones:
    • Octave GUI doesn't start for some Windows users. Bug in Qt 5.14 that is fixed in Qt 5.15.
    • Crash to desktop fixed in Octave core (bug #61191).
    • Crash to desktop fixed in librsb (bug #60042, only affects Windows bundle).
    • Command line arguments with parameters (e.g. --path) can't be combined with --gui (bug #60886).
  • Ask on discourse for pending changes and do a new release.

Approximate release date for Octave 7?[edit]

  • Last few cycles: merge to stable and release date of first stable version:
    • 6.x: merge to stable: 2020-02-17 --- release: 2020-11-26 (~ 9.5 month)
    • 5.x: merge to stable: 2018-12-20 --- release: 2019-02-23 (~ 2 month)
    • 4.4.x: merge to stable: 2018-04-04 --- release: 2018-04-30 (< 1 month)
    • 4.2.x: merge to stable: 2016-09-28 --- release: 2016-11-13 (~ 1.5 month)
  • Unfinished projects:
    • Symbol visibility breaks tests for indexing expressions on macOS. Also many linker warnings similar to this (see bug #59820):
ld: warning: direct access in function 'conv_to_int_array(Array<octave::idx_vector> const&)' from file 'liboctave/array/.libs/libarray.a(libarray_la-Array-util.o)' to global weak symbol 'vtable for Array<long long>' from file 'liboctave/array/.libs/libarray.a(libarray_la-Array-i.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
    • Support paths including spaces (mostly for Windows - not relying on short file names). What about package Makefiles? Probably best if we defer that one to later.
    • more efficient mex file interface with direct pointers to data in Octave arrays (jwe)
    • Prefer OCTAVE_LOCAL_BUFFER over Array objects where possible (Rik, not a blocker)
  • Probably merge default to stable some time in November
  • Probably release Octave 7 around the end of this year or early 2022.

CamelCase in Octave functions?[edit]

  • What is our current stance on that? --> Avoid it for consistency. Allowed for compatibility.

Octave released on MSYS2[edit]

  • Not aiming to replace MXE Octave (more reliable, tested, stable(?)). Rather complement it.
  • Target group:
    • Users that want to use e.g. Octave packages that depends on third party packages not included in MXE Octave.
    • Users that need features of newer versions of packages that are included in MXE Octave.

GCC plugins[edit]

  • Call out to anyone who has experience with compiler plugins
  • Is it possible to write a compiler plugin that identifies variables that match certain conditions? E.g., m_ prefix for member variables.
  • Might allow other analysis of the code: E.g., are static or global variables used in a thread-safe manner?

Convenience function to check for integer property[edit]

  • Add a function that checks if a double has an integer value.
  • Also return true for integer type input.
  • What is a good name (in Octave and C++ code)?

Broadcasting with special matrix types[edit]

  • Topic comes up repeatedly in bug reports.
  • Add convenience option to disable support for these types (range, diagonal matrix, permutation matrix)?
  • Cast to full matrices before broadcasting? Special handling for NaN and Inf values!


See also[edit]