Julien Puydt writes:
> Le 31/08/2012 00:19, Robert Bradshaw a écrit :
>> On Thu, Aug 30, 2012 at 12:17 PM, David Roe wrote:
What in particular was bothersome about github?
>
>> Issue-tracking in particular is sub-par on github (though I've heard
>> they've been working on this), and having t
Le 31/08/2012 00:19, Robert Bradshaw a écrit :
On Thu, Aug 30, 2012 at 12:17 PM, David Roe wrote:
What in particular was bothersome about github?
Issue-tracking in particular is sub-par on github (though I've heard
they've been working on this), and having to both is a pain. There's
also the
On Thu, Aug 30, 2012 at 12:17 PM, David Roe wrote:
>>
>> What in particular was bothersome about github?
>
> I don't remember all the details, but I think having to deal with both
> trac and github got very tiresome. We don't want to move completely
> to github since we have a bunch of existing t
>
> What in particular was bothersome about github?
I don't remember all the details, but I think having to deal with both
trac and github got very tiresome. We don't want to move completely
to github since we have a bunch of existing tickets and progress on
trac. So we decided to try making git
On 8/30/12 1:20 PM, Keshav Kini wrote:
Jason Grout writes:
On 8/30/12 1:10 PM, Julien Puydt wrote:
Le 30/08/2012 19:51, Jason Grout a écrit :
If/when we move to github or to bitbucket or something, where people can
easily push their own branches, it will be much more natural to push
your in-p
Jason Grout writes:
> On 8/30/12 1:10 PM, Julien Puydt wrote:
>> Le 30/08/2012 19:51, Jason Grout a écrit :
>>> If/when we move to github or to bitbucket or something, where people can
>>> easily push their own branches, it will be much more natural to push
>>> your in-progress code up and collabo
On Thursday, August 30, 2012 1:52:17 PM UTC-4, jason wrote:
>
>
> I post in-progress code to trac because:
>
> 1. It's a backup of the code. There has been several times when I
> wanted to go back to an old patch and work on it more, but the only
> place I could find it was a copy I had put u
On 8/30/12 1:10 PM, Julien Puydt wrote:
Le 30/08/2012 19:51, Jason Grout a écrit :
If/when we move to github or to bitbucket or something, where people can
easily push their own branches, it will be much more natural to push
your in-progress code up and collaborate.
*IF* !?
Progress seems to
Le 30/08/2012 19:51, Jason Grout a écrit :
If/when we move to github or to bitbucket or something, where people can
easily push their own branches, it will be much more natural to push
your in-progress code up and collaborate.
*IF* !?
Snark on #sagemath
--
You received this message because yo
On 2012-08-30 19:51, Jason Grout wrote:
> I post in-progress code to trac because:
>
> 1. It's a backup of the code. There has been several times when I
> wanted to go back to an old patch and work on it more, but the only
> place I could find it was a copy I had put up on trac.
> 2. It lets othe
On 8/30/12 12:42 PM, Luis Finotti wrote:
Firstly, thanks all for the replies.
On Thursday, August 30, 2012 12:54:31 PM UTC-4, Simon King wrote:
Hi Luis,
On 2012-08-30, Michael Orlitzky >
wrote:
>
> In general, if you're trying to sidestep the mercurial workflow,
Firstly, thanks all for the replies.
On Thursday, August 30, 2012 12:54:31 PM UTC-4, Simon King wrote:
>
> Hi Luis,
>
> On 2012-08-30, Michael Orlitzky >
> wrote:
> >
> > In general, if you're trying to sidestep the mercurial workflow, ...
>
> Are you? It seems to me that following the mercur
On Aug 30, 9:54 am, Simon King wrote:
> Do "hg qimport /path/to/my.patch"
> * The previous command was importing the patch, but not *applying* it.
> Hence, do "hg qpush"
> * Rebuild your new Sage version ("../../sage -br" or so)
I found the abbreviation
hg qimport -P ...
to combine the
Hi Luis,
On 2012-08-30, Michael Orlitzky wrote:
> On 08/30/2012 12:36 PM, Luis Finotti wrote:
>> Dear all,
>>
>> I had some changes made in a older version of sage. I wanted to create
>> a patch that I can apply to a new install, without uploading to trac (as
>> the changes are not "good enough
On 8/30/12 11:36 AM, Luis Finotti wrote:
Dear all,
I had some changes made in a older version of sage. I wanted to create
a patch that I can apply to a new install, without uploading to trac (as
the changes are not "good enough"). Can anyone tell me the necessary
commands or point me in the ri
On 08/30/2012 12:36 PM, Luis Finotti wrote:
> Dear all,
>
> I had some changes made in a older version of sage. I wanted to create
> a patch that I can apply to a new install, without uploading to trac (as
> the changes are not "good enough"). Can anyone tell me the necessary
> commands or point
Dear all,
I had some changes made in a older version of sage. I wanted to create a
patch that I can apply to a new install, without uploading to trac (as the
changes are not "good enough"). Can anyone tell me the necessary commands
or point me in the right direction?
Best,
Luis
--
You rec
Hello,
I am currently an software development intern at Inktank [1] although my
undergraduate background was in physics and mathematics, well as much as
one can have a background in those fields as an undergraduate at a liberal
arts college, the Salvus project sounds exactly what I wanted to de
Hello,
I am a software development intern at Inktank [1] in Los Angeles and I
would also be interested in helping with this project, as well Salvus. I
know that the automatic creation of virtual machine images is a problem
that we had to tackle so there is a body of tools that could probably be
Hello,
I am a software development intern at Inktank [1] in Los Angeles and I
would also be interested in helping with this project, as well Salvus. I
know that the automatic creation of virtual machine images is a problem
that we had to tackle so there is a body of tools that could probably be
On 2012-08-30 13:17, Simon King wrote:
> Assume that there are five patches on a ticket with a positive review.
> Would it make life easier for you if we'd fold the five patches into one? Or
> is it alright to keep the five patches separate?
I should add: even more important than this is the fact
On 2012-08-30 17:00, Simon King wrote:
> If patches concern different topics, then I'd like to have them on
> different tickets.
Off topic, but I couldn't agree more.
There are a lot of "failed" tickets (i.e. needs_work forever) which
failed because they were trying to do too much at once. I like
Hi!
On 2012-08-30, kcrisman wrote:
> However, in some cases there is a sort of patcherrhea and folding them
> together is wise, so think about it on a case by case basis. What would
> *you* want as a reviewer or release manager for your patch, on specific
> ticket X?
If patches concern diffe
Here is a very interesting article mentioned on Slashdot:
http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html
It's about Google figuring out how to securely host user content. It
reminds me of some of the issues we've dealt with in having public Sage
notebooks
On 2012-08-30 16:11, kcrisman wrote:
>
> >
> > Luckily, we have lots of those in the developer pool :)
> Unfortunately, not on the buildbots (we only have one OS X 10.4 PPC and
> one OS X 10.6 x86_64 machine).
>
>
> Sorry, I meant that a lot of people report their results on vari
>
>
> >
> > Luckily, we have lots of those in the developer pool :)
> Unfortunately, not on the buildbots (we only have one OS X 10.4 PPC and
> one OS X 10.6 x86_64 machine).
>
Sorry, I meant that a lot of people report their results on various
machines, including Lion and occasionally 10.5.
Le 30/08/2012 15:13, Simon King a écrit :
Thanks for all your comments! So, it seems people agree that having
several small patches is good for reviewing. But once it has a positive
review, the patches should be folded.
Other open source projects do things like this : a patch is for a single
c
On 2012-08-30 15:13, kcrisman wrote:
>
>
> On Wednesday, August 29, 2012 4:44:55 PM UTC-4, Matthew Alton wrote:
>
> I have 5 SPARC machines at the house. I don't know if any of them
> will run the current version of Solaris. They're pretty geriatric.
>
> I have access to an AIX ma
> > Thanks for all your comments! So, it seems people agree that having
> > several small patches is good for reviewing. But once it has a positive
> > review, the patches should be folded.
>
> +1
>
Again, unless there are different authors. And I'm sure Jeroen would
point out that sometimes err
On Thu, Aug 30, 2012 at 9:13 AM, Simon King wrote:
> Hi all!
>
> On 2012-08-30, Francois Bissey wrote:
>> On 30/08/12 23:19, Jeroen Demeyer wrote:
>>> On 2012-08-30 13:17, Simon King wrote:
Hi!
This is a question to the release manager(s):
Assume that there are five patch
Making it easy for the reviewer is definitely a bonus of not folding.
Another reason not to fold is if the patches have different authors.
Finally, if some of the patches change things in earlier patches in direct
response to reviewer comments, folding them can make it hard to trace
whether t
Hi all!
On 2012-08-30, Francois Bissey wrote:
> On 30/08/12 23:19, Jeroen Demeyer wrote:
>> On 2012-08-30 13:17, Simon King wrote:
>>> Hi!
>>>
>>> This is a question to the release manager(s):
>>>
>>> Assume that there are five patches on a ticket with a positive review.
>>> Would it make life ea
On Wednesday, August 29, 2012 4:44:55 PM UTC-4, Matthew Alton wrote:
>
> I have 5 SPARC machines at the house. I don't know if any of them will
> run the current version of Solaris. They're pretty geriatric.
>
> I have access to an AIX machine with a C compiler. We're good there. It
> was t
On 30 August 2012 12:19, Jeroen Demeyer wrote:
> On 2012-08-30 13:17, Simon King wrote:
>> Hi!
>>
>> This is a question to the release manager(s):
>>
>> Assume that there are five patches on a ticket with a positive review.
>> Would it make life easier for you if we'd fold the five patches into on
On 30/08/12 23:19, Jeroen Demeyer wrote:
> On 2012-08-30 13:17, Simon King wrote:
>> Hi!
>>
>> This is a question to the release manager(s):
>>
>> Assume that there are five patches on a ticket with a positive review.
>> Would it make life easier for you if we'd fold the five patches into one? Or
>
On 2012-08-30 13:17, Simon King wrote:
> Hi!
>
> This is a question to the release manager(s):
>
> Assume that there are five patches on a ticket with a positive review.
> Would it make life easier for you if we'd fold the five patches into one? Or
> is it alright to keep the five patches separat
Hi!
This is a question to the release manager(s):
Assume that there are five patches on a ticket with a positive review.
Would it make life easier for you if we'd fold the five patches into one? Or
is it alright to keep the five patches separate?
Best regards,
Simon
--
You received this messa
An update:
The ticket
http://trac.sagemath.org/sage_trac/ticket/13304
does not solve this problem.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group,
Hi,
I am working on linear codes and I observed a high memory consumption when
constructing codes of large length. I figured out that this problem already
appears in the construction of vector spaces:
sage: F. = GF(4)
sage: M = MatrixSpace(F, 8, 1).random_element()
sage: V = VectorSpace(F,
39 matches
Mail list logo
