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
-~----------~----~----~----~------~----~------~--~---
