On Dec 5, 11:27 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 5, 2008 at 2:54 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > Hello folks,
>
> > the extcode repo in Sage is somewhat of a dumping ground what doesn't
> > really fit anywhere else. Below is the disk use of all directories
> > that aren't more or less empty:
>
> > 44K dist
> > 36K gap
> > 24K images
> > 1.2M javascript
> > 228K magma
> > 52K maxima
> > 3.0M notebook
> > 1.9M pari
> > 400K pickle_jar
> > 204K sagebuild
> > 16K singular
> > 7.2M total
>
> > The 3.0 MB notebook is at least size-wise 95% javascript, too. We
> > (Jason Grout is doing all the hard work) are in the process of moving
> > all the javascript packages we use (jsmath, jquery, ...) to spkgs so
> > that the repo will be much smaller in the future while the .hg repo
> > information itself will grow by another couple MB. In the end the
> > compressed extcode.spkg will be just as large as before the removal.
> > And shipping such an amount of basically 3rd party code we checked in
> > and then removed seems like a waste of resources. But what to do?
>
> > (a) nuke the extrepo and move things into other places. The
> > pickle_jar could go into the main Sage repo, the pari scripts into the
> > pari.spkg, the images and the notebook code could also be part of the
> > main repo. That leaves certain code for Maxima, Singular and Magma in
> > search of a place to hang out.
>
> > (b) reset the extrepo. This is the less invasive option, but would
> > destroy the version history of some of the files. One option here is
> > to check in files in the name of the previous main author, but it
> > seems like a bad move.
>
> > Either way we should do something about the extocde repo. Since the
> > doc repo will die in 3.3. it seems like an excellent opportunity to
> > finish some long needed cleanup. I could certainly imagine some
> > combination of (a) and (b), i.e. the pari data seems to be large
> > untouched in a while and the pari.spkg would seem like a canonical
> > place for it. Putting those pari scripts and data under revision
> > control also seems rather pointless.
>
> > Thoughts?
Hi,
> I am very opposed to moving any of the code in other languages into
> spkg's.
I didn't make myself clear on that point, but I have the same
intention as you do: I would claim that the pari data is special in
that regard since it consists on the the following scripts/data:
1.5M SEA
20K buzzard
108K cremona
84K dokchitser
160K simon
I think all of them are from some upstream source and we do rarely if
ever change those unlike say the Magma code which is written for Sage
specifically by us. Since I agree that sticking them into the
pari.spkg would cause trouble for packagers I would suggest we create
an pari_scripts.spkg and stick them in there. I see no point checking
those files into the main Sage devel repo since we don't actively
change them anyway and would only waste resources in tracking them.
I will comment more on each individual directory below.
> I think spkg's should as close as possible approximate the
> upstream originals. This is very important for the Debian and other
> packaging efforts, and is conceptually much better. For example, Nick
> and I were working on the Sage/Magma interface yesterday, and had to
> write lots of code that also goes in the data/extcode/magma directory.
> Exactly the same thing could have happened with Gap, and it would
> have sucked for half our patches to be patches against the Gap spkg.
Absolutely.
> However, I don't like the current situation either. I'm tempted to
> actually propose that we move everything we need that is in extcode to
> the main Sage library repo, just like Mike Hansen is moving the docs
> of Sage to that repository. Then we delete the extcode spkg and
> repository completely.
> We would thus have a new subdirectory:
>
> SAGE_ROOT/devel/sage/extcode
>
> with subdirectories for various languages. A big plus to this is
> that, e.g., the work Nick and I was doing would involve a single patch
> against the main sage library instead of one patch for extcode and one
> for the main library.
Yes, I like that very much and am certainly in favor here.
> The main reason the repos are broken up now is just historical and
> because our previous revision control system (darcs) seemed to not
> scale very well. Mercurial scales fine, and seems to have no problem
> at all dealing with the entire massive Sage history, so I think adding
> the Sphinx docs and extcode to the main library would be a good move.
I did not know that that was the reason for the existence of the doc
and ext repos, but that is good to know for future "obscure questions
about the history of Sage" quizzes at future Sage Days :)
> So that's my counter-proposal.
>
> -- Wiliam
The following directories should be deleted - at least Tim Abbott
mentioned that the Debian people disliked empty directories. IIRC
William said they were an historical artifact, but maybe someone else
would come up with a reason to keep them. But if they are needed for
some interface we should just change those interfaces to use SAGE_TMP
or something along those lines.
0B MuPAD
0B QEPCAD
0B genus2reduction
0B gnuplot
0B kash
0B macaulay2
0B maple
0B mathematica
0B matlab
0B octave
0B sage
0B sobj
--------
Now on to the more interesting files and directories:
36K dist
Probably delete since that is the Debian code to package the extcode
repo.
--------
24K gap
Move to Sage Dev repo. David Joyner mentioned earlier he could now
implement that functionality in Sage, but I would suggest we move it
anyway to not hold up the move.
--------
20K images
Move to Sage Dev repo
--------
1.1M javascript
Move to independent spkgs - work in progress
--------
200K magma
Move to Sage Dev repo
--------
40K maxima
Move to Sage Dev repo
--------
4.0K mirror:
I am sure the following can be safely deleted: :)
cd $HOME/sage/web/dist/src/extcode-darcs/
darcs changes > changelog_darcs.txt
echo "uploading"
rsync -axLH --rsh=ssh --delete -r -v * modular:/home/was/www/sage/
dist/src/extcode-darcs
--------
4.0K mwrank
this contains the file primes with says: "19047851" I assume this
constant can be stuck either somewhere else or hardcoded in some
place.
--------
2.8M notebook
Mostly javascript which is being moved to spkgs, the other data should
go into the Sage Dev repo. Since the templates are over there anyway
it seems better to have one place for that data than two. It should be
audited which data are actually still in use so we can nuke the rest.
--------
1.8M pari
See above: I would like those to get moved to a pari_scripts.spkg
--------
392K pickle_jar
Move to Sage Dev repo
--------
192K sagebuild
We might have to hang on for that one for a while until -tp is
completely independent of pbuild, so move to Sage Dev repo
--------
8.0K singular
Move to Sage Dev repo
--------
The following four: Delete - no longer needed
4.0K spkg-debian
4.0K spkg-dist
4.0K spkg-install
4.0K sage-push
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
