gfan 0.7 #238
gfan 0.7 #238
Conversation
mahrud
force-pushed
the
gfan
branch
2 times, most recently
from
3a454ee to
947eb46
Compare
Formula/gfan.rb
Outdated
| + for(int i=0;i<v.size();i++)if((ret=v[i]))break; | ||
| if(ret<0)ret=-ret; | ||
| assert(ret!=0); | ||
| for(int i=0;i<v.size();i++)ret=gcdGFAN(ret,v[i]); |
There was a problem hiding this comment.
This patch contains the contents of M2/libraries/gfan/patch-0.6.2, right? Do we know why these changes are necessary? I've only needed the <cstdint> patch for the Debian gfan package to build.
There was a problem hiding this comment.
No, a few things have changed.
There was a problem hiding this comment.
You're right that the patches seem excessive. I'll look into whether the exit(1)s were necessary to fix something in the package.
There was a problem hiding this comment.
Yeah, basically Dan wanted error signals it seems:
Macaulay2/M2@f088148#diff-bd52196e0826f3b0c95eb09f00bc87f1bfedb2c4752f017a631ec6517d28477e
There was a problem hiding this comment.
Those exit's aren't in the Debian/Ubuntu, Fedora, or Gentoo gfan packages.
There was a problem hiding this comment.
Probably the package should be updated to reflect this ...
There was a problem hiding this comment.
I don't understand the point of the exit's. They all appear in something like this:
assert(0);
exit(1);But assert(0) will always abort the program, so we never even reach the call to exit.
There was a problem hiding this comment.
Yeah, I think once the int128 issue is resolved I'll just remove the exits.
mahrud
force-pushed
the
gfan
branch
3 times, most recently
from
d35ccbf to
0de9588
Compare
| template <> struct MyMakeUnsigned<int>{typedef unsigned int type;}; | ||
| template <> struct MyMakeUnsigned<long int>{typedef unsigned long int type;}; | ||
| + template <> struct MyMakeUnsigned<long long int>{typedef unsigned long long int type;}; | ||
| template <> struct MyMakeUnsigned<__int128>{typedef unsigned __int128 type;}; |
There was a problem hiding this comment.
I'm not sure if this makes sense. It seems like support for __int128 is patchy and on some systems it's just long long int, at least that's my guess from errors like
src/gfanlib_circuittableint.h:617:57: error: invalid use of incomplete type 'struct gfan::MyMakeUnsigned<long long int>'
617 | typename MyMakeUnsigned<longword>::type positiveResultBoundTimesD=extMul(negabs(s).v,boundA.v);
| ^~~~~~~~~~~~~~~~~~~~~~~~~It's a mystery to me why having both declarations makes the compiler happy, but I hope it's not introducing an overflow bug.
There was a problem hiding this comment.
These new __int128's are giving me lots of problem in the Debian package, too -- gfan won't even build on 32-bit systems any more.
|
I can't reproduce the build errors at home. @mikestillman can you try building the new gfan on macos-14 and giving me the patch that works for you? |
mahrud
force-pushed
the
gfan
branch
18 times, most recently
from
890a89f to
95d9f2d
Compare
|
@d-torrance I think I figured how to get all these builds to finish at once. It may help with the Ubuntu builds. |
No description provided.