Volker Braun wrote:
Is it actually frozen or is your computer just slow? ;-) In any case
your dtrace seems to be out of date. The new docbuilder uses the python
multiprocessing module. Is your FreeBSD new enough to support that?
Google search suggests that there were some semaphore problems up u
Montgomery-Smith, Stephen wrote:
So I ran the make process again. After getting to the point of freezing, using top, I
could see that there were a couple of invocations of python2.7. FreeBSD uses truss in
place of strace, and using "truss -p pid" where pid was the pid of one of the
invocatio
Is it actually frozen or is your computer just slow? ;-) In any case your
dtrace seems to be out of date. The new docbuilder uses the python
multiprocessing module. Is your FreeBSD new enough to support that? Google
search suggests that there were some semaphore problems up until a few
years a
So I ran the make process again. After getting to the point of freezing, using
top, I could see that there were a couple of invocations of python2.7. FreeBSD
uses truss in place of strace, and using "truss -p pid" where pid was the pid
of one of the invocations of python2.7, I could see lines
What about implementing Google's constraint programming library (
https://code.google.com/p/or-tools/)? It can be useful for problems in
discrete mathematics, and would give Sage capabilities that it appears that
no other mathematical software has.
On Friday, 8 March 2013 01:43:43 UTC-8, mmarco
can you strace/debug the process and see what its hanging at?
On Saturday, March 9, 2013 7:40:19 PM UTC-5, Stephen Montgomery-Smith wrote:
>
> Building on FreeBSD, the doc creation process freezes after this point:
>
> [history_a] loading pickled environment... not yet created
> [history_a] buil
Building on FreeBSD, the doc creation process freezes after this point:
[history_a] loading pickled environment... not yet created
[history_a] building [inventory]: targets for 1 source files that are
out of date
[history_a] updating environment: 1 added, 0 changed, 0 removed
[history_a] reading s
Op vrijdag 8 maart 2013 10:43:43 UTC+1 schreef mmarco het volgende:
>
> IIRC, the call for projects of Google summer of code was last year
> around march or april. Should we start to get prepared for this?
>
> I think you're right that we should. One thing that I would like to have
in Sage is be
Le 09/03/2013 10:54, Jeroen Demeyer a écrit :
On 2013-03-09 09:58, Julien Puydt wrote:
What is the point of an automated test which reliably fails on many boxes?
It doesn't *reliably* fail, it *rarely* fails.
I have three computers here which can't pass that test. Only one of them
is an ARM
Hi Robert,
On 2013-03-09, Robert Bradshaw wrote:
> Ugh. Usually, multiple inheritance from extension types in Python (and
> hence Cython) is prohibited because the base types have different
> layouts, ...
Ah, I thought they were incompatible, but Python just didn't realise.
> Here the class lay
On 2013-03-09 09:58, Julien Puydt wrote:
> What is the point of an automated test which reliably fails on many boxes?
It doesn't *reliably* fail, it *rarely* fails.
I think the worst tests in this regard are
* r.py: #9970
* expect.py: #10476
--
You received this message because you are subscribe
Le 07/03/2013 20:15, Julien Puydt a écrit :
Le 07/03/2013 18:24, leif a écrit :
Julien Puydt wrote:
Le 02/03/2013 08:16, Julien Puydt a écrit :
I'll run "make ptestlong" later, and report in this thread.
- a timeout (haven't looked at it yet)
sage -t --long -force_lib
devel/sage/sage/quad
Related:
http://stackoverflow.com/questions/10857515/cannot-inherit-from-multiple-classes-defining-slots
On Sat, Mar 9, 2013 at 12:28 AM, Robert Bradshaw
wrote:
> Ugh. Usually, multiple inheritance from extension types in Python (and
> hence Cython) is prohibited because the base types have diff
Ugh. Usually, multiple inheritance from extension types in Python (and
hence Cython) is prohibited because the base types have different
layouts, e.g.
class C(Integer, RealDoubleElement): pass
...:
Traceback (most recent call last):
Hi!
Currently, I try to make homsets and morphisms compliant with what one
would usually do when implementing parents and elements---in particular,
the default __mul__ and __add__ should do something meaningful and should
thus not be overridden. In particular, one would implement addition in
subcl
15 matches
Mail list logo
