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 low-hanging fruits that we should clean up
> first. Right now Vincent is adding "from __future__ import print_function"
>
--
You received this message because you are sub
What exactly are the benefits of using Python3? I thought that it tended to
be a bit slower for computation, since it uses infinite precision numbers
instead of ints. Not that I'm against it, I just didn't know the
motivation.
--
You received this message because you are subscribed to the Goo
OK, I've pressed the button - http://sagecell.sagemath.org is now
running the latest version of Sage 7.2, together with a "significantly
touched up" version of the SageMathCell code itself.
Please report any new (or old) errors that you notice - I will try to
fix them tomorrow (Saturday) afternoon
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
(http://
On Fri, May 20, 2016 at 3:32 PM, D. S. McNeil wrote:
> On the subject of 3, for anyone who hasn't been following, a number of teams
> on the science stack have thought about Aaron's argument and are making
> plans:
>
> https://python3statement.github.io/
>
Thanks. To anybody else that clicks the
On the subject of 3, for anyone who hasn't been following, a number of
teams on the science stack have thought about Aaron's argument and are
making plans:
https://python3statement.github.io/
Doug
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
The following is not related to why I asked this question (which
involves some data science curriculum development at Berkeley), but
there is a huge thread about the Sympy lead dev threatening today to
discontinue support for Python2 for Sympy:
https://news.ycombinator.com/item?id=11738470
On Fr
I was on trac, looking at the tickets under "Bugs silently producing wrong
answers". All of them seemed quite old, for the most part, and none of
them(that I could find) had anything under Branch. Does this mean that they
have been dealt with? What exactly is the situation with all of those
tic
Hi Sage-Devel,
I just spent the week teaching numpy and matplotlib in the context of
Sage. Walking around and watching why/how students got frustrated on
certain homework problems revealed one way we could improve Sage,
which would make Sage much more useful and natural overall.It
seems to me
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
On 2016-05-20 20:04, William Stein wrote:
How much might it cost to get Sage to work with Python3?
That's very difficult to say... many of the easy parts have been done.
But we haven't really looked at the hard parts, comparison for example.
--
You received this message because you are subsc
On Friday, May 20, 2016 at 11:26:50 AM UTC-7, Nils Bruin wrote:
>
> Come to think of it, I think that flag already exists:
>
> sys.setrecursionlimit(5)
>
OK, patching sage.doctest.forker.init_sage to include this statements
results in:
sage -t src/sage/functions/other.py # Killed due to seg
On Friday, May 20, 2016 at 9:50:05 AM UTC-7, Samuel Lelievre wrote:
>
>
> Could you tell which two places you have in mind?
>
http://trac.sagemath.org/ticket/20624
http://trac.sagemath.org/ticket/10963#comment:242
In both cases, the "RuntimeError: Maximum recursion depth exceeded" was
caught by
Hi,
Somebody with possibly substantial grant funds asked me today: "How
much might it cost to get Sage to work with Python3?"
I don't know. Anybody have any thoughts? Is there anybody reading
this who wishes they could spend several months getting Sage to fully
work with Python3 instead of t
2016-05-19 16:49:24 UTC+2, Nils Bruin:
>
> You can use infinite recursion productively in python. It even evaluates
> pretty quickly:
>
> We've used it in the sage library in at least two places (although
>
one was rewritten a while ago to use a different mechanism).
>
Could you tell which two
>
> It's like if setuptools is loaded for whatever reason, then setuptools
> will be used to install jupyter_core. The question is: why was
> setuptools loaded in the first place? Do you have any custom Python
> packages installed which could do this?
>
Yes, that is indeed this issue! I hav
> >>>But maybe for examplehttp://trac.sagemath.org/ticket/8170could be
> justclosed?
> >>
> >> Was that a typo for another ticket?
> >
> > No. It is a good example of what Jeroen said, I think. A reasonable
> > suggestion made 6 years ago, no comments at all after that, no comments
> > tel
I don't manage to reproduce this on Linux...
On 2016-05-20 15:32, Jeroen Demeyer wrote:
It seems that your installation of jupyter_core is
using *setuptools* instead of *distutils*.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
On Fri, May 20, 2016 at 3:35 PM, Jeroen Demeyer wrote:
> On 2016-05-20 15:33, Erik Bray wrote:
>>
>> Meanwhile PyPI seems to be working fine, but it nevertheless is
>> blowing up with network connection issues
>
>
> The fact that those network connections don't work is a Sage feature: there
> are
On 2016-05-20 15:33, Erik Bray wrote:
Meanwhile PyPI seems to be working fine, but it nevertheless is
blowing up with network connection issues
The fact that those network connections don't work is a Sage feature:
there are special measures to prevent network connections during
spkg-install.
On Fri, May 20, 2016 at 3:01 PM, Nathan Dunfield wrote:
> When trying to build Sage 7.2 from source on OS X (10.8 and 10.9), I get the
> following error (complete logs also attached):
>
> Installed
> /pkgs/sage-7.2/local/lib/python2.7/site-packages/jupyter_core-4.1.0-py2.7.egg
> Processing depende
On 2016-05-20 15:01, Nathan Dunfield wrote:
When trying to build Sage 7.2 from source on OS X (10.8 and 10.9), I get
the following error (complete logs also attached):
That is very strange. It seems that your installation of jupyter_core is
using *setuptools* instead of *distutils*. There is t
>
> Is this a parallel make?
>
No, it was single-threaded. (Unless parallel make is the default, to be
precise I just typed "make".)
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving ema
Is this a parallel make? If yes: can you check if the problem persists
when building serially?
--
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
When trying to build Sage 7.2 from source on OS X (10.8 and 10.9), I get
the following error (complete logs also attached):
Installed
/pkgs/sage-7.2/local/lib/python2.7/site-packages/jupyter_core-4.1.0-py2.7.egg
Processing dependencies for jupyter-core==4.1.0
Searching for traitlets
Reading http
On 19 May 2016 at 19:43, John Cremona wrote:
> On 19 May 2016 at 18:06, Jeroen Demeyer wrote:
>> On 2016-05-19 18:15, John Cremona wrote:
>>>
>>> On 19 May 2016 at 17:11, Jeroen Demeyer wrote:
On 2016-05-19 13:54, John Cremona wrote:
>
>
> Was it the 6.10 - 7.1 upgrade whic
>>>But maybe for examplehttp://trac.sagemath.org/ticket/8170could be justclosed?
>>
>> Was that a typo for another ticket?
>
> No. It is a good example of what Jeroen said, I think. A reasonable
> suggestion made 6 years ago, no comments at all after that, no comments
> telling how this should b
27 matches
Mail list logo
