[PyX-devel] Re: Some comments on PyX

[Fernando P. <fp...@co...>]

Hi all,

thanks for your replies on this topic.  I'm subscribed to pyx-devel now, =
so I=20
can follow the discussion better.  I'll try to summarize my replies to th=
e=20
various messages here to minimize overall traffic.

Andre Wobst wrote:

>>'import pyx' doesn't provide access to pyx's modules.  The examples pro=
vided
>>all use 'from pyx import *', which is bad form for larger scripts, wher=
e 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(),[])
[snip]
>=20
> 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=
e in=20
startup time caused by this import.  However, since the current default p=
retty=20
much pushes people to default to 'from pyx import *' all the time, they a=
re=20
_already_ paying that price :)  The above solution therefore won't add an=
y=20
overhead to most users, except those who are careful to do 'from pyx impo=
rt=20
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=
 *'=20
statements are just bad coding style.  If the default behavior requires p=
eople=20
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=
 ;)=20
And one day, a weird bug pops up because you pasted a little pyx script i=
nto a=20
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 [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
... [snip]
Namespaces are one honking great idea -- let's do more of those!

Really, namespaces _are_ a good thing.  I strongly (but humbly :) advocat=
e=20
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=
 bit=20
trying to get distutils to do what you want.  Distutils is incredibly bad=
ly=20
documented, and getting it to do anything beyond its defaults is _extreme=
ly_=20
difficult.

I'd strongly suggest that you guys download IPython=20
(http://ipython.scipy.org), and look at its setup.py file.  In particular=
,=20
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=
e a=20
distutils extension called install_data_ext (in the directory setupext/ o=
f the=20
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=
t the
>>ideal default for some latex-related reasons I don't understand, the tr=
uth is
>>that distributions as popular as RedHat choke on the current configurat=
ion.
>>If this simple change makes pyx work out of the box for many users, it =
is that
>>much more likely to become popular.
>=20
>=20
> 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 =
to=20
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=
l=20
have :)  Unless there is a good technical reason NOT to have a default wh=
ich=20
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=
out may=20
>>be just too short.  We serve /home from an old Solaris box, and latex'i=
ng a=20
>>file typically is a bit of a slow process with lots of network read/wri=
te=20
>>activity.  I wouldn't be surprised if this was a rather common situatio=
n in=20
>>typical unix shops.
>>
>>FIX: I'd advocate for a much longer timeout, perhaps 30 seconds at leas=
t.  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 muc=
h more
>>robust system in the face of 'real world' network environments.
>=20
>=20
> 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.
>=20
> BTW: You can always do so by "text.set(waitfortex=3D30)" for the defaul=
t
> 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=
tand=20
your concerns about not making it overly long.  I'd suggest that 30 secon=
ds=20
still sounds reasonable to me, but that's open to debate.  However, there=
's a=20
  very simple solution which perhaps will make everyone happy: you can ha=
ve a=20
long timeout by default (say 30 seconds), and an internal timeout (harcod=
ed to=20
5 seconds).  The code waits for the internal timeouts, and every time tha=
t=20
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=
d.=20
Aborting.

This way you give your users feedback, and the system will be much more r=
obust=20
in the face of slow networks or fresh latex installations which will need=
 to=20
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).
>=20
>=20
>>I've put up what I get (temporarily) in
>>http://windom.colorado.edu/~fperez/tmp/pattern.eps
>>in case the developers find it useful.
>=20
>=20
> 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=
o I=20
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):
>=20
> 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=
yx=20
under windows.  You may want to be careful not to hardcode /etc or ~ for =
your=20
config file locations if you want pyx to be at least useable under window=
s.=20
You may look at what I did in ipython to address that issue (basically, s=
tore=20
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=
nd=20
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.

Regards,

Fernando.