Online Developer Meeting (2022-07-26): Difference between revisions

← Older edit

Online Developer Meeting (2022-07-26) (view source)

Revision as of 19:37, 26 July 2022

723 bytes added , 26 July 2022

m

→‎Today's topics

Mmuetzel

Bureaucrats, Administrators

254

edits

@@ Line 5: / Line 5: @@
 * GSoC progress
-** '''Progress was presented by available mentors. Generally good. Some discussion on openlibm, accepted that negative results are also valuable.'''
+** Progress was presented by available mentors. Projects are on track.
-* VM progress?
+** Openlibm project concluded that the approach doesn't work. Valuable negative result!
-** '''Petter presented updates on his VM.'''
+** libtiff project will probably implement the classdef as an .m file. (At least the constructor, which is hard/impossible to implement in C++ code. It is not a "normal" DLDFCN). Will probably move from dld to core (libtiff dependency).
-** '''jwe prefers incorporating that into the default branch of Octave as soon as practical, and let it remain off by default unless the user wants to enable it with a configure switch or a runtime switch'''
+* When should a new function go to core or load dynamically?
-** '''This would be formed into an API for a generic VM approach to Octave that can be used for other VMs such as the Jitter one, etc'''
+** If the dependencies are already linked into Octave core -> No big benefit to have it dynamically loaded. More sensible to add in core.
+** If function loads a big (new) dependency, it might make sense to load it "on demand". --> dldfcn
+* VM progress:
+** Petter presented updates on his VM. Good progress. But still a lot to do.
+** will incrementally move from fork to default branch as an experimental feature with a configure option to disable it.
+** will most likely not be active by default in Octave 8 (either not compiled or de-activated on run-time)
+** won't stop the option for alternative VM implementations. Might help to define an "API" for other VM implementations (like Jitter, etc).
+* Release process for Octave 7.2:
+** About 10 (actual) changes since the last release candidate (about 6 weeks ago). Should we make a second release candidate?
+*** No new release candidate. Proceed with a release after some final preparations (e.g., NEWS file).
+** Not much feedback for the first release candidate. Should we skip making release candidates entirely and directly make releases? Should we announce them more prominently (e.g., on the web page)?
+*** Call for ideas.
 * Octave packages progress update
 * Managing diversity of libraries (libm, libc etc)
 ** See [https://octave.discourse.group/t/point-of-openlibm-project-or-if-even-julia-wants-to-shift-away-from-openlibm-do-we-want-to-use-it/2980/  background]
-* Release process for Octave 7.2:
-** About 10 (actual) changes since the last release candidate (about 6 weeks ago). Should we make a second release candidate?
-** Not much feedback for the first release candidate. Should we skip making release candidates entirely and directly make releases? Should we announce them more prominently (e.g., on the web page)?
 * Octave 7.3 and 8 timeline?