That reply wasn't intended to go to mpir-devel. Though I suppose there is nothing terribly evil in what I wrote, so I'll leave it there. Maybe some of this will prompt healthy discussion.
Bill. 2009/7/8 Bill Hart <[email protected]>: > 2009/7/8 William Stein <[email protected]>: >> >> On Mon, Jul 6, 2009 at 8:42 PM, Bill Hart<[email protected]> wrote: >>> >>> I've started writing some development documentation, which will take >>> quite some time to complete. Here is what I have so far: >>> >>> http://sage.math.washington.edu/home/wbhart/mpir-development.pdf >> >> * p-adic --> $p$-adic >> >> * is not on software end users --> is not on software for end users >> >> * " but on the needs of developers as users." -- what does that mean? >> >> * "Finally, development of MPIR is focused largely on extreme performance. >> This >> is of course the most fun component of working on MPIR, as other developers >> ..." >> >> I think it would be pretty cool to include a plot of the mpirbench >> score over the last few years on some architecture here. You could >> emphasize that while clock speeds have stood essentially still during >> the last 5 years, MPIR/GMP's speed has more than doubled. >> >> * "Most extensive high level libraries which use MPIR routines >> actually use the mpn layer," -- what does that mean? Is Sage or NTL >> a "high level library"? It doesn't use mpn... > > Sorry, but NTL does use mpn's, extensively. And of course Sage does, > via Pari, FLINT, zn_poly, NTL and in many other places. I think roed > even uses them directly for some things (I'm not 100% sure I think I > just remember seeing that). > >> >> * "Windows and linux differ" -- capitalize Linux. (this problem is >> all over in the doc) >> >> * " 32 bit OSX" --> "32-bit OS X". In general, replace "OSX" >> everywhere by "OS X". >> >> * "than on linux, however a longstanding deficiency of MPIR" -- I >> think it should be "linux; however,". >> >> * "Arm" --> "ARM" >> >> * "The mpz, mpq anf mpf layers" --> "The mpz, mpq and mpf layers" >> >> * Your asterisked lists would look a lot better (I think) if you used >> >> \begin{itemize} >> \item the entry >> ... >> \end{itemize} >> >> * "type make check to run all these tests." --> "type {\tt make check} >> to run all these tests."; same for "make tune" later, etc. >> >> * "/doc/devel contains" --> "doc/devel contains" >> >> * " on 32 bit X86 code " --> " on 32-bit x86 code " >> >> * "build.vc9 - visual solutions files for MSVC " --> "build.vc9 - >> Visual Studio solutions files for MSVC " >> >> * "svn co http://modular.math.jmu.edu/svn/mpir/mpir/trunk mpir-trunk " >> I own "mpir.org", so I could probably use proxying to make it so >> "svn co http://svn.mpir.org/mpir/trunk mpir-trunk" >> would work. Thoughts? > > I think Jason Martin doesn't want to keep hosting the repo. So not > much point until someone else volunteers. > >> >> * I tried the above command and got the following: >> "Last login: Tue Jul 7 16:31:04 on ttys004 >> You have new mail. >> teragon:~ wstein$ cd tmp/ >> teragon:tmp wstein$ wget svn co >> http://modular.math.jmu.edu/svn/mpir/mpir/trunk mpir-trunk >> --17:04:21-- http://svn/ >> => `index.html' >> Resolving svn... 72.13.86.194 >> Connecting to svn|72.13.86.194|:80... >> >> [hang for 10 minutes and I give up!!!!!]" >> > > why did you put wget? > > Without wget it takes 30 seconds to check out the entire flint repo, > including every past released version of FLINT and trunk. > >> * <rant> >> >> SVN sucks. It's the dark ages. It's sad on page 8 that you can't >> just tell the developer -- >> (1) change files, > > svn lets you do that.... > >> (2) check into to your local repo > > no need, any changes made are automatically in your local working > copy, unless you are adding new files, in which case you do > > svn add filename > > to put them under revision control > >> (3) change more files, check in more changes > > nothing new here, same as above, no need to "check in", just change the files > >> (4) When you're ready, post patches that any other developer can >> just try out in their local repo. > > svn diff > file.patch > > post to wherever or whomever you like. > > As far as the operations go that you have just listed, it is actually > easier to do them in svn than in HG. > > One advantage of HG over SVN is that you can make lots of local > commits before a global commit. The main advantage of that is the > possibility of a more atomic commit log. The GMP project certainly has > that. > > As far as work flow goes however, HG is irrelevant for my purposes. My > editor has all the features for keeping track of and reverting local > changes, that I need. I don't need my revision control software to do > that. > > As for sharing my work as I go with others, and collaborating, svn > forces a different work flow for that. I cannot send someone some > patches that represent a half done job, get them to work on part of it > while I work on another part and keep the whole thing out of the > central repo so it doesn't bother other developers, then have both of > us commit our respective patches to the central repo when done. > > The standard way of doing this with svn is to make a branch in the > central repo and give the community of people who want to collaborate > on that branch write access to the repo. Then it is exactly the same > as sending patches to one another. You just do it via the repo. For > large projects with multiple branches, it eventually becomes > prohibitive. With three developers, or even 10 it works just fine. > > SVN does force a slightly different workflow, and in terms of internet > bandwidth, it is more expensive as Brian found out. But it still > works, just fine. > > (Brian's issue can easily be resolved by him making a copy locally on > his hard drive then using the svn switch command. Then he could > download multiple branches without checking the entire branch out > every time - only the changes from from the point it was branched, are > sent.) > >> >> You promised me you would watch Linus's talk here: >> http://www.youtube.com/watch?v=4XpnKHJAok8 >> Please keep in mind that Linus is arguably the most successful person >> ever at organizing and growing a large open source project. >> >> </rant> > > I gave up on this issue again. The one person who is supposedly > maintaining the git repo has no time to keep doing so. I can't even > get him to rebase it. No one cares about this issue. Or everybody > cares, but no one who has any intention of setting up a repo or > maintaining it or actually contributing to MPIR, cares. > > It annoys me that I read a document about what makes an open source > project successful. It is written by one of the authors of svn. I'm > told to watch a video by Linus, who wrote Git. Brian wants to use Hg > because he thinks Git users have freetard tendencies. Gonzalo assures > me Darcs is far superior technologically to Hg or Git. > > This issue just frustrates the hell out of me. It's like arguing > politics or religion. > > The fact of the matter is the most popular revision control software > for Windows users writing C code is svn. In fact the most popular > revision control software fullstop is svn. > >> >> * "ammend" --> "amend" >> >> Awesome! Please let me know when you post a new version with all the >> new typos fixed. >> > > Thanks for all the corrections. By the way, despite it saying that it > is, this document is not actually in the repo yet. No reason. I just > didn't bother putting it there yet. > > Bill. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
