I use Python as a interactive data analysis environment. That is, I
use the IPython enhanced interactive shell and have sessions that run
to hundreds or thousands of commands, loading data, plotting it,
transforming it, plotting again, etc.
However, this usage pattern is hampered by the fact that if I leave
PyX alone for ~2 minutes and then try to plot something, PyX always
seems to have lost contact with its TeX process and I get backtraces:
<class 'pyx.text.TexResultError'>: TeX didn't respond as expected
within the timeout period (60 seconds).
Then I have to quit python, restart, load all my data and functions,
and then start working again.
I've used PyX like this for a long time, and in the past ~once per day
or so I'd lose contact with TeX, and ~80 percent of the time I could
reestablish contact via some combination of:
1) pyx.text.reset()
2) pyx.text.reset(reinit=True)
3) dreload(pyx)
4) a function I wrote that reloads all loaded modules
5) a function I wrote that deletes all of the pyx modules from
sys.modules, imports, PyX, then reimports all other modules that use
PyX (intended to try to get all of the references to the old modules)
However, now none of these things work for me. #1 and #2 fail to
solve the problem. #3 fails when dreload can't seem to find the
linestyle module, where the abbreviated backtrace (including the error
and the part that seems to be related to PyX) is:
.....
/home/novak/bin/local/lib/python2.5/site-packages/pyx/graph/data.py in
<module>()
26 import math, re, ConfigParser, struct, warnings
27 from pyx import text
---> 28 from pyx.style import linestyle
29 from pyx.graph import style
30
.....
/var/lib/python-support/python2.5/IPython/deep_reload.py in
ensure_fromlist(m, fromlist, recursive)
118 submod = import_module(sub, subname, m)
119 if not submod:
--> 120 raise ImportError, "No module named " + subname
121
122 # Need to keep track of what we've already reloaded to prevent
cyclic evil
<type 'exceptions.ImportError'>: No module named pyx.linestyle
Finally, #4 and #5 seem to work but when I try to use PyX after that I
get errors from the code near line 50 of attr.py from PyX 0.10:
if isinstance(a, attr):
newattrs = a.merge(newattrs)
else:
raise TypeError("only instances of class attr.attr are allowed")
I get a type error. When I enter the debugger at that point, it
_looks_ like the attribute in question is indeed a subclass of type
attr (when you print out a, it says 'instance of whatever' which is a
subclass of attr), but isinstance(a, attr) returns false. This seems
puzzling.
I have a guess about what is happening here, which may or may not be
comprehensible or have anything to do with reality: It's that my
rampant reloading of pyx modules has left two instances of the attr
class in memory (the instance of the class object itself (what you get
when you call super()), not instances of the class). Furthermore,
isinstance does something like calling super() repeatedly and
comparing the id()'s of the result with the class object of the
instance in question. If none of them match, isinstance returns
false. However, if there are two copies of the attr class object
laying around, then an instance can look and smell like an attr object
but not point to the _correct_ attr object, hence isinstance returns
false. However, my understanding is obviously on shaky ground here.
Finally, notes on environment. I'm using Ubuntu 8.04, Python 2.5.2,
and PyX 0.10. tex --version => TeX 3.141592 (Web2C 7.5.6), and latex
--version => pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)
k
Esoteric unrelated note: In Common Lisp, the object system assumes
that you'll be using the system interactively and will occasionally
want to redefine objects as you're debugging them. Therefore when
this happens, the system knows how to update the _previously created
instances already sitting in memory_ with the new definition. This
amazes me. You don't have to run around the system trying to track
down the old instances and delete them, similar to what I did above
where I tried to delete all of the old references to the PyX modules
so that they'd be replaced by the newly reloaded ones, and you
wouldn't have problems with things seeming to be instances of a class
but not really being instances of the class.
Sigh... sorry that this is so rambling. I'm interested to hear if
anyone successfully (or unsuccessfully) uses PyX in this mode. If
anyone knows how to avoid the problem or how to fix it, that's even
better...
with gratitude for advice,
Greg
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user
