Re: [sage-devel] removing the dev scripts

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 checkou

Re: [sage-devel] Unicode in Sage Worksheets

On 7 May 2015 at 22:29, François Bissey 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 you >> try: >> g=sin(x)

Re: [sage-devel] Unicode in Sage Worksheets

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 20

Re: [sage-devel] Unicode in Sage Worksheets

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/tmp

Re: [sage-devel] Unicode in Sage Worksheets

On 05/08/15 14:08, Bill Page wrote: On 7 May 2015 at 21:37, François Bissey 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 supp

Re: [sage-devel] Unicode in Sage Worksheets

On 7 May 2015 at 21:37, François Bissey 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 that branch 3.x is (more or

Re: [sage-devel] Unicode in Sage Worksheets

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 w

Re: [sage-devel] Unicode in Sage Worksheets

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 gi

Re: [sage-devel] Unicode in Sage Worksheets

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 sage

Re: [sage-devel] removing the dev scripts

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

Re: [sage-devel] removing the dev scripts

> 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

Re: [sage-devel] removing the dev scripts

> > > 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 r

Re: [sage-devel] removing the dev scripts

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 (

Re: [sage-devel] upgrade of sage from 6.4.1 to 6.6 eclib linkage error

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 er

[sage-devel] upgrade of sage from 6.4.1 to 6.6 eclib linkage error

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\" -DPACKAGE_TA

[sage-devel] Re: Catalog of algebras: the definition of an algebra

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 "associ

[sage-devel] Re: build sage-6.6 on osx fails on R compile

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 a

Re: [sage-devel] cross-post from flint-devel: python bindings for Flint and Arb (work in progress)

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 clas

Re: [sage-devel] Re: Catalog of algebras: the definition of an algebra

On 7 May 2015 at 13:30, Simon King wrote: > Hi Travis, > > On 2015-05-06, Travis Scrimshaw 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"

Re: [sage-devel] Unicode in Sage Worksheets

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 sage.inte

[sage-devel] Re: Catalog of algebras: the definition of an algebra

Hi Travis, On 2015-05-06, Travis Scrimshaw 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, please don't n

Re: [sage-devel] removing the dev scripts

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 serve

[sage-devel] removing the dev scripts

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 useful.

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

On Sat, Apr 18, 2015 at 10:48 AM, Julien Puydt 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. Exactly. As for ou

[sage-devel] Re: Catalog of algebras: the definition of an algebra

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 shou

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

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 bookkeep

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

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".

Re: [sage-devel] Catalog of algebras: the definition of an algebra

On 2015-05-06 21:08, Travis Scrimshaw wrote: On #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

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

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 i

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

> 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 rece

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

> 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 becaus

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

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

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

> 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 reaso

[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

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