OK, flint-1.0.1 is available now at http://www.flintlib.org/
With any luck this fixes all the issues we've found.
The only changes are the bug fixes and some corrections and omissions
for the manual.
Bill.
On 7 Dec, 16:29, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Dec 7, 10:41 am, B
On Dec 7, 10:41 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> Sounds sensible. I'll get to work on making that new tarball as soon
> as I get back from Real Job TM.
>
:)
> In the meantime it would be great to hear if changing the u_int64_t's
> to uint64_t's and changing the #includes actually fix
On Dec 7, 5:51 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> This bug is quite possibly not in FLINT, but in GMP or even gcc
> itself. I use "static inline" throughout FLINT (earlier revisions did
> not, but I fixed this before FLINT 1.0) because the rules for "static
> inline" are the same in the c9
On 7 Dec, 03:07, Carl Witty <[EMAIL PROTECTED]> wrote:
> On my 64-bit x86 Debian testing Linux box, running a prerelease of gcc
> 4.3, compilation failed, because gcc 4.3 in "-std=c99" mode switches
> to the standard meaning of inline, instead of the traditional gcc
> meaning. I've posted a com
Sounds sensible. I'll get to work on making that new tarball as soon
as I get back from Real Job TM.
In the meantime it would be great to hear if changing the u_int64_t's
to uint64_t's and changing the #includes actually fixes it so it
compiles out of the box on SPARC32.
I think it probably shou
On Dec 7, 10:21 am, Bill Hart <[EMAIL PROTECTED]> wrote:
Bill,
> Michael, if you want to fix the bug in the code you have in SAGE
> without getting the new tarball tonight, simply replace the 64 with
> FLINT_BITS on line 291 of fmpz_poly-test.c
I will do that and see if the tests pass.
>
> I'v
Michael, if you want to fix the bug in the code you have in SAGE
without getting the new tarball tonight, simply replace the 64 with
FLINT_BITS on line 291 of fmpz_poly-test.c
I've checked that this bug is not a problem elsewhere in that file.
Also you'll want to replace those handful of u_int64
Ouch, the problem is solved. In fact this test will fail on *all* 32
bit machines. There is a really silly bug in the test code itself. The
function it tests is most likely fine.
So this is definitely a bug. I will issue FLINT 1.01 this evening,
fixing this and the other problems we've noted.
Th
On Dec 7, 10:08 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote:
Bill,
I will write that test program you asked for in the next couple hours.
The sparc box is 64 bit, I am just compiling in 32 bit mode. If I find
some time I will build in 64 b
On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote:
> On my 32-bit x86 Debian testing Linux box, looking at install.log, one
> test failed:
> Testing _fmpz_poly_max_bits1()... FAIL!
> (All other FLINT tests passed. The build is still running, so I don't
> know whether Sage doctests will p
Ah I just found another problem. Although c99 requires stdint.h to
define these things, I am including sys/types.h which is not the
accredited cross platform solution. I apparently consulted a dodgy
document on the web which gets this wrong. On many systems sys/types.h
#includes stdint.h, but appa
On 7 Dec, 04:30, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Dec 7, 12:02 am, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > You hopefully mean uint64_t, not u_int64_t. There should be no
> > occurrences of u_int64_t left in FLINT. If that's not the case, please
> > let me know.
>
> [EMAIL
On Dec 7, 12:02 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> You hopefully mean uint64_t, not u_int64_t. There should be no
> occurrences of u_int64_t left in FLINT. If that's not the case, please
> let me know.
[EMAIL PROTECTED] flint-1.0$ grep -r u_int64_t *
src/long_extras.c:static u_int64
On Dec 7, 4:07 am, Carl Witty <[EMAIL PROTECTED]> wrote:
> On Dec 6, 12:43 pm, mabshoff <[EMAIL PROTECTED]
>
> dortmund.de> wrote:
> > Please touch devel/sage-main/sage/libs/flint/fmpz_poly.pyx and do a
> > "sage -b", otherwise the flint doctests will fail. The spkg runs the
> > FLINT test suite
On Dec 6, 12:43 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> Please touch devel/sage-main/sage/libs/flint/fmpz_poly.pyx and do a
> "sage -b", otherwise the flint doctests will fail. The spkg runs the
> FLINT test suite per default, so please report success as well as
> failures here, toge
It looks to me like a short is 16 bits and a long is 32 bits on
SPARC32. But even finding documentation online which gives this
information is difficult.
Bill.
On 6 Dec, 23:02, Bill Hart <[EMAIL PROTECTED]> wrote:
> You hopefully mean uint64_t, not u_int64_t. There should be no
> occurrences of
You hopefully mean uint64_t, not u_int64_t. There should be no
occurrences of u_int64_t left in FLINT. If that's not the case, please
let me know.
Also, if uint32_t is not available in 32 bit mode, your compiler is
either not c99 compliant or the machine does not have both a native 32
bit type an
Okay, two things:
1) I would love to get some feedback from Linux/Itanium with this
since we have an open ticket for that.
2) The test suite failed on Solaris 9/Sparc in 32 bit mode. I ran it
three times and it was always the same failure:
Testing _fmpz_poly_max_bits1()... FAIL!
At least one
18 matches
Mail list logo
