Jason,
If I add *-apple to line 1107 of configfsf.sub will that fix this bug,
reported on sage-devel?
"I am having an error in building Sage 3.4.1 on an intel mac running
10.5.
The error is in mpir:
Deleting assembly files which depend on PIC assembly working or 32
bit
OSX on Intel hardware
chec
On Wed, Apr 22, 2009 at 7:17 PM, Bill Hart wrote:
> Release candidate 3 is up on the website: http://www.mpir.org/
Ok on my Penryn system the 32 bit pentium4 and 64bit core2 and amd64
code compiles and all tests ok. The new test project works great
Brian so I think we are good to go for the Wi
2009/4/22 Robert Gerbicz :
>
>>
>> Do you have a canonical reference on the Strong Lehmer test. As a
>> number theorist, I should have heard of it, but to my embarrassment, I
>> have not! {blush}
>>
> Look: http://mersennewiki.org/index.php/Pocklington%27s_Theorem
> in our case f=p.
Ah, so this i
Release candidate 3 is up on the website: http://www.mpir.org/
This RC and the previous one (unannounced) add some missing code and
fixes test projects for the MSVC port in Windows, reported by Jeff
Gilchrist. There are no changes to the linux code for either RC 2 or
RC3.
Bill.
--~--~-~-
Thanks Brian, I'll issue RC3 with this fix.
Bill.
2009/4/22 Cactus :
>
>
>
> On Apr 22, 6:48 pm, Cactus wrote:
>> On Apr 22, 6:29 pm, Jeff Gilchrist wrote:
>>
>>
>>
>> > On Wed, Apr 22, 2009 at 1:22 PM, Cactus wrote:
>> > > To overcoem this problem I hence had to drop all the test project
>>
On Apr 22, 6:48 pm, Cactus wrote:
> On Apr 22, 6:29 pm, Jeff Gilchrist wrote:
>
>
>
> > On Wed, Apr 22, 2009 at 1:22 PM, Cactus wrote:
> > > To overcoem this problem I hence had to drop all the test project
> > > dependencies and this means that it is no longer possible to build
> > > them al
>
> Do you have a canonical reference on the Strong Lehmer test. As a
> number theorist, I should have heard of it, but to my embarrassment, I
> have not! {blush}
>
> Look: http://mersennewiki.org/index.php/Pocklington%27s_Theorem
in our case f=p. It doesn't mention, but in my number theory book it
On Wednesday 22 April 2009 18:18:06 Robert Gerbicz wrote:
> 2009/4/22 Cactus
>
> > On Apr 22, 5:40 pm, gerrob wrote:
> > > Hi!
> > >
> > > I've written a much faster code than the currently used in gmp/mpir.
> > > Million of bits numbers can be tested in about 1 sec, but slower by a
> > > factor
On Wednesday 22 April 2009 17:45:43 Bill Hart wrote:
> Do you want to fix this for the release or just in trunk? If you are
> sure it can't be hit in the release, no need to fix it there.
>
x86_64 is OK , and pentium are definitely OK
so I'll just fix it in trunk
> 2009/4/22 Jason Moxham :
> >
On Apr 22, 6:29 pm, Jeff Gilchrist wrote:
> On Wed, Apr 22, 2009 at 1:22 PM, Cactus wrote:
> > To overcoem this problem I hence had to drop all the test project
> > dependencies and this means that it is no longer possible to build
> > them all at once.
>
> Ah ok.
>
> > The way I now do this i
On Apr 22, 6:18 pm, Robert Gerbicz wrote:
> 2009/4/22 Cactus
>
>
>
>
>
> > On Apr 22, 5:40 pm, gerrob wrote:
> > > Hi!
>
> > > I've written a much faster code than the currently used in gmp/mpir.
> > > Million of bits numbers can be tested in about 1 sec, but slower by a
> > > factor of 2 up
Hi Robert,
Sure no problems.
Just to confirm, though, I notice that it states that the code is part
of GNU MP. That's absolutely no problem, but just wanted to make sure
that this is not because you based your code on existing code in GMP?
If so, it is very important to know that you based it on
On Apr 22, 10:18 am, Robert Gerbicz wrote:
> 2009/4/22 Cactus
Hi Robert,
> > Would you be willing to release it under a license that would allow
> > MPIR to incorporate it?
>
> > Thank you for your interest, which is much appreciated.
>
> > Brian Gladman
>
> OK, I've changed the license,
On Wed, Apr 22, 2009 at 1:22 PM, Cactus wrote:
> To overcoem this problem I hence had to drop all the test project
> dependencies and this means that it is no longer possible to build
> them all at once.
Ah ok.
> The way I now do this is to build the test library first and then
> select all th
On Apr 22, 6:05 pm, Jeff Gilchrist wrote:
> Brian, another thing I'm confused about for MSVC testing. I load
> mpir-tests.sln and it has 143 projects. If I do a Build Solution
> (with Release and x64 selected like I used for building the MPIR
> library) I get an error about test-lib.lib not b
2009/4/22 Cactus
>
>
>
> On Apr 22, 5:40 pm, gerrob wrote:
> > Hi!
> >
> > I've written a much faster code than the currently used in gmp/mpir.
> > Million of bits numbers can be tested in about 1 sec, but slower by a
> > factor of 2 up to about 1000 bits numbers on my pc. Tested a lot, it
> > s
Brian, another thing I'm confused about for MSVC testing. I load
mpir-tests.sln and it has 143 projects. If I do a Build Solution
(with Release and x64 selected like I used for building the MPIR
library) I get an error about test-lib.lib not being present. If I
select that project and build it,
Another MSVC issue. The MPIR library itself now compiles but when I
try to load mpir-tests.sln to compile the test code, I get an error
about the following project is missing:
build.vc9\mpir-tests\mpn.divebybm1of.vcproj
Small documentation changes in readme.txt, it still refers to gmp.lib
in so
On Apr 22, 5:40 pm, gerrob wrote:
> Hi!
>
> I've written a much faster code than the currently used in gmp/mpir.
> Million of bits numbers can be tested in about 1 sec, but slower by a
> factor of 2 up to about 1000 bits numbers on my pc. Tested a lot, it
> should be good.
> You can use it for
Cool, thanks. We'll check the code out and see if we can include it in
the next release.
Which algorithm do you use, i.e. can you say why it is so much faster?
Bill.
2009/4/22 gerrob :
>
> Hi!
>
> I've written a much faster code than the currently used in gmp/mpir.
> Million of bits numbers can
Do you want to fix this for the release or just in trunk? If you are
sure it can't be hit in the release, no need to fix it there.
2009/4/22 Jason Moxham :
>
>
> There is potential error in mul.c , the mul_2 is assumed to give the correct
> result for size=1 . mul_n and addmul_n require size>=n
Hi!
I've written a much faster code than the currently used in gmp/mpir.
Million of bits numbers can be tested in about 1 sec, but slower by a
factor of 2 up to about 1000 bits numbers on my pc. Tested a lot, it
should be good.
You can use it for whatever you want. I've sent it to Torbjorn
Granlu
There is potential error in mul.c , the mul_2 is assumed to give the correct
result for size=1 . mul_n and addmul_n require size>=n in general . We are OK
because the current mul_2 for x86_64 and pentium (the only two cpus that have
one) happen to be correct for size=1 .
The refmpn.c also ass
On Apr 22, 5:23 pm, Bill Hart wrote:
> Brian,
>
> Just to confirm, you test the Windows build only, on these machines.
Yes, that's correct.
Brian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"mpir-devel" g
Brian,
Just to confirm, you test the Windows build only, on these machines.
Bill.
2009/4/22 Cactus :
>
>
>
> On Apr 22, 3:57 pm, Jeff Gilchrist wrote:
>> On Wed, Apr 22, 2009 at 7:16 AM, Bill Hart
>> wrote:
>> > Thanks Jeff. I've added a testing matrix on the
>> > website:http://www.mpir.or
On Apr 22, 3:57 pm, Jeff Gilchrist wrote:
> On Wed, Apr 22, 2009 at 7:16 AM, Bill Hart
> wrote:
> > Thanks Jeff. I've added a testing matrix on the website:http://www.mpir.org/
>
> > Can you look down the list and make sure I have listed your systems on
> > which MPIR 1.1.1 now passes. I thin
On Wednesday 22 April 2009 17:07:41 Jeff Gilchrist wrote:
> Penryn cygwin just passed all test with RC2 as well.
Is it just me , or does the above line read
Penguin singwin just passed :)
>
> Jeff.
>
>
--~--~-~--~~~---~--~~
You received this message becaus
Penryn cygwin just passed all test with RC2 as well.
Jeff.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from thi
On Wed, Apr 22, 2009 at 11:11 AM, Bill Hart wrote:
> Yep, that's right. I'll add that too. I'll be interested to see if you
> hit the t-export test failure. Note that you can't have spaces in the
> path to the source directory if you want to run make check. This is an
> issue with libtools and I
Here is another reference to a bug in comparison of zero byte arrays
with memcmp:
http://www.nabble.com/Bug-in-boot-code-memcmp-with-zero-length-tt20039621.html
Bill.
2009/4/18 Bill Hart :
> This seems relevant:
>
> http://gmplib.org/list-archives/gmp-bugs/2007-August/000813.html
>
> The gcc ve
Yep, that's right. I'll add that too. I'll be interested to see if you
hit the t-export test failure. Note that you can't have spaces in the
path to the source directory if you want to run make check. This is an
issue with libtools and I'm told the sun will implode before it gets
fixed. That exclu
On Wednesday 22 April 2009 16:08:28 Jeff Gilchrist wrote:
> On Wed, Apr 22, 2009 at 11:03 AM, Bill Hart
wrote:
> > Thanks. I will add that now.
> >
> > We should be able to expand our list of machines for regular testing
> > later today. I've sent out some emails and expect to expand the list
>
On Wed, Apr 22, 2009 at 11:03 AM, Bill Hart wrote:
> Thanks. I will add that now.
>
> We should be able to expand our list of machines for regular testing
> later today. I've sent out some emails and expect to expand the list
> quite a bit - though surely this will lead to new test failures.
I
2009/4/22 Jeff Gilchrist :
>
> On Wed, Apr 22, 2009 at 7:16 AM, Bill Hart
> wrote:
>
>> Thanks Jeff. I've added a testing matrix on the website: http://www.mpir.org/
>>
>> Can you look down the list and make sure I have listed your systems on
>> which MPIR 1.1.1 now passes. I think I got them. E
On Wed, Apr 22, 2009 at 7:16 AM, Bill Hart wrote:
> Thanks Jeff. I've added a testing matrix on the website: http://www.mpir.org/
>
> Can you look down the list and make sure I have listed your systems on
> which MPIR 1.1.1 now passes. I think I got them. Even better, could
> you make a list of
Yep, I'm wrong about the license. It is GPL v2 on those files.
Moreover, it is not necessary for them to be LGPL (our current ones
are not) as they don't end up being linked when the library is built.
So we can use them.
We should first grep for changes to configfsf.sub which we have
heavily modi
Thanks Jeff. I've added a testing matrix on the website: http://www.mpir.org/
Can you look down the list and make sure I have listed your systems on
which MPIR 1.1.1 now passes. I think I got them. Even better, could
you make a list of those you have tested on and I will make sure I put
the right
On Wed, Apr 22, 2009 at 3:31 AM, Cactus wrote:
> There is a problem but it is mul_2.asm that is missing, not
> addmul_2.asm. I'll commit it to trunk shortly so that it can be moved
> into the next 1.1.1 RC.
Sorry I meant mul_2.asm but pasted the wrong filename in the e-mail.
So many asm files,
I've updated speed so we can do comparisons of combined functions easier.
rev 1941+ in trunk
a new option colsum=A+B+...+Z
which sums the speed columns A,B, ...(MAX 4 columns for time being)
Note: the summed columns A,B, etc are excluded from the fastest # thing
-r and -d now take a parame
On Apr 22, 9:55 am, Willem Jan Palenstijn wrote:
> On Wed, Apr 22, 2009 at 01:38:13AM -0700, Cactus wrote:
> > On Apr 22, 9:15?am, Willem Jan Palenstijn wrote:
> > > svn checkouthttp://modular.math.jmu.edu/svn/mpir/mpir/trunkmpir-trunk
> > > cp -a mpir-trunk mpir-1.1
> > > cd mpir-1.1
> > > sv
Did we ever get around to backing up the actual svn db itself ?
On Wednesday 22 April 2009 09:55:13 Willem Jan Palenstijn wrote:
> On Wed, Apr 22, 2009 at 01:38:13AM -0700, Cactus wrote:
> > On Apr 22, 9:15?am, Willem Jan Palenstijn wrote:
> > > svn checkouthttp://modular.math.jmu.edu/svn/mpir
On Wed, Apr 22, 2009 at 01:38:13AM -0700, Cactus wrote:
> On Apr 22, 9:15?am, Willem Jan Palenstijn wrote:
> > svn checkouthttp://modular.math.jmu.edu/svn/mpir/mpir/trunkmpir-trunk
> > cp -a mpir-trunk mpir-1.1
> > cd mpir-1.1
> > svn switchhttp://modular.math.jmu.edu/svn/mpir/mpir/mpir-1.1
> >
>
On Apr 22, 9:15 am, Willem Jan Palenstijn wrote:
> On Wed, Apr 22, 2009 at 08:54:42AM +0100, Jason Moxham wrote:
>
> > Hi
>
> > It's hard to believe that svn(or the others) dont have a solution for this.
> > How about something like this
>
> > Brian wants branch-xyz , he logs into svn server ,
On Wed, Apr 22, 2009 at 09:21:30AM +0100, Bill Hart wrote:
> I wonder actually if we do use switch whether making changes to the
> currently "switched" branch also automatically makes those changes to
> trunk. I guess not, as that would probably be illogical. But then
> again, I don't know how it
I believe the graphical Windows TortoiseSVN client offers the switch
command. At least it shows up in my client (which is admittedly 32 bit
Windows).
Sorry for not paying more attention to this issue before now.
Eventually a transition to a distributed system will also fix this
issue (and others)
On Wed, Apr 22, 2009 at 08:54:42AM +0100, Jason Moxham wrote:
>
> Hi
>
> It's hard to believe that svn(or the others) dont have a solution for this.
> How about something like this
>
> Brian wants branch-xyz , he logs into svn server , runs a diff of trunk
> directory against branch to create
Hi
It's hard to believe that svn(or the others) dont have a solution for this.
How about something like this
Brian wants branch-xyz , he logs into svn server , runs a diff of trunk
directory against branch to create a patch file. He only has to download the
patch file and apply it against his
On Apr 22, 8:31 am, Cactus wrote:
> On Apr 22, 6:38 am, Bill Hart wrote:
>
>
>
> > Hi Jeff,
>
> > I just downloaded the tarball and the file is there for me in
> > mpn/x86_64w/addmul_2.asm
>
> > There must be something up with the paths in the project files.
> > Perhaps Brian can take a look a
On Apr 22, 6:38 am, Bill Hart wrote:
> Hi Jeff,
>
> I just downloaded the tarball and the file is there for me in
> mpn/x86_64w/addmul_2.asm
>
> There must be something up with the paths in the project files.
> Perhaps Brian can take a look at this.
>
> Bill.
>
> 2009/4/22 mabshoff :
>
>
>
> >
49 matches
Mail list logo
