Robert Bradshaw writes:
> On Mon, Feb 20, 2012 at 8:21 PM, Keshav Kini wrote:
>> The following would occur when you did `sage -b`:
>>
>> 1. sage-.ebuild would be copied out of the Sage library tree,
>> specifically out of the tree of the revision at the head of the
>> trac-12345 branch o
On Mon, Feb 20, 2012 at 8:21 PM, Keshav Kini wrote:
> On Tue, Feb 21, 2012 at 07:27, Robert Bradshaw
> wrote:
>> On Mon, Feb 20, 2012 at 6:45 AM, Keshav Kini wrote:
>>> Robert Bradshaw writes:
But yes, this sounds like a great idea! So the
collection of .ebuild files (and their suppor
On Tue, Feb 21, 2012 at 07:27, Robert Bradshaw
wrote:
> On Mon, Feb 20, 2012 at 6:45 AM, Keshav Kini wrote:
>> Robert Bradshaw writes:
>>> But yes, this sounds like a great idea! So the
>>> collection of .ebuild files (and their supporting patches, etc.) is in
>>> the Sage repository, but period
On Mon, Feb 20, 2012 at 6:45 AM, Keshav Kini wrote:
> Robert Bradshaw writes:
>> On Fri, Feb 17, 2012 at 1:09 AM, Keshav Kini wrote:
>>> Robert Bradshaw writes:
>>> In the category of "glue code" I meant to include everything in
>>> $SAGE_LOCAL/bin/sage-*. I see much of that stuff as more relat
Robert Bradshaw writes:
> On Fri, Feb 17, 2012 at 1:09 AM, Keshav Kini wrote:
>> Robert Bradshaw writes:
>> In the category of "glue code" I meant to include everything in
>> $SAGE_LOCAL/bin/sage-*. I see much of that stuff as more related to
>> maintenance of the entire distribution of software
On Fri, Feb 17, 2012 at 1:09 AM, Keshav Kini wrote:
> Robert Bradshaw writes:
>>> But considering that we might one day want to make part of the Sage
>>> library possible to install into your system Python distribution
>>> (right?), it might be a good idea to keep it separate from the
>>> "infras
Robert Bradshaw writes:
>> But considering that we might one day want to make part of the Sage
>> library possible to install into your system Python distribution
>> (right?), it might be a good idea to keep it separate from the
>> "infrastructure" part of Sage.
>
> While that's a nice idea, there
On Thu, Feb 16, 2012 at 3:32 AM, Keshav Kini wrote:
> Robert Bradshaw writes:
>>> Well, considering among other things the recent discussions about
>>> licensing, I don't think that it's going to be possible to have a single
>>> top-level repository for all Sage code.
>>
>> But for everything not
Robert Bradshaw writes:
>> Well, considering among other things the recent discussions about
>> licensing, I don't think that it's going to be possible to have a single
>> top-level repository for all Sage code.
>
> But for everything not part of the upstream packages, licensing
> shouldn't be an
On Wed, Feb 15, 2012 at 10:35 PM, Keshav Kini wrote:
> Robert Bradshaw writes:
>
>> On Thu, Feb 9, 2012 at 7:53 AM, Jason Grout
>> wrote:
>>> You correctly interpreted my response, and I agree with your conclusions. I
>>> haven't used the sage branch-handling code in years.
>>
>> I used them e
Robert Bradshaw writes:
> On Thu, Feb 9, 2012 at 7:53 AM, Jason Grout
> wrote:
>> You correctly interpreted my response, and I agree with your conclusions. I
>> haven't used the sage branch-handling code in years.
>
> I used them extensively when (1) I was working on my thesis, and
> wanted a
On Feb 9, 5:44 pm, William Stein wrote:
> On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout
> wrote:
> > On 2/9/12 4:28 PM, Michael Orlitzky wrote:
>
> >> I think if we could get rid of a few magic commands in favor of 'mv',
> >> 'cp', and 'ln', it would make the process seem less daunting.
>
> > +1
On Thu, Feb 9, 2012 at 2:28 PM, Michael Orlitzky wrote:
> A personal anecdote: I've used sage for about 4 years, but only started
> contributing in the last couple of months because the development process
> looks scary to an outsider.
>
> When I started, at every step of the process, I already kn
On 2/9/12 4:44 PM, William Stein wrote:
On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout wrote:
On 2/9/12 4:28 PM, Michael Orlitzky wrote:
I think if we could get rid of a few magic commands in favor of 'mv',
'cp', and 'ln', it would make the process seem less daunting.
+1. And then the new us
On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout wrote:
> On 2/9/12 4:28 PM, Michael Orlitzky wrote:
>
>> I think if we could get rid of a few magic commands in favor of 'mv',
>> 'cp', and 'ln', it would make the process seem less daunting.
>
>
> +1. And then the new user that is learning how to do sa
On 2/9/12 4:28 PM, Michael Orlitzky wrote:
I think if we could get rid of a few magic commands in favor of 'mv',
'cp', and 'ln', it would make the process seem less daunting.
+1. And then the new user that is learning how to do sage has skills
that transfer elsewhere.
Jason
--
To post t
On 02/09/2012 04:18 PM, kcrisman wrote:
I think you are totally missing the point. To a newbie who has heard
of the following:
cd
mv
hg
ln
you are right. My assumption is that we would like to be as inviting
as possible to those who have not. (And they are legion; think of the
Windows world
> Would you have any objection to getting rid of the actual commands
> `sage -clone`, `sage -b ` (just plain `sage -b` would stay of
> course), and friends, so that this behavior can be removed? Again, you
> could easily do this stuff manually:
>
> $ cd $SAGE_ROOT/devel/
> $ mv sage vanilla
> $ hg
On Thu, Feb 9, 2012 at 7:53 AM, Jason Grout wrote:
> On 2/9/12 9:44 AM, Keshav Kini wrote:
>>
>> On Thu, Feb 9, 2012 at 23:30, Jason Grout
>> wrote:
>>>
>>> I use separate directories in devel/ to have multiple versions of the new
>>> sage notebook installed. They're almost all git repositories,
On Fri, Feb 10, 2012 at 00:51, kcrisman wrote:
> I think it's great that we've made the updates to the developer guide
> that explain queues, and I have been using them a lot more for the
> last year or so. But remember, a lot of the infrastructure was put in
> place in order to aid new developer
On Feb 9, 11:15 am, John Cremona wrote:
> People are answering the question I intended to ask. So far no-one
> uses the branching mechanism. Who knows if it still worksif it
> doesn't someone should remove mention of it from the docs.
Oh, it works, or at least has within the last year.
I
People are answering the question I intended to ask. So far no-one
uses the branching mechanism. Who knows if it still worksif it
doesn't someone should remove mention of it from the docs.
John
On 9 February 2012 15:53, Jason Grout wrote:
> On 2/9/12 9:44 AM, Keshav Kini wrote:
>>
>> On Th
On 2/9/12 9:44 AM, Keshav Kini wrote:
On Thu, Feb 9, 2012 at 23:30, Jason Grout wrote:
I use separate directories in devel/ to have multiple versions of the new
sage notebook installed. They're almost all git repositories, though :). I
don't know if that counts as a yes or no to your question
On Thu, Feb 9, 2012 at 23:30, Jason Grout wrote:
> I use separate directories in devel/ to have multiple versions of the new
> sage notebook installed. They're almost all git repositories, though :). I
> don't know if that counts as a yes or no to your question.
IMO it's important to note that
On 2/9/12 9:01 AM, John Cremona wrote:
Does anyone still use branches?
I use separate directories in devel/ to have multiple versions of the
new sage notebook installed. They're almost all git repositories,
though :). I don't know if that counts as a yes or no to your question.
Jason
--
On Feb 9, 2012 7:01 AM, "John Cremona" wrote:
>
> Does anyone still use branches?
I haven't in years!
>I used to always do a "sage -clone"
> right after building a test version, but since using queues I never do
> that. If I need to test something which affects more than the Sage
> library, not
Does anyone still use branches? I used to always do a "sage -clone"
right after building a test version, but since using queues I never do
that. If I need to test something which affects more than the Sage
library, notably a new version of an spkg, I just copy the entire
build using cp -r, and wo
On Thu, Feb 9, 2012 at 01:45, William Stein wrote:
> On Tue, Feb 7, 2012 at 9:57 PM, Keshav Kini wrote:
>> My $0.02.
>
> I disagree with what you wrote above. Perhaps you have a different
> impression than me of how Mercurial is used, given the relative sizes
> of our contributions to the Sage l
On Tue, Feb 7, 2012 at 9:57 PM, Keshav Kini wrote:
> Sorry, I managed to activate some button on Google Groups accidentally and
> prematurely post the above message...
>
> +100. Our main problem with Mercurial is that we are not *using* it. We are
> just using Mercurial as a way for Jeroen to gene
Done!
-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 group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sag
> +100. Our main problem with Mercurial is that we are not *using* it. We
> are just using Mercurial as a way for Jeroen to generate changelogs, and no
> other collaborative purpose whatsoever (despite what individual developers
> such as William might be doing with qfinishing patches, committing,
Sorry, I managed to activate some button on Google Groups accidentally and
prematurely post the above message...
+100. Our main problem with Mercurial is that we are not *using* it. We are
just using Mercurial as a way for Jeroen to generate changelogs, and no
other collaborative purpose whatso
+100.
--
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
On 2012-02-07 21:08, William Stein wrote:
> What I'm suggesting is that the script that auto-adds ticket numbers
> should strip the user-added ticket number first, to avoid extensive
> duplication.
If you send me the magic sed/awk/perl/python/whatever script to do this,
I'll happily use it :-)
--
On 2/7/12 3:17 PM, William Stein wrote:
OK, I'm beginning to be convinced Mercurial is kind of lacking
(compared to git) if the only way for 99% of us to use it is to only
use queues.
To be fair, it's more our workflow than mercurial itself. You have pull
requests and things like that with Me
On Tue, Feb 7, 2012 at 12:59 PM, Jason Grout
wrote:
> On 2/7/12 2:46 PM, William Stein wrote:
>>
>> On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout
>> wrote:
>>>
>>> On 2/7/12 2:16 PM, Robert Bradshaw wrote:
On Tue, Feb 7, 2012 at 12:08 PM, William Stein
wrote:
>
>
On Tue, Feb 7, 2012 at 12:59 PM, Jason Grout
wrote:
> On 2/7/12 2:46 PM, William Stein wrote:
>>
>> On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout
>> wrote:
>>>
>>> On 2/7/12 2:16 PM, Robert Bradshaw wrote:
On Tue, Feb 7, 2012 at 12:08 PM, William Stein
wrote:
>
>
On 2/7/12 2:46 PM, William Stein wrote:
On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout
wrote:
On 2/7/12 2:16 PM, Robert Bradshaw wrote:
On Tue, Feb 7, 2012 at 12:08 PM, William Steinwrote:
On Tue, Feb 7, 2012 at 12:00 PM, Simon King
wrote:
Hi William,
On 7 Feb., 20:47, William Stein
On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout
wrote:
> On 2/7/12 2:16 PM, Robert Bradshaw wrote:
>>
>> On Tue, Feb 7, 2012 at 12:08 PM, William Stein wrote:
>>>
>>> On Tue, Feb 7, 2012 at 12:00 PM, Simon King
>>> wrote:
Hi William,
On 7 Feb., 20:47, William Stein wrote:
>
On 2/7/12 2:16 PM, Robert Bradshaw wrote:
On Tue, Feb 7, 2012 at 12:08 PM, William Stein wrote:
On Tue, Feb 7, 2012 at 12:00 PM, Simon King wrote:
Hi William,
On 7 Feb., 20:47, William Stein wrote:
It's important (in fact, critical) that the trac ticket number is
clearly available in the c
On Tue, Feb 7, 2012 at 12:08 PM, William Stein wrote:
> On Tue, Feb 7, 2012 at 12:00 PM, Simon King wrote:
>> Hi William,
>>
>> On 7 Feb., 20:47, William Stein wrote:
>>> It's important (in fact, critical) that the trac ticket number is
>>> clearly available in the commit message. But having it
On Tue, Feb 7, 2012 at 12:00 PM, Simon King wrote:
> Hi William,
>
> On 7 Feb., 20:47, William Stein wrote:
>> It's important (in fact, critical) that the trac ticket number is
>> clearly available in the commit message. But having it twice in two
>> different ways in almost every message seems
Hi William,
On 7 Feb., 20:47, William Stein wrote:
> It's important (in fact, critical) that the trac ticket number is
> clearly available in the commit message. But having it twice in two
> different ways in almost every message seems a little bit sloppy to
> me.
We were told, by different rel
43 matches
Mail list logo
