Tue 2020-04-28 22:49:09 UTC, Cactus:
>
> On 28/04/2020 23:28, 'Bill Hart' via mpir-devel:
> > You may be right, but I don't see where your files are in our repo:
> >
> > https://github.com/wbhart/flint2
> >
> > [...]
> >
> > Perhaps you could open a ticket with your observations on my Flint repo?
On Tuesday, 28 April 2020 23:49:09 UTC+1, Cactus wrote:
>
> On 28/04/2020 23:28, 'Bill Hart' via mpir-devel wrote:
> > You may be right, but I don't see where your files are in our repo:
> >
> > https://github.com/wbhart/flint2
> >
> > This would be better discussed on the flint list as Isu
On 28/04/2020 23:28, 'Bill Hart' via mpir-devel wrote:
> You may be right, but I don't see where your files are in our repo:
>
> https://github.com/wbhart/flint2
>
> This would be better discussed on the flint list as Isuru Fernando could
> chime in. He understands CMake much better than I do. I
You may be right, but I don't see where your files are in our repo:
https://github.com/wbhart/flint2
This would be better discussed on the flint list as Isuru Fernando could
chime in. He understands CMake much better than I do. I don't want to make
assertions about it, as they often prove to be w
On Tuesday, 28 April 2020 23:09:02 UTC+1, Cactus wrote:
>
> On 28/04/2020 22:48, 'Bill Hart' via mpir-devel wrote:
> > They both take about 0.6s with our continuous integration. I don't know
> > if @tthsqe12 would expect them to randomly hit a really hard case?
> >
> >
> https://ci.appveyor.
On 28/04/2020 22:48, 'Bill Hart' via mpir-devel wrote:
> They both take about 0.6s with our continuous integration. I don't know
> if @tthsqe12 would expect them to randomly hit a really hard case?
>
> https://ci.appveyor.com/project/wbhart/flint2/builds/32491737/job/1os2ex9o3pe53bhe
>
I was un
On Tuesday, 28 April 2020 15:51:06 UTC+1, Cactus wrote:
>
> On 28/04/2020 15:44, 'Bill Hart' via mpir-devel wrote:
>
> > That's great news, thanks Brian.
>
> I fear that I have reported a complete pass too early as I missed the
> fact that my test code had to abort two tests after running for
They both take about 0.6s with our continuous integration. I don't know
if @tthsqe12 would expect them to randomly hit a really hard case?
https://ci.appveyor.com/project/wbhart/flint2/builds/32491737/job/1os2ex9o3pe53bhe
Bill.
On Tue, 28 Apr 2020 at 16:51, Brian Gladman wrote:
> On 28/04/202
On 28/04/2020 15:44, 'Bill Hart' via mpir-devel wrote:
> That's great news, thanks Brian.
I fear that I have reported a complete pass too early as I missed the
fact that my test code had to abort two tests after running for too long
(over 120 seconds). These are:
fmpq_mpoly/t-gcd.exe
fmpq_m
That's great news, thanks Brian.
Bill.
On Tue, 28 Apr 2020 at 15:58, Brian Gladman wrote:
> On 28/04/2020 00:06, Bill Hart wrote:
> > Dear Brian,
> >
> > MSVC 32 and 64 bit are now completely passing in out continuous
> > integration with our trunk branch.
> >
> > Could you possibly test this a
On 28/04/2020 00:06, Bill Hart wrote:
> Dear Brian,
>
> MSVC 32 and 64 bit are now completely passing in out continuous
> integration with our trunk branch.
>
> Could you possibly test this and see if it works for you. We are of
> course using CMake to generate the build files and I know you have
That's interesting. You have different errors with MSVC than we do.
We don't see this but we do see a different error.
On Tue, 21 Apr 2020 at 20:14, Brian Gladman wrote:
> On 21/04/2020 16:50, 'Bill Hart' via mpir-devel wrote:
> > Isuru reinserted the necessary line FLINT_DLL const unsigned int
On 21/04/2020 16:50, 'Bill Hart' via mpir-devel wrote:
> Isuru reinserted the necessary line FLINT_DLL const unsigned int
> partitions_lookup[128];
>
> Perhaps you could check if this works for you now.
It builds fine. The tests give one error:
1523 tests
Isuru reinserted the necessary line FLINT_DLL const unsigned int
partitions_lookup[128];
Perhaps you could check if this works for you now.
Bill.
On Tue, 21 Apr 2020 at 17:26, Bill Hart wrote:
> Hi Brian,
>
> Isuru Fernando believes he may have found the issue. I'll try reinserting
> the expor
Hi Brian,
Isuru Fernando believes he may have found the issue. I'll try reinserting
the export as soon as we fix some other issues and see if it passes again.
For example, the fmpz_poly_factor test hangs at present. We haven't been
able to figure out why.
We are using MSVC files built by CMake I
On Tuesday, 21 April 2020 00:28:28 UTC+1, Bill Hart wrote:
>
> Hi Brian,
>
> After making these changes, our cmake continuous integration fails. I
> think the problem is with this line:
>
> FLINT_DLL const unsigned int partitions_lookup[128];
>
> Is this only relevant for MSVC?
>
> Bill.
>
Good
Hi Brian,
After making these changes, our cmake continuous integration fails. I think
the problem is with this line:
FLINT_DLL const unsigned int partitions_lookup[128];
Is this only relevant for MSVC?
Bill.
On Tue, 21 Apr 2020 at 00:37, Bill Hart wrote:
> Hi Brian,
>
> I have fixed the thre
Hi Brian,
I have fixed the three issues you pointed out to do with building an Arb
dll. Thanks very much for pointing these out.
As for the flint dll, I don't mind what name is used. It's not a problem
for me. This is technically flint2, not flint. But it is very many years
since anyone has used
Hi Bill and Fredrik,
Being in CORVID lockdown, I decided to have a look at building Arb with
Visual Studio. This has gone pretty well but I have a few issues on
which I would appreciate your advice.
I can compile and build Arb as a static library without any issues but
building Arb as a DLL fails
19 matches
Mail list logo
