Menu
▾
▴
[PyX-devel] Re: Some comments on PyX
|
From: Andre W. <wo...@us...> - 2003-10-16 06:34:05
|
Fernando,
thanks for your detailed report. There are important issues we surely
want to address. Let me briefly give you some comments right now on
some issues, which are easy to solve.
On 15.10.03, Fernando Perez wrote:
> 'import pyx' doesn't provide access to pyx's modules. The examples provided
> all use 'from pyx import *', which is bad form for larger scripts, where this
> kind of blanket import is bound to cause nasty name collisions.
>
> FIX: trivial. In __init__.py, add after __all__ is defined:
>
> # Load __all__ in pyx namespace so that a simple 'import pyx' gives
> # access to them via pyx.<name>
> for name in __all__:
> __import__(name,globals(),locals(),[])
Right now you can do the following:
wobsta@mbo:~$ python
Python 2.3.2 (#1, Oct 6 2003, 16:59:47)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyx
>>> import pyx.canvas
>>> c = pyx.canvas.canvas()
>>> c.text(0, 0, "Hello, world!")
<pyx.text._textbox instance at 0x4030f86c>
>>> c.writetofile("hello")
Yes, you have to do the second import statement. But is that really a
crucial point? I'm interested in Jörgs response to that as well.
> - PROBLEM: setup.py doesn't put things in the proper place if --home is given
> different from the default. I used --home=~/usr/local, and while pyx itself
> went into ~/usr/local/lib/python/pyx, its .lfs files went to
> ~/usr/local/share/pyx. But the pyx program itself expects to find them
> somewhere else, because trying to run hello.py produces:
>
> planck[examples]> python hello.py
> Traceback (most recent call last):
> File "hello.py", line 4, in ?
> c.text(0, 0, "Hello, world!")
> File "/home/fperez/usr/local/lib/python/pyx/canvas.py", line 767, in text
> return self.insert(self.texrunner.text(x, y, atext, *args))
> File "/home/fperez/usr/local/lib/python/pyx/text.py", line 2283, in text
> return self._text(unit.topt(x), unit.topt(y), expr, *args)
> File "/home/fperez/usr/local/lib/python/pyx/text.py", line 2271, in _text
> self.execute(expr, *helper.getattrs(args, texmessage, default=self.texmessagedefaultrun))
> File "/home/fperez/usr/local/lib/python/pyx/text.py", line 1994, in execute
> raise IOError("file '%s' not found. Available latex font sizes: %s" % (lfsname, lfsnames))
> IOError: file '10pt.lfs' not found. Available latex font sizes: []
>
> This may be a bug in setup.py, or in pyx itself (pyx may need to adjust its
> search paths according to where it got installed). I don't know for sure.
>
> Putting some print statements in text.py gave the following:
>
> *** file 10pt.lfs not found!
> *** file /usr/share/pyx/10pt.lfs not found!
> *** file /home/fperez/usr/local/lib/python/pyx/lfs/10pt.lfs not found!
>
> So the problem is in how pyx builds its search path (lines 1980-93 in
> text.py). It needs to pick up the correct installation path, or setup.py
> needs to make sure that the lfs files end up underneath the pyx directory
> (instead of above it, in ../../share).
>
> FIX: For now I can fix it manually, by moving the .lfs files to a directory
> (which must be created first) called
> /home/fperez/usr/local/lib/python/pyx/lfs. But this needs to be done
> permanently in the code. I'm not exactly sure what the correct fix is.
This hole subject is very important to be improved. I may tell you,
why it is the way it is right now: The first search path is just the
local directory in case you're placing own lfs-files there. The second
path is pythons share directory. Since these lfs-files are installed
as data_files by setup.py they automatically come into this share
directory. PyX now asks python for its default share directory ... yes
and this goes wrong when installing PyX to another place. I'll try to
find out how to fix this. It should be a common problem using
data_files and distutils. (Unfortunately those things are kind of
difficult to learn out of the distutils documentation).
However, the third search path is for inplace compilation and usage
(thus basically for development). It uses the path where the modules
are located which is fine, but it seems not to be the correct place to
install data_files to that possition. Thus it is not intended to be
used in a properly installed PyX package.
BTW, for the second search path: We could do a path search like in the
third case and walk towards "../../share" in order to reach the share
directory. But what if you tell the setup.py to install the data_files
at some other place? (I'm not sure if you're allowed to do so.) I have
to really address this correctly since we now know that it is broken.
> PROBLEM
> -------
>
> After fixing the previous one manually, I still can't run hello.py.
> Note that I've also seen this error on a machine where pyx was 'setup.py
> install'ed to a default directory.
>
> Here's the traceback:
>
> planck[examples]> python hello.py
> Traceback (most recent call last):
> File "hello.py", line 6, in ?
> c.writetofile("hello")
>
> ... [snip]
>
> RuntimeError: no information for font 'cmr10' found in font mapping file, aborting
>
> This problem is discussed in:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=3225190&forum_id=23700
>
> FIX: change around line 504 of text.py, from:
>
> fontmap = readfontmap(["psfonts.map"])
>
> to:
>
> fontmap = readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"])
>
> It might be worth doing this in the mainline sources. Even if it is not the
> ideal default for some latex-related reasons I don't understand, the truth is
> that distributions as popular as RedHat choke on the current configuration.
> If this simple change makes pyx work out of the box for many users, it is that
> much more likely to become popular.
Its likely that we will have some /etc/pyxrc and ~/.pyxrc for that in
the future (like you can have a .dvipsrc telling dvips to do the same
as PyX regarding the fonts; its the 'p' option in the dvipsrc or the
'u' at the command line). We should provide an example for that file
telling people to possibly include that map files when they are
running a TeX installation not using type1 fonts by default.
> PROBLEM
> -------
>
> Trying to run the latex.py example:
>
> planck[examples]> python latex.py
> Traceback (most recent call last):
> File "latex.py", line 9, in ?
> c.text(0, 0, r"This is \LaTeX.")
>
> .... [snip]
>
> pyx.text.TexResultError: TeX didn't respond as expected within the timeout
> period (5 seconds).
> The expression passed to TeX was:
> \documentclass{article}%
> \PyXInput{3}%
> After parsing the return message from TeX, the following was left:
> *
>
>
> The problem is that on a system where ~ is NFS mounted, a 5 second timeout may
> be just too short. We serve /home from an old Solaris box, and latex'ing a
> file typically is a bit of a slow process with lots of network read/write
> activity. I wouldn't be surprised if this was a rather common situation in
> typical unix shops.
>
> FIX: I'd advocate for a much longer timeout, perhaps 30 seconds at least. I
> changed it to 30 (line 1848 of text.py), and it works fine even on our
> sluggish network. While this timeout is a bit long, it makes pyx a much more
> robust system in the face of 'real world' network environments.
I do not want to make it very long, because people might have to wait
for that timeout if TeX is broken badly (however, once your setup is
fine its not likely that you step into that problem). People are
probably not waiting that long if their script seem to hang. We might
make that an option in the .pyxrc as well ... so that you can adjust
it to your specific needs. You're right that you might want to
increase this value to make PyX more reliable.
BTW: You can always do so by "text.set(waitfortex=30)" for the default
texrunner and in the same way at the constructor when creating own
texrunner instances.
> PROBLEM
> -------
>
> After fixing the above, I can run most of the included examples. The only
> remaining issues are:
>
> - The pattern.eps file looks very different from the one on the website. The
> global figure is indeed the PyX logo, but instead of being made out of little
> copies of PyX, it's made out of text blocks. This may or may not be an issue
> with my system, I don't know.
It's likely that you're just observing a problem of ghostscript here.
Try to turn off the anti-aliasing feature of ghostscript (it helps in
quite some cases where ghostscript behaves badly). In ghostview press
"a" for that. You may also send this file to a PostScript 2 aware
printer (IIRC these pattern things are PostScript Level 2 features).
> I've put up what I get (temporarily) in
> http://windom.colorado.edu/~fperez/tmp/pattern.eps
> in case the developers find it useful.
Yes, it works for me with disabled antialiasing in ghostscript.
> - bar.py and minimal.py don't run because the corresponding .dat files are not
> included in the distribution.
I've got this report yesterday from Andrea Riciputi as well and
already fixed the distribution configuration in CVS in that respect.
I quickly want to summarize my impression (also in order to tell Jörg
about my point of what we should do):
1) We need some runtime configuration possibility (like a pyxrc). We
had discussed it in terms of the mapping files before already. There
are two further use-cases: the timeout configuration (suggested above)
and the TeX --ipc option (I've done some tests working nicely, but now
I have to work in the direction of a pagewise dvi-reading inside PyX).
2) I have to address the share/data_files search path issue.
Thanks for all your intensive work in testing our package. You
hopefully will like it so it was worse your effort. You're welcome to
further join the discussion.
André
PS: I'm crossposting this to pyx-devel in order to let other
developers be able to join your discussion.
--
by _ _ _ Dr. André Wobst
/ \ \ / ) wo...@us...
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/
|
