Hi Steffen, Thank you for the feedback and the practical guidance on the integration path, it is much appreciated.
On the name: I have to admit "scatti" is my favourite too, and for what it's worth, it is not just a translation, in Italian, "scatto" literally means a jerk, a sudden movement, which is exactly the quantity the library controls. It may be the right name once the project moves to a team-maintained home. As for progress: my colleague YangYang has already completed the C port. The repository is here: https://github.com/mika4128/cruckig A few highlights from the two days of work: - Pure C99, zero external dependencies - 100% correctness match against the original C++ Ruckig across ~100,000 random trajectories (timing differences at machine precision) - Slightly faster than the C++ version at equivalent optimization levels - .deb packaging already in place (runtime and dev packages) - Python and Rust bindings included - v0.1.0 tagged The next steps are: 1. Test on an actual RTAI system to confirm it builds and runs cleanly in that environment, this is the critical validation we still need 2. Integrate into LinuxCNC, following your suggestion of bundling it first and extracting it as a proper dependency once the Debian packaging has matured We will report back once we have RTAI test results. Best regards, Luca On March 28, 2026 8:05:45 AM GMT+08:00, "Steffen Möller via Emc-developers" <[email protected]> wrote: > >Hello, >.... >> To that end, I'd like to propose creating a C port of Ruckig, >> tentatively called cruckig, maintained as a separate repository. The >> upstream Ruckig library is mathematically stable and well-tested at this >> point; activity there is mostly wrapper updates, not algorithmic >> changes. A C port would be safe to stabilize and maintain independently. > >I cannot judge the feasibility of your endeavour but I can tell that you >need a better name. Also, I expect that the source tree will diverge >quickly from its reference - so why stick to it. > >How about "cont" - for "continuous", obviously. I also like >"screech" (for the sound that the system makes when the library goes wrong, >along the idea of what ruckig means). Or just translate it to "scatti". > >> A few open questions I'd welcome input on: >> >> 1. Would it make sense to host this under the LinuxCNC organization, >> something like https://github.com/LinuxCNC/cruckig? > >Any would do. But I suggest you start with your personal repository and at >some point transfer it to a team maintained one - like that of LinuxCNC. This >can be done any time. > >> 2. On the integration path: should cruckig be bundled inside LinuxCNC >> first (similar to how Ruckig is now), go through the Debian packaging >> process in parallel, and then be extracted as a proper dependency once >> packaged? Or is it cleaner to pursue the separate repo and Debian >> package from the start, and only integrate it as a dependency once that >> is in place? > >I suggest to have it as a stable repository somewhere. Debian can then use >that as a root of its packaging and LinuxCNC can always have it as a >git submodule until it has arrived in the various Linux distros. > >> 3. I have not personally gone through the Debian packaging process, so >> I'd welcome guidance on what that realistically involves and whether the >> phased approach is standard practice or just added complexity. > >It can ship with LinuxCNC as a start and then be extracted. > >> Looking forward to hearing your thoughts. > >I had no deeper look at ruckig. So I cannot tell about how difficult it will >be. >But do not worry about how to integrate it. Since LinuxCNC will need >the backports anyway, and will need it faster than Debian has a new package >backported, >I am confident that it will all be an integration with LinuxCNC first, just >like it is now. > >Best, >Steffen > > >_______________________________________________ >Emc-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
