On Mon, 20 Apr 2015, Nathann Cohen wrote:
I made http://trac.sagemath.org/ticket/16865 from this 8 months ago,
but nobody has said which should be defined correct way.
Given the following output, it would indeed make more sense if 2 were... at the
top.
sage: Poset([[1,2],[[1,2]]]).top()
2
Hi!
On 2015-04-21, Clemens Heuberger wrote:
> 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.
For a similar re
Hello Jeroen,
1) I am sorry for having released a broken patchbot without testing it. All
my apologies. As far as I know, 2.3.3 is now repaired.
2) the *only current working patchbot* seems to be pcl337b, running
patchbot 2.3.2 probably with --skip-base
All the other machines seem to meet variou
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
-- Forwarded message --
From: Roberto Panai
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 is not a (updated) binar
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 th
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
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,
Hi Jeroen,
On 2015-04-20, 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)
See my previous post: This is wha
On 2015-04-20 21:37, Simon King wrote:
Hi Jeroen,
On 2015-04-20, Jeroen Demeyer 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 penalt
On 2015-04-20, Simon King 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, but one can cope
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 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,
Hi Jeroen,
On 2015-04-20, Jeroen Demeyer 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 "type(self)" twice? I a
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. if
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
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 buil
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" (wh
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 it
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 wo
Hi!
In http://trac.sagemath.org/ticket/7298 (on HTML5 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 would
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
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 stran
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 > wrote:
> > Currently I get new segfaults in some experimental code, and they arise
> > when PY_NEW
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: https://g
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 2015-04-20, Simon King 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
def __cinit__(self, *
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 s
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,
>
> ? 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: P
On 20/04/15 04:54, David Roe wrote:
On Sun, Apr 19, 2015 at 10:18 AM, Volker Braun
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 Google Groups
"sage-devel
The correct link for Nicolas:
https://www.youtube.com/watch?feature=player_detailpage&v=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:
https://w
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 (a
On 20 April 2015 at 02:16, John H Palmieri 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 internally.
> One solution
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 cas
36 matches
Mail list logo
