Release a new version

[ryandesign]

A user reported to MacPorts that libticables2 1.3.5 (the latest version published on SourceForge in 2016) does not build on Apple Silicon Macs.

It appears this was fixed in ef41c51 (in 2021).

Perhaps it is time to release a new version?

[debrouxl]

The time to release a new version is indeed nearing, slowly. I pushed forward some patches to that effect about a month ago, nearly half of the patches which shouldn't require much in the way of rework.

MacPorts could apply this single fix onto libticables2 1.3.5, or better, package a snapshot of the Git repository, like multiple Linux distros :)

[ryandesign]

MacPorts could apply this single fix onto libticables2 1.3.5,

We already did!

or better, package a snapshot of the Git repository, like multiple Linux distros :)

We generally discourage that. We don't feel it's our responsibility to investigate and be responsible for whether a particular upstream commit constitutes a stable release. We prefer that developers make that determination and take over that responsibility by issuing stable release versions.

[eli-schwartz]

Any status update?

[debrouxl]

Well, I push things forward a bit once in every while :)
As far as this repo is concerned, I still need to spend time implementing the unwrap command for tifileutil, which will clear the way for the first commits of the experimental2 branch, up to the Nspire models split + CX II initial support commit.
Beyond that, down the experimental2 branch, the lab equipment support commit is a more serious roadblock: the first iteration of the API wasn't that good, but the second one needs more work, starting with a rebase and therefore nontrivial conflict resolution...

[eli-schwartz]

Thanks for clarification. I was trying to investigate https://bugs.gentoo.org/927586 / https://bugs.gentoo.org/862381 to see if they are still relevant for the current code in git but this is easier with releases...

[debrouxl]

Looks like 927586 was fixed relatively quickly after 1.18 (by c8bdc69 ), though I don't remember whether it was detected by a toolchain or I simply fixed it when widening the key code to 32 bits. It's an ABI break, but known libti* clients are FLOSS and can be recompiled anyway.
That TIEmu keeps building on modern toolchains is amazing, though the standard version is much less fragile. Prototype mismatch fixes belong upstream.

[eli-schwartz]

Nice.

Based on a quick eyeball of src/gui/debugger/dbg_data.{c,h} it looks like tiemu still has at least some problems. I can open a bug report for it in a bit.

(All I did so far to resolve the bug was disable LTO a.k.a. "massively global optimization pass that tickles UB into becoming miscompilations" while preparing to investigate further.)