On Fri, Jan 27, 2012 at 2:04 AM, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line options use a standard library, however, since it was
> opened (a long time ago), the
On Tuesday, February 28, 2012, Keshav Kini wrote:
> William Stein writes:
>> On Tue, Feb 28, 2012 at 8:43 AM, Keshav Kini
wrote:
>>> It's not actually a fallback for b), though. If a file does exist with
>>> the same name as a subcommand, b) makes it impossible to use that
>>> subcommand without
On 2012-01-29 22:29, Keshav Kini wrote:
> On Mon, Jan 30, 2012 at 05:27, Keshav Kini wrote:
>> Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for
>> example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b`
>> doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's
On Mon, Jan 30, 2012 at 05:27, Keshav Kini wrote:
> Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for
> example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b`
> doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's a
> workaround. The question then becomes, wo
On Mon, Jan 30, 2012 at 04:36, Ivan Andrus wrote:
> I agree it's ugly. I think what the user really wants is things like
>
> sage test --build-first
>
> rather than
>
> sage build test
>
> I can't imagine any ever wanting
>
> sage build shell test notebook
>
> In other words, the test command wou
On Jan 29, 2012, at 7:57 PM, Keshav Kini wrote:
>>> I think the key change should be to become Posix compliant, and
>>> these are allowable short options. And they combine nicely: "sage
>>> -bta" would mean rebuild everything and test everything.
>> These commands are odd. For most programs you
On Sun, Jan 29, 2012 at 13:55, R. Andrew Ohana wrote:
> On Sat, Jan 28, 2012 at 21:19, David Roe wrote:
>> * I would like to still allow "sage -t" as a way to access the "sage
>> test" subcommand, "sage -b" to access the "sage build" subcommand,
>> etc.
> This is fairly straightforward with the a
On Sat, Jan 28, 2012 at 21:19, David Roe wrote:
>> % sage ARGS # this would be for running sage scripts, or a couple of
>> oddball arguments
>> % sage notebook ARGS
>> % sage pkg ARGS # this would include spkg stuff
>> % sage pkg install # since install has some special flags like -f or -s
>> % sa
> % sage ARGS # this would be for running sage scripts, or a couple of
> oddball arguments
> % sage notebook ARGS
> % sage pkg ARGS # this would include spkg stuff
> % sage pkg install # since install has some special flags like -f or -s
> % sage test ARGS
> % sage build ARGS
> % sage {python,maxim
On Friday, January 27, 2012 2:19:59 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2012-01-27 11:17, David Roe wrote:
> > Why? So that things like sage -i can work without python?
> Exactly.
>
And also for speed issues, as William brought up a year or two ago when we
discussed this sort of thing. If
On 2012-01-27 11:23, Keshav Kini wrote:
> We could bake into $SAGE_ROOT/sage (a shell script) the functionality to
> launch anything someone with an unbuilt copy of Sage would need (such as
> release management utilities or whatever you have in mind), which should
> be a pretty small subset of Sage
On Jan 27, 2012, at 11:32 AM, Keshav Kini wrote:
> On Fri, Jan 27, 2012 at 18:26, David Roe wrote:
>> We're working on rewriting the doctest framework only. So we're still
>> just sticking to hyphens, but are making them UNIX-compliant: --gdb
>> instead of -gdb for example. My first impression o
On Fri, Jan 27, 2012 at 02:32, Keshav Kini wrote:
> On Fri, Jan 27, 2012 at 18:26, David Roe wrote:
>> We're working on rewriting the doctest framework only. So we're still
>> just sticking to hyphens, but are making them UNIX-compliant: --gdb
>> instead of -gdb for example. My first impression
On Fri, Jan 27, 2012 at 02:26, David Roe wrote:
> We're working on rewriting the doctest framework only. So we're still
> just sticking to hyphens, but are making them UNIX-compliant: --gdb
> instead of -gdb for example. My first impression of your proposal is
> that I like it, though there are
On Fri, Jan 27, 2012 at 18:26, David Roe wrote:
> We're working on rewriting the doctest framework only. So we're still
> just sticking to hyphens, but are making them UNIX-compliant: --gdb
> instead of -gdb for example. My first impression of your proposal is
> that I like it, though there are
On Fri, Jan 27, 2012 at 18:28, William Stein wrote:
>> (Incidentally, why does $SAGE_LOCAL point to $SAGE_ROOT/local/bin and not
>> $SAGE_ROOT/local as the name would suggest?)
>>
>
> It does point to $SAGE_ROOT/local.
Oops, why did I think it didn't? Sorry for the noise. (I'll keep that
in mind
On Friday, January 27, 2012, Keshav Kini wrote:
> We could bake into $SAGE_ROOT/sage (a shell script) the functionality to
launch anything someone with an unbuilt copy of Sage would need (such as
release management utilities or whatever you have in mind), which should be
a pretty small subset of S
If we keep $SAGE_ROOT/sage as a shell script that calls the python script
$SAGE_ROOT/local/bin/sage-sage, we could work around the optional
subparsers issue in $SAGE_ROOT/sage itself, i.e. insert an argument "--" if
$1 is not in the list of sage-sage subparsers hardcoded into
$SAGE_ROOT/sage .
We're working on rewriting the doctest framework only. So we're still
just sticking to hyphens, but are making them UNIX-compliant: --gdb
instead of -gdb for example. My first impression of your proposal is
that I like it, though there are some ambiguities in the syntax: in
mercurial the subcomma
We could bake into $SAGE_ROOT/sage (a shell script) the functionality to
launch anything someone with an unbuilt copy of Sage would need (such as
release management utilities or whatever you have in mind), which should be
a pretty small subset of Sage's full functionality (right?). And then
$SA
On Fri, Jan 27, 2012 at 02:07, David Roe wrote:
> Come over to Padelford: Robert and I are working on something like this. :-)
Is it at all similar to what I proposed? If not, please share :)
> David
>
> On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana wrote:
>> So I've been looking into restart
On Fri, Jan 27, 2012 at 02:17, David Roe wrote:
> Why? So that things like sage -i can work without python?
> David
Which is a valid, given that we can do that now before building sage.
>
> On Fri, Jan 27, 2012 at 02:15, Jeroen Demeyer wrote:
>> On 2012-01-27 11:04, R. Andrew Ohana wrote:
>>> S
On 2012-01-27 11:17, David Roe wrote:
> Why? So that things like sage -i can work without python?
Exactly.
--
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
Why? So that things like sage -i can work without python?
David
On Fri, Jan 27, 2012 at 02:15, Jeroen Demeyer wrote:
> On 2012-01-27 11:04, R. Andrew Ohana wrote:
>> So I've been looking into restarting ticket #21 now that we have
>> argparse in python 2.7.
> -1 to making Python a requirement to
On 2012-01-27 11:04, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7.
-1 to making Python a requirement to run $SAGE_ROOT/sage.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group,
On Fri, Jan 27, 2012 at 02:11, William Stein wrote:
>
>
> On Friday, January 27, 2012, William Stein wrote:
>> I'm +1 to making sweeping changes to argument syntax & parsing in sage-5.0
>> or sage-6.0.
>>
>
> Though I don't want to loose any features... and have some respect for our
> 1-year depr
On Friday, January 27, 2012, William Stein wrote:
> I'm +1 to making sweeping changes to argument syntax & parsing in
sage-5.0 or sage-6.0.
>
Though I don't want to loose any features... and have some respect for our
1-year deprecation policy.
> On Friday, January 27, 2012, R. Andrew Ohana
wrot
I'm +1 to making sweeping changes to argument syntax & parsing in sage-5.0
or sage-6.0.
On Friday, January 27, 2012, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line o
Come over to Padelford: Robert and I are working on something like this. :-)
David
On Fri, Jan 27, 2012 at 02:04, R. Andrew Ohana wrote:
> So I've been looking into restarting ticket #21 now that we have
> argparse in python 2.7. The basic premise of the ticket was to make
> our command line opt
So I've been looking into restarting ticket #21 now that we have
argparse in python 2.7. The basic premise of the ticket was to make
our command line options use a standard library, however, since it was
opened (a long time ago), the command line options have become an
incredibly cluttered mess as
30 matches
Mail list logo
