On Tue, 2026-03-03 at 19:35 +0100, Janneke Nieuwenhuizen wrote: > Janneke Nieuwenhuizen writes: > > Jonas Hahnfeld writes: > > > > and never got merged. So we've just been patching Guile ourselves (to > > > > create Windows binaries for Dezyne, for example). Recently, Jonas > > > > Hahnfeld managed to split that patch up in several bits, make fixes for > > > > lightening, and get it merged; lovely! > > > > > > I would like to clarify that I *did not* split up the patch because it > > > was entirely based on the concept of requiring and patching mini-gmp. > > > The merged changes work with upstream interfaces of GMP, at the expense > > > of a slightly slower conversion in case the value at run-time falls > > > between 2**32 and 2**64 and does not fit into long. > > > > Ah sorry, I totally missed that. But your patch still adheres to the > > requirement of having identical .go files for any 64-bit system, right? > > Hmm, I'm really puzzled now. In > > https://codeberg.org/guile/guile/pulls/90#issuecomment-9744014 > > I believe it's you (? I'm not all that great with these newfangled GUI > interfaces) who replies to my > > >> I'll be looking at that next for =wip-mingw-2026=, which interestingly, > >> "lacks" the huge x86_64-mingw32 commit that we've been working with for > >> years. > > with > > > AFAICT the commit has been split up, [..] > > What am I missing?
Yeah, rereading it now my comment is not quite understandable. What I'm trying to say is that the branch doesn't *lack* the huge x86_64-mingw32 commit but it's there is some smaller pieces and explaining how #22 is following a different approach.
signature.asc
Description: This is a digitally signed message part
