On 22 May 2010 03:17, Jason Moxham <[email protected]> wrote: > On Friday 21 May 2010 14:16:49 Bill Hart wrote: >> Regarding time frame for the release, I really hope there are plans to >> get mpir-2.0.1 out the door as soon as possible. >> >> I know Sage has been waiting on these gcd normalisation issues to be >> fixed for absolutely ages. They still use mpir-1.2.2 !!! >> >> The significant holdups I see are: >> >> * broken with gcc 4.5.0 on ia64 - probably not an MPIR bug (may have >> to blacklist this gcc on ia64 along with gcc 4.3.2 on all 64 bit >> machines) > > this is fixed > >> * some issue on another skynet machine - something to do with the >> setup of the machine > > this is fixed except for a purely local issue(I think) wrong linker installed > see this from configue log on fulvia > > hecking if gcc -std=gnu99 supports -c -o file.o... yes > checking whether the gcc -std=gnu99 linker (/usr/local/binutils-2.20.1/x86_64- > SunOS-core2-gcc-4.4.3/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... yes > checking dynamic linker characteristics... solaris2.10 ld.so > > where gcc is version 4.5.0 , but the linker is 4.4.3 > > >> * add copyi.c copyd.c to linux build (this is done by adding them to >> mpn_functions in configure.in and running autoconf, automake, ON >> BOXEN!!) > > I can do this now , easy peasey lemon squeezey :) > >> * document the normalisation changes in mpir.texi (if this hasn't >> already been done - I forgot if I did it or not) >> > > Is there a spec , or do we just state we are now the same as old gmp and gmp > post 5.0.1? >
Simply take the definitions from the GMP docs for mpn_gcdext. The new test code tests precisely this spec and I've tested hundreds of millions of normalisations to make sure it is right. >> I would focus attention on these so the release can be made. >> > > There is the rosemary make tune issue (although isn't rosemary a virtual > machine?) I don't know where Rosemary is. Minh? > > And what do we what to do about the mpn_sqr(_n) names ? I cant figure out how > to duplicate the symbols in libtool. > I could do it in asm like this. > rename our sqr as "internal_sqr_fn" > define in asm two duplicate symbols "mpn_sqr" and "mpn_sqr_n" and just point > both of these to the internal_sqr_fn" symbol (perhaps need one jmp > instruction?) The only thing you can really do is change the name internally to mpn_sqr. Put the #define the other way around in mpir.h. I think Brian's solution would work, but it introduces a function pointer I think, so it's not efficient. > > >> Bill. >> >> On 21 May 2010 13:07, Jason Moxham <[email protected]> wrote: >> > On Friday 21 May 2010 07:54:49 Cactus wrote: >> >> On May 21, 12:24 am, Jason Moxham <[email protected]> wrote: >> >> > On Wednesday 19 May 2010 12:49:51 Bill Hart wrote: >> >> > > Hi all, >> >> > > >> >> > > In the past few months I've been increasingly busy with my research >> >> > > and looking at my calendar for the next few months (urgh is it even >> >> > > years), I see I am going to have not as much time as I would like to >> >> > > work on bignum stuff. >> >> > > >> >> > > I think it is time to pass on the responsibilities I've had within >> >> > > the project to some others. >> >> > > >> >> > > I'll still be available to ask stuff and I'm sure I'll be able to >> >> > > contribute some code from time to time. >> >> > > >> >> > > I understand that the 2.0.1 release is quite close and I'll still be >> >> > > available to help Minh through the process. >> >> > > >> >> > > The logical person to be in charge of linux stuff is Jason Moxham >> >> > > (who is also capable of making releases) and of course Brian is as >> >> > > always, in charge of Windows stuff. For contributions for upcoming >> >> > > releases, please talk to these guys. I'm sure they'll update >> >> > > everyone with any plans for releases as they come to light. >> >> > > >> >> > > Bill. >> >> > >> >> > OK , I'm happy to do it. >> >> > From memory I believe this is what we have up and coming... >> >> > >> >> > v2.0.1 is a gcd normalization and a few minor bugletts >> >> > >> >> > v2.1.0 is a MSVC vs2010 update (assuming everything appears on time) >> >> > >> >> > There are some minor x86_64 assembler tweeks/updates , linux portions >> >> > ready to go , and windows versions depending on how the MSVC update >> >> > goes. My windows box is still in the shop so I can't do the windows >> >> > bit for the moment. >> >> >> >> Let me know when you add these to SVN and I'll look at doing it. >> >> >> >> When you say 'minor tweeks/updates', do you mean a few individual >> >> instruction changes that won't need full conversion or full 'Linux to >> >> Windows' assembler code conversion? >> >> >> >> Brian >> > >> > Both , but mainly full conversion , I could do the simpler ones if I had >> > my windows box back from the shop , I might get it back in time depends >> > on what sort of time frame we expect for the release. if not we can delay >> > until the next release. >> > >> > Jason >> > >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "mpir-devel" group. To post to this group, send email to >> > [email protected]. To unsubscribe from this group, send email >> > to [email protected]. For more options, visit this >> > group at http://groups.google.com/group/mpir-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
