Editing Online Developer Meeting (2021-10-26)
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
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)] --> Ask for testing the release candidate (Markus) | ||
* <code>pkg test sparsersb</code> crashes Octave (only when installed to read-only directory?). Needs further investigation. | |||
* <code>pkg test sparsersb</code> 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? | |||
* Which version numbers to update in which files on (minor) release? (CITATION file?) | |||
* Update of merge date for Octave 7.x? | |||
=== Importance of allowing Octave headers in C language sources === | === Importance of allowing Octave headers in C language sources === | ||
Line 23: | Line 19: | ||
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 | 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. | ||
--> 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 === | === Fallback topic: <code>spawn</code> with <code>P_OVERLAY</code> works differently on POSIX and Windows === | ||
(Only if there is nothing else to talk about.) | |||
Markus' current understanding: | Markus' current understanding: | ||
Line 33: | Line 31: | ||
* 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? | ||
== Previous topics == | == Previous topics == |