255
edits
(→C++17) |
|||
(13 intermediate revisions by 3 users not shown) | |||
Line 6: | Line 6: | ||
* Meet and greet 5 minutes before meeting (audio testing). | * Meet and greet 5 minutes before meeting (audio testing). | ||
=== MXE Octave branches | === MXE Octave branches === | ||
* | * Which changes should go on which branch? | ||
** "default": everything new | |||
** "release": conservative updates | |||
*** new Octave packages + dependent libraries (if necessary and applicable) | |||
*** MXE libraries which have severe bugs / security issues. | |||
* Which branch should the buildbots use? | |||
** http://buildbot.octave.org:8010/ (jwe) | |||
*** Probably add builders to jwe's buildbot that build the current Octave stable branch with MXE Octave's release branch. | |||
*** Is there a way to trigger daily builds of the mxe builders only if there have been changes in Octave or MXE Octave. | |||
** https://buildbot.octave.space/ (Kai) | |||
*** General move to "release" branch (probably May) | |||
*** One additional build of "w64" with "default" branch | |||
=== Buildbots === | |||
* Find out how to trigger a build on changes in two repositories? | |||
** Untested idea: https://github.com/gnu-octave/octave-buildbot/pull/9/files | |||
=== GitHub === | |||
* Markus wants to try out using GitHub runners | |||
** https://octave.discourse.group/t/ci-with-github-hosted-runners/1081 | |||
** Try out macOS runners | |||
* Therefore a folder ".github" will be added to the Octave main repo | |||
** Can be removed anytime if it proves as not useful. | |||
* If other services (despite GitHub) are going to be tested, respective files might be added too. | |||
=== String class strategy === | === String class strategy === | ||
* Strategy for transition to string class syntax (incompatible to current double-quoted character vectors in Octave)? | * Strategy for transition to string class syntax (incompatible to current double-quoted character vectors in Octave)? | ||
** Issue treatment of escape characters (first interpreted when Xprintf is applied). | |||
*** https://www.mathworks.com/help/matlab/ref/string.html | |||
* Suggestion to implement an initial string class at one point | |||
** Many existing Octave code (packages) might break. | |||
** In the transition time using | |||
*** Octave .oct-config files to manage how double quoted strings are treated | |||
*** Implement convertStringsToChars and solve issue per function basis (Matlab compatible, probably straight forward, but many changes). | |||
**** https://www.mathworks.com/help/matlab/ref/convertstringstochars.html | |||
* Initial implementation by Andrew Janke | |||
** https://github.com/apjanke/octave-tablicious/blob/master/inst/string.m | |||
** http://blog.apjanke.net/2019/04/20/matlab-string-representation-is-a-mess.html | |||
=== Classdef === | |||
* Wish to define classdef classes from C++ "nicely" (currently only from m-files comfortable usable). | |||
* This would also help implementing the string class. | |||
=== C++17 === | === C++17 === | ||
Line 18: | Line 59: | ||
* Updates: https://octave.discourse.group/t/using-c-17-features/1026 | * Updates: https://octave.discourse.group/t/using-c-17-features/1026 | ||
* Allow using more modern C++ dialects (C++17 STL std::filesystem or boost::filesystem)? | * Allow using more modern C++ dialects (C++17 STL std::filesystem or boost::filesystem)? | ||
** qt6 requires C++17 https://www.qt.io/blog/qt-6.0-released | |||
** gcc 8.x (2018) still not C++17 feature complete (e.g. std::filesystem cannot fully be used, no benefit) | |||
*** https://en.cppreference.com/w/cpp/compiler_support#cpp17 | |||
*** https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 | |||
General consensus was to stay with C++11 until a "killer application" shows up that rectifies changing to a newer standard. | |||
=== Short introduction: SavannahAPI === | === Short introduction: SavannahAPI === | ||
Line 23: | Line 70: | ||
* Former [https://octave.discourse.group/t/remaining-items-for-the-6-1-release/350 "Release burn down chart"]. | * Former [https://octave.discourse.group/t/remaining-items-for-the-6-1-release/350 "Release burn down chart"]. | ||
* https://octave.space/savannah/ | * https://octave.space/savannah/ | ||
=== Bug Maintenance/Clean Up === | |||
:''The author of this topic did not attend the meeting. There was a short discussion about [[GSoC]] and the [[Short projects]] page.'' | |||
There are already ~1600 open bugs at 1 min/bug this is over 1 day. | |||
This is not manageable. Many of these could be closed: | |||
* Are complete because a new version is released {{bug|53576}} | |||
* Can be implemented since there is a new version {{bug|50820}} notice comments 24 & 25 | |||
* Maintainers have the function but have not submitted it {{bug|58530}} | |||
For preparing for [[GSoC]] it states to fix bugs, missing functions, etc. | |||
The ideal scenario would mean being inundated with fixes, and new functions. | |||
A maintained [[Short projects]] page would be necessary to avoid comments as in {{bug|32088}}. | |||
What is the best approach to resolving this? | |||
* <strike>A new wiki page</strike> so one with permission can see all the "easy closes". | |||
** Please reuse the [[Short projects]] page for this purpose, which is currently unmaintained. | |||
* Pinging bugs/patches for a status update. | |||
** Yes, always a good idea and this is basically what happens very slowly. It would be great to see more volunteers triaging the bug and patch trackers. | |||
== Previous topics == | == Previous topics == | ||
:''The following items were not discussed. Just some links to progress on those items are displayed.'' | |||
=== Octave 7 === | === Octave 7 === | ||
===== Improve graphics ===== | ===== Improve graphics ===== | ||
Line 48: | Line 117: | ||
* "Ditch" old UNIX system functions (e.g. popen) | * "Ditch" old UNIX system functions (e.g. popen) | ||
** https://octave.discourse.group/t/moving-posix-system-call-and-library-functions-out-of-core-octave/1027 | |||
** Move to package? | ** Move to package? | ||
* performance of symbol lookup | * performance of symbol lookup | ||
** use <code>std::unordered_map</code>, rather than <code>std::map</code> to increase performance (e.g. of interpreter lookups) | ** use <code>std::unordered_map</code>, rather than <code>std::map</code> to increase performance (e.g. of interpreter lookups) | ||
Line 56: | Line 125: | ||
** Some instances are more difficult to replace. jwe will post something about this on the discourse forum. | ** Some instances are more difficult to replace. jwe will post something about this on the discourse forum. | ||
* improve HDF5 integration | * improve HDF5 integration | ||
==== Documentation ==== | ==== Documentation ==== |