[sage-devel] Re: newbie development questions
I made a similar message (on kubuntu) go away by editing /etc/mercurial/hgrc.d/hgext.rc putting a # (comment) at the start of the line which mentioned themissing package. John On 9/23/07, cwitty [EMAIL PROTECTED] wrote: On Sep 20, 11:46 am, Jason Grout [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: newbie development questions
Thanks for the very helpful guide!
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
On 9/21/07, alex clemesha [EMAIL PROTECTED] wrote:
Yeah, nice summary Robert.
I feel like I just re-learned how to use Mercurial with SAGE.
Alex
On 9/20/07, Robert Miller [EMAIL PROTECTED] wrote:
Maybe I can offer more words of advice. The source revision system
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
[sage-devel] Re: newbie development questions
On 9/22/07, John Cremona [EMAIL PROTECTED] 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. 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
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: newbie development questions
Thanks for the further explanation.
On 9/22/07, William Stein [EMAIL PROTECTED] wrote:
On 9/22/07, John Cremona [EMAIL PROTECTED] 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
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: newbie development questions
On 9/20/07, Jason Grout [EMAIL PROTECTED] wrote: 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. 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 [EMAIL PROTECTED]:~/sage/sage-2.8.3/devel/sage$ cat /home/grout/.hgrc [ui] username = Jason Grout [EMAIL PROTECTED] 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 Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: newbie development questions
Maybe I can offer more words of advice. The source revision system
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?
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-devel] Re: newbie development questions
Thanks for the blueprint! I knew most of that but it was very helpful
to see it all spelled out in order.
-Marshall
On Sep 20, 2:52 pm, Robert Miller [EMAIL PROTECTED] wrote:
Maybe I can offer more words of advice. The source revision system
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?
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
