sage/homology/examples.py doctest timeout in the latest 4.6.1.alpha2

[François Bissey]

Hi,

After building 4.6.1.alpha2 (16 Nov 2010 13:35) I and one other
person in sage-on-gentoo have observed the following time out:
sage -t -long -verbose -force_lib "devel/sage/sage/homology/examples.py" #
Time out

More precisely here the bit where it get stuck:
Trying:
P5 = simplicial_complexes.RealProjectiveSpace(Integer(5)) # long time: 45
seconds###line 501:_sage_ >>> P5 =
simplicial_complexes.RealProjectiveSpace(5) # long time: 45 seconds
Expecting nothing
ok
Trying:
P5.f_vector() # long time###line 502:_sage_ >>> P5.f_vector() # long
time
Expecting:
[1, 63, 903, 4200, 8400, 7560, 2520]
ok
Trying:
P5.homology() # long time###line 504:_sage_ >>> P5.homology() # long
time
Expecting:
{0: 0, 1: C2, 2: 0, 3: C2, 4: 0, 5: Z}
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***

[1800.2 s]

-----------------------

This occurred on Gentoo linux on one x86 box and one amd64 box, I may have
some more report later from debian boxes.

Any idea what could be behind this?

Francois

[François Bissey]

I just found out that it was introduced in alpha2 by ticket #9125 so it is new
stuff being tested here.

Francois

[John H Palmieri]

I think we can just delete this test ("P5.homology()"). Should we
open a new ticket or modify #9125?

--
John

[John H Palmieri]

Actually, the right thing to do is to rewrite the doctest as something
like

sage: P5.homology() # long time # optional - CHomP

{0: 0, 1: C2, 2: 0, 3: C2, 4: 0, 5: Z}

If Sage can find CHomP on your system, it uses that for homology
computations, and I must have had that installed when working on the
patch, because without CHomP:

sage: time P5.homology()
CPU times: user 2758.52 s, sys: 15.05 s, total: 2773.57 s
Wall time: 2857.58 s

With CHomP:

sage: time P5.homology()
CPU times: user 0.05 s, sys: 0.05 s, total: 0.11 s
Wall time: 1.02 s

So it's a completely reasonable doctest if CHomP is present, but not
otherwise.

--
John

[mhampton]

Pretty good example of why CHomP is worth including!

-Marshall

[François Bissey]

Ok, yes, on the machine the test passed it took quite a long time. Is CHomP
an optional or experimental package right now? Or nowhere?

Francois

[John H Palmieri]

On Nov 17, 9:35 pm, François Bissey <f.r.bis...@massey.ac.nz> wrote:
> > Pretty good example of why CHomP is worth including!
>
> > -Marshall

> Ok, yes, on the machine the test passed it took quite a long time. Is CHomP
> an optional or experimental package right now? Or nowhere?

It's experimental. I hope that running "sage -i chomp" will work on
any platform (as long as you have internet access to download the
spkg), but I haven't tested it extensively. It works on sage.math, on
my Mac running OS X 10.6, and on a Solaris box, which is pretty good
for a start, but I haven't tried it on all of the various linux
platforms.

I think Marshall is right, and we should try to upgrade it to
optional. How does that work? Aside from testing on lots of
different platforms, does it require some discussion on sage-devel?

--
John

[David Kirkby]

[François Bissey]

OK I installed the latest (upstream) version of chomp (this is sage-on-gentoo
so I don't have a matching spkg) and indeed the test passed in no time at all.

It would be nice if they were versionning the software and their tarball one
way or another.

Francois (who is wondering if Dave has anything to say)

[David Kirkby]

Sorry for the empyt reply I just made. Somehow I hit "Send" by mistake.

On 18 November 2010 06:05, John H Palmieri <jhpalm...@gmail.com> wrote:

> On Nov 17, 9:35 pm, François Bissey <f.r.bis...@massey.ac.nz> wrote:
>> > Pretty good example of why CHomP is worth including!
>>
>> > -Marshall

Well, the fact a doctest fails that relied on CHomP is not exactly a
good reason for including it! There may be good reasons for including
it, but so a broken doctest then pases is not one of them.

>> Ok, yes, on the machine the test passed it took quite a long time. Is CHomP
>> an optional or experimental package right now? Or nowhere?
>
> It's experimental.  I hope that running "sage -i chomp" will work on
> any platform (as long as you have internet access to download the
> spkg), but I haven't tested it extensively.

It failed on my OpenSolaris machine, with:

g++ -O2 -ansi -pedantic -Wall -I../include -o
../obj/capd-homengin/engines.o -c \
../src/capd-homengin/engines.cpp
In file included from ../include/capd/auxil/clock.h:18:0,
from ../include/capd/auxil/Stopwatch.h:19,
from ../include/capd/homologicalAlgebra/homAlgFunctors.hpp:27,
from ../include/capd/homologicalAlgebra/cubSetFunctors.hpp:22,
from ../include/capd/multiEngHom/MultiEngHomT.h:30,
from ../src/capd-homengin/engines.cpp:35:
../include/capd/capd/operatingSystemSetting.h:73:2: error: #error Your
system cannot be determined automatically by the KRAK package.Please
edit the configuration file appropriately.
In file included from ../include/capd/auxil/Stopwatch.h:19:0,
from ../include/capd/homologicalAlgebra/homAlgFunctors.hpp:27,
from ../include/capd/homologicalAlgebra/cubSetFunctors.hpp:22,
from ../include/capd/multiEngHom/MultiEngHomT.h:30,
from ../src/capd-homengin/engines.cpp:35:
../include/capd/auxil/clock.h: In function 'long double getWorldSeconds()':
../include/capd/auxil/clock.h:54:32: error: aggregate
'getWorldSeconds()::_timeb timebuffer' has incomplete type and cannot
be defined
In file included from ../include/capd/auxil/Stopwatch.h:19:0,
from ../include/capd/homologicalAlgebra/homAlgFunctors.hpp:27,
from ../include/capd/homologicalAlgebra/cubSetFunctors.hpp:22,
from ../include/capd/multiEngHom/MultiEngHomT.h:30,
from ../src/capd-homengin/engines.cpp:35:
../include/capd/auxil/clock.h:55:31: error: '_ftime' was not declared
in this scope
../include/capd/auxil/clock.h:57:5: warning: control reaches end of
non-void function
make[2]: *** [../obj/capd-homengin/engines.o] Error 1
make[2]: Leaving directory
`/export/home/drkirkby/sage-4.6.1.alpha2/spkg/build/chomp-20100213.p1/src/make'
:

The fact you said it worked on Solaris, can I assume that was on
t2.math or other SPARC (mark, mark2) and not fulvia (x86)?

I created http://trac.sagemath.org/sage_trac/ticket/10288

for this.

I've not looked at the code, but I doubt that would be difficult to
fix if it works on any sort of Solaris system.

> It works on sage.math, on
> my Mac running OS X 10.6, and on a Solaris box,
which is pretty good
> for a start, but I haven't tried it on all of the various linux
> platforms.
>
> I think Marshall is right, and we should try to upgrade it to
> optional.  How does that work?  Aside from testing on lots of
> different platforms, does it require some discussion on sage-devel?
>
> --
> John

I personally think it would be a good idea to do that for all upgrades
of Experimental->Optional, since optional is supposed to be supported
by the Sage community, unlike experimental where there are no
requirements that anyone will support them.

See

http://trac.sagemath.org/sage_trac/ticket/9690

for some differences between the types of packages.

Dave

[John H Palmieri]

On Nov 18, 1:40 am, David Kirkby <david.kir...@onetel.net> wrote:
> Sorry for the empyt reply I just made. Somehow I hit "Send" by mistake.
>

> On 18 November 2010 06:05, John H Palmieri <jhpalmier...@gmail.com> wrote:
>
> > On Nov 17, 9:35 pm, François Bissey <f.r.bis...@massey.ac.nz> wrote:
> >> > Pretty good example of why CHomP is worth including!
>
> >> > -Marshall
>
> Well, the fact a doctest fails that relied on CHomP is not exactly a
> good reason for including it! There may be good reasons for including
> it, but so a broken doctest then pases is not one of them.

It wasn't exactly broken, it just takes a really long time. And it's
a new doctest, added in 4.6.1.alpha2, so modifying the doctest to
require the use of CHomP doesn't seem like a bad idea.

> It failed on my OpenSolaris machine

I now have an spkg which builds on hawk.

> The fact you said it worked on Solaris, can I assume that was on
> t2.math or other SPARC (mark, mark2) and not fulvia (x86)?

I think that's right. I think that when I made the spkg, Sage wasn't
building on fulvia, so the spkg didn't get tested there.

> I created
>
> http://trac.sagemath.org/sage_trac/ticket/10288
>
> for this.

I've posted a new spkg there.

--
John