On Mar 19, 2010, at 11:06 AM, William Stein wrote:
On Fri, Mar 19, 2010 at 9:00 AM, John H Palmieri <jhpalmier...@gmail.com
> wrote:
On Mar 19, 1:36 am, William Stein <wst...@gmail.com> wrote:
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):
wst...@boxen:~$ time sage -gp < /dev/null
real 0m0.030s
user 0m0.000s
sys 0m0.010s
wst...@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'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.
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
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@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.
