On Sun, Mar 4, 2012 at 3:48 AM, R. Andrew Ohana wrote:
>
> On Mar 4, 2012 3:12 AM, "Robert Bradshaw"
> wrote:
>>
>> On Sat, Mar 3, 2012 at 3:21 PM, R. Andrew Ohana
>> wrote:
>> > I've created a repo on github: github.com/ohanar/sagescripts
>> >
>> > Much of the backbone has been setup, although
On 2012-03-04 11:29, R. Andrew Ohana wrote:
> Can you be more specific? Introducing the two variables or decoupling
> sage-scripts?
I meant "decoupling sage-scripts". And the consequences all depend on
the approach you're taking. Anyway, there already is a ticket but no
consensus on how to do it:
"R. Andrew Ohana" writes:
> I mainly wanted a clean repo to start with, but given how simple it is to move
> over scripts now, I'll see about basing it off of the current scripts repo
> next
> time I work on it.
I converted the current scripts repo to git and put it on the sagemath
org on github
On Mar 4, 2012 2:42 AM, "Keshav Kini" wrote:
>
> "R. Andrew Ohana" writes:
> > I've created a repo on github: github.com/ohanar/sagescripts
>
> From https://github.com/ohanar/sagescripts/blob/master/README :
> > it should be relatively easy at this point to move old bash scripts
> > into this rep
On Mar 4, 2012 3:12 AM, "Robert Bradshaw"
wrote:
>
> On Sat, Mar 3, 2012 at 3:21 PM, R. Andrew Ohana
wrote:
> > I've created a repo on github: github.com/ohanar/sagescripts
> >
> > Much of the backbone has been setup, although I've ported very few
> > actual scripts (the ones there are mainly to
On Sat, Mar 3, 2012 at 3:21 PM, R. Andrew Ohana wrote:
> I've created a repo on github: github.com/ohanar/sagescripts
>
> Much of the backbone has been setup, although I've ported very few
> actual scripts (the ones there are mainly to test that my generating
> code actually does what I want it to
"R. Andrew Ohana" writes:
> I've created a repo on github: github.com/ohanar/sagescripts
>From https://github.com/ohanar/sagescripts/blob/master/README :
> it should be relatively easy at this point to move old bash scripts
> into this repo (python scripts to come)
Wait, are you planning to just
On Mar 3, 2012 11:47 PM, "Jeroen Demeyer" wrote:
>
> On 2012-03-04 00:21, R. Andrew Ohana wrote:
> > Also, I would like to decouple the sage-scripts spkg from sage
> > releases, since in many cases it seems like the only change is a
> > version bump. I've added SAGE_VERSION and SAGE_RELEASE_DATE t
On 2012-03-04 00:21, R. Andrew Ohana wrote:
> Also, I would like to decouple the sage-scripts spkg from sage
> releases, since in many cases it seems like the only change is a
> version bump. I've added SAGE_VERSION and SAGE_RELEASE_DATE to
> sage-env, which can hopefully remedy this.
Please don't.
I've created a repo on github: github.com/ohanar/sagescripts
Much of the backbone has been setup, although I've ported very few
actual scripts (the ones there are mainly to test that my generating
code actually does what I want it to).
The way it is setup is pretty basic:
Scripts will still be w
On Fri, Mar 2, 2012 at 1:27 AM, Jason Grout wrote:
> On 3/2/12 2:55 AM, Robert Bradshaw wrote:
>>
>> I think sage foo ... should default to running bin/sage-foo (in the
>> sage environment) if it exists, and treat foo as a file otherwise.
>> Virtually no argument parsing (aside from understanding
Jason Grout writes:
> -1 to magic parsing of 'sage foo'. What if sage-foo was later added
> to sage? Then things would break for people.
I agree. This works for `git` only because `git ` is not valid
usage.
> I like the idea of 'sage run foo' to run foo. How would that be added
> to a script
On 3/2/12 2:55 AM, Robert Bradshaw wrote:
I think sage foo ... should default to running bin/sage-foo (in the
sage environment) if it exists, and treat foo as a file otherwise.
Virtually no argument parsing (aside from understanding --) would be
involved here, and the decision to use bash/python/
On 02/28/2012 03:45 PM, 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 changing directory o
John H Palmieri writes:
> With the current setup, "foo.sage" needs to be preparsed into a Python file,
> and the way Sage knows to preparse it is to recognize its extension ".sage":
> see the script sage-run. I think if you do "sage foo", then it treats "foo" as
> a Python file. So I guess there i
On Tuesday, February 28, 2012 12:45:08 PM UTC-8, 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
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 changing directory or deleting/moving the file. One
>> m
On Tue, Feb 28, 2012 at 8:43 AM, Keshav Kini wrote:
> On Tue, Feb 28, 2012 at 23:54, Michael Orlitzky wrote:
>> On 02/27/12 15:51, R. Andrew Ohana wrote:
>> > 2) The standard solution has been brought up, and I think it is decent
>> > one; we use an escape mode with a double dash (e.g. sage --
>>
On Tue, Feb 28, 2012 at 23:54, Michael Orlitzky wrote:
> On 02/27/12 15:51, R. Andrew Ohana wrote:
> > 2) The standard solution has been brought up, and I think it is decent
> > one; we use an escape mode with a double dash (e.g. sage --
> > some_script.sage).
>
> This should probably be the fallb
On 02/27/12 15:51, R. Andrew Ohana wrote:
>
> 2) How would we handle sage scripts (or other things that are truly
> arguments and not subcommands)
> 2) The standard solution has been brought up, and I think it is decent
> one; we use an escape mode with a double dash (e.g. sage --
> some_script.s
That SEP suggests adding subcommands similar to what Andrew suggested. But
I don't agree with removing sage -t etc because you can get the same
functionality with make.
David
On Mon, Feb 6, 2012 at 05:08, Keshav Kini wrote:
> I just found this SEP (Sage Enhancement Proposal), which one might wa
I just found this SEP (Sage Enhancement Proposal), which one might want to
take a look at: http://wiki.sagemath.org/UnifiedCommandLineSEP
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this grou
P.S. Link to the ticket http://trac.sagemath.org/sage_trac/ticket/21
(although most of what is there is old to very old).
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 tic
23 matches
Mail list logo
