On Sat, Apr 18, 2015 at 12:10:47PM -0700, 'Martin R' via sage-combinat-devel
wrote:
Sorry, I should have made myself clearer: I do not understand the
design decision behind the way map_coefficients works.
Shouldn't it rather check whether the function actually produces
something
-- Forwarded message --
From: Roberto Panai robertopa...@sardus.it
Date: Mon, Apr 20, 2015 at 4:00 PM
Subject: Sage Math on Raspbian /Raspberry Pi 2
To: wst...@gmail.com
Dear William,
I just bought one Raspberry Pi 2 and I saw Wolfram Mathematica is
already in. Apparently there
On 04/20/2015 09:31 PM, Jeroen Demeyer wrote:
For the record, this is what I did as release manager:
1. take a bunch of tickets with positive_review, make a private Sage
release with them, test them on the buildbot.
2a. if there are buildbot failures and it's clear which ticket caused
Hi Andrey
I can confirm that sage-6.6 was built successfully on an 8 year old pentium
with 2GB of RAM and about 10 GB of swap, I was looking from time to time at
the swap use during the ~15 hours built, I think almost 3GB was the top.
This was done with Debian Jessie, which I have to say, is
I have a somewhat related problem: Since February (I do not recall the exact
revision, but might very well be early in the 6.6 release cycle), I cannot do a
parallel build with 4 processes on my notebook with 4 GB RAM anymore.
My observation was that cythonizing takes huge amounts of memory (~ 2
Hi Jeroen,
On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
Thank you! Is there a penalty for doing type(self) twice?
I don't think so, but you should profile. When in doubt, use
cdef type t = type(self) # The cdef type is very important!
obj = t.__new__(t)
See my previous
On Monday, April 20, 2015 at 12:55:27 PM UTC-7, Jeroen Demeyer wrote:
Thank you! Is there a penalty for doing type(self) twice?
I don't think so, but you should profile. When in doubt, use
cdef type t = type(self) # The cdef type is very important!
obj = t.__new__(t)
Yes, very much
? I made http://trac.sagemath.org/ticket/16865 from this 8 months ago,
but
nobody has said which should be defined correct way. Do we at least have
same opinion about that this is a bug?
Given the following output, it would indeed make more sense if 2 were... at
the top.
sage:
Hi,
#17688: remove PY_NEW from Sage libs
#18030: cimport it instead of using the .pxi
Though I am not sure why you get these errors.
Vincent
On 20/04/15 15:00, Volker Braun wrote:
Nothing changed as far as I know. You should be using the usual Python
idiom of __new__ and not
PY_NEW:
On 2015-04-20, Simon King simon.k...@uni-jena.de wrote:
Currently I get new segfaults in some experimental code, and they arise
when PY_NEW is called. Has something changed for that function?
I found that the segfaults vanish when I remove optional arguments from
__cinit__. I.e., instead of
I would like to second this demand:
see for example http://patchbot.sagemath.org/ticket/17821/
for one example of misbehavior of sage4
to update:
sage -i http://chapoton.perso.math.cnrs.fr/patchbot-2.3.3.spkg
Frederic
Le dimanche 19 avril 2015 13:21:47 UTC+2, vdelecroix a écrit :
Hello,
Nothing changed as far as I know. You should be using the usual Python
idiom of __new__ and not
PY_NEW: https://github.com/cython/cython/wiki/FAQ#id21
On Monday, April 20, 2015 at 8:38:45 AM UTC-4, Simon King wrote:
Hi!
Currently I get new segfaults in some experimental code, and they
On Monday, April 20, 2015 at 3:27:45 AM UTC+2, François wrote:
On 04/20/15 09:23, ggrafendorfer wrote:
Sagetex e.g., is one reason:
http://www.sagemath.org/doc/installation/sagetex.html
I have to agree with other that setting SAGE_ROOT is
asking for trouble. For the case of of
Hi!
Currently I get new segfaults in some experimental code, and they arise
when PY_NEW is called. Has something changed for that function?
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and
On 20 April 2015 at 02:16, John H Palmieri jhpalmier...@gmail.com wrote:
As far as I can tell, it is never a good idea to set SAGE_ROOT, nor is it
ever suggested that you do so in the documentation. I think you could expect
things to break if you set environment variables which Sage uses
The correct link for Nicolas:
https://www.youtube.com/watch?feature=player_detailpagev=JVVMMULwR4s#t=2701
Best,
Bruno
Le 20/04/2015 11:05, Viviane Pons a écrit :
Hi everyone,
we were a bunch of Sage people at PyCon this year. Here's a link to
the talk I gave about combinatorics:
Hi everyone,
we were a bunch of Sage people at PyCon this year. Here's a link to the
talk I gave about combinatorics:
https://www.youtube.com/watch?v=3LZiZKgVjaU
Nicolas Thiery also gave a lightning (5 minutes) talk about our crazy class
hierarchy.
https://www.youtube.com/watch?v=3LZiZKgVjaU
On 20/04/15 04:54, David Roe wrote:
On Sun, Apr 19, 2015 at 10:18 AM, Volker Braun vbraun.n...@gmail.com
wrote:
I agree, coercion G - M is probably the right thing to do here.
+1
Thanks for your support! I opened #18258.
--
You received this message because you are subscribed to the
My guess would be that you just have a corrupt heap and then you fail
randomly at new allocations.
On Monday, April 20, 2015 at 8:45:14 AM UTC-4, Simon King wrote:
On 2015-04-20, Simon King simon...@uni-jena.de javascript: wrote:
Currently I get new segfaults in some experimental code, and
On Sunday, April 19, 2015 at 12:32:20 PM UTC-4, leif wrote:
On 04/19/2015 05:41 PM, Nathann Cohen wrote:
I often have a look at positively reviewed tickets and sometimes ask
questions about the review. Positive review just mean that one person
agreed
that the changes were good to be
If I have typeset_mode(True) in SMC and try to do
maxima_calculus('algebraic: true;')
I get a RuntimeError:
https://cloud.sagemath.com/projects/8a65b3c2-4322-4858-b6f9-e85fc7dac4f8/files/2015-04-20-093152.sagews
The problem seems to be that latex() on the output fails...which is a
bit
On Monday, 20 April 2015 12:10:21 UTC-6, Volker Braun wrote:
Which build step / which setup.py? Logs?
I believe it was building Sage itself and getting stuck at rings. Can't
provide a log now, will try to run it again overnight and post a log
tomorrow.
On Monday, April 20, 2015 at
Which build step / which setup.py? Logs?
On Monday, April 20, 2015 at 12:33:24 PM UTC-4, Andrey Novoseltsev wrote:
Hello,
Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It
has swap as well, but I don't think it was used much, the wall time was
just a bit bigger than
Hi,
i confirm i had the same issue on a Genuine Intel(R) CPU T2050 @ 1.60GHz
with 1GB of RAM (+1.5GB swap), the build of 6.5 was sucessful, but get stuck for
6.6.
Ciao,
Thierry
On Mon, Apr 20, 2015 at 09:33:24AM -0700, Andrey Novoseltsev wrote:
Hello,
Up to Sage-6.5 I was able to build it
On 2015-04-20 14:38, Simon King wrote:
Has something changed for that function?
Yes, very much. It gradually changed in various sub-tickets of
http://trac.sagemath.org/ticket/17854
Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage
types Integer and RealDoubleElement (which
Right now there is no feature detection, so any discussion about possible
performance issues are unlaid eggs. I don't think its going to be an issue,
and it also can be delayed during startup. The _rich_repr_ have the job of
deciding no the best representation for a particular object, so they
Hello,
Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has
swap as well, but I don't think it was used much, the wall time was just a
bit bigger than user+system, about 8-9 hours.
With Sage-6.6 it gets stuck while processing rings directory: swap is not
full yet, but
Hi!
In http://trac.sagemath.org/ticket/7298 (on HTML5 video for animations)
and some other tickets I'm currently dealing with the effects of the rich
output framework introduced by Volker in
http://trac.sagemath.org/ticket/17234. I've some concerns about the
scalability of this approach, and
For the record, this is what I did as release manager:
1. take a bunch of tickets with positive_review, make a private Sage
release with them, test them on the buildbot.
2a. if there are buildbot failures and it's clear which ticket caused
them: set the ticket to needs_work and GOTO 1.
2b.
On 2015-04-20 21:37, Simon King wrote:
Hi Jeroen,
On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage
types Integer and RealDoubleElement (which use custom allocation
functions that Cython isn't aware of)
Thank
Hi Jeroen,
On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage
types Integer and RealDoubleElement (which use custom allocation
functions that Cython isn't aware of)
Thank you! Is there a penalty for doing
On 04/20/2015 06:33 PM, Andrey Novoseltsev wrote:
Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It
has swap as well, but I don't think it was used much, the wall time was
just a bit bigger than user+system, about 8-9 hours.
I hope the 8-9 hours refer to the total time,
On 2015-04-19 13:21, Vincent Delecroix wrote:
Hello,
It seems that the patchbot
Gentoo Base System/2.2/x86_64/3.2.1-gentoo-r2/sage4
is somewhat broken! (it fails at a very early step while other build bot
did well)
Once the new patchbot proves that it actually works better than the
current
On 2015-04-20, Simon King simon.k...@uni-jena.de wrote:
Thank you! Is there a penalty for doing type(self) twice? I am
thinking of PY_NEW(type(self)) versus type(self).__new__(type(self)),
with typical application in the creation of elements in methods like
_add_ or _mul_.
There is a penalty,
34 matches
Mail list logo
