1,847
edits
Online Developer Meeting (2021-10-26): Difference between revisions
Online Developer Meeting (2021-10-26) (edit)
Revision as of 03:50, 27 October 2021
, 27 October 2021→Todays topics: Add notes and memory of Kai
(→Todays topics: Add more topics from meeting.) |
(→Todays topics: Add notes and memory of Kai) |
||
| Line 10: | Line 10: | ||
[https://octave.discourse.group/t/start-release-process-for-octave-6-4-0/1652 Start release process for Octave 6.4.0] | [https://octave.discourse.group/t/start-release-process-for-octave-6-4-0/1652 Start release process for Octave 6.4.0] | ||
* 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) | ||
* Which version numbers to update in which files on (minor) release? (CITATION file?) | * <code>pkg test sparsersb</code> crashes Octave (only when installed to read-only directory?). | ||
* Update of merge date for Octave 7.x? | ** Needs further investigation. | ||
* 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 === | === 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. | ||
** 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>. | |||
=== | === <code>spawn</code> with <code>P_OVERLAY</code> works differently on POSIX and Windows === | ||
Markus' current understanding: | Markus' current understanding: | ||
| Line 33: | Line 35: | ||
* [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? | * [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. | Short term: Test if the wrapper can be replaced with a link (or copy) of "octave-gui.exe" in MSYS2. | ||
| Line 43: | Line 45: | ||
=== Paths with spaces (on Windows) === | === 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. | 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 octave.space when the first nightlies of Octave 7 will be built. | ** '''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. | ** Try to fix those issues where we find them or get reports. | ||
== Previous topics == | == Previous topics == | ||