proposal: standard command-line options in Sage
John H Palmieri
than --notebook). I propose that we switch to standard ones. Here are
two reasons:
1. They're standard, and standards are good. People used to Unix-type
systems will expect our options to work this way. I think if we
decide to continue not using the standard format, we should have a
good reason.
2. If we use standard command-line options, we can use an existing
command-line parser, like Python's optparse, instead of having our own
home-grown version (in SAGE_ROOT/local/bin/sage-sage). A standard
Python library package is likely to be more robust than something home-
grown. For example, we can solve trac ticket #21 (and the related
ticket #180) this way. For another example, note that "sage -merge"
works but "sage --merge" doesn't; this sort of thing can be fixed on a
case-by-case basis, but it's harder to even introduce such
inconsistencies with optparse.
My proposal is:
(a) first, we include new command-line options but don't turn them on
by default, instead printing a message like this one when you type
"sage [...]" with a nonempty argument:
Note: Using old-style Sage command-line options.
To try out Sage's experimental GNU/Posix-style command-line
options
(for example, 'sage --notebook' instead of 'sage -notebook'), set
the
environment variable $SAGE_NEW_OPTIONS to something nonempty.
To bypass this message, set the environment variable
$SAGE_SKIP_OPTIONS_MESSAGE to something nonempty.
Running "sage" (with no arguments) would not trigger this message.
(Perhaps we could only turn this on in prerelease (alpha and rc)
versions? Alternatively, a change like this could go with the version
5.0 release.)
(b) after a while, we switch this to
Warning: Using old-style Sage command-line options.
Sage is changing to use conventional GNU/Posix-style command-line
options
(for example, 'sage --notebook instead of 'sage -notebook). This
change will
become the default soon. Meanwhile, to use this new style (and
therefore
to avoid seeing this message), set the environment variable
$SAGE_NEW_OPTIONS to something nonempty.
perhaps with no easy way of disabling this message while using old-
style options.
(c) finally, we turn on the new options, perhaps with an environment
variable $SAGE_OLD_OPTIONS to use the old ones, with the understanding
that any changes in command-line options may not be maintained for the
old version.
I have patches to implement this which I can post at trac ticket #21
if people think it's a good idea. I'd be very surprised if my
implementation of the new options doesn't have bugs, but refereeing
and phase (a) would get people to test it out. As far as I can tell,
all spkg-install files for the standard packages would continue to
function: first, they look good at a glance. Second, I applied the
patches, set $SAGE_NEW_OPTIONS to something non-zero, ran "sage --
sdist", and built the new version without issues. I haven't looked at
any optional or experimental spkgs yet.
Opinions? Perhaps we should start a new newsgroup to discuss this? :)
By the way, while investigating this, I came up with some questions:
- What should "sage blah.spkg" do? It looks like it's supposed to
install the spkg, although this isn't documented anywhere that I can
see. Should we keep this behavior, or just make the user type "sage -i
blah.spkg"?
- "sage -log" seems to be broken: it tries to write to the
nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
it?
- "sage -np" seems to be broken, or at least it doesn't do what I
expect (or indeed anything different from just "sage", as far as I
could see). Should we remove it or fix it?
- what is "sage -darcs" supposed to do? I don't know what "darcs" is,
and I don't see any packages which seem relevant.
- what about "sage -axiom"? What package installs axiom? Fricas?
- does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
- how about "sage -gthread" and friends?
- how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
etc.?
For any of these, we have several choices: (1) delete them, (2) keep
them, (3) keep them but don't document them (don't list them when you
type "sage --advanced"), (4) ??
--
John
Tim Joseph Dumol
Looks like a good plan. This might be a good way to do things portably:
http://code.google.com/p/shflags/
By the way, while investigating this, I came up with some questions:
- What should "sage blah.spkg" do? It looks like it's supposed to
install the spkg, although this isn't documented anywhere that I can
see. Should we keep this behavior, or just make the user type "sage -i
blah.spkg"?
- "sage -log" seems to be broken: it tries to write to the
nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
it?
- "sage -np" seems to be broken, or at least it doesn't do what I
expect (or indeed anything different from just "sage", as far as I
could see). Should we remove it or fix it?
- what is "sage -darcs" supposed to do? I don't know what "darcs" is,
and I don't see any packages which seem relevant.
- what about "sage -axiom"? What package installs axiom? Fricas?
- does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
- how about "sage -gthread" and friends?
- how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
etc.?
I do/did.
For any of these, we have several choices: (1) delete them, (2) keep
them, (3) keep them but don't document them (don't list them when you
type "sage --advanced"), (4) ??
--
John
--
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
To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
--
Tim Joseph Dumol <tim (at) timdumol (dot) com>
http://timdumol.com
Dan Drake
> Sage uses non-standard command-line options (e.g., -notebook rather
> than --notebook). I propose that we switch to standard ones. Here are
> two reasons:
A big +1 here. No need to reinvent the wheel; we are manually parsing
command-line options, and should instead take advantage of the getopt or
optparse modules.
Your implementation plan sounds good, and should let us shake out bugs
without making Sage unusable for anyone.
> By the way, while investigating this, I came up with some questions:
>
> - What should "sage blah.spkg" do? It looks like it's supposed to
> install the spkg, although this isn't documented anywhere that I can
> see. Should we keep this behavior, or just make the user type "sage -i
> blah.spkg"?
Off the top of my head, I think "sage blah.spkg" should ask you if you
want to install the spkg and just exit if you say no.
> - "sage -log" seems to be broken: it tries to write to the
> nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
> it?
(Again off the top of my head...) I say remove this. It's doesn't seem
relevant to our current development procedures.
> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
> and I don't see any packages which seem relevant.
>
> - what about "sage -axiom"? What package installs axiom? Fricas?
>
> - does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
>
> - how about "sage -gthread" and friends?
>
> - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
> etc.?
We should remove -darcs, since we don't use it anymore; I've never used
any of the other options.
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
William Stein
> On Thu, 18 Mar 2010 at 09:05PM -0700, John H Palmieri wrote:
>> Sage uses non-standard command-line options (e.g., -notebook rather
>> than --notebook). I propose that we switch to standard ones. Here are
>> two reasons:
>
> A big +1 here. No need to reinvent the wheel; we are manually parsing
> command-line options, and should instead take advantage of the getopt or
> optparse modules.
The main issue I see is that using getopt or optparse means that the
"local/bin/sage-sage" script will go from not depending on Python to
depending on Python. This may cause trouble for the build system, and
may slow down commands such as "sage -gp", since doing "sage -gp" now
means also starting Python, in addition to Pari.
Other than that, I can't see any negatives.
The sage-sage file parsed like 2 or 3 options when I first wrote it,
and I planned to redo it "right", but then it kept getting longer...
> Your implementation plan sounds good, and should let us shake out bugs
> without making Sage unusable for anyone.
>
>> By the way, while investigating this, I came up with some questions:
>>
>> - What should "sage blah.spkg" do? It looks like it's supposed to
>> install the spkg, although this isn't documented anywhere that I can
>> see. Should we keep this behavior, or just make the user type "sage -i
>> blah.spkg"?
>
> Off the top of my head, I think "sage blah.spkg" should ask you if you
> want to install the spkg and just exit if you say no.
>
>> - "sage -log" seems to be broken: it tries to write to the
>> nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
>> it?
>
> (Again off the top of my head...) I say remove this. It's doesn't seem
> relevant to our current development procedures.
+1
>
>> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
>> and I don't see any packages which seem relevant.
Delete it.
>>
>> - what about "sage -axiom"? What package installs axiom? Fricas?
Fricas.
>>
>> - does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
I use "sage -inotebook" and have used "sage -crap". I wrote "sage
-min" to satisfy complaints from David Harvey...
>> - how about "sage -gthread" and friends?
I don't know what that is.
>> - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
>> etc.?
That should stay. And somebody should really be using it again :-).
William
Adam Webb
On Mar 19, 5:05 am, John H Palmieri <jhpalmier...@gmail.com> wrote:
> Sage uses non-standard command-line options (e.g., -notebook rather
> than --notebook). I propose that we switch to standard ones. Here are
> two reasons:
>
> 1. They're standard, and standards are good. People used to Unix-type
> systems will expect our options to work this way. I think if we
> decide to continue not using the standard format, we should have a
> good reason.
>
> 2. If we use standard command-line options, we can use an existing
> command-line parser, like Python's optparse, instead of having our own
> home-grown version (in SAGE_ROOT/local/bin/sage-sage). A standard
> Python library package is likely to be more robust than something home-
> grown. For example, we can solve trac ticket #21 (and the related
> ticket #180) this way. For another example, note that "sage -merge"
> works but "sage --merge" doesn't; this sort of thing can be fixed on a
> case-by-case basis, but it's harder to even introduce such
> inconsistencies with optparse.
>
I think it is a great idea.
>
> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
> and I don't see any packages which seem relevant.
>
I assume this refers to the distributed source code management.
(http://darcs.net/) Perhaps someone was thinking of it as an
alternative to mercurial. It does have an interesting theory of
patches.
> - what about "sage -axiom"? What package installs axiom? Fricas?
>
This is leftover from when fricas used to use the name axiom as a
synonym. This is no longer the case. If axiom is installed globally it
will be used. There is no spkg for it but there are optional tests
that assume the presence of axiom.
Adam
William Stein
It was included in Sage and we used it for everything from about Feb
2006 to sometime in 2007.
In 2006, Mercurial wasn't mature enough.
>> - what about "sage -axiom"? What package installs axiom? Fricas?
>>
>
> This is leftover from when fricas used to use the name axiom as a
> synonym. This is no longer the case. If axiom is installed globally it
> will be used. There is no spkg for it but there are optional tests
> that assume the presence of axiom.
>
> Adam
>
>> For any of these, we have several choices: (1) delete them, (2) keep
>> them, (3) keep them but don't document them (don't list them when you
>> type "sage --advanced"), (4) ??
>>
>> --
>> John
>
> --
> 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
>
> To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Dan Drake
> The main issue I see is that using getopt or optparse means that the
> "local/bin/sage-sage" script will go from not depending on Python to
> depending on Python. This may cause trouble for the build system, and
> may slow down commands such as "sage -gp", since doing "sage -gp" now
> means also starting Python, in addition to Pari.
Good point -- although Python does start very fast. I see that bash has
a "getopts" builtin, although it doesn't do --style arguments. I
downloaded shflags, which Tim suggested, and using it amounts to sourcing a
31KB shell library, which seems like a pretty reasonable, uh, option --
check out http://code.google.com/p/shflags/wiki/Documentation10x
William Stein
> On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
>> The main issue I see is that using getopt or optparse means that the
>> "local/bin/sage-sage" script will go from not depending on Python to
>> depending on Python. This may cause trouble for the build system, and
>> may slow down commands such as "sage -gp", since doing "sage -gp" now
>> means also starting Python, in addition to Pari.
>
> Good point -- although Python does start very fast.
PARI starts up nearly twice as fast as Python (for me on boxen.math):
wstein@boxen:~$ time sage -gp < /dev/null
real 0m0.030s
user 0m0.000s
sys 0m0.010s
wstein@boxen:~$ time sage -python < /dev/null
real 0m0.048s
user 0m0.020s
sys 0m0.020s
Other commands such as "sage -hg" will also suddenly take 50% longer
if we make this switch using Python.
> I see that bash has
> a "getopts" builtin, although it doesn't do --style arguments. I
> downloaded shflags, which Tim suggested, and using it amounts to sourcing a
> 31KB shell library, which seems like a pretty reasonable, uh, option --
> check out http://code.google.com/p/shflags/wiki/Documentation10x
How long does it take?
--William
>
>
>
> Dan
>
> --
> --- Dan Drake
> ----- http://mathsci.kaist.ac.kr/~drake
> -------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkujNlAACgkQr4V8SljC5LoUiQCgkwOwvkXA2/jvQxNdO80S6fzQ
> pXcAnAxhDUcw7q48nfezS1kQDgddk9ll
> =B0xF
> -----END PGP SIGNATURE-----
Dan Drake
> PARI starts up nearly twice as fast as Python (for me on boxen.math):
>
> wstein@boxen:~$ time sage -gp < /dev/null
> real 0m0.030s
> user 0m0.000s
> sys 0m0.010s
> wstein@boxen:~$ time sage -python < /dev/null
> real 0m0.048s
> user 0m0.020s
> sys 0m0.020s
On my computer, I get a "real" time of 0.30 s for pari and 0.40 s for
python, using your test. For shflags, this is what I get:
drake@klee:/tmp/shflags-1.0.3/src$ time /bin/bash < /dev/null
real 0m0.003s
user 0m0.000s
sys 0m0.002s
drake@klee:/tmp/shflags-1.0.3/src$ time /bin/bash -c '. ./shflags'
real 0m0.015s
user 0m0.009s
sys 0m0.006s
So, way faster. And on Linuxen that use dash for /bin/sh (like Ubuntu),
we can get faster still if we write strictly POSIX-compliant scripts:
drake@klee:/tmp/shflags-1.0.3/src$ time /bin/sh < /dev/null
real 0m0.001s
user 0m0.000s
sys 0m0.002s
drake@klee:/tmp/shflags-1.0.3/src$ time /bin/sh -c '. ./shflags'
real 0m0.007s
user 0m0.004s
sys 0m0.004s
One potentially big problem is that shflags doesn't do -- options on OS
X since bash there is only version 3.2 and doesn't have some of the
builtin getopt stuff:
drake@bsd:~/shflags-1.0.3/examples$ ./hello_world.sh --name foo
flags:WARN getopt: illegal option -- -
-n ame -- foo
flags:FATAL unable to parse provided options with getopt.
It looks like among fast, portable, and easy to use, we can choose any
two. :)
Martin Albrecht
I find these incredibly useful!
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Jason Grout
> Sage uses non-standard command-line options (e.g., -notebook rather
> than --notebook). I propose that we switch to standard ones. Here are
> two reasons:
>
+1!
When this issue came up a year or two ago, there seemed to be a
surprising amount of opposition to typing the extra dash, so the
interest in changing the options and parsing waned. I would be very
happy to see us switch to standard GNU option parsing.
Thanks,
Jason
--
Jason Grout
Tim Joseph Dumol
On Fri, Mar 19, 2010 at 12:47 AM, Dan Drake <dr...@kaist.edu> wrote:The main issue I see is that using getopt or optparse means that the
> On Thu, 18 Mar 2010 at 09:05PM -0700, John H Palmieri wrote:
>> Sage uses non-standard command-line options (e.g., -notebook rather
>> than --notebook). I propose that we switch to standard ones. Here are
>> two reasons:
>
> A big +1 here. No need to reinvent the wheel; we are manually parsing
> command-line options, and should instead take advantage of the getopt or
> optparse modules.
"local/bin/sage-sage" script will go from not depending on Python to
depending on Python. This may cause trouble for the build system, and
may slow down commands such as "sage -gp", since doing "sage -gp" now
means also starting Python, in addition to Pari.
This code does the requisite parsing in pure shell script: http://code.google.com/p/shflags/, which I think removes the only negative :-)
--
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
To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
--
John H Palmieri
> On Fri, Mar 19, 2010 at 1:31 AM, Dan Drake <dr...@kaist.edu> wrote:
> > On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
> >> The main issue I see is that using getopt or optparse means that the
> >> "local/bin/sage-sage" script will go from not depending on Python to
> >> depending on Python. This may cause trouble for the build system, and
No, it builds fine for me: I said this in the original post. I also
just temporarily deleted my system version of Python and tried again.
It had no problems getting past building python, so I think it should
work just fine for the whole build. (I think I also said that I
hadn't looked at any optional packages; some of them might very well
break.)
> >> may slow down commands such as "sage -gp", since doing "sage -gp" now
> >> means also starting Python, in addition to Pari.
>
> > Good point -- although Python does start very fast.
>
> PARI starts up nearly twice as fast as Python (for me on boxen.math):
>
> wstein@boxen:~$ time sage -gp < /dev/null
> real 0m0.030s
> user 0m0.000s
> sys 0m0.010s
> wstein@boxen:~$ time sage -python < /dev/null
> real 0m0.048s
> user 0m0.020s
> sys 0m0.020s
>
> Other commands such as "sage -hg" will also suddenly take 50% longer
> if we make this switch using Python.
50% is one way to say it, but (on my machine) 0.06 seconds is another
way. I don't think I'll notice the difference when running "sage --
hg". I don't use "sage --gp", but I don't see this being a problem
for just running the command-line interpreter -- a slight delay at the
beginning is not a big deal. If you are going to run "sage --gp",
passing it a single command to execute, and repeating it many times,
then there might be an issue, but then you should do "sage --sh"
first, then just use "gp" to avoid any overhead.
> > I see that bash has
> > a "getopts" builtin, although it doesn't do --style arguments. I
> > downloaded shflags, which Tim suggested, and using it amounts to sourcing a
> > 31KB shell library, which seems like a pretty reasonable, uh, option --
> > check outhttp://code.google.com/p/shflags/wiki/Documentation10x
>
> How long does it take?
This may be an option (but Dan Drake's post suggests otherwise?), but
not written by me: I don't know how to write shell scripts. If
someone else wants to do this, please go ahead.
Meanwhile, I've posted a Python/optparse version at
<http://trac.sagemath.org/sage_trac/ticket/21>.
This deletes the "sage --darcs" option but keeps all of the others.
--
John
John H Palmieri
wrote:
> > - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
>
> I find these incredibly useful!
Great! I thought someone had said that they were broken, so I'm happy
that they're not.
--
John
Nick Alexander
+1. In fact, I tried to do this years ago, but my patch broke all
over the place and was bit-bucketed quickly :(
Nick
William Stein
I'm still concerned about slowing down all of the "sage
-various_system" commands. A typical use case of Sage for some
sysadmins is to install Sage system-wide, type "sage:
install_scripts('/usr/local/bin/')", and get scripts "gp", "gap",
etc., in /usr/local/bin/, which just call the corresponding "sage
-gp","sage -gap", etc. It's really sad if all of those scripts
become significantly slower (over twice as slow) just because of this
switch.
I've written many interactive webpages that use cgi-bin, and for them
it matters a lot how long "sage -gp" takes. Also, many people will
attest to using "sage -gp" for a quick computation instead of "sage",
just because it is so fast.
I think the tradeoff for using shflags is more reasonable, though
obviously the OS X issue is significant.
Another possibility might be to first check for "--gp", "--gap", etc.,
and do those before doing the general option parsing. I.e., just do
what you already planned, but with one optimization to deal with this
use case.
-- William
Robert Bradshaw
For reference, http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3cbd24be221/3b4ab29f1e115961
In any case, I would now be in favor of such a move. As for making the
transition, I'm not a huge fan of trying to control it via environment
variables (at least, once it's beyond the extremely experimental
stage). Once we have the back end, lets start using it by making a
substitution for a fixed list of command, e.g. '-notebook' -> '--
notebook' before invoking . Down the road we can add deprecation
warnings whenever such a substitution is made, and eventually get rid
of this step altogether.
Perhaps keeping the old code around and usable in some form would be
worth it for a while, because bugs here could be rather debilitating.
- Robert
Robert Bradshaw
That's a good point. Also, we don't want to be messing with any of the
options that might come after sage --gap. This would probably be a
quick optimization, if the first option is X where X is in some list,
dispatch to X right away.
- Robert
John H Palmieri
>
> I'm still concerned about slowing down all of the "sage
> -various_system" commands. A typical use case of Sage for some
> sysadmins is to install Sage system-wide, type "sage:
> install_scripts('/usr/local/bin/')", and get scripts "gp", "gap",
> etc., in /usr/local/bin/, which just call the corresponding "sage
> -gp","sage -gap", etc. It's really sad if all of those scripts
> become significantly slower (over twice as slow) just because of this
> switch.
I still don't think that "twice as slow" == "significantly slower": if
the difference is around 5/100 of a second, it's slower, but is it
significant? We should test it to see if it's actually noticeable.
> I've written many interactive webpages that use cgi-bin, and for them
> it matters a lot how long "sage -gp" takes.
This is possibly a good point, but again it needs testing.
> Also, many people will
> attest to using "sage -gp" for a quick computation instead of "sage",
> just because it is so fast.
>
> I think the tradeoff for using shflags is more reasonable, though
> obviously the OS X issue is significant.
As I said, I don't know anything about writing shell scripts, but if
someone else wants to do this, that's fine with me. If there is an
issue on OS X, though, that's a problem, and it also suggests a lack
of portability. (What about Solaris, for instance?) One advantage to
working with Python is that we know what version of Python we're
using, because we actually install it. So we ought to be able to make
a Python-based version very portable.
> Another possibility might be to first check for "--gp", "--gap", etc.,
> and do those before doing the general option parsing. I.e., just do
> what you already planned, but with one optimization to deal with this
> use case.
That's an interesting idea.
--
John
John H Palmieri
On Mar 19, 11:13 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Mar 19, 2010, at 10:23 AM, Nick Alexander wrote:
>
>
>
>
>
>
>
> > On 19-Mar-10, at 6:53 AM, Jason Grout wrote:
>
> >> On 03/18/2010 10:05 PM, John H Palmieri wrote:
> >>> Sage uses non-standard command-line options (e.g., -notebook rather
> >>> than --notebook). I propose that we switch to standard ones. Here
> >>> are
> >>> two reasons:
>
> >> +1!
>
> >> When this issue came up a year or two ago, there seemed to be a
> >> surprising amount of opposition to typing the extra dash, so the
> >> interest in changing the options and parsing waned. I would be
> >> very happy to see us switch to standard GNU option parsing.
>
> > +1. In fact, I tried to do this years ago, but my patch broke all
> > over the place and was bit-bucketed quickly :(
>
> For reference,http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3...
>
> In any case, I would now be in favor of such a move. As for making the
> transition, I'm not a huge fan of trying to control it via environment
> variables (at least, once it's beyond the extremely experimental
> stage). Once we have the back end, lets start using it by making a
> substitution for a fixed list of command, e.g. '-notebook' -> '--
> notebook' before invoking . Down the road we can add deprecation
> warnings whenever such a substitution is made, and eventually get rid
> of this step altogether.
>
> Perhaps keeping the old code around and usable in some form would be
> worth it for a while, because bugs here could be rather debilitating.
My patch basically just creates a new file, sage-sage.py, and
SAGE_ROOT/sage calls it (right now depending on the value of an
environment variable) instead of sage-sage. So the original parser
sage-sage is still there. I've slightly modified it, adding "--merge"
to the existing option "-merge", for instance, but it's essentially
intact.
--
John
William Stein
Nice. So basically it calls sage-sage, and if that doesn't parse any
options, it then calls sage-sage.py? In that case, "sage -gp" won't
be any slower at all.
I think this is a great architecture, and we can get rid of most of
sage-sage, but leave a little for speed purposes.
William
John H Palmieri
> On Fri, Mar 19, 2010 at 9:00 AM, John H Palmieri <jhpalmier...@gmail.com> wrote:
>
> Another possibility might be to first check for "--gp", "--gap", etc.,
> and do those before doing the general option parsing. I.e., just do
> what you already planned, but with one optimization to deal with this
> use case.
This was within my shell-scripting abilities, so I've incorporated it
into the patch at #21. Now "sage --gp" starts as quickly as it did
before.
--
John
John H Palmieri
On Mar 19, 2:29 pm, William Stein <wst...@gmail.com> wrote:
In the most recent patch, it does this:
1. The file SAGE_ROOT/sage calls the new shell script sage-sage-
quickstart, which runs sage-env and then checks for --gp, --hg, etc.
2. If it finds one of these options, sage-sage-quickstart runs the
corresponding program (passing the rest of the command line as
arguments). If it doesn't find one, it runs either sage-sage (which
now no longer runs sage-env) or sage-sage.py (the new parser) to parse
the command line, depending on the value of the environment variable
SAGE_NEW_OPTIONS. So the old sage-sage doesn't get run at all if this
variable is set.
--
John
Ondrej Certik
What is the status of this?
I didn't find the sage-sage.py in here:
http://hg.sagemath.org/scripts-main/
Ondrej
Robert Bradshaw
Ondrej Certik
Ah, ok, thanks!
Ondrej