pyx-devel — PyX development

Re: [PyX-devel] Weird font crash under RedHat 9.0

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

Andre Wobst wrote:

 > It's likely that the TeX installation on your RH9 box is configured to
 > use pk fonts by default instead of PostScript Type1 fonts. Take a look
 > to the PyX FAQ 4.3.6. It should guide you to the correct places to
 > look at and explain how to solve the problem.

Many thanks, Andre.  I'll look into this on Monday (back in the office) and 
I'll bug you again if I get stuck, which I doubt: the faq entry is fairly 
detailed, so I should be ok with it.

Best,

Fernando.

Re: [PyX-devel] Weird font crash under RedHat 9.0

[Andre W. <wo...@us...>]

Hi,

On 07.05.04, Fernando Perez wrote:
> I have some code which works perfectly OK in a Fedora box, yet is crashing 
> when run on a RH9 machine.  The final exception is:
> 
>   File "/home/fperez/usr/local/lib/python/pyx/dvifile.py", line 636, in 
>   __init__
>     raise RuntimeError("no information for font '%s' found in font mapping 
> file, aborting" % name)
> RuntimeError: no information for font 'cmmi10' found in font mapping file, 
> aborting
> 
> Both the RH9 and the Fedora boxes are heavily used for latex writing, so I 
> know the fonts are there on both.  I tried building PyX itself  (I'm 
> running 0.6.2) on both machines, and the results don't change.
> 
> I would very much appreciate any pointers.  I'm including a very detailed 
> traceback below, in case it helps.

It's likely that the TeX installation on your RH9 box is configured to
use pk fonts by default instead of PostScript Type1 fonts. Take a look
to the PyX FAQ 4.3.6. It should guide you to the correct places to
look at and explain how to solve the problem.

HTH,

André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Weird font crash under RedHat 9.0

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

Hi all,

I have some code which works perfectly OK in a Fedora box, yet is crashing 
when run on a RH9 machine.  The final exception is:

   File "/home/fperez/usr/local/lib/python/pyx/dvifile.py", line 636, in __init__
     raise RuntimeError("no information for font '%s' found in font mapping 
file, aborting" % name)
RuntimeError: no information for font 'cmmi10' found in font mapping file, 
aborting

Both the RH9 and the Fedora boxes are heavily used for latex writing, so I 
know the fonts are there on both.  I tried building PyX itself  (I'm running 
0.6.2) on both machines, and the results don't change.

I would very much appreciate any pointers.  I'm including a very detailed 
traceback below, in case it helps.

Thanks in advance,

Fernando.


===========================================================================

In [6]: run tfun
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/fperez/research/code/mwadap/tfun.py
       5
       6 f = Function.FunctionFromCode(nnod,eps,'testing/poisson_rho1g_2d.c')
----> 7 f.coef_tree.draw_skeleton('foo')
         f = <Function.FunctionFromCode instance>, global coef_tree = 
undefined, global draw_skeleton = undefined
       8
       9 def ft(eps=eps):

/home/fperez/research/code/mwadap/Function.py in __draw_skeleton_2d(self={2: 
{(3, 3): [[ -2.08188932e-13,  3.38157819e-13...865062e-15,  8.68178784e-16, 
8.93188220e-17,]]}}, fname='foo', label=1, palette='Hue', fill=0)
     507         if fname.endswith('.eps'):
     508             fname = fname[:-4]
--> 509         c.writeEPSfile(fname)
         c = <pyx.canvas.canvas object>, global writeEPSfile = undefined, 
fname = 'foo'
     510         # Show in gv
     511         os.system('gv %s.eps &' % fname)

/home/fperez/usr/local/lib/python/pyx/canvas.py in 
writeEPSfile(self=<pyx.canvas.canvas object>, filename='foo.eps', 
paperformat=None, rotated=0, fittosize=0, margin='1 t cm', bbox=None, 
bboxenlarge='1 t pt')
     425         mergedprolog = []
     426
--> 427         for pritem in self.prolog():
         pritem = undefined, self = <pyx.canvas.canvas object>, global prolog 
= <module 'pyx.prolog' from '/home/fperez/usr/local/lib/python/pyx/prolog.pyc'>
     428             for mpritem in mergedprolog:
     429                 if mpritem.merge(pritem) is None: break

/home/fperez/usr/local/lib/python/pyx/canvas.py in 
prolog(self=<pyx.canvas.canvas object>)
     146         result = []
     147         for cmd in self.PSOps:
--> 148             result.extend(cmd.prolog())
         result = [], global extend = undefined, cmd = <pyx.text.textbox 
object>, global prolog = <module 'pyx.prolog' from 
'/home/fperez/usr/local/lib/python/pyx/prolog.pyc'>
     149         return result
     150

/home/fperez/usr/local/lib/python/pyx/text.py in prolog(self=<pyx.text.textbox 
object>)
     610
     611     def prolog(self):
--> 612         self.ensuredvicanvas()
         self = <pyx.text.textbox object>, global ensuredvicanvas = undefined
     613         return canvas._canvas.prolog(self)
     614

/home/fperez/usr/local/lib/python/pyx/text.py in 
ensuredvicanvas(self=<pyx.text.textbox object>)
     599     def ensuredvicanvas(self):
     600         if self.dvicanvas is None:
--> 601             self.finishdvi()
         self = <pyx.text.textbox object>, global finishdvi = undefined
     602             assert self.dvicanvas is not None, "finishdvi is broken"
     603         if not self.insertdvicanvas:

/home/fperez/usr/local/lib/python/pyx/text.py in 
finishdvi(self=<pyx.text.texrunner instance>)
     960             page = 1
     961             for box in self.needdvitextboxes:
--> 962                 box.setdvicanvas(self.dvifile.readpage([ord("P"), 
ord("y"), ord("X"), page, 0, 0, 0, 0, 0, 0]))
         box = <pyx.text.textbox object>, global setdvicanvas = undefined, 
self = <pyx.text.texrunner instance>, global dvifile = <module 'pyx.dvifile' 
from '/home/fperez/usr/local/lib/python/pyx/dvifile.pyc'>, global readpage = 
undefined, global ord = undefined, page = 1
     963                 page += 1
     964         if self.dvifile.readpage(None) is not None:

/home/fperez/usr/local/lib/python/pyx/dvifile.py in 
readpage(self=<pyx.dvifile.dvifile instance>, pageid=[80, 121, 88, 1, 0, 0, 0, 
0, 0, 0])
    1244                                 afile.readint32(),
    1245                                 afile.readint32(),
-> 1246 
afile.read(afile.readuchar()+afile.readuchar()))
         afile = <pyx.dvifile.binfile instance>, global read = undefined, 
global readuchar = undefined
    1247             else:
    1248                 raise DVIError

/home/fperez/usr/local/lib/python/pyx/dvifile.py in 
definefont(self=<pyx.dvifile.dvifile instance>, cmdnr=1, num=6, c=195060286, 
q=655360, d=655360, fontname='cmmi10')
     877             font = virtualfont(fontname, c, q/self.tfmconv, 
d/self.tfmconv, self.fontmap, self.debug > 1)
     878         except (TypeError, RuntimeError):
--> 879             font = type1font(fontname, c, q/self.tfmconv, 
d/self.tfmconv, self.fontmap, self.debug > 1)
         font = undefined, global type1font = <class pyx.dvifile.type1font>, 
fontname = 'cmmi10', c = 195060286, q = 655360, self = <pyx.dvifile.dvifile 
instance>, global tfmconv = undefined, d = 655360, global fontmap = undefined, 
global debug = undefined
     880
     881         self.fonts[num] = font

/home/fperez/usr/local/lib/python/pyx/dvifile.py in __init__(self=font cmmi10 
designed at 10 tex pts used at 10 tex pts, name='cmmi10', c=195060286, 
q=10485760.0, d=10485760.0, fontmap={'bchb8r': <pyx.dvifile.fontmapping 
instance>, 'bchbi8r': <pyx.dvifile.fontmapping instance>, 'bchbo8r': 
<pyx.dvifile.fontmapping instance>, 'bchr8r': <pyx.dvifile.fontmapping 
instance>, 'bchri8r': <pyx.dvifile.fontmapping instance>, 'bchro8r': 
<pyx.dvifile.fontmapping instance>, 'cob': <pyx.dvifile.fontmapping instance>, 
'cobo': <pyx.dvifile.fontmapping instance>, 'com': <pyx.dvifile.fontmapping 
instance>, 'contnav': <pyx.dvifile.fontmapping instance>, ...}, debug=0)
     634         self.fontmapping = fontmap.get(name)
     635         if self.fontmapping is None:
--> 636             raise RuntimeError("no information for font '%s' found in 
font mapping file, aborting" % name)
         global RuntimeError = undefined, name = 'cmmi10'
     637
     638     def getbasepsname(self):

RuntimeError: no information for font 'cmmi10' found in font mapping file, 
aborting
WARNING: Failure executing file: <tfun.py>

Re: [PyX-devel] minor bug with greek symbol theta

[Faheem M. <fa...@em...>]

On Mon, 3 May 2004, Andre Wobst wrote:

> Hi,
>
> On 03.05.04, Faheem Mitha wrote:
> > > > c.text(0, 0, "$\theta$")
> >
> > The $\theta$ behaviour does seem to me to violate the principle of least
> > surprise. Since the expression is in standard LaTeX syntax, would it not
> > be better to generate the theta symbol as would be expected, and use other
> > syntax to generate a tab (if desired)?
>
> First I have to tell you, that PyX does *not* invent a new language.
> To my mind this is a major feature compared to other (programmable)
> graphic solutions (even sometimes those languages might be very nice
> for certain tasks -- like in metapost). Thus our string handling is
> not at all TeX centered but its the standard behaviour of the Python
> language. While we could try to be sophisticated and parse the strings
> for control characters, this would render the string handling very
> obscure and is not at all an option!

Yes, I agree it is best to not invent a new language and just use Python
as is. Much more stable and robust.

> In Python there are raw strings, which are very usefull to write TeX
> expressions. Make use of them, that's perfect. Beyond that I don't
> think this issue is subject to any discussion.

I see. Thanks for the information. I'll use raw strings instead.

I need to learn more before I can make informed comments/suggestions. I
apologise for this uninformed one, and for any offense it may have caused.
Take care.

                                                                Faheem.

Re: [PyX-devel] minor bug with greek symbol theta

[Andre W. <wo...@us...>]

Hi,

On 03.05.04, Faheem Mitha wrote:
> > > c.text(0, 0, "$\theta$")
> 
> The $\theta$ behaviour does seem to me to violate the principle of least
> surprise. Since the expression is in standard LaTeX syntax, would it not
> be better to generate the theta symbol as would be expected, and use other
> syntax to generate a tab (if desired)?

First I have to tell you, that PyX does *not* invent a new language.
To my mind this is a major feature compared to other (programmable)
graphic solutions (even sometimes those languages might be very nice
for certain tasks -- like in metapost). Thus our string handling is
not at all TeX centered but its the standard behaviour of the Python
language. While we could try to be sophisticated and parse the strings
for control characters, this would render the string handling very
obscure and is not at all an option!

In Python there are raw strings, which are very usefull to write TeX
expressions. Make use of them, that's perfect. Beyond that I don't
think this issue is subject to any discussion.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] minor bug with greek symbol theta

[Faheem M. <fa...@em...>]

On Sat, 1 May 2004, Magnus Lie Hetland wrote:

> Faheem Mitha <fa...@em...>:
> >
> > Hi,
> >
> > The following generates the word "heta"
> >
> > from pyx import *
> > c = canvas.canvas()
> > c.text(0, 0, "$\theta$")
> > c.writeEPSfile("theta")
> >
> > I'm guessing this a bug. Please cc, I'm not subscribed. Thanks.
>
> Yup -- in your code :). "\t" is a tab. Use r"$\theta$" or "$\\theta$".

I see. Thanks for the information. This was actually forwarded from a
friend who was also trying PyX for the first time. Neither of us have got
past just playing with it, but it looks very nice, and potentially very
useful.

The $\theta$ behaviour does seem to me to violate the principle of least
surprise. Since the expression is in standard LaTeX syntax, would it not
be better to generate the theta symbol as would be expected, and use other
syntax to generate a tab (if desired)?

BTW, on an off-topic note, have you considered adding a chapter on the
Python C API to your book, "Practical Python"?

                                                               Faheem.

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Andre W. <wo...@us...>]

Hi,

On 01.05.04, Faheem Mitha wrote:
> svn-buildpackage got upset becasuse the upstream tarball contains
> manual/manual.pdf, but this gets cleaned by `make clean' and gets built by
> make, so it looks like it should not be there in the upstream tarball. The
> same comments apply to faq/pyfaq.pdf.

I think there is difference between creating a source package (for
debian or similar) and our distribution of PyX. We include a
precompiled version of the manual and faq to make it easier for the
user to become familiar with PyX. You are right, you can create both
documents from the source, which is also included in the distribution.
But in order to build the pdf files you already have to setup your
environment properly (Python, TeX, etc.). However, when building a
source package for a distribution, those pdf files are not *source*
files and should not be part of a source package.

> I've considering removing these from the upstream tarball and rebuilding
> it, but I thought I would ask here first, since the tarball is supposed to
> correspond to pristine sources. Perhaps the *.pdf files were provided for
> people who don't want to build their own docs? It was not there in the
> 0.4.1 version in the official Debian package (I have not checked the
> others). It does make the tarball rather big.

Feel free do create the package the way it suits best to the policy of
the distribution. Nothing else matters as far as I am concerned.

> Also, there appears to be no way to generate examples/examples.pdf from
> source. Is that correct?

Yes. I consider example.pdf to be not at all usefull, once you can run
the examples yourself. We've build and included the pdf for promotion
only. I would suggest to take the source of the examples as parts of
the documentation without taking care of the examples.pdf. However we
may provide the build script in future as well (its available via CVS
already, of course) if there are strong demands for that ...

> Also, I ran into errors when trying to build manual.html. I'd appreciate
> assistance on this, though the error messages were not very useful, so I
> am not sure how much information I can provide.

You need to create a symbolic link of mkhowto from the python
documentation tools (Do not just copy the file, since it uses the
symlink to find further files it requires). In case this doesn't
already solve your problem, feel free to post a little more
information about your problem. But I'm not an expert in pythons
documentation tools ... I just worked it out how to get it running
myself (on fink, Jörg now uses it on debian as well). May be there
somebody on this list, who has a better knowlegde of pythons
documentation utils once we know a little more about your problem.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] minor bug with greek symbol theta

[Magnus L. H. <ma...@he...>]

Faheem Mitha <fa...@em...>:
>
> Hi,
> 
> The following generates the word "heta"
> 
> from pyx import *
> c = canvas.canvas()
> c.text(0, 0, "$\theta$")
> c.writeEPSfile("theta")
> 
> I'm guessing this a bug. Please cc, I'm not subscribed. Thanks.

Yup -- in your code :). "\t" is a tab. Use r"$\theta$" or "$\\theta$".

>                                                        Faheem.

-- 
Magnus Lie Hetland              "Wake up!"  - Rage Against The Machine
http://hetland.org              "Shut up!"  - Linkin Park

[PyX-devel] minor bug with greek symbol theta

[Faheem M. <fa...@em...>]

Hi,

The following generates the word "heta"

from pyx import *
c = canvas.canvas()
c.text(0, 0, "$\theta$")
c.writeEPSfile("theta")

I'm guessing this a bug. Please cc, I'm not subscribed. Thanks.

                                                       Faheem.

[PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Faheem M. <fa...@em...>]

Dear PyX Developers,

I recently discovered PyX. I had recently started using Python, and read
an article on PyX in lwn.net (April 15th edition).
http://lwn.net/Articles/79562/ is the url.

This looks like a very interesting project.

Since the official Debian package is hopelessly out of date, I spent a bit
of time rolling my own. This was relatively easy since I was able to build
on the work of the official Debian package.

I use the version control system, subversion, so I tried using the Debian
helper scripts svn-buildpackage
(http://packages.debian.org/testing/devel/svn-buildpackage).

svn-buildpackage got upset becasuse the upstream tarball contains
manual/manual.pdf, but this gets cleaned by `make clean' and gets built by
make, so it looks like it should not be there in the upstream tarball. The
same comments apply to faq/pyfaq.pdf.

I've considering removing these from the upstream tarball and rebuilding
it, but I thought I would ask here first, since the tarball is supposed to
correspond to pristine sources. Perhaps the *.pdf files were provided for
people who don't want to build their own docs? It was not there in the
0.4.1 version in the official Debian package (I have not checked the
others). It does make the tarball rather big.

Also, there appears to be no way to generate examples/examples.pdf from
source. Is that correct?

Also, I ran into errors when trying to build manual.html. I'd appreciate
assistance on this, though the error messages were not very useful, so I
am not sure how much information I can provide.

                                                              Faheem.

[PyX-devel] [ pyx-Bugs-945621 ] '%%BoundingBox: (atend)' not recognized

[SourceForge.net <no...@so...>]

Bugs item #945621, was opened at 2004-04-30 14:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=945621&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: '%%BoundingBox: (atend)' not recognized

Initial Comment:
I have a postscript file which has the following lines in the header:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: (atend)
%%Title: GMT v3.4.4 Document from /sw/bin/grdview
%%Creator: GMT
%%For: boyle
%%DocumentNeededResources: font Helvetica
%%CreationDate: Fri Apr 30 13:43:34 2004
%%LanguageLevel: 1
%%DocumentData: Clean7Bit
%%EndComments

at the end of the file, there occurs the lines:

%%Trailer
%%BoundingBox: 122 36 618 666
% Reset translations and scale and call showpage
S -2325 0 T 4.16667 4.16667 scale 0 A
showpage
end

The bounding box is at the end because the file is built sequentially 
and the final bounds are not known until the end.
In any case this is legal postscript, but Pyx cannot find the 
bounding information since epsfile.py quits the search after finding 
the %%EndComments.
I extended the search in epsfile.py until the showpage line and this 
seems to work. A better fix would key off the (atend) syntax to 
extend the search. 

Jim boyle
bo...@ll...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=945621&group_id=45430

[PyX-devel] normpath parametrization

[Andre W. <wo...@us...>]

Hi,

at the last PyX developer meeting we had a discussion about the
parametrization of normpaths. First, let me briefly summarize the
current status and the things, we've already decided:

A normpath consists of a list of subnormpaths. Each subnormpath is
either closed or not. A subnormpath consists of a list of
normpathitems (in the current code you can find normpathel, but we
decided to switch from -el to -item). There are only two kind of
normpathitems, namely normline and normcurve. The line or curve of a
normpathitem is parametrized by a parameter with range 0 to 1 (0 is
the starting point of the normpathitem and 1 the end point).

Each subnormpath has an epsilon, which is an accuracy (the length of
the maximal deviation of certain operations). A normpathitem is not
allowed to be shorter than epsilon. Thus you can convert an arc length
of the subnormpath into a parameter and vice versa without numerical
instabilities. The integer part of the parametrization of the
subnormpath selects a normpathitem. The fractional part of the
parametrization is the parameter within this normpathitem.

In our old design, the parametrization of the normpath was build by
summing the parametrizations of the subnormpaths. This leads to an
uncontinuous behaviour when jumping from one subnormpath to the next
(there was another epsilon involved here). We already decided, that we
will use a tuple for this parametrization in the future. The first
number of this tuple will be an integer selecting a subnormpath. The
second number is the parameter for the selected subnormpath.

Now there is a dispute on what to do with a parameter at the
subnormpath when this parameter is out of bound. There are different
possibilities. Let me tell you three of them, we have discussed,
although only two are still in discussion (the other was rejected by
the developers):

1) We could raise an error, when the parameter is outside the valid
   range. But we immediately step into a problem: we would need
   another epsilon, which allows for small exceedings of the parameter
   range (to gain stabilitly). Note, that this is a different epsilon
   than the accuracy of a subnormpath mentioned above, since
   increasing the accuracy (lowering the epsilon of the subnormpath)
   should not automatically tighten the allowed parameter range
   exceedings. Thus the developers have already rejected this
   solution.

2) We could cut the parameter to the allowed parameter range. Using a
   parameter outside of the allowed parameter range to the left or to
   the right would lead to the starting or end point, respectively.
   PRO: You won't step out of the path.
   CONTRA: You parametrize the start and end point of the path,
           although the parameter might be far out of bounds.

3) We could ignore range exceedings completely. A parameter outside of
   the allowed parameter range will usually give you a point not at
   the path.
   PRO: A invalid parameter results in a point outside of the path.
   CONTRA: It does it without any warning.

I'm not telling you, which version is favoured by which developer, but
we all would like to see any kind of comments to this issue. Thanks
for reading ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Announcement: PyX 0.6.3 released

[Andre W. <wo...@us...>]

Hi,

PyX 0.6.3 was released today. It fixes two small bugs in the graph
system. The distribution now contains PDF files instead of PostScript
files for the manual and the examples and includes the sources for the
manual and the faq. See the changelog below.

André


--------

0.6.3 (2004/04/27):
  - graph module:
    - fix drawing with background
    - fix insertion of a zero length path when the whole line is outside
      the valid axis range (reported by Marko Vendelin)
  - distribution:
    - include source for faq and manual
    - distribute the pdf instead of postscript (manual, faq, examples)

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

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

Hi Andre,

Andre Wobst wrote:
> Hi Fernando,
> 
> On 20.04.04, Fernando Perez wrote:
> 
>>Thanks for addressing this.  I noticed you are discussing the finer points 
>>of the solution, and running into the usual (and incredibly annoying) 
>>limitations of distutils.
> 
> 
> I've seen you joining those discussions in the c.l.p and we had this
> issue together before as well (I think it was on this list). So let me
> briefly tell you, what solution I came up yesterday. Its not at all
> perfect, but I think it points into the correct direction to go.

[snip]

> Another thing would be to discuss this issue and the PyX solution we
> have now on sig-distutils or the like. Its obviously a general problem
> within distutils and its missing a standard solution. We might
> postpone that until we have some feedback from our new solution ...

While I see nothing in principle wrong with your solution, and I think it's a 
very reasonable approach for existing (up to python 2.3) installations, I 
would REALLY like to see the distutils developers make something like this 
much easier.  The problem you are facing is a fairly standard one, and there's 
no reason why something like this should require such convoluted solutions.

The distutils setup() function should simply have a standard way of leaving 
this information in the package installation directory.  IMHO, setup() should 
always create a __setup__.py file in the package's top directory, containing a 
dictionary with all the values for the various paths which were _actually_ 
created, depending on what the user put in.  This file should also have the 
possibility of being used by an automatic uninstall routine, by being a proper 
python script itself:

#### hypothetical __setup__.py (not indented, typed in my mail client):

setup_data = {'data_dir':'/home/foo/local/share',
	      'package_dir':'home/foo/local'}

if __name__ == '__main__':
   import distutils
   import sys
   if sys.argv[1] == 'uninstall':
     distutils.uninstall(setup_data)

#######################################################

If something as simple as this were done by distutils, we'd have:

1.  A trivial way for any package to know where all of its stuff ended up 
splattered on the filesystem, so it can go later and find any of its own files.

2.  An automatic, platform independent way to do uninstalls:

$  python __setup__.py uninstall

Any thoughts?  Feel free to pass this message on to c.l.p or the distutils 
folks, if you like the idea.  I'll have very limited computer access for a 
week or two starting tomorrow, so I won't be able to follow this further. 
However, I would very much like to see improvements on this fronts, distutils 
is IMHO one of python's few outright disastrous areas.

Cheers,

f

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Andre W. <wo...@us...>]

Hi Fernando,

On 20.04.04, Fernando Perez wrote:
> Thanks for addressing this.  I noticed you are discussing the finer points 
> of the solution, and running into the usual (and incredibly annoying) 
> limitations of distutils.

I've seen you joining those discussions in the c.l.p and we had this
issue together before as well (I think it was on this list). So let me
briefly tell you, what solution I came up yesterday. Its not at all
perfect, but I think it points into the correct direction to go.

So first of all I decided we would need a siteconfig.py file, where I
just store the path configuration. This is part of the pyx module, so
it lives in the source tree. There is already a siteconfig.py in CVS
and it will also be in the source distribution. It calculates path
information relative to its current position, so you can start using
PyX right from the CVS or from an unpacked source distribution.

When installing PyX via distutils however, the siteconfig.py is not
copied from the source tree, but a new one is created containing the
actual install positions. I did this step within build_py, because
this way I can just replace the copy operation by something else for
this single file (this is slightly different from the solution I had
first). The only disadvantage is, that you have to create a dependency
of this build step from install_data to get the positions you need to
write into siteconfig.py! (Obviously a better solution would be to
create a install_siteconfig or the like, but it is more complicated to
inject into distutils.)

As far as I can see this solution works well and it obviously helps to
fix the problem you had. It would be good to test this new install
behaviour with a release candidate before the next release, so may be
there are some volunteers around here, who would like to do so. I
would appreciate testing on Windows at most, since I can do Linux
(Debian) and Mac OS (fink) myself. But I do not like to build a test
trunk for the new setup.py currently, because parts of PyX are broken
the CVS due to development right now.

Another thing would be to discuss this issue and the PyX solution we
have now on sig-distutils or the like. Its obviously a general problem
within distutils and its missing a standard solution. We might
postpone that until we have some feedback from our new solution ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

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

Andre Wobst wrote:

> Absolutely right. It was a bad design from the very beginning. We
> included ~/usr/local/lib/python/pyx/lfs only, because we needed it for
> CVS and local running (without using distutils and setup.py). When
> installing PyX via setup.py we really need to store the path to the
> share directory to have it available later on and do not include the
> ~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py
> accordingly and introduced a siteconfig.py (which is temporarily
> overwritten during install). IFAIK this is the solution to go. (Any
> distutils expert around?) We could step further and could define the
> "/etc/pyxrc" position along the same lines. The later is an open issue
> as well.

Thanks for addressing this.  I noticed you are discussing the finer points of 
the solution, and running into the usual (and incredibly annoying) limitations 
of distutils.  Good luck with that, it's driven me crazy in the past many 
times.  distutils is great if you only want to do the trivial setup.py of 
their examples, but it sucks for more complicated things.  In particular, 
getting information out of it (where it puts things, so your program can later 
know where to look for them) has always been frustrating to me (and it's 
undocumented as far as I know; reading the source code seems the only way of 
finding out).

Best, and again many thanks for PyX.  You have written a tool I'd been 
dreaming of for several years, but which I'd never had the time or the energy 
to write myself :)

f

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Andre W. <wo...@us...>]

Hi,

On 20.04.04, Joerg Lehmann wrote:
> Ok, but then we should include a comment in the siteconfig.py file
> indicating that this file is ignored when PyX is being installed.

Fine, I'll do that.

> > What do you think about adding a flag to setup.cfg, where we enable
> > the global pyxrc (this includes copying the pyxrc to the appropriate
> > position) and denote the path of the global configuration in
> > siteconfig.py (otherwise we could set this variable in siteconfig.py
> > to None). I don't know whether its a good idea to make a global pyxrc
> > an install option (I've never seen such a behaviour before). 
> 
> IMHO there is no reason for making this configurable. We should always
> install a global pyxrc file in the appropriate directory. The only open
> question is how to obtain this directory from distutils...

Ok, so lets modify setup.py to always install the global pyxrc. You
can get "/etc" from distutils somehow (and you can set it to a
different location like with "--home=..." or even within the
setup.cfg). I'll take a look at it and do an implementation together
with an enhancement of siteconfig.py.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Joerg L. <jo...@us...>]

Hi,

On 20.04.04, Andre Wobst wrote:
> First I thought (as well), that we would need that for our CVS
> developer version only. But you may download the distribution and use
> PyX without any install (you may add the PyX base directory to the
> PYTHONPATH or just run python in the base directory). Then you want
> our developer behaviour as well (otherwise we could just skip the
> distribution of siteconfig.py). I think it's fine -- its just an
> additional feature, that we can run PyX without any setup. Of course,
> we could do that path adjustment outside of siteconfig.py as well
> instead of replacing siteconfig.py. It would blow up the code, where
> we access the siteconfig, and thats actually worse to my eyes.

Ok, but then we should include a comment in the siteconfig.py file
indicating that this file is ignored when PyX is being installed.

> Another issue is, that the lfs lives in a different directory than
> other shared material (pyx.def, textboxes.tex in the future -- which
> are distributed in contrib). Currently I've just left everything as it
> is. I'm not sure whether its worth any thoughts at all. In principal,
> the shared data material is different from other things we might
> distribute in contrib in the future (like a dvips.py).

Sure, we have to think about the locations for these files at some
point.

> What do you think about adding a flag to setup.cfg, where we enable
> the global pyxrc (this includes copying the pyxrc to the appropriate
> position) and denote the path of the global configuration in
> siteconfig.py (otherwise we could set this variable in siteconfig.py
> to None). I don't know whether its a good idea to make a global pyxrc
> an install option (I've never seen such a behaviour before). 

IMHO there is no reason for making this configurable. We should always
install a global pyxrc file in the appropriate directory. The only open
question is how to obtain this directory from distutils...

        Joerg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Andre W. <wo...@us...>]

Hi,

On 20.04.04, Joerg Lehmann wrote:
> On 20.04.04, Andre Wobst wrote:
> > I've patched setup.py
> > accordingly and introduced a siteconfig.py (which is temporarily
> > overwritten during install). 
> 
> Nice, although it's not clear why we do not only create the
> siteconfig.py file temporarily. In other words: why is there a
> siteconfig.py in the distribution, if it's just ignored by the
> installer.

First I thought (as well), that we would need that for our CVS
developer version only. But you may download the distribution and use
PyX without any install (you may add the PyX base directory to the
PYTHONPATH or just run python in the base directory). Then you want
our developer behaviour as well (otherwise we could just skip the
distribution of siteconfig.py). I think it's fine -- its just an
additional feature, that we can run PyX without any setup. Of course,
we could do that path adjustment outside of siteconfig.py as well
instead of replacing siteconfig.py. It would blow up the code, where
we access the siteconfig, and thats actually worse to my eyes.

Another issue is, that the lfs lives in a different directory than
other shared material (pyx.def, textboxes.tex in the future -- which
are distributed in contrib). Currently I've just left everything as it
is. I'm not sure whether its worth any thoughts at all. In principal,
the shared data material is different from other things we might
distribute in contrib in the future (like a dvips.py).

> +1 on including the pyxrc path in the siteconfig.py file

What do you think about adding a flag to setup.cfg, where we enable
the global pyxrc (this includes copying the pyxrc to the appropriate
position) and denote the path of the global configuration in
siteconfig.py (otherwise we could set this variable in siteconfig.py
to None). I don't know whether its a good idea to make a global pyxrc
an install option (I've never seen such a behaviour before). On the
other hand we do not (yet) install the global pyxrc at all. This
contradicts setting up the path of the global pyxrc during the
install. Or should we switch to always install the global pyxrc?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Joerg L. <jo...@us...>]

Hi,

On 20.04.04, Andre Wobst wrote:
> Absolutely right. It was a bad design from the very beginning. We
> included ~/usr/local/lib/python/pyx/lfs only, because we needed it for
> CVS and local running (without using distutils and setup.py). When
> installing PyX via setup.py we really need to store the path to the
> share directory to have it available later on and do not include the
> ~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py
> accordingly and introduced a siteconfig.py (which is temporarily
> overwritten during install). 

Nice, although it's not clear why we do not only create the
siteconfig.py file temporarily. In other words: why is there a
siteconfig.py in the distribution, if it's just ignored by the
installer.

> IFAIK this is the solution to go. (Any distutils expert around?) We
> could step further and could define the "/etc/pyxrc" position along
> the same lines. The later is an open issue as well.

+1 on including the pyxrc path in the siteconfig.py file

        Joerg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

Re: [PyX-devel] Problems with lfs files when installed to non-standard location

[Andre W. <wo...@us...>]

Hi,

On 19.04.04, Fernando Perez wrote:
> I've been able to solve the problem by hand, by copying the contents of 
> ~/usr/local/share/pyx to ~/usr/local/lib/python/pyx/lfs.   But this seems 
> like an ugly solution to me.  I don't know off-hand how to fix it, but 
> somehow you guys will need to make the routine which searches for these 
> files know where to look, even when the user installed to a different 
> prefix.

Absolutely right. It was a bad design from the very beginning. We
included ~/usr/local/lib/python/pyx/lfs only, because we needed it for
CVS and local running (without using distutils and setup.py). When
installing PyX via setup.py we really need to store the path to the
share directory to have it available later on and do not include the
~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py
accordingly and introduced a siteconfig.py (which is temporarily
overwritten during install). IFAIK this is the solution to go. (Any
distutils expert around?) We could step further and could define the
"/etc/pyxrc" position along the same lines. The later is an open issue
as well.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Problems with lfs files when installed to non-standard location

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

Hi all,

I just installed PyX 0.6.2 on a clean system, but to a non-standard directory, 
using:

python setup.py install --home=~/usr/local

The installation went fine, and the lfs files (listed as data_files in 
setup.py) were correctly put in ~/usr/local/share/pyx.  However, in usage, PyX 
won't find any of them, and I get error messages like:

===========================================================================

In [4]: rho.coef_tree.draw_skeleton('foo')
---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)

?

/home/fperez/research/code/mwadap/Function.py in __draw_skeleton_2d(self, 
fname, label, palette, fill)
     489                    r"$N_{nod}=%s, \epsilon=%1.1e, N_{blocks}=%s$" %
     490                    (self.nnod,self.cutoff,self.nkeys()),
--> 491                    [pyx.text.halign.center])
     492
     493         # Generate eps file

/home/fperez/usr/local/lib/python/pyx/canvas.py in text(self, x, y, atext, 
*args, **kwargs)
     254         returns the inserted textbox"""
     255
--> 256         return self.insert(self.texrunner.text(x, y, atext, *args, 
**kwargs))
     257
     258

/home/fperez/usr/local/lib/python/pyx/text.py in text(self, x, y, expr, 
textattrs, texmessages)
    1113         for i in range(lentextattrs):
    1114             expr = textattrs[lentextattrs-1-i].apply(expr)
-> 1115         self.execute(expr, self.defaulttexmessagesdefaultrun + 
self.texmessagesdefaultrun + texmessages)
    1116         if self.texipc:
    1117             if first:

/home/fperez/usr/local/lib/python/pyx/text.py in execute(self, expr, texmessages)
     861                         raise IOError("file '%s' is not available or 
not readable. Available LaTeX font size files (*.lfs): %s" % (lfsname, lfsnames))
     862                     else:
--> 863                         raise IOError("file '%s' is not available or 
not readable. No LaTeX font size files (*.lfs) available. Check your 
installation." % lfsname)
     864                 self.execute(lfsdef, [])
     865                 self.execute("\\normalsize%\n", [])

IOError: file '10pt.lfs' is not available or not readable. No LaTeX font size 
files (*.lfs) available. Check your installation.

===========================================================================


I've been able to solve the problem by hand, by copying the contents of 
~/usr/local/share/pyx to ~/usr/local/lib/python/pyx/lfs.   But this seems like 
an ugly solution to me.  I don't know off-hand how to fix it, but somehow you 
guys will need to make the routine which searches for these files know where 
to look, even when the user installed to a different prefix.

Regards,

Fernando.

ps.  I'm loving pyx as it matures, keep up the good work!

[PyX-devel] Announcement: PyX 0.6.2 released

[Andre W. <wo...@us...>]

Hi,

yesterday evening PyX 0.6.2 was released, which fixes some bugs
introduced during the code reorganization of the graph module.


André


------------

0.6.2 (2004/04/07):
  - graph module:
    - fixed title=None + graph key issue reported by Gabriel Vasseur
    - graph.axis.painter.plain -> graph.axis.painter.regular
      (as it was in parts of the documentation already)
    - changeable-gridattrs-become-None-bug fixed
    - graph style cutting outside lines (double-)fixed


-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Announcement: PyX 0.6.1 released

[Andre W. <wo...@us...>]

Hi,

I've uploaded PyX 0.6.1, which fixes an install bug regarding the
graph subdirectory.

André


---------

0.6.1 (2004/03/31):
  - fixes missing install of the graph and axis directories introduced in 0.6
  - some minor updates to the faq


-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Re: [Pyx-user] Announcement: PyX 0.6 released

[Andre W. <wo...@us...>]

Hi,

On 31.03.04, Brett Calcott wrote:
> This is very very cool. Everything works out of the box. Almost...
> 
> Slight install prob: graph module doesn't get installed. I manually copied
> it. I guess this would fix it.
> 
> 87c87
> <       packages=['pyx', 'pyx/t1strip', 'pyx/pykpathsea'],
> ---
> >       packages=['pyx', 'pyx/t1strip', 'pyx/pykpathsea', 'pyx/graph'],

It seems to become a bad tradition, that we always need to do a 0.x.1
release. I am really sorry. It looks like we need to prepare release
candidates. While separating the graph module and never installing PyX
system-wide (I'm always sticking to "python setup.py build_ext -if"),
I have never recoginzed that problem. We may have to add not only
pyx/graph, but pyx/graph/axis as well. I'll try it and prepare a new
release today.

Sorry for any inconveniences.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/