IRC channel logs
2025-02-19.log
back to list of logs
<rlb>And finally, I don't recall enough about gmp (been a good while), but I wondered if there were reasons we'd had the more complex code (unless those early commits weren't just "necessary" clean up) -- some of the numerics iirc goes to lengths to be more efficient (and calls more specific functions), even when it requires messier logic. <rlb>I mean, unless the simplification wasn't also just a side effect of changes made necessary by the other work. <rlb>(Oh, and if we're changing it to pack two ints into one for w64 (not positive), then given that both types uintptr_t and unsigned long are "integral", I wondered what the chance was that we might have missed cases (if the compiler won't notice) where we're still treating the value like an integer rather than two ints...). If there's a concern, suppose you could double-check by temporarily changing it to a non-integral struct or <rlb>something with accessors, and find everywhere the compiler crashes.) <rlb>Wait, could we just switch to uint64_t? i.e. if that's what we really mean? <rlb>Anyway, I didn't do a complete review (nor finish looking at all the code), just enough to wonder about all that. <daviid>rlb: it would be nice, as time allows ofc, if you could answer the bug-report with 'all the above' remarks. this will let them know, they may come with solutions, they have (lilypond) a few guile/C wizards there ... if you do, thanks! <daviid>you could answer their last 'gentle ping' <daviid>fwiw, we had a great package using guile as well, zrythm, but they recently dropped guile entirely, and they told me, just afew weeks ago, that this was because of the lack of support on ouindoze - i was about to suggest they port to g-golf, but they also moved to use Qt, for the exact same reason (so they told me the - the GNOME team says their libs build fine 'there', and meson is 'cool', the zrythm author claimed the opposite along