Yep, that's very important. When I mentioned MPIR-Lite I wasn't just talking about single limb stuff by the way. I really meant to have something like MPIR but stripped of all the nastiness, just make it really easy to contribute. Not sure exactly what form that would take which is why I haven't actually gone ahead and tried to do it just yet.
But certainly the gmp.h file would be really straightforward, the build system would be automatic, like in FLINT-Lite, no need to edit any configure or makefile. Testing would not use try, there'd just be a simple program to test each function. We'd get rid of the CNST_LIMB madness, there'd be no nails, the code would only have to work on linux x86_64 with gcc to be accepted. Just don't support anything else. In the end, it might be a nice way to get MPIR to the point of having a better build system than it currently has. Presumably the whole project would grow and the build system would get better and better and eventually people would think, hey, I know how to make that support Sun, or Apple, or something more exotic, etc. Dunno if it would work. Maybe wait and see how FLINT-Lite turns out. Already one person has requested a 32 bit version of FLINT-Lite because that is what they develop on. And I have to admit that my Windows is 32 bits on my laptop, which is what I usually use, so at present I cannot develop FLINT-Lite on my laptop. But seriously, if I can't test it on a 64 bit machine anyway, it's broken, so... Bill. 2009/9/3 Jason Moxham <[email protected]> > > On Thursday 03 September 2009 21:58:02 Jason Moxham wrote: > > On Wednesday 02 September 2009 20:08:48 Bill Hart wrote: > > > Hi all, > > > I finally managed to work out how to set up a Git repo on my new > machine > > > and publish it to the web: > > > > > > http://selmer.warwick.ac.uk/gitweb/FLINT-Lite.git > > > > > > This is for my new FLINT-Lite project, but at this point much of the > code > > > in there may be useful to MPIR, it contains a module called > ulong_extras > > > which deals with single limb arithmetic. > > > > We could do with a proper set of functions/macros for single(and double) > > limb operations , and expose them to the user. I have quite often used > mpz > > types not because they are bignum's but because I then have gcd,sqrt, etc > > allready done. > > > > > If anyone is interested in that project, there is a google group which > I > > > just started: > > > > I certainly interested in the single limb stuff , nice lot of highly > > optimized asm code to write , just what I like , dont know where the time > > is going to come from :( > > > > > http://groups.google.co.uk/group/flint-devel?hl=en > > > > > > If you just want to play around with git, there's some basic > instructions > > > on the first post to that list. But feel free to post questions here. > > > Once I get a bit more familiar with gitweb I'll make a repo of MPIR > from > > > our current svn repo and post it on that same website. It should be no > > > problems to give people write access to it, though it isn't 100% > > > necessary with git, you can just publish your repo and we can pull from > > > it. > > > > > > If you want to play right away: > > > > > > git clone git://selmer.warwick.ac.uk/FLINT-Lite.git FLINT-Lite > > > > > > (make check does something if it knows where MPIR is). > > > > > > It would be great to have a similar project for MPIR, i.e. x86_64 only, > > > just drop files in and no makefile or configuration nonsense, etc. It > > > might be worth thinking about an MPIR-Lite which is really, really easy > > > for people to contribute to. What do people think of that idea? Most of > > > the code could then be "ported" or modified to the standard MPIR style > > > and pulled into the main MPIR project, but the average contributor > > > wouldn't have to understand all the intricacies of MPIR development to > > > contribute! > > > > > > Bill. > > > > Sound good , do we need to do a MPIR-lite though? How about just putting > it > > in the "demo" directory. We could rename the directory mpir-ext or > > future-code , and have a gmp-impl.h and longlong.h in there.We could > build > > a libmpirext.a from it , or just a standalone exe > > > > > Another very important point , is that new contributers can see their code > going in , and being used. The Sage project makes a point of this , and I > fully agree with it. > > I've just checked some dates , because I didn't want to rely on memory as I > may of exaggerated it in my mind, but I contributed some code to a project > a > few years back , and it didn't appear until the next release which was 3.5 > years later :( , what a joke. > > 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 -~----------~----~----~----~------~----~------~--~---
