On Apr 22, 6:38 am, Bill Hart <goodwillh...@googlemail.com> 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 <michael.absh...@mathematik.uni-dortmund.de>:
>
>
>
> > On Apr 21, 5:25 pm, Jeff Gilchrist <jeff.gilchr...@gmail.com> wrote:
> >> On Tue, Apr 21, 2009 at 6:30 PM, Bill Hart <goodwillh...@googlemail.com>
> >> wrote:
> >> > I've put release candidate 1 for MPIR 1.1.1 up on the website.
>
> >> Houston we have a problem (you guys must really love me by now)...
>
> > Well, as long as you are finding bugs I don't see any problem with you
> > complaining and we are happy to have you :)
>
> >> First the good news, it works fine with my gcc 3.x k8 system, and to
> >> good core2 system. The one causing us problems before is down right
> >> now so hopefully that will back up tomorrow to test.
>
> >> But I found another problem with Windows. There is 1 more assembler
> >> files listed in the MSVC lib_mpir_core2 and lib_mpir_amd64 Assembler
> >> project file but is missing from the mpn/x86_64w/ directory in the
> >> 1.1.1 RC1 tarball.
>
> >> - addmul_2.asm
>
> > Ok. Brian ought to be asleep by now, so hopefully in the morning he
> > will give us some feedback.
>
> > I am glad we did an rc this time. Fortunately MPIR 1.1 did not show
> > any problems when building and testing Sage 3.4.1.rc4 against in on
> > 20+ systems.
>
> >> Jeff.
>
> > Cheers,
>
> > Michael
Hi All,
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.
This release suffered because I was away last week but I am wodering
what can be done to reduce these sort of issues in future.
Having an independent test of the Windows build is clearly a big step
forward so Jeff's contribution is vital and much appreciated by me.
One of the problems is that most university based contributors to MPIR
seem to be able to assume that bandwidth use is not an issue but for
me this is not the case as I have access via an Internet Service
Provider (ISP) with a maximum 8 Mbit/sec access speed and 'pay as you
go' bandwidth costs.
If I point my SVN client at the SVN root, every branch added takes a
very long time to download and uses a lot of bandwidth even though the
difference between the new branch and an existing one might be only
one or two small files. This is quite mad and I am hence wondering
whether Mercurial would overcome this problem? I say Mercurial rather
than GIT because GIT does not have a working
As a result I now mostly operate SVN against the MPIR trunk branch and
don't see the other branches. This is not ideal but I cannot really
operate within the current policy that a new branch is creaated for
each area in which changes are being done.
Would it not be possible to operate with just a few (<= 3) active
branches?
Brian
--~--~---------~--~----~------------~-------~--~----~
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 this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
