Re: [sage-devel] Re: patchbot server not responding

nt. > > I will then setup a single kubernetes cluster on the bare metal > machines, and people who are allocated credentials will be able to run > containers that way. I'm not sure what I'll do about persistent > storage (if anything). > > William > > On Th

Re: [sage-devel] patchbot server not responding

Please check up on fileserver.sagemath.org, too, while you are at it... On Thursday, July 21, 2016 at 2:20:17 AM UTC+2, William wrote: > > On Wed, Jul 20, 2016 at 12:39 PM, Frédéric Chapoton > wrote: > > Anything new on the patchbot server status ? > > I will have

[sage-devel] Re: error compiling ntl in sage 7.3.beta8

On Tuesday, July 19, 2016 at 5:35:55 PM UTC+2, leif wrote: > > Huh, dead old toolchain on a recent Intel machine. > Centos/Redhat 6 is from 2010 and supported until 2020... If you want to get good performance for recent hardware you'd need something fresher, of course. -- You received this

[sage-devel] Re: Did trac server change its rsa keys?

The key changed with the recent reinstall On Tuesday, July 19, 2016 at 3:47:26 PM UTC+2, mmarco wrote: > > Trying to `git trac push` I get the following error message. Is it > expected or someone is trying to MITM me? > > Traceback (most recent call last): > File

[sage-devel] Re: Git repository should have Sage versions as branches not tags

Don't know, possibly nobody On Sunday, July 17, 2016 at 11:06:37 PM UTC+2, Paul Masson wrote: > > Thanks. > > Another question: who closes Issues and Pull Requests on Github that have > been marked ready for closure? > > On Sunday, July 17, 2016 at 1:56:38 AM UTC-

[sage-devel] Re: libtinfo.so.5: no version information available

do you have LD_LIBRARY_PATH or LD_PRELOAD set? On Sunday, July 17, 2016 at 12:27:27 PM UTC+2, Harald Schilly wrote: > > Hi, when I'm compiling sage (either from develop or 7.2), I'm getting lots > and lots of error lines like: > > /bin/sh: /ext/sage/7.2/local/lib/libtinfo.so.5: no version

[sage-devel] Re: Git repository should have Sage versions as branches not tags

done On Saturday, July 16, 2016 at 11:19:21 PM UTC+2, Paul Masson wrote: > > The mirror actually has three branches. This one hasn't been touched in > over a year: > > https://github.com/sagemath/sage/tree/module-list-cleanup > > Shouldn't it be removed at some point? > > On Wednesday, July 13,

[sage-devel] Re: screen output of compilation

I added that in #20712 If you think its annoying then revert it, fine with me. On Friday, July 15, 2016 at 1:27:03 PM UTC+2, chris wuthrich wrote: > > Hi all. > > When I do make or sage -b each time there is now a huge print > > python_packages = ['sage', 'sage.lfunctions', >

[sage-devel] fileserver.sagemath.org is down

Which afaik is the root mirror and where I upload third-party packages and source tarballs -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[sage-devel] Re: Git repository should have Sage versions as branches not tags

Checking out a branch or a tag should be pretty much the same. The only potential pitfall is that you need to quote numbers in yaml, otherwise they are interpreted as numbers. So change branch: develop into e.g. branch: '7.2' On Thursday, July 14, 2016 at 3:53:21 AM UTC+2, John Phamlore

Re: [sage-devel] VotePlugin for trac?

The point of voting/starring/+1-ing a ticket is that one can express importance without having to post a "me too" comment (and without having to spam developer's inboxes). On Tuesday, July 5, 2016 at 4:00:57 PM UTC+2, vdelecroix wrote: > > On 05/07/16 09:53, Dima Pasechnik wrote: > > As an

[sage-devel] Re: Broken git trac checkout?

You need the latest version of git-trac-command, e.g. by checking out https://github.com/sagemath/git-trac-command On Monday, July 4, 2016 at 10:36:16 AM UTC+2, Jori Mäntysalo wrote: > > Is it just me, or is trac broken? > > $ git trac checkout 20918 > Loading ticket #20918... > Traceback

[sage-devel] Re: Trac workflow and needs_review

No I haven't. Really it should be a trac plugin that prevents you from setting a ticket to positive review without filling out Author and Reviewer fields. A somewhat orthogonal issue is whether to record plain text names or user ids. The advantage of plain text is that anyone can be listed (),

[sage-devel] Re: [sage-edu] Viewpoint Article in Math Intelligencer on open texts

Oh the irony... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to

[sage-devel] Re: python3 again

On Thursday, June 30, 2016 at 5:12:50 PM UTC+2, Frédéric Chapoton wrote: > > It is still not very clear to me what SAGE_PYTHON3 (well hidden) is > supposed to achieve. > When building Sage-the-distribution, it builds python3 instead of python2. Anything that uses Sage's own python will then be

[sage-devel] Re: python3 again

It wouldn't surprise me too much if you can' t build python2 inside a python 3 venv. Its pretty low on the priority of things to support imho. Try building with SAGE_PYTHON3=yes On Thursday, June 30, 2016 at 3:29:25 PM UTC+2, Frédéric Chapoton wrote: > > Hello everybody, > > I am trying to

Re: [sage-devel] Re: spkgs assumed for doctesting but not default installed

On Thursday, June 30, 2016 at 2:26:47 PM UTC+2, Johan S. R. Nielsen wrote: > > ar: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required > by /usr/lib/libLLVM-3.8.so) Are you using llvm? As far as I know that doesnt' work, though I haven't tried it myself. -- You received

[sage-devel] Re: spkgs assumed for doctesting but not default installed

sounds like the first "make" failed... On Wednesday, June 29, 2016 at 5:38:24 PM UTC+2, Johan S. R. Nielsen wrote: > > Hi sage-devel > > Today I made a fresh clone of the develop branch, ran "make", and then > tried to run "./sage -t". To my surprise, this didn't work at all! > > First off,

Re: [sage-devel] Re: ssh fail

ername at {git,trac}.sagemath.org" unless you are one of the server admins. On Wednesday, June 29, 2016 at 10:56:17 AM UTC+2, Erik Bray wrote: > > On Wed, Jun 29, 2016 at 9:19 AM, Volker Braun <vbrau...@gmail.com > > wrote: > > You can't ssh into trac. What should work

[sage-devel] Re: ssh fail

You can't ssh into trac. What should work is: $ ssh g...@git.sagemath.org PTY allocation request failed on channel 0 hello vbraun, this is git@trac running gitolite3 3.5.3.1-2 (Debian) on git 1.9.1 R W sage On Tuesday, June 28, 2016 at 11:26:32 PM UTC+2, tara fife wrote: > > I wasn't able

Re: [sage-devel] Trac workflow and needs_review

On Tuesday, June 28, 2016 at 6:23:18 PM UTC+2, Erik Bray wrote: > > Currently the release manager *closes* a ticket and marks it as > "fixed" when merging the change for testing. No. Tickets are closed *after* tests succeed. The only race condition is if somebody else reopens positively

[sage-devel] Cup product over integers

It seems that we currently can't compute cup products in cohomology over the integers, only over fields. Is that correct? Is there a ticket to extend it over the integers? Surely that's an interesting question, isn't it? -- You received this message because you are subscribed to the Google

[sage-devel] Re: Trac Authentication error

sagemath.org info > > hello jhonrubia6, this is git@trac running gitolite3 3.5.3.1-2 (Debian) on > git 1.9.1 > > > > R Wsage > > > So the authentication seems ok. There must be something with my trac > config... > > El domingo, 26 de junio de 2016, 0:31

[sage-devel] Re: Trac Authentication error

The realm is correct. Are you sure that you are executing the right git-trac script? Use /path/to/git-trac config to be sure you aren't using an old version in your PATH On Saturday, June 25, 2016 at 1:07:01 PM UTC+2, jhonrubia6 wrote: > > After the move of the trac server I get

[sage-devel] Re: Trac Authentication error

Updated package is at https://trac.sagemath.org/ticket/20880 On Saturday, June 25, 2016 at 1:13:50 PM UTC+2, Dima Pasechnik wrote: > > Please install the latest update of git-trac. > Note e.g. that " realm sage.math.washington.edu" is certainly incorrect > in your log. > > On Saturday, June 25,

Re: [sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

> remote: return u.close() > remote: File "/usr/lib/python2.7/xmlrpclib.py", line 792, in close > > remote: raise ResponseError() > remote: xmlrpclib.ResponseError: ResponseError() > To g...@trac.sagemath.org:sage.git

Re: [sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

Thanks, everything is working now! On Thursday, June 23, 2016 at 1:58:27 PM UTC+2, Erik Bray wrote: > > On Thu, Jun 23, 2016 at 11:14 AM, Erik Bray <erik@gmail.com > > wrote: > > On Jun 23, 2016 11:10, "Volker Braun" <vbrau...@gmail.com > &

Re: [sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

te: > > On Wed, Jun 22, 2016 at 7:48 PM, Volker Braun <vbrau...@gmail.com > > wrote: > >> On Wednesday, June 22, 2016 at 7:23:34 PM UTC+2, Erik Bray wrote: > >>> > >>> Conceivably it would not be hard to provide an alternative HTTP digest

[sage-devel] Re: "git trac push" can no longer change branch on Trac

Yes thats because the authentication doesn't work right now (see the other thread) On Thursday, June 23, 2016 at 10:27:38 AM UTC+2, Jeroen Demeyer wrote: > > With the latest git-trac-command: > > $ git trac push > Pushing to Trac #20868... > Guessed remote branch:

Re: [sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

On Wednesday, June 22, 2016 at 7:23:34 PM UTC+2, Erik Bray wrote: > > Conceivably it would not be hard to provide an alternative HTTP digest > backend for login as well. > That would be the easiest solution... can you set it up? -- You received this message because you are subscribed to the

[sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

Thats because of https, you need to do the analog change that I just did on the git-trac script: diff --git a/git_trac/digest_transport_py2.py b/git_trac/digest_transport_py2.py index 28a8520..c030432 100644 --- a/git_trac/digest_transport_py2.py +++ b/git_trac/digest_transport_py2.py @@ -121,7

[sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

PS: I can't seem to authenticate over xmlrpc; Did you follow the advice at: https://trac-hacks.org/wiki/XmlRpcPlugin#ProblemswhenAccountManagerPluginisenabled -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and

[sage-devel] Re: {trac,git}.sagemath.org downtime Wednesday 6/22

The authentication changed, we used to have http digest (browser popup window, with realm) and now its the trac builtin one. This breaks the git-trac script as it tries to authenticate over http digest. I can fix it up but first let me ask: Is that going to stay? On Monday, June 20, 2016 at

[sage-devel] Re: trac 20530 leads to trouble building the doc in sage-on-gentoo

This is now http://trac.sagemath.org/20845 On Sunday, June 19, 2016 at 11:34:33 AM UTC+2, Volker Braun wrote: > > This is now https://gitlab.com/embeddable-common-lisp/ecl/issues/258 > > On Sunday, June 19, 2016 at 11:18:05 AM UTC+2, Volker Braun wrote: >> >> If you l

[sage-devel] Re: trac 20530 leads to trouble building the doc in sage-on-gentoo

This is now https://gitlab.com/embeddable-common-lisp/ecl/issues/258 On Sunday, June 19, 2016 at 11:18:05 AM UTC+2, Volker Braun wrote: > > If you look at ECL's current_dir() function then it starts with a buffer > length of 128 bytes and then increases it if ENAMETOOLONG is raised. But

Re: [sage-devel] trac 20530 leads to trouble building the doc in sage-on-gentoo

François > > > On 19/06/2016, at 21:18, Volker Braun <vbrau...@gmail.com > > wrote: > > > > If you look at ECL's current_dir() function then it starts with a buffer > length of 128 bytes and then increases it if ENAMETOOLONG is raised. But > thats the w

[sage-devel] Re: trac 20530 leads to trouble building the doc in sage-on-gentoo

If you look at ECL's current_dir() function then it starts with a buffer length of 128 bytes and then increases it if ENAMETOOLONG is raised. But thats the wrong error, it should be ERANGE according to the man page. On Sunday, June 19, 2016 at 12:56:04 AM UTC+2, François wrote: > > Hi, > >

Re: [sage-devel] trac slow/unresponsive

On Friday, June 17, 2016 at 5:35:06 PM UTC+2, Erik Bray wrote: > > It blocks on reading environ['wsgi.input'] [1], which is a file-like > handle to the form post data in the body of the request. This happens > regardless of whether Trac tries to read or my own code. The request body > just

Re: [sage-devel] trac slow/unresponsive

Possibly because trac static assets need to be served by the web server instead of trac's own handler? Otherwise trac is really slow, we had that before. On Friday, June 17, 2016 at 4:39:22 PM UTC+2, Erik Bray wrote: > > On Fri, Jun 17, 2016 at 1:52 PM, Jeroen Demeyer

[sage-devel] Re: What is the best time for Trac downtime?

In any case thats from our trac-git plugin not working, the merge of the branch should have been in that temporary directory On Thursday, June 16, 2016 at 9:47:42 PM UTC+2, Paul Masson wrote: > > I agree with Dima: working infrastructure takes top priority. > > Erik, on the new server I'm

[sage-devel] Re: Make fail on OS X

Delete the "local" directory and then rebuild On Tuesday, June 14, 2016 at 6:22:33 PM UTC+2, Ben Salisbury wrote: > > Hi all, > > I recently attempted to update to the latest development version of Sage. > However, I had to stop the process during the `make distclean` stage using > `Cmd+C`.

Re: [sagemath-admins] Re: [sage-devel] Re: http://trac.sagemath.org vs https://trac.sagemath.org

Btw when I go to http://sagemathcloud.com then I'm greeted by a cloudflare Error 521 page, presumably this is not intended ;-) On Wednesday, June 8, 2016 at 3:18:55 PM UTC+2, Harald Schilly wrote: > > On Wed, Jun 8, 2016 at 2:53 PM, William Stein > wrote: > > Of some

[sage-devel] Re: Plotting arccsch() in Sage 7.2

Its probably this: sage: arcsinh(float(0.1)) 0.09983407889920758 sage: arccsch(float(0.1)) (2.99822295029797+0j) On Sunday, June 12, 2016 at 7:50:34 AM UTC+2, Ralf Stephan wrote: > > On Sunday, June 12, 2016 at 3:07:07 AM UTC+2, kcrisman wrote: >> >> There may have been some change in Pynac

[sage-devel] Re: Abandon Python 2.6 support?

Note that we can trivially support Python 2.6 just by vendoring argparse.py. Make user's lives easier or save a few kilobytes of disk space? How is this not a total slam-dunk? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] import and build with py3

On Saturday, June 11, 2016 at 1:27:50 PM UTC+2, William wrote: > > I'm confused by this whole thread. Why exactly do you think what you want > to do is even possible? > Sage does not support python3 yet. > I'm also confused; Though what should work is: Use Python 3.3+ to satisfy Sage's

[sage-devel] Re: import and build with py3

misc.lazy_import' > > So my question is: what is the cause of this error ? The same error > happens for several cython modules. > > Frederic > > > Le vendredi 10 juin 2016 20:59:31 UTC+2, Volker Braun a écrit : >> >> Whats your question >> >> a) you wan

[sage-devel] Re: import and build with py3

YTHON3=yes make" On Friday, June 10, 2016 at 2:37:43 PM UTC-4, Frédéric Chapoton wrote: > > Sure, but how can I try ? Is there something like a flag to pass to make ? > > Le vendredi 10 juin 2016 20:19:38 UTC+2, Volker Braun a écrit : >> >> Sage is supposedly requiring Python 2

[sage-devel] Re: import and build with py3

Sage is supposedly requiring Python 2.7 or 3.3+ to build, but it isn't tested with py3 so its unlikely to actually work. On Friday, June 10, 2016 at 2:10:38 PM UTC-4, Frédéric Chapoton wrote: > > Hello, > > What is the correct way to start trying to build sage in a python3 > (virtual)

Re: [sagemath-admins] Re: [sage-devel] Re: http://trac.sagemath.org vs https://trac.sagemath.org

, June 8, 2016 at 3:50:13 PM UTC-4, Erik Bray wrote: > > On Wed, Jun 8, 2016 at 7:03 PM, Volker Braun <vbrau...@gmail.com > > wrote: > > The diff viewer doesn't work; I'm not sure if its supposed to but here > we > > go: > > > > 1) go to http://104.197.14

Re: [sagemath-admins] Re: [sage-devel] Re: http://trac.sagemath.org vs https://trac.sagemath.org

seems amiss (the data itself is a couple days old). > > Thanks, > Erik > > On Wed, Jun 8, 2016 at 11:04 AM, Volker Braun <vbrau...@gmail.com > > wrote: > > Of course trac pages are mostly dynamic content, so this would only help > > with a couple of icons etc. &g

Re: [sagemath-admins] Re: [sage-devel] Re: http://trac.sagemath.org vs https://trac.sagemath.org

Of course trac pages are mostly dynamic content, so this would only help with a couple of icons etc. On Wednesday, June 8, 2016 at 8:54:20 AM UTC-4, William wrote: > > Of some relevance -- Harald Schilly was recently in the process of > putting a CloudFlare 'pro subscription' in front of all

[sage-devel] Re: Sage infrastructure repository + GitHub cleanup

Some of those repos are out of date, too. If in doubt check with whats actually on the trac VM. Really we need a better (any!) configuration management. E.g. by having a repo with salt/ansible/... VM configuration or dockerfiles etc. Having a VM thats being prodded by a dozen different admins

Re: [sage-devel] Re: sage infrastructure at UW

Sholud have been public key, of course. Though you all can send me your private keys, too, if you want ;-) On Tuesday, June 7, 2016 at 12:59:08 PM UTC-4, Jan Groenewald wrote: > > > On 7 June 2016 at 18:54, Volker Braun <vbrau...@gmail.com > > wrote: > >> I can prob

[sage-devel] Re: sage infrastructure at UW

Jun 7, 2016 at 12:14 PM, Volker Braun <vbrau...@gmail.com > > wrote: > > On Tuesday, June 7, 2016 at 11:22:10 AM UTC-4, William wrote: > >> > >> Erik has volunteered to setup trac, and will do so soon. > > > > > > There are a bunch of caveats

[sage-devel] Re: Build failure Sage 7.3.beta3 on Mac OS 10.9 with binary-pkg

Thats probably the shebang length limit. Can you try to reduce LENGTH in binary_pkg/path_placeholder.py (80 or so should keep you in the limit, then) On Tuesday, June 7, 2016 at 12:18:15 PM UTC-4, leif wrote: > > Nathan Dunfield wrote: > > I used the instructions on

[sage-devel] Re: sage infrastructure at UW

Our git server is read/write, of course. Authentication is so that only you can push to branches matching u/dimpase/.*, and that is handled by gitolite. There is no authentication for the cgit repo viewer, as you said. Ideally, everything but the git server and the trac database would be

[sage-devel] Re: sage infrastructure at UW

On Tuesday, June 7, 2016 at 11:22:10 AM UTC-4, William wrote: > > Erik has volunteered to setup trac, and will do so soon. There are a bunch of caveats to that one as far as I remember: * The ssh key management plugin for trac shares the keys over the local file system with gitolite

[sage-devel] Re: hosting wiki and trac

+1 to hosting at at Tier 1 cloud provider Also, if you have any arguments pro or con then send it to the mailinglist and not to William's private email. On Tuesday, June 7, 2016 at 8:28:07 AM UTC-4, William wrote: > > Hi, > > I am being pressured by various people to host trac and wiki in

Re: [sage-devel] sage infrastructure at UW

IMHO thats not a big deal, some orgs are experimenting with permanently running datacenters at 90+F... The best course of action is probably to wait and get the machines back up. Then slowly move the infrastructure out of UW. On Monday, June 6, 2016 at 11:27:39 AM UTC-4, Dima Pasechnik

[sage-devel] Re: Trac and wiki

The buildbot is gone, too. I'm also travelling this week and don't have much time to do anything... Especially for trac with our custom plugins I'd really prefer a docker container with a working Dockerfile than a random VM that has been prodded by dozens of people over the course of years.

[sage-devel] Re: Developing sage-based code out of tree

Make a python package with a setup.py that cythonizes your own code and installs it as nils_module. To use it, use something like "from nils_module.all import *". Ideally you'd be able to create a new virtualenv from sage's python but that doesn't work right now. On Sunday, June 5, 2016 at

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 3:54:57 PM UTC-4, Nils Bruin wrote: > > It could be that the undecorated code is bug-free > That is obviously fine, just don't decorate it with a memoization operator. But don't code that is manifestly wrong with a memoziation operator but then fixed by a subtle

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 2:02:53 PM UTC-4, Simon King wrote: > > But my second suggestion was: Add an option to @cached_method, so that one > can request copy-on-return. > I understood what you want, but I'm saying that its bad to have a bug in the code that is then worked around by a

[sage-devel] Re: Users can permanently modify GF(5).list()

IMHO we shouldn't slow down cached_method just to allow you to write incorrect code (and caching a returned list is a bug). If anything, cached_method should print a warning if the result is mutable so people can fix their code. On Friday, June 3, 2016 at 1:10:25 PM UTC-4, Simon King

Re: [sage-devel] Users can permanently modify GF(5).list()

On Thursday, June 2, 2016 at 5:41:59 PM UTC-4, William wrote: > >X.list() > might very well return a tuple of four *mutable* 2x2 matrices. Then > this X.tuple() is still very much mutable, and the original problem > has not been solved.I guess that's my point. > But that has is

Re: [sage-devel] Users can permanently modify GF(5).list()

On Thursday, June 2, 2016 at 5:34:49 PM UTC+2, William wrote: > > (1) No matter your grammar argument about deficiencies in the > technical language, it's a fact that the majority of English speakers > is going to consider this confusing. > The majority of English speakers will be perfectly

[sage-devel] Re: PEP idea: unary division

I'm guessing that this won't fly with upstream ;-) Is it really faster? A new __unary_div__ method everywhere? Is it really faster than special-casing the 1/x case in __div__? Also, /x/ is a regular expression in JS. If Python ever wanted to support that syntax then this would be stepping on

Re: [sage-devel] Users can permanently modify GF(5).list()

ay, June 2, 2016 at 7:10:58 AM UTC+2, Kiran Kedlaya wrote: > > Eh? Shouldn't foo.list() return the same as list(foo) (a list) and > foo.tuple() the same as tuple(foo) (a tuple)? > > On Tuesday, May 31, 2016 at 6:08:51 AM UTC-7, Volker Braun wrote: >> >> I've said it before

[sage-devel] Re: Infix mod operator?

PS: This would still leave room for a preparser hack for the easy-to-implement paren-mod infix operator: X (mod Y) -->X * mod(Y) Thoughts? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: Infix mod operator?

On Tuesday, May 31, 2016 at 7:07:14 PM UTC+2, Nils Bruin wrote: > > - you're introducing a new reserved word in sage, which will break > previous code. > Well "mod 3" can't occur inside a valid Python expression so at most it'll unbreak currently-broken code ;-) Though, especially for

[sage-devel] Infix mod operator?

This was a request at sd74: sage: 42 mod 8 2 sage: type(42 mod 8) Thoughts? Ticket is at http://trac.sagemath.org/ticket/20735 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

Re: [sage-devel] Users can permanently modify GF(5).list()

I've said it before: list() should always return a tuple. Yes I know its called list, but its just an English thing that verb and noun can't be distinguished. Certainly no excuse to cache mutable data structures. On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote: > > On

[sage-devel] Re: Weird ImportError with six

great minds think alike ;-) On Tuesday, May 31, 2016 at 8:26:54 AM UTC+2, Frédéric Chapoton wrote: > > It's because these is a "six" module in sage/misc. > > I met this problem in #20694 > > Solution: use from __future__ import absolute import > > Frederic > > Le mardi 31 mai 2016 07:55:14

[sage-devel] Re: Weird ImportError with six

This imports src/sage/misc/six.py The best fix is probably from __future__ import absolute_import to get the saner py3 behavior. On Tuesday, May 31, 2016 at 7:55:14 AM UTC+2, Andrey Novoseltsev wrote: > > Hello, > > Can anybody explain (even better - fix ;-)) what is going on with this >

[sage-devel] Re: Opinions on mostly superfluous refactoring

Imho many sage modules have grown too long, including but not limited to some 20kloc monsters. +1 to splitting things up! On Monday, May 30, 2016 at 6:22:53 PM UTC+2, Erik Bray wrote: > > Hi all, > > I recently needed to dive into the sage_setup.autogen.interpreters > module in order to make

Re: [sage-devel] Re: weird output: show of FiniteField

Ah forgot about the existing ticket... On Monday, May 30, 2016 at 3:57:42 PM UTC+2, Daniel Krenn wrote: > > Why was > On 2016-05-30 15:51, Volker Braun wrote: > > This is now http://trac.sagemath.org/ticket/20711 > > created and code not attached to the existing > >

[sage-devel] Re: weird output: show of FiniteField

This is now http://trac.sagemath.org/ticket/20711 On Sunday, May 22, 2016 at 11:47:50 AM UTC+2, Daniel Krenn wrote: > > We have > > sage: show(FiniteField(2)) > \newcommand{\Bold}[1]{\mathbf{#1}}0 1 > > which is the list of elements and not $F_2$ (what I would expect). > > However, the

Re: [sage-devel] Renaming generic curve classes

On Monday, May 30, 2016 at 8:46:37 AM UTC+2, Johan S. R. Nielsen wrote: > > I'm a bit surprised at the naming scheme "_generic", etc. in the first > place. They are different implementations and not injected in the global namespace. The global namespace only has factory functions that

[sage-devel] Re: trac's automerging error

It means that our trac plugin had problems mergin in the lastest beta. You should try to merge yourself, and see if there are any conflicts. If there are conflicts: resolve and push. Its possible that manual merge succeeds because the git commandline client is better at merging, in that case

[sage-devel] Re: Copyrights

There is no contributor license agreement. Every file must be GPLv2+ licensed. If you start a new file you have copyright on that module whether you put your name in there or not; But we need the GPLv2+ statement to distribute it as part of Sage. On Thursday, May 26, 2016 at 12:16:11 PM

[sage-devel] Re: Warnings traceback for top level

Apparently the IPython/Jupyter devs don't want to change their deprecation warnings and advise users to filter them out: https://github.com/ipython/ipython/issues/9242. So something like warnings.filterwarnings('default', category=DeprecationWarning, module='.*/mypackage/.*') should work if

[sage-devel] Re: Problem with string.py and math.py

"." is in sys.path unless others have write permissions on the current directory. On Sunday, May 22, 2016 at 3:55:23 PM UTC+2, Jeroen Sijsling wrote: > > Dear all, > > (I also posted this about a quarter of an hour ago, but I now think that I > must have done something wrong. I am sorry if

[sage-devel] Re: weird output: show of FiniteField

PS: I'd be more than happy to get rid of the special casing for pretty_print, there is no reason to list iterators beyond backward compatibility for a pretty weird use case. On Sunday, May 22, 2016 at 12:05:10 PM UTC+2, Volker Braun wrote: > > For historic reasons, pretty_print() of ite

[sage-devel] Re: weird output: show of FiniteField

For historic reasons, pretty_print() of iterators lists elements: sage: pretty_print(iter([1,2,3])) 1 2 3 And finite fields are iterators: sage: isinstance(GF(2), collections.Iterator) True On Sunday, May 22, 2016 at 11:47:50 AM UTC+2, Daniel Krenn wrote: > > We have > > sage:

[sage-devel] Re: Piecewise functions in Sage 7.2

Piecewise functions are symbolic functions now; The problem is that your g doesn't define a symbolic function, so you can't use it as input to piecewise: sage: g(x) ... TypeError: unable to simplify to float approximation. You can manually define a symbolic function whose numeric evaluation is

[sage-devel] Re: Piecewise functions in Sage 7.2

Thats the expected output since 1 is not in the domain: sage: f.domain() (0, 1) + (1, 3) + (3, 4) You probably want sage: g = piecewise([[(0,1),x], [[1,3],2-x], [(3,4),x-4]]) sage: g.domain() (0, 4) sage: g.plot([0,4]) On Sunday, May 22, 2016 at 12:06:27 AM UTC+2, paulmasson wrote: > > Since

[sage-devel] Re: reset a commit in trac

Assuming that you have the branch checked out: git reset --hard HEAD~ # go back one commit git trac push --force # if you use the git-trac script On Saturday, May 21, 2016 at 8:04:04 PM UTC+2, jhonrubia6 wrote: > > Is there a way to reset the last (erroneous) commit in trac ticket

[sage-devel] Re: Python3

Twisted should work under Python3 now. Some modules are missing but sagenb might not depend on the more obscure stuff... On Saturday, May 21, 2016 at 10:27:53 AM UTC+2, Dima Pasechnik wrote: > > Given the snail speed of twised is ported to Python 3, sagenb won't be > ready in another year or

Re: [sage-devel] Re: Python3

ning: the cmp argument is not supported in 3.x DeprecationWarning: type inequality comparisons not supported in 3.x On Saturday, May 21, 2016 at 10:19:17 AM UTC+2, Jeroen Demeyer wrote: > > On 2016-05-21 01:11, Volker Braun wrote: > > I think there are a couple of low-hanging fruits that we

[sage-devel] Re: Doctests failures in sage.dev

Removing sagedev is now http://trac.sagemath.org/ticket/20645 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to

[sage-devel] Re: Python3

My apologies! In my defense, it was really late last night ;-) On Saturday, May 21, 2016 at 8:23:07 AM UTC+2, Frédéric Chapoton wrote: > > Sorry, but I am not Vincent. > > Le samedi 21 mai 2016 01:11:12 UTC+2, Volker Braun a écrit : >> >> I think there are a couple of lo

[sage-devel] Re: Python3

I think there are a couple of low-hanging fruits that we should clean up first. Right now Vincent is adding "from __future__ import print_function" everywhere, which is a great start. There are a couple of further __future__ imports that we should gradually roll out. The future library

[sage-devel] Re: using infinite recursion productively

On Friday, May 20, 2016 at 9:43:33 PM UTC+2, Nils Bruin wrote: > > On Friday, May 20, 2016 at 11:26:50 AM UTC-7, Nils Bruin wrote: >> >> sys.setrecursionlimit(5) >> > OK, patching sage.doctest.forker.init_sage to include this statements > results in: > Can we make this check part of our usual

Re: [sage-devel] error building ipython for sage-7.2

Shows once again: we should overwrite logs and only keep the most recent one. The current state is super confusing. On Wednesday, May 18, 2016 at 10:50:03 PM UTC+2, François wrote: > > On 05/19/16 02:28, John Cremona wrote: > > Two similar machines running ubuntu 14.04 and gcc-4.8.4. On one

[sage-devel] Doctests failures in sage.dev

A number of buildbot machines are now failing tests, probably due to a recent git update? In any case, I propose to remove sage.dev. Of course feel free to fix the failures if you want to keep it ;-) sage -t --long src/sage/dev/git_interface.py

[sage-devel] Re: error building ipython for sage-7.2

the (py)zmq installation is the problem. Whats the output of ldd local/lib/python/site-packages/zmq/backend/cython/_device.so On Wednesday, May 18, 2016 at 4:29:18 PM UTC+2, John Cremona wrote: > > Two similar machines running ubuntu 14.04 and gcc-4.8.4. On one 7.2 > built fine but on the

[sage-devel] Re: Some quick git tips

The developer guide has a lot of material about git: http://doc.sagemath.org/html/en/developer/index.html On Thursday, May 12, 2016 at 7:06:36 AM UTC+2, saad khalid wrote: > > Hey guys: > > I was wondering... So, I have my local install of Sage 7.1 from source. I > didn't get the source using

[sage-devel] Re: OS X binaries: which versions OS X are supported?

We don't have a buildbot on old OSX machines. If you are willing to host one then it would be easy to build binaries. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email

[sage-devel] Re: Error installing package ecl-15.3.7p0

Do you have libffi-devel installed (however the package is talled on Suse)? On Monday, May 9, 2016 at 3:08:58 PM UTC+2, Johannes Martin wrote: > > Hi, > > I cannot compile the source files of sage on > openSuse Leap 42 > > Linux linux-noh5 4.1.20-11-default #1 SMP PREEMPT Fri Mar 18 14:42:07 UTC

Re: [sage-devel] Re: Building binaries...

The intended way to customize this is to create your own sage-debian.yaml where you modify the build instructions as you want them: build: | export SAGE_FAT_BINARY=yes export SAGE_PARALLEL_SPKG_BUILD=yes export MAKE='make -j{ncpu}' make git gc --aggressive --prune=now Then

<    1   2   3   4   5   6   7   8   9   10   >