Recently I was doing some middleweight polytope calculations - meaning
stuff that takes about 15 minutes to compute on a nice machine - and
the convex_hull call to polymake began to hang at a certain point.
The faster your machine, the bigger a polytope you need to reproduce
this, but its a pretty robust bug.
The problem seems to lie in some sort of deadlock with the popen3 call
in the cmd method of the Polytope class in polytope.py. I can "fix"
this by simply deleting the error-checking code and moving the
stdin.close() command - i.e. at the end of the cmd definition I have
stdin, stdout, stderr = os.popen3(c)
#stdin.close()
#err = stderr.read()
#if len(err) > 0:
# raise RuntimeError, err
ans = stdout.read()
if len(ans) == 0:
raise ValueError, "%s\nError executing polymake command
%s"%(
err,cmd)
stdin.close()
self.__data = open(F).read()
return ans
and it seems to work fine on my bigger polytopes. In searching the
source, I noticed that there are similar constructions elsewhere, and
so this may be a pervasive problem.
I have become confused trying to understand the finer points of popen,
popen2, popen3, popen4, and popen2.Popen3, subprocess,
os.system, ....python seems to have a bewildering array of such
functions. I would be interested in any opinions. Doug Hellman seems
to have some clearly written thoughts up at
http://blog.doughellmann.com/2007/07/pymotw-subprocess.html
on subprocess.
If I can get a little help and insight on this I will try to write a
patch.
-Marshall
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
