newbie development questions
Jason Grout
1. When I make changes to, say, devel/sage-branch/sage/graphs/graph.py,
I don't see those changes available in SAGE. For example, I added a
function to the Graph class, but I couldn't access that function when I
started up SAGE. Eventually I accidentally did "sage -b branch", which
looked like it copied and recompiled the graph.py file in the build
directory and my changes worked fine. To see changes that I make in the
source files, is that the proper procedure? (i.e., do sage -b branch
before launching sage, even though devel/sage already points to
sage-branch?)
2. Something seems wrong with my mercurial installation. I can't figure
out where something might be misconfigured, though. I get errors about
hgext/hct when using hg_sage inside of sage, but when running hg outside
of sage, everything seems fine. I can find hct.py in
/usr/local/lib/python2.5/site-packages/hgext/. Does anyone have any
idea where I can poke to find out what's wrong? I'm running Ubuntu.
Here's some relevant info:
$ sage
----------------------------------------------------------------------
| SAGE Version 2.8.4.2, Release Date: 2007-09-13 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading SAGE library. Current Mercurial branch is: graphs
hg_sage: hg_sage.status()
Getting status of modified or unknown files:
cd "/home/grout/sage/sage-2.8.3/devel/sage" && hg status
*** failed to import extension hgext/hct: No module named hgext/hct
*** failed to import extension hgext/hct: No module named hgext/hct
M sage/graphs/graph.py
---
Branch: graphs
sage:
Exiting SAGE (CPU time 0m0.01s, Wall time 0m23.53s).
$ cd "/home/grout/sage/sage-2.8.3/devel/sage" && hg status
M sage/graphs/graph.py
grout@good:~/sage/sage-2.8.3/devel/sage$ cat /home/grout/.hgrc
[ui]
username = Jason Grout <jason...@creativetrax.com>
ignore=~/.hgignore
[extensions]
#hgext.convert=
$ ls -las /usr/local/lib/python2.5/site-packages/hgext/hct.py
4 -rw-r--r-- 1 root staff 1151 2007-09-06 16:23
/usr/local/lib/python2.5/site-packages/hgext/hct.py
$
Thanks,
Jason
William Stein
>
> I have two newbie development questions.
>
> 1. When I make changes to, say, devel/sage-branch/sage/graphs/graph.py,
> I don't see those changes available in SAGE. For example, I added a
> function to the Graph class, but I couldn't access that function when I
> started up SAGE. Eventually I accidentally did "sage -b branch", which
> looked like it copied and recompiled the graph.py file in the build
> directory and my changes worked fine. To see changes that I make in the
> source files, is that the proper procedure? (i.e., do sage -b branch
> before launching sage, even though devel/sage already points to
> sage-branch?)
>
Do "sage -br" everytime.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Robert Miller
used by sage is Mercurial:
http://www.genunix.org/wiki/index.php/Mercurial
The commands listed there have their equivalents in sage-land:
$ hg ci
becomes
$ sage -hg ci
The 'devel' directory contains all the different branches. When you
are running sage, you are running a single branch. The link 'sage' in
devel always points to the current branch. If you are running sage in
a certain branch, the objects hg_sage, hg_doc, hg_extcode and
hg_scripts correspond to Mercurial repositories for the main sage
library (including graph.py), the documentation, external files
(including our graph database ;) ), and scripts related to interfacing
etc, respectively. I usually only work with hg_sage, which is what you
want if you're editing graph.py.
Maybe the easiest way to explain it is to describe a development cycle
(the answer to your question #1 is at 4b):
1. Download and install sage ( you may want to read your favorite
Dickens novel while this is happening ;) )
2. (Optional) do sage -upgrade if it has been a while since you did
#1. This will download and install the latest packages, including the
package for the main sage library. In other words, this will bring you
up to date with the latest 'official' version. Sometimes this breaks,
but don't panic-- most likely, you will just need to force some
package to install again (mail the list at this point, probably).
3. (Also optional) if you want the latest, bleeding edge, super-
current code, you can also do hg_sage.pull() while you're running in
the 'main' branch. I always like to have my main branch as up to date
as possible, and do coding work on other branches, which brings us to:
4. Editing and testing code:
Suppose you have just done 1-3 in order. You are now ready to begin
hacking! To follow a concrete example, we'll start from the beginning:
4a. Create a branch you can safely hack in. If you simply run sage,
you will be in the current branch, which is by dafault sage-main. Do:
sage: hg_sage.clone('hackbranch')
This will copy the current branch to a branch called 'hackbranch', as
well as change the current branch to 'hackbranch'. Once the clone
command finishes, you will already be in the new branch. You can
verify this (or check what branch you are in whenever you like) by
typing hg_sage.status(). This will show you what you have modified, as
well as identify which branch you are in.
4b. Switching between branches: Anytime you do
$ sage -b branch,
you will build the branch 'branch'. If you aren't editing the files in
branch, you won't have access to the changes, since this also switches
the current branch to 'branch'. After doing 4a, you are in the branch
'hackbranch', so you shouldn't need to switch back and forth at all
while you are working: the command
$ sage -br
will build and run the current branch.
4c. Writing and testing code: now that you're this far, write some
functions, doing sage -br to test them out. Once you're happy with the
way the function works, write some doctests for the function and test
them, for example:
$ sage -t devel/sage-hackbranch/sage/graphs/graph.py
This tells sage to do all the doctests in graph.py and report if any
fail. Not specifying a file will test every file in sage! Note that
this is equivalent to
$ sage -t devel/sage/sage/graphs/graph.py,
since hackbranch is the current branch, and the symbolic link 'sage'
points to hackbranch.
5. Check in your changes, and submit a patch:
Once you have something that you definitely like, you should check in
your changes. This is done by
sage: hg_sage.ci()
When you do this, you will be shown the changes you have made, so
simply hit q when you're done looking at them. Then it will take you
to a vi screen, or something similar. Insert an insightful comment,
explaining what you have done, and save the file. Upon exit, Mercurial
will do the rest- it records the change in the repository, so that you
can share your changes with others, by:
sage: hg_sage.bundle('blah')
This creates a file called blah.hg, which contains the information of
what you changed. You can unbundle a bundle, which applies the changes
to a branch, via
sage: hg_sage.apply('blah.hg').
Note:
You must check in your changes before any transaction. If you haven't
checked in, and you try to do something else, Mercurial will
automatically put you into 'checking-in' mode first.
As far as the following, are you getting this error when you run the
main branch of sage, before modification?
> > username = Jason Grout <jason-s...@creativetrax.com>
> > ignore=~/.hgignore
>
> > [extensions]
> > #hgext.convert=
> > $ ls -las /usr/local/lib/python2.5/site-packages/hgext/hct.py
> > 4 -rw-r--r-- 1 root staff 1151 2007-09-06 16:23
> > /usr/local/lib/python2.5/site-packages/hgext/hct.py
> > $
--Robert L Miller
Hamptonio
to see it all spelled out in order.
-Marshall
alex clemesha
I feel like I just re-learned how to use Mercurial with SAGE.
Alex
John Cremona
Questions: (1) since you started your new branch with hg_sage.clone(),
I presume that this creates a branch of the subset of sage files
covered by hg_sage , as opposed to the other subsets (hg_scripts,
hg_doc, hg_extcode).
My own recent hacking, which rather foolishly has been done *without*
first creating such a new branch, involves two files covered by
hg_extcode and one covered by hg_sage. Would the right way to have
started this process have been to do this
hg_sage.clone('hackbranch')
hg_extcode.clone('hackbranch')
with some sensible name replacing 'hackbranch', but with the same name
for both (for sanity rather than necessity)?
(2) Secondly, now that I have done various hg-*.commit() commands, I
have ended up in a mess after the latest upgrade, so what I want to do
now is revert everything to the official files (after making sure I
have kept copies of my hacked files), then start my branch as above,
then move the hacked files into the branch directories.
How do I do this reversion (apart from downloading a complete fresh
set of sources, which perhaps would be safest)?
Apologies for asking questions which must seem stupid to most
sage-devel readers!
John
--
John Cremona
William Stein
> My own recent hacking, which rather foolishly has been done *without*
> first creating such a new branch, involves two files covered by
> hg_extcode and one covered by hg_sage. Would the right way to have
> started this process have been to do this
>
> hg_sage.clone('hackbranch')
> hg_extcode.clone('hackbranch')
>
> with some sensible name replacing 'hackbranch', but with the same name
> for both (for sanity rather than necessity)?
Yes that would have been sensible. However, hg_*.clone is only
_implemented_ for hg_sage. Moreover, and this is very important,
when you upgrade with "sage -upgrade", it will overwrite changes
you make to hg_extcode. This is completely a NotYetImplemented
issue. These are trac tickets 546 to 548. Also, having branches
for the other repositories is potentially much more complicated
than for the hg_sage repository.
> (2) Secondly, now that I have done various hg-*.commit() commands, I
> have ended up in a mess after the latest upgrade, so what I want to do
You should only have a mess in hg_sage, since it's the only one
that does a merge.
> now is revert everything to the official files (after making sure I
> have kept copies of my hacked files), then start my branch as above,
> then move the hacked files into the branch directories.
>
> How do I do this reversion (apart from downloading a complete fresh
> set of sources, which perhaps would be safest)?
Do that.
> Apologies for asking questions which must seem stupid to most
> sage-devel readers!
They aren't stupid.
Given the current status of implementation of cloning stuff, etc., if you
are doing a lot of development to Sage, it is best to do the following:
(1) Have one completely copy of Sage that you do not upgrade regularly,
where you do all your hacking, and
(2) Have a working plain copy of Sage that you do upgrade. Then after
upgrading that plain copy, you can pull your changes from 1. E.g.,
hg_extcode.pull('/path/to/1's/extcode').
I would like merging, etc, i.e., track tickets 546 -- 548 to get
resolved very soon.
Hopefully I can do that before the next Sage release.
-- William
John Cremona
On 9/22/07, William Stein <wst...@gmail.com> wrote:
>
> On 9/22/07, John Cremona <john.c...@gmail.com> wrote:
> > My own recent hacking, which rather foolishly has been done *without*
> > first creating such a new branch, involves two files covered by
> > hg_extcode and one covered by hg_sage. Would the right way to have
> > started this process have been to do this
> >
> > hg_sage.clone('hackbranch')
> > hg_extcode.clone('hackbranch')
> >
> > with some sensible name replacing 'hackbranch', but with the same name
> > for both (for sanity rather than necessity)?
>
> Yes that would have been sensible. However, hg_*.clone is only
> _implemented_ for hg_sage. Moreover, and this is very important,
> when you upgrade with "sage -upgrade", it will overwrite changes
> you make to hg_extcode.
So I just realized *!&*&! and am hoping that my emacs backup file is
not so out of date.
As a warning to others: when you get back after a trip and find that
there's a new version of Sage to upgrade to (and it would have to be a
very short trip for that not to be the case ;)) think first!
This is completely a NotYetImplemented
> issue. These are trac tickets 546 to 548. Also, having branches
> for the other repositories is potentially much more complicated
> than for the hg_sage repository.
>
> > (2) Secondly, now that I have done various hg-*.commit() commands, I
> > have ended up in a mess after the latest upgrade, so what I want to do
>
> You should only have a mess in hg_sage, since it's the only one
> that does a merge.
>
True
> > now is revert everything to the official files (after making sure I
> > have kept copies of my hacked files), then start my branch as above,
> > then move the hacked files into the branch directories.
> >
> > How do I do this reversion (apart from downloading a complete fresh
> > set of sources, which perhaps would be safest)?
>
> Do that.
Doing it now...
>
> > Apologies for asking questions which must seem stupid to most
> > sage-devel readers!
>
> They aren't stupid.
>
> Given the current status of implementation of cloning stuff, etc., if you
> are doing a lot of development to Sage, it is best to do the following:
> (1) Have one completely copy of Sage that you do not upgrade regularly,
> where you do all your hacking, and
> (2) Have a working plain copy of Sage that you do upgrade. Then after
> upgrading that plain copy, you can pull your changes from 1. E.g.,
> hg_extcode.pull('/path/to/1's/extcode').
>
OK -- time to get organised, I see!
John
> I would like merging, etc, i.e., track tickets 546 -- 548 to get
> resolved very soon.
> Hopefully I can do that before the next Sage release.
>
> -- William
>
> >
>
--
John Cremona
cwitty
> 1. When I make changes to, say, devel/sage-branch/sage/graphs/graph.py,
> I don't see those changes available in SAGE. For example, I added a
> function to the Graph class, but I couldn't access that function when I
> started up SAGE. Eventually I accidentally did "sage -b branch", which
> looked like it copied and recompiled the graph.py file in the build
> directory and my changes worked fine. To see changes that I make in the
> source files, is that the proper procedure? (i.e., do sage -b branch
> before launching sage, even though devel/sage already points to
> sage-branch?)
>
> 2. Something seems wrong with my mercurial installation. I can't figure
> out where something might be misconfigured, though. I get errors about
> hgext/hct when using hg_sage inside of sage, but when running hg outside
> of sage, everything seems fine. I can find hct.py in
> /usr/local/lib/python2.5/site-packages/hgext/. Does anyone have any
> idea where I can poke to find out what's wrong? I'm running Ubuntu.
> cd "/home/grout/sage/sage-2.8.3/devel/sage" && hg status
> *** failed to import extension hgext/hct: No module named hgext/hct
> *** failed to import extension hgext/hct: No module named hgext/hct
This is (a slightly different variant of) TRAC #310.
The problem is that your local Ubuntu mercurial installation reads its
configuration information from /etc/mercurial, and looks for mercurial
extension packages in /usr/local/lib/python2.5/site-packages/hgext.
Your SAGE-specific mercurial installation, in your sage directory,
reads its configuration information from /etc/mercurial (same as
before) but looks for mercurial extension packages in .../sage/local/
lib/python2.5/hgext. Your Ubuntu mercurial installation put something
in /etc/mercurial that says to use the hct extension package; but your
SAGE copy of mercurial doesn't have that package available.
The simplest "workaround" is to simply ignore the error messages; they
don't seem to hurt anything. Less simple workarounds would include
editing the appropriate file under /etc/mercurial to avoid requiring
that extension, or installing the hct extension in SAGE's copy of
mercurial (perhaps copying the hct.py file suffices). The fix is
probably to change SAGE's mercurial to not pay attention to /etc/
mercurial.
Carl
John Cremona
/etc/mercurial/hgrc.d/hgext.rc
putting a # (comment) at the start of the line which mentioned
themissing package.
John
--
John Cremona