Developer Meeting Agenda 2026-09-27 - 20:00 CEST

[grandixximo]

According to our bi-weekly schedule alternating between "early" and "late", this video meeting is next Sunday 2026-Sep-27 at 20:00 CEST.

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=9&day=27&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136&p5=165&p6=256

I will not be able to attend this one. Anything on my PRs can go in the PR threads and I will pick it up the next day. Please write the conclusions into this agenda as usual.

Agenda

1. hal: Break the HAL API - Move to 64-bit exclusively #4565 HAL API break, 64-bit only. The big one from the plan agreed last meeting (item 4 of Developer Meeting Agenda 2026-09-13 - 10:00 CEST #4497). Two review rounds done, everything raised is fixed on the branch; it went conflicting after the 2.9 merge (Merge 2.9 into master #4575) and needs a rebase. Points to settle:
   • Testing status on real hardware. Who has run the branch on what? So far RPi5 + 7I96S + Modbus by @BsAtHome. The Tcl side had two real regressions (hal_procs_lib.tcl netlist, halconfig.tcl), both fixed; Tcl 8.6 still uses a 32-bit internal representation (64-bit only in Tcl 9), so Tcl configs deserve a look.
   • Merge criteria and timing. Do we merge as soon as CI and a few hardware reports are green, or wait for a fixed date?
   • ~pre2 version bump and tag. @BsAtHome holds the bump for the docs PR and wants to tag the tree once all the changes are in, so the CI packages carry the right version. See also item 7.
   • Docs PR follows separately (per the PR description). Order of merge relative to the code.
   • Config migration tooling: hal: Add halfileupdate to convert HAL configuration files #4499 (halfileupdate) is draft until the renaming is settled, which hal: Break the HAL API - Move to 64-bit exclusively #4565 settles. Same for hal: Add halcompupdate to migrate .comp files to the new HAL API #4256 (halcompupdate). Do we want these in before or right after the break so users are not left without a converter?
   • hm2_modbus .mbccb files need recompiling from .mbccs after the break; where do we tell users (release notes, NEWS, docs)?
   • After the merge: many hal_[gs]et_[us]i32() remain, the tree is not 64-bit clean yet. That is the third phase from last meeting; who takes which components?
2. Signed vs unsigned integers in HAL, discussion The unsigned integer question #4526. The thread has narrowed a lot, so what is left is a set of yes/no decisions rather than a debate:
   • lut5.0.function and hm2 raw.write-data are out of the argument: a param and a debug hatch, neither netted.
   • Nothing on the table loses bits on sint. A u64 register keeps every bit on a signed pin; what uint buys is semantics and a guard at protocol boundaries (hm2_modbus register images, and cia402.comp netting the CiA 402 statusword and controlword as bit patterns between two separately maintained components). Do we keep uint?
   • Cross-netting inside the integer class: make a bool/sint/uint mismatch a warning instead of an error, signal type still fixed by newsig or the first pin of net, never following later pins. @BsAtHome is not against it; agreed in the thread that the converters stay and that the writer-flag clamp idea is dropped.
   • hal_get_bool() reads _b while hal_set_bool() writes _u, so on a big-endian machine every bool reads false. The double negation over the full word that the cross-net change needs also fixes this.
   • NaN policy. The conv_real_* converters get replace_nan / replace_inf_positive / replace_inf_negative pins, clamp_ disappears from the real to int direction because there is no wrap to offer, and @BsAtHome proposes the conversion components stop being generated and become static. @rene-dev's FPU invalid-operation flag catches conversions and ordered comparisons but not a NaN that is only copied. Who writes which piece, and does any of it block hal: Break the HAL API - Move to 64-bit exclusively #4565?
3. Branch protection, discussion Branch Protection #4558. "Require branches to be up to date" was turned off again. Do we make rip-and-test (or more) a hard requirement, or keep CI as a strong signal with an escape hatch for infrastructure flakes? Also consideration withe some devs discontent see qtplasmac: fix conversational circle M3 vs M03 bug #4580 and Chris on the mailing list.
4. Include layout, include: use angle brackets for exported headers, and check it #4375 and include: move the exported headers into a directory of their own #4461. Last meeting decided to move all includes after the 64-bit migration. Confirm the order: hal: Break the HAL API - Move to 64-bit exclusively #4565 first, then include: move the exported headers into a directory of their own #4461, then the angle-bracket check include: use angle brackets for exported headers, and check it #4375.
5. Wayland. gremlin: host the GTK preview on Gtk.GLArea without GLX #4538 hosts the GTK gremlin on Gtk.GLArea without the GLX dlopen hack; @alex-pres reports pncconf and gremlin run on Weston with it, which makes Wayland fix (namely pncconf's sample panel) #4523 unnecessary (and answers issue PYOPENGL_PLATFORM=glx must be set if using Wayland (pncconf) #4522). The remaining X11-only pieces are GtkSocket in gmoccapy and everything Tk. Do we want a tracking issue for native Wayland?
6. hostmot2 driver fixes, fix safety and correctness bugs in hostmot2 drivers #4488 by @sleepybishop. @BsAtHome asked for a split (sserial and abs_encoder need hardware testing, pktuart/eth can go in a first batch). The author is waiting for guidance on how to split. Can we give a concrete list?
7. Package version in CI artifacts, issue CI build artifacts on master have wrong version #4555. Master builds are labelled 2.10.0~pre0 because the 2.10.0~pre1 tag was never pushed, and scripts/get-version-from-git returns v2.9.8-* if not run from master branch #4030 is the same problem. Decide what determines the version: the VERSION file, with the commit hash appended how? @BsAtHome offered a patch. This needs settling before the ~pre2 tag in item 1.
8. hm2_eth read timeouts on real hardware, issue hm2_eth read timeout #4525. Bisected at the Stuttgart meeting to one line in dd68759. @pcw-mesa reproduces a timeout per second with deliberate packet loss and sees no practical harm, @hdiethelm has branches to test. Question for the meeting: what is the intended behavior on a dropped packet, and does this hold anything for 2.10?
9. Homing. Three PRs from the Master: Homing gantry fails on every other attempt #4572 investigation, all tested on @Sigma1912's gantry:
   • homing: stop the correct joints when aborting a homing sequence #4574, one line: HOME_ABORT indexes through a pointer that is already offset, so an abort from joint N stops joints N and up, and past eight joints it writes off the end of the array. Independent of the other two.
   • homing: run every leg of a synchronized home sequence together #4577, a negative HOME_SEQUENCE only synchronized the final move, so search, back-off and latch ran per joint and each leg racked the frame. This runs every leg of the group together.
   • homing: bound the homing moves, return from a failed latch move #4578, homing moves are planned to twice the joint travel, so a dead or stuck switch drives into a limit or into the table at search speed. This bounds them from HOME_SEARCH_DIST and HOME_LATCH_DIST and returns from a failed latch.
   • homing: run every leg of a synchronized home sequence together #4577 and homing: bound the homing moves, return from a failed latch move #4578 both rewrite the same part of homing.c, so the order matters. Also issue HOME_OFFSET is doing double duty #4527: HOME_OFFSET is doing double duty and is not documented as the code behaves, which blocks absolute-encoder machines that also have home switches.
10. ini parser identifiers vs the xhc-hb04 pendant, inifile: accept dash in section and variable identifiers #4573. The new ini parser restricts identifiers to letters, digits and underscore; that broke the xhc-hb04 sample configs (dashed [XHC_HB04_BUTTONS] keys like start-pause) and the pendant comp's own layout cfg files ([XHC-HB04] section). @BsAtHome: dropping the dash was intentional, the pendant was missed. Options: accept the dash again (inifile: accept dash in section and variable identifiers #4573 restores the old behavior, currently draft), or deliberately rename all pendant identifiers to underscores with migration coverage for INI keys, layout cfg files and HAL pin names (xhc-hb04.button-start-pause), in line with the other 2.10 breaks (hal: Break the HAL API - Move to 64-bit exclusively #4565). Decide direction. This also gates Remove Tcl from sample configs #4524: the pendant configs are the first Tcl-generated ones to flatten, that is where the dash question came up, and the flattening is on hold until this is settled.
11. PRs
    See PRs for merge/comments.
    • feat(rs274ngc): add ROTARY_MODULO axis mode #3969 ROTARY_MODULO: open for review since Aug 16, no review yet.
    • Add Support for Dogbone Homing #4009 dogbone homing: @sundtek and @dirkx are testing on hardware this week; the branch now conflicts with master.
    • halcompile: reject declarations that claim the same HAL name #4298 halcompile duplicate HAL names: every review point addressed on Sep 22, Error() now goes through the normal reporter. Ready from my side.
    • tp: keep the G33 sync origin on the spindle index #4453 G33 sync origin on the spindle index: rebased Sep 13, consecutive G33 verified unchanged, ready to merge.
    • hm2_eth: Xenomai4 OOB improvements #4503 hm2_eth Xenomai4 OOB: tested by @zz912, initf hm2_eth.realtime-init no longer needed. Two-board case untested. hm2_eth: Create support library's #4498 (hm2_eth support libraries) is the design discussion with @BsAtHome about exporting the API from the existing posix/xenomai libraries instead of new .so files.
    • axis: read the program the config opens once the HAL is whole #4507 axis: read the config's program once the HAL is whole. No review yet.
    • Add spindle angle offset (D word) for G33 and G76 threading #4519 spindle angle offset (D word) for G33/G76: Fix spindle position-sync jitter and catch infeasible thread pitches #4441 is in, tp: keep the G33 sync origin on the spindle index #4453 is not; rebase after tp: keep the G33 sync origin on the spindle index #4453 lands.
    • hal, gmoccapy: a SIGTERM during startup no longer leaves the GUI running #4532 hal, gmoccapy SIGTERM during startup: @BsAtHome's os._exit() concern addressed, timer gone. Ready to merge.
    • Fix invalid escape sequences in holecircle and plasmac2 #4536 invalid escape sequences in holecircle and plasmac2: trivial, ready to merge.
    • gremlin: host the GTK preview on Gtk.GLArea without GLX #4538 gremlin on Gtk.GLArea: needs testers on different GPUs and drivers before merge.
    • interp: G43.4 and G49 as spellings over the kinematics switch #4548 G43.4 and G49 over the kinematics switch: rebased on the merged task: a kinematics selection is seen on the next line, and the test reads it there #4563/tests: kins-switch holds the joints from the program's own switch to identity #4564, C-linkage remark addressed, mergeable.
    • kinematics: a Jacobian entry point, supplied by every module #4550 kinematics Jacobian entry point: @BsAtHome's memset and docs points folded in, pumakins and three21kins now register closed forms so nothing in tree answers through central differences. Ready.
    • twp: split the machine maths out of the tilted work plane remap #4551 twp remap split: @BsAtHome's questions answered, mergeable.
    • Draw (WORKPIECE,...) stock as a translucent solid #4552 WORKPIECE stock as translucent solid: liked by @andypugh and @hansu, keys renamed to OD and ID as suggested.
    • gcode: estimate how long a program takes during the parse #4554 program time estimate during parse: under test, question on what the display shows after an error or a stop.
    • hal: Break the HAL API - Move to 64-bit exclusively #4565 HAL API break: see item 1.
    • homing: stop the correct joints when aborting a homing sequence #4574, homing: run every leg of a synchronized home sequence together #4577, homing: bound the homing moves, return from a failed latch move #4578 homing: see item 9.
    • Honor [AXIS_<letter>] TYPE in the interpreter, canon and motion #4581 [AXIS_<letter>] TYPE honored in the interpreter and canon, plus a new [TRAJ] FEED_AXES. A config whose TYPE contradicts the letter changes behavior, which is the point, but it is a behavior change: worth a note in the 2.10 release notes. @BsAtHome has one review comment open.

[hdiethelm]

Short comment on 8. hm2_eth read timeouts on real hardware, issue #4525

dd68759 does not drop any more or less packages than before, at least not intentionally. It only changes the timeouts from polling recv with 10us interval to using ppoll, reducing the CPU load noticeably.

A noticeable difference I introduced is a message that shows receive timeouts, so it makes timeouts visible. All other logic already existed and was not changed.

Reducing the CPU load or using ppoll could have unanticipated issues on specific PC's, this is the reason for the test branches in case someone can reproduce this.

But it could also simply be that making the timeouts visible gave a false positive while bisecting.

If desired, I can join the meeting.

[grandixximo]

You are welcome to join, not sure who else is going to be present, it's too late for me... @BsAtHome is most probably going to be there, worst case scenario you can have a nice chat with him ;-)

[BsAtHome]

If desired, I can join the meeting.

If you can, please do. It is often easier to talk about a problem than to read about it.

[snowgoer540]

With regard to #3, I apologize, as I won’t be able to attend the meeting. I know I wasn’t asked to attend - I found out about it through the developer email chain on the SourceForge website - but I wanted to at least have some representation, particularly since it appears that others may be coming into the discussion with an established agenda.

What most concerns me is not that Chris made a perceived mistake (he did have plenty of discussion surrounding the changes from what I saw). Mistakes happen, and I have no objection to discussing how changes to the project should be reviewed going forward. What concerns me is the way a long-time contributor to this project has been treated as a result.

There are not many active developers left on this project, and there are even fewer who have been around long enough to understand the history and context behind the code. That institutional knowledge has value, and I don't think it should be dismissed.
I also find the response to Chris' mistake difficult to reconcile with the history of the project. The person who enabled branch protection and reverted the changes unilaterally has himself committed a number of very large changes to the codebase with little or no advance discussion, and in some cases those changes subsequently sat for a year or more with significant issues still outstanding. None of those changes went through a PR.

For some examples, look at the discussion surrounding commits 7ebe7d9, 9d79c2a, 9a45ed9, and 13b52cb. The point isn't to dredge up the past, it is to point out that the standard now apparently being applied to Chris’ commits only seems to apply since someone didn’t like having their toes stepped on.

I am certainly not opposed to code review. I have opened plenty of PRs for changes where I wanted another set of eyes. I also have commits where I discussed the changes with other developers privately before committing them. I have no problem with review when it is actually useful and appropriate. Collaboration definitely moves things forward.

What I do object to is changing the rules without discussion and then treating someone as though they violated an established process when that process did not previously exist or was not previously enforced.

There is also a long-standing precedent for having a maintainer responsible for a particular portion of the project. As long as I have been contributing, GUIs have effectively operated that way. The users generally do not care whether a particular GUI feature was implemented through a PR, a direct commit, or some other mechanism. They cared that the feature worked and that bugs were fixed.
For issues in the main portion of the project, changes were generally handled through PRs, or by the person responsible for that particular section of the code. That division of responsibility existed for a reason: people who maintain a particular part of the project develop an understanding of its history, architecture, and the consequences of seemingly small changes.

If the project now wants to move to a different development model, I am willing to discuss that. But I don't think it is reasonable to silently change the process, apply it retroactively, selectively, and then use someone's mistake as justification for the change.

[grandixximo]

Agree with the sentiment here, the discussion is still ongoing in the mailing list as well.

https://sourceforge.net/p/emc/mailman/emc-developers/

Reading @rene-dev messages, he made the change on the basis that it was implicitly already agreed by all devs, that assumption turned out to be wrong, my stance FWIW is that the restriction should be rolled back, and the discussion moved forward, possibly on the mailing list or on #4558 a discussion I opened for that purpose, or in a live meeting which could be organized at other times to fit the schedules of the effected devs...

The most visible portion of the discussion seems to be on the mailing list, I'd suggest you also post this there for more visibility.