On 2015-05-06 21:24, Volker Braun wrote:
There is no reason that closed should be final, until the new branch
is published we *can* always back. That doesn't mean that you *should*
dump a pile of extra bookkeeping on me.
Let me make it clear that I don't want to dump a pile of extra
Hello,
dev script are a mess (see #18356). Could I remove everthing in
sage/dev/ that is related to communication with the git server or the
trac server? The function would provide help and links to the
documentation instead.
I also want to keep the import-patch feature that is definitely
Hi All,
I think it would be a good idea to have a subcategory of associative
algebras
(and inheritance of classes from an associative class). Morphisms need to
know to check associativity.
On the other hand, I was convinced years ago (by an argument of Bergman
at Berkeley) that algebras
On 2015-05-07 06:15, Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an
Again, this is precisely what you should point out during the review
process.
But the review process has to end at one point if we ever want to merge a
ticket.
On Thursday, May 7, 2015 at 9:44:03 AM UTC+2, Nathann Cohen wrote:
Sure, in exceptional cases a positive_review / closed ticket
On Sat, Apr 18, 2015 at 10:48 AM, Julien Puydt julien.pu...@laposte.net wrote:
May I notice that :
(1) the ticket is in stage needs_review or positive_review ;
(2) what is actually reviewed is a precise commit in a git branch ;
(3) nothing forces the ticket and the branch to be synchronized.
On 2015-05-06 20:16, Clemens Heuberger wrote:
1) When the release manager starts to work on a ticket, he sets it to closed
in order to avoid further modification. This might lead to reopening closed
tickets when a problem arises in the merge.
2) The second part was about the automatic merge.
Sure, in exceptional cases a positive_review / closed ticket needs to be
unmerged. But that should be the exception, and not part of the normal flow.
In particular, just because you aren't finished bikeshedding / rearranging
the comments / fixing documentation typos is not enough of a reason;
In my experience, people don't set a ticket to needs_work because of
something trivial at that time. Less read the code anyway, once it is
already in positive_review ;-)
Or else they add a commit immediately.
(I don't strike myself as being very clear, these days O_o)
Nathann
--
You
Again, this is precisely what you should point out during the review
process.
But the review process has to end at one point if we ever want to merge a
ticket.
Oh, you meant *after* a positive review. I had misread, sorry.
In my experience, people don't set a ticket to needs_work because of
On 2015-05-06 21:08, Travis Scrimshaw wrote:
On #15635 http://trac.sagemath.org/ticket/15635, we are trying to
decide whether we want non-associative algebras to be included in the
catalog of algebras.
The argument against including them is most people think of algebras
as being associative
Can you try using the new eclib package at
http://trac.sagemath.org/ticket/18369 ?
It may not solve this problem, but we might as well troubleshoot on
the latest version (20150423).
I am not sure but it seems that during configuration it is picking up
different version of gmp / mpir. From the
We could add git trac as a standard package now, I haven't made any
changes outside of the release management stuff in a while
On Thursday, May 7, 2015 at 12:31:46 PM UTC+2, Jeroen Demeyer wrote:
On 2015-05-07 12:06, Vincent Delecroix wrote:
Hello,
dev script are a mess (see
Looks like I would want this single commit.
https://github.com/pexpect/pexpect/commit/aac5897aa12daf056b8fe08f1b6512d9f60c2d27
The branch seems otherwise strangely stale (210 commits
behind master). May be someone didn't merge it in the
right branch?
Francois
On 05/08/15 12:02, François Bissey
I have other ways but if it mostly work and the notebook also works
we may want to upgrade that antiquity like there is no tomorrow.
Francois
On 05/08/15 10:07, Bill Page wrote:
Maybe this patch solves the problem:
https://github.com/pexpect/pexpect/pull/109/files
I pulled pexpect 3.x from
Were they already deprecated, though? In that event there should be a
well-defined time at which they could be removed.
The documentation has been removed in #17555. If I remember correctly,
the associated sage-devel thread settled on something like we stop
advertising them but will keep the
On Thursday, May 7, 2015 at 7:20:58 AM UTC+2, leif wrote:
Well, this simply should not happen
Exactly. You keep proposing complicated processes to make room for
something that should not happen.
The only
difference being that *someone else* came to the conclusion it isn't yet
ready to
On 2015-05-07 12:06, Vincent Delecroix wrote:
Hello,
dev script are a mess (see #18356). Could I remove everthing in
sage/dev/ that is related to communication with the git server or the
trac server?
Please don't!
I still use the dev script occasionally for read-only access to the Trac
If you want doctests failures here is a sample (6.7.beta4):
sage -t --long /usr/lib64/python2.7/site-packages/sage/interfaces/expect.py
**
File /usr/lib64/python2.7/site-packages/sage/interfaces/expect.py, line 285,
in
Hi Travis,
On 2015-05-06, Travis Scrimshaw tsc...@ucdavis.edu wrote:
We would like to hear your thoughts on the matter,
I wouldn't like so much to denote something as non-bla (where bla
can be associative, commutative, unital, finite, ...), when non-bla
just means not necessarily bla.
So,
On 7 May 2015 at 22:29, François Bissey
francois.bis...@canterbury.ac.nz wrote:
Pushed a branch at http://trac.sagemath.org/ticket/10295 we can continue
the work there.
OK, thanks.
On 05/08/15 14:22, François Bissey wrote:
Unfortunately, the notebook is still broken with newer pexpect. If
On 05/08/15 14:08, Bill Page wrote:
On 7 May 2015 at 21:37, François Bissey
francois.bis...@canterbury.ac.nz wrote:
Looks like I would want this single commit.
https://github.com/pexpect/pexpect/commit/aac5897aa12daf056b8fe08f1b6512d9f60c2d27
The branch seems otherwise strangely stale (210
Unfortunately, the notebook is still broken with newer pexpect. If you try:
g=sin(x); plot(g,(x,-pi,3*pi/2))
You get this:
Python 2.7.8 (default, Apr 22 2015, 10:15:06)
[GCC 4.9.2] on linux2
Type help, copyright, credits or license for more information.
import os;os.chdir(/tmp/tmplVMYJZ);
On 2015-05-07 22:36, Volker Braun wrote:
We could add git trac as a standard package now, I haven't made any
changes outside of the release management stuff in a while
It's not just about installing them, it's also about making it work
without configuration:
$ ./sage --git trac checkout
On 7 May 2015 at 21:37, François Bissey
francois.bis...@canterbury.ac.nz wrote:
Looks like I would want this single commit.
https://github.com/pexpect/pexpect/commit/aac5897aa12daf056b8fe08f1b6512d9f60c2d27
The branch seems otherwise strangely stale (210 commits
behind master).
Yes. I suppose
Pushed a branch at http://trac.sagemath.org/ticket/10295 we can continue
the work there.
Francois
On 05/08/15 14:22, François Bissey wrote:
Unfortunately, the notebook is still broken with newer pexpect. If you try:
g=sin(x); plot(g,(x,-pi,3*pi/2))
You get this:
Python 2.7.8 (default, Apr 22
Dear all,
arb (for real balls) has been merged in 6.6.beta1.
The corresponding ticket for complex balls
http://trac.sagemath.org/ticket/17218
needs review. It only provides the parent and the element itself in order to fix
the interface; a second step would then be to populate the
This is a problem introduced in a recent xcode. An Apple include file does
not play nice with gcc. See the thread in
sage-support https://groups.google.com/forum/#!topic/sage-support/9m5N0KUqkWo
.
http://trac.sagemath.org/ticket/18254 has all the details as well. See
comment 44 and 51 for
Hello,
dev script are a mess (see #18356). Could I remove everthing in
sage/dev/ that is related to communication with the git server or the
trac server?
Were they already deprecated, though? In that event there should be a
well-defined time at which they could be removed.
--
On Thursday, 7 May 2015 22:47:41 UTC+1, Nathann Cohen wrote:
Were they already deprecated, though? In that event there should be a
well-defined time at which they could be removed.
The documentation has been removed in #17555. If I remember correctly,
the associated sage-devel thread
Maybe this patch solves the problem:
https://github.com/pexpect/pexpect/pull/109/files
I pulled pexpect 3.x from github which as I understand it is quite a
few patches ahead of 3.3.
$ git clone https://github.com/pexpect/pexpect.git
$ cd pexpect
$ git checkout 3.x
then installed it into my
I think it would be a good idea to have a subcategory of associative
algebras
(and inheritance of classes from an associative class). Morphisms need to
know to check associativity.
The current heirarchy is to start Magmatic algebras (no assumptions), then
you add the axioms
Nice. Could you try the example at
http://trac.sagemath.org/ticket/10295#comment:7
in a sage notebook session and see if it works?
François
On 7/05/2015, at 17:23, Bill Page bill.p...@newsynthesis.org wrote:
On 6 May 2015 at 23:28, leif not.rea...@online.de wrote:
Bill Page wrote:
Is there
On 7 May 2015 at 13:30, Simon King simon.k...@uni-jena.de wrote:
Hi Travis,
On 2015-05-06, Travis Scrimshaw tsc...@ucdavis.edu wrote:
We would like to hear your thoughts on the matter,
I wouldn't like so much to denote something as non-bla (where bla
can be associative, commutative, unital,
I tried to upgrade sage from 6.4.1 to 6.6 under linuxmint 17.1 (32 bits,
MATE) and I got this linkage error for the package eclib-20150323.
My box has 1GiB RAM and two cpu-s 'AMD Athlon(tm) 64 X2 Dual Core Processor
5000+'
The part of the log follows:
g++ -DPACKAGE_NAME=\eclib\
35 matches
Mail list logo
