thanks for your replies on this topic. I'm subscribed to pyx-devel now, =
can follow the discussion better. I'll try to summarize my replies to th=
various messages here to minimize overall traffic.
Andre Wobst wrote:
>>'import pyx' doesn't provide access to pyx's modules. The examples pro=
>>all use 'from pyx import *', which is bad form for larger scripts, wher=
>>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__:
> Yes, you have to do the second import statement. But is that really a
> crucial point? I'm interested in J=F6rgs response to that as well.
As others have mentioned, the only real drawback is the potential increas=
startup time caused by this import. However, since the current default p=
much pushes people to default to 'from pyx import *' all the time, they a=
_already_ paying that price :) The above solution therefore won't add an=
overhead to most users, except those who are careful to do 'from pyx impo=
this,that,that_else' alone. From looking at the examples, not even the=20
developers do that :)
I think it's quite important to encourage clean usage of pyx, and 'import=
statements are just bad coding style. If the default behavior requires p=
to keep track of the subpieces of pyx manually like:
import pyx.canvas, pyx.text, ...
believe me, users will just get used to doing 'import *'. We're all lazy=
And one day, a weird bug pops up because you pasted a little pyx script i=
larger program to give the big program eps generation capabilities, and=20
inadvertently you got a namespace clash.
Like the Zen of Python says:
In : import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Namespaces are one honking great idea -- let's do more of those!
Really, namespaces _are_ a good thing. I strongly (but humbly :) advocat=
that pyx follows this design principle.
> 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.
This is most likely a distutils issue. I warn you: you'll suffer quite a=
trying to get distutils to do what you want. Distutils is incredibly bad=
documented, and getting it to do anything beyond its defaults is _extreme=
I'd strongly suggest that you guys download IPython=20
(http://ipython.scipy.org), and look at its setup.py file. In particular=
because I faced very similar problems, and a proper solution finally was=20
contributed by a user (Jack Moffit, one of the Ogg Vorbis guys). He wrot=
distutils extension called install_data_ext (in the directory setupext/ o=
ipython distro) which handles _precisely_ issues like this. You'll save=20
yourselves lots of headaches if you use this.
>>fontmap =3D readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"])
>>It might be worth doing this in the mainline sources. Even if it is no=
>>ideal default for some latex-related reasons I don't understand, the tr=
>>that distributions as popular as RedHat choke on the current configurat=
>>If this simple change makes pyx work out of the box for many users, it =
>>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.
I think the pyxrc file is an excellent idea, but is there any reason not =
use fontmap =3D readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"]) =
? As I=20
said, the better things work 'out of the box', the more happy users yoy'l=
have :) Unless there is a good technical reason NOT to have a default wh=
makes the package more robust in the face of diverse installations and=20
configurations, this approach is IMHO a good one to follow.
>>The problem is that on a system where ~ is NFS mounted, a 5 second time=
>>be just too short. We serve /home from an old Solaris box, and latex'i=
>>file typically is a bit of a slow process with lots of network read/wri=
>>activity. I wouldn't be surprised if this was a rather common situatio=
>>typical unix shops.
>>FIX: I'd advocate for a much longer timeout, perhaps 30 seconds at leas=
>>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 muc=
>>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=3D30)" for the defaul=
> texrunner and in the same way at the constructor when creating own
> texrunner instances.
Again, this is an issue of balancing robustness vs convenience. I unders=
your concerns about not making it overly long. I'd suggest that 30 secon=
still sounds reasonable to me, but that's open to debate. However, there=
very simple solution which perhaps will make everyone happy: you can ha=
long timeout by default (say 30 seconds), and an internal timeout (harcod=
5 seconds). The code waits for the internal timeouts, and every time tha=
expires it prints a warning:
*** PyX INFO: still waiting for latex after 5 seconds...
*** PyX INFO: still waiting for latex after 10 seconds...
*** PyX INFO: still waiting for latex after 15 seconds...
*** PyX ERROR: the timeout of 30 seconds expired and latex did not respon=
This way you give your users feedback, and the system will be much more r=
in the face of slow networks or fresh latex installations which will need=
build many fonts in a first pass.
> 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
>>in case the developers find it useful.
> Yes, it works for me with disabled antialiasing in ghostscript.
Same here, thanks for the tip. I had never had problems with AA in gv, s=
didn't think of that. Issue solved then.
> I quickly want to summarize my impression (also in order to tell J=F6rg
> 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).
One word of warning: in the scipy lists, there are people trying to use p=
under windows. You may want to be careful not to hardcode /etc or ~ for =
config file locations if you want pyx to be at least useable under window=
You may look at what I did in ipython to address that issue (basically, s=
those locations in internal variables which are read by a routine which=20
handles the platform issues; not pretty but effective).
> 2) I have to address the share/data_files search path issue.
Again, that one is a major pain in the ass with distutils, and keep in mi=
the ipython suggestion where Jack's module solves the problem.
> 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.
No problem. Thanks for the great tool.