Producing patch - no working Sage
Dr. David Kirkby
Currently Sage will not build on my Ultra 27, so I can't do anything from inside
the Sage environment.
I must get to grips with 'hg' and how to produce patches for Sage using
Mercurial. I've never really got the hang of it! But the developers guide at
http://www.sagemath.org/doc/developer/producing_patches.html
assumes you have Sage running anyway. There are no examples of doing anything if
Sage will not build.
dave
Jason Grout
Basically, I think that roughly, hg_sage.<command> command is the same
as going into
SAGE_ROOT/devel/sage/sage
and typing
% hg <command>
so hg_sage.commit() is the same as
% cd SAGE_ROOT/devel/sage/sage
% hg commit
etc.
DISCLAIMER: I don't ever do any patches from within sage. I always work
from the command line using hg.
You can do "hg help" or "hg help commit" to get brief help. You can
also look on http://mercurial.selenic.com/ or
http://mercurial.selenic.com/guide/
Does that help?
Thanks,
Jason
Minh Nguyen
On Thu, Dec 31, 2009 at 3:42 AM, Dr. David Kirkby
<david....@onetel.net> wrote:
> How can I produce a patch for Sage, if my Sage will not run on my machine?
If you don't have hg installed on your system, you can use the command
diff instead. For example, say the following content is saved to a
file called "myfile.txt":
<myfile-content>
This sentense has a some typ0s.
</myfile-content>
Next, you fix typos in the file to get the new file "mynewfile.txt":
<mynewfile-content>
This sentence has a some typos.
</mynewfile-content>
You have to make sure that you first create a copy of "myfile.txt" and
rename it as "mynewfile.txt" before doing any editing. You can now
produce a diff file between myfile.txt and mynewfile.txt:
diff -Naur myfile.txt mynewfile.txt > mydiff.patch
which produces the following diff content:
$ cat mydiff.patch
--- myfile.txt 2009-12-30 08:50:54.462302935 -0800
+++ mynewfile.txt 2009-12-30 08:51:15.389961721 -0800
@@ -1 +1 @@
-This sentense has a some typ0s.
+This sentence has a some typos.
When you compile Sage from source, Mercurial should also be built and
installed during the build process. If the mercurial spkg is
successfully installed, it should be in
SAGE_ROOT/local/bin/hg
In that case, make an alias to hg such as the following:
alias 'hg'='/path/to/SAGE_ROOT/local/bin/hg'
If you're trying to edit the Sage library, i.e. SAGE_ROOT/dev/sage/,
then cd to SAGE_ROOT/dev/sage, edit the necessary file(s). Afterwards,
do "hg status" to see which files have changed. To see the actual new
content, do "hg diff"; be careful here because the output of "hg diff"
is sent to standard output by default so you might see a bunch of
stuff flash through your terminal screen. However, you should be able
to redirect the output of "hg diff" to a file and review your changes.
You can review your changes by looking at the diff output. When you're
certain that you've made all necessary changes, do "hg commit" to
commit your changes. To produce a patch, do
$ hg export tip > mychanges.patch
The basic steps are more or less similar if you're trying to edit a
file in an spkg. In any case, you need to make sure that the directory
you're editing from has a Mercurial repository. The command "hg
status" should not report any errors if your current directory is
under revision control.
--
Regards
Minh Van Nguyen
John Cremona
hg, or has too old a version, and then I just use "sage -hg" to run
Sage's own hg. That's after building Sage, of course.
John
2009/12/30 Minh Nguyen <nguye...@gmail.com>:
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Dr. David Kirkby
> Hi David,
>
> On Thu, Dec 31, 2009 at 3:42 AM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>> How can I produce a patch for Sage, if my Sage will not run on my machine?
>
> If you don't have hg installed on your system, you can use the command
> diff instead. For example, say the following content is saved to a
> file called "myfile.txt":
>
> <myfile-content>
> This sentense has a some typ0s.
> </myfile-content>
>
> Next, you fix typos in the file to get the new file "mynewfile.txt":
>
> <mynewfile-content>
> This sentence has a some typos.
> </mynewfile-content>
>
> You have to make sure that you first create a copy of "myfile.txt" and
> rename it as "mynewfile.txt" before doing any editing. You can now
> produce a diff file between myfile.txt and mynewfile.txt:
>
> diff -Naur myfile.txt mynewfile.txt > mydiff.patch
I've installed 'hg'.
But in any case, the 'diff' on Solaris does not support -N or -a. I've tended to
just use -u when attaching patches, but Solaris supports the -r and
I just checked the POSIX spec
http://www.opengroup.org/onlinepubs/9699919799/utilities/diff.html
and do not see -N or -a.
> which produces the following diff content:
>
> $ cat mydiff.patch
> --- myfile.txt 2009-12-30 08:50:54.462302935 -0800
> +++ mynewfile.txt 2009-12-30 08:51:15.389961721 -0800
> @@ -1 +1 @@
> -This sentense has a some typ0s.
> +This sentence has a some typos.
I get very similar.
bash-3.2$ echo "This sentance has a some typoOs" > myfile.txt
bash-3.2$ echo "This sentance no longer has a typo" > mynewfile.txt
bash-3.2$ diff -ur myfile.txt mynewfile.txtcd c_lib
--- myfile.txt Wed Dec 30 17:33:41 2009
+++ mynewfile.txt Wed Dec 30 17:34:13 2009
@@ -1,1 +1,1 @@
-This sentance has a some typoOs
+This sentance no longer has a typo
bash-3.2$
> When you compile Sage from source, Mercurial should also be built and
> installed during the build process. If the mercurial spkg is
> successfully installed, it should be in
>
> SAGE_ROOT/local/bin/hg
>
> In that case, make an alias to hg such as the following:
>
> alias 'hg'='/path/to/SAGE_ROOT/local/bin/hg'
I've not got that far. I just tried to install it with:
bash-3.2$ ./sage -f mercurial-1.3.1.p0
but that fails. I do however have a somewhat older version installed in /usr/bin.
bash-3.2$ hg --version
Mercurial Distributed SCM (version 1.1.2)
or I could of course build Mercurial from source. Perhaps it would be sensible I
updated to at least the version in Sage.
> If you're trying to edit the Sage library, i.e. SAGE_ROOT/dev/sage/,
> then cd to SAGE_ROOT/dev/sage, edit the necessary file(s). Afterwards,
> do "hg status" to see which files have changed. To see the actual new
> content, do "hg diff"; be careful here because the output of "hg diff"
> is sent to standard output by default so you might see a bunch of
> stuff flash through your terminal screen. However, you should be able
> to redirect the output of "hg diff" to a file and review your changes.
> You can review your changes by looking at the diff output. When you're
> certain that you've made all necessary changes, do "hg commit" to
> commit your changes. To produce a patch, do
>
> $ hg export tip > mychanges.patch
>
> The basic steps are more or less similar if you're trying to edit a
> file in an spkg. In any case, you need to make sure that the directory
> you're editing from has a Mercurial repository. The command "hg
> status" should not report any errors if your current directory is
> under revision control.
So lets assume the I'm trying to change spkg-install in
$SAGE_ROOT/spkg/standard/foobar-1.0.spkg
what is the procedure? I can decompress that to spkg, which will create
spkg/standard/foobar-1.0/spkg-install
Then do I just cd to
$SAGE_ROOT/spkg/standard/foobar-1.0/
and make changes to $SAGE_ROOT/spkg/standard/foobar-1.0/spkg-install ?
Or should $SAGE_ROOT/spkg/standard/foobar-1.0.spkg be copied somewhere else
first? If so, does it matter where? (I normally tend to extract the file, then
increment the patch number, so I'd be editing
$SAGE_ROOT/spkg/standard/foobar-1.0.p0/spkg-install
Martin Albrecht added a patch for me to
http://trac.sagemath.org/sage_trac/ticket/7505
which adds two new files
$SAGE_ROOT/spkg/base/testcc.sh
$SAGE_ROOT/spkg/base/testcxx.sh
I noticed the diff is relative to /dev/null That patch needs updating now. I'm
not sure the best way to do that. There's nothing in the patch which would
suggest where the files go, though it is explained in the ticket, and the reason
why.
Dave
Dr. David Kirkby
> I regularly use Sage on a machine which either does not have its own
> hg, or has too old a version, and then I just use "sage -hg" to run
> Sage's own hg. That's after building Sage, of course.
>
> John
Yes, but the point was, on my Sun Ultra 27, Sage will not build. I have 'hg'
installed in /usr/bin though.
Dave
William Stein
You should probably build hg from source yourself. It's best to use
the same version that is included in Sage.
You might also want to build differ if you want the -Naur flags to work.
William
Dr. David Kirkby
> On Wed, Dec 30, 2009 at 9:59 AM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>> John Cremona wrote:
>>> I regularly use Sage on a machine which either does not have its own
>>> hg, or has too old a version, and then I just use "sage -hg" to run
>>> Sage's own hg. That's after building Sage, of course.
>>>
>>> John
>> Yes, but the point was, on my Sun Ultra 27, Sage will not build. I have 'hg'
>> installed in /usr/bin though.
>>
>
> You should probably build hg from source yourself. It's best to use
> the same version that is included in Sage.
Yes, I'll do that. Installing 'hg' is no problem. If I can get Sage to build,
I'm sure I can manage 'hg'!
> You might also want to build differ if you want the -Naur flags to work.
I prefer to avoid GNUisms whenever possible.
> William
>
Dave
Minh Nguyen
On Thu, Dec 31, 2009 at 4:54 AM, Dr. David Kirkby
<david....@onetel.net> wrote:
<SNIP>
> (I normally tend to extract the file, then
> increment the patch number, so I'd be editing
> $SAGE_ROOT/spkg/standard/foobar-1.0.p0/spkg-install
That sounds sensible.
> Martin Albrecht added a patch for me to
>
> http://trac.sagemath.org/sage_trac/ticket/7505
>
> which adds two new files
>
> $SAGE_ROOT/spkg/base/testcc.sh
> $SAGE_ROOT/spkg/base/testcxx.sh
>
> I noticed the diff is relative to /dev/null That patch needs updating now. I'm
> not sure the best way to do that.
As you said on ticket #7505, your latest attachments "testcc.sh" and
"testcxx.sh" are updated versions of previous attachments. I
understand that Martin's patch "trac_7505.patch" is a patch file for
your earlier test scripts. Now that you have attached newer versions
of the test scripts, I think it's not necessary to also update
Martin's patch. What you can do is create a new patch from your
updated test scripts. Without using Mercurial, this can be done as
follows:
[mvngu@t2 trac-7505]$ diff -u /dev/null testcc.sh > testcc.diff
[mvngu@t2 trac-7505]$ diff -u /dev/null testcxx.sh > testcxx.diff
[mvngu@t2 trac-7505]$ cat testcc.diff testcxx.diff >
trac_7505-test-scripts.patch
[mvngu@t2 trac-7505]$ ls
testcc.diff testcxx.sh
testcc.sh trac_7505-test-scripts.patch
testcxx.diff
So you can now upload "trac_7505-test-scripts.patch" to the trac server.
> There's nothing in the patch which would
> suggest where the files go, though it is explained in the ticket, and the reason
> why.
I see that you and Martin have agreed to place the test scripts under
SAGE_ROOT/spkg/base
Martin's patch was probably produced somewhere outside of the Sage
directory tree. But I think that doesn't matter in this case. To apply
a patch using "patch" and without using hg, you download the patch
file to the relevant directory and use the "patch" command. I admit
that doing something like this
patch < trac_7505.patch
is OK under Linux. But on Solaris, I have trouble using "patch" as the
above command is more chatty. It's a common experience, I think, of
people like myself who are transitioning to using non-GNU tools on
Unix.
Dr. David Kirkby
Thank you. I've put the patch on the server. If you have a spare minute, perhaps
you could review it. A few people have looked at it, and Peter Jeremy has made
some significant changes, so he can no longer review it. I'd like to get it into
Sage asap, as then one can develop a better solution to this 64-bit issue with
spkg-install scripts, where some of them only work on OS X, and some work on any
platform.
Once we know what *compiler* someone is using, we can determine what is the
appropriate option to build a 64-bit executable - if any are needed.
I don't know of a linux box which has Sun Studio installed, but if there was
one, the scripts should report 'Sun_Studio'. I'm unable to test on every
platform, but they work on any I have tried.
> patch < trac_7505.patch
>
> is OK under Linux. But on Solaris, I have trouble using "patch" as the
> above command is more chatty. It's a common experience, I think, of
> people like myself who are transitioning to using non-GNU tools on
> Unix.
Yes, there are differences, and they can be annoying some times. That has been
very much the history of Unix in general - many versions all a bit different.
I do not know how accurate this diagram on Wikipedia is:
http://en.wikipedia.org/wiki/File:Unix_history-simple.en.svg
but it gives at least some idea of how influence each other. I've never even
heard of 'OpenServer' until I looked at that diagram, though I know of SCO unix
from which it is derived. I've also used one commerical distribution of Unix,
which is not on that diagram. But I can't even recall what it was called. It was
similar to SCO unix, and run on x86 PCs. It came on 5.25" floppy disks -
probably before your time!
Linux is following that tradition, with many distributions, all a bit different.
http://en.wikipedia.org/wiki/Linux_distribution
says there are over 600 distributions, with over 300 of them maintained. I do
not know how true that is.
But I personally prefer to use just POSIX options, then I can be 99% sure they
will work on any platform. Even systems which are not fully POSIX compliant,
usually support those options.
Dave