matplotlib-devel Mailing List for matplotlib (Page 2)

I just installed matplotlib-0.63.4 on Mac OSX 10.3, with some 
difficulties i detail (and answer) below.
Using Fink (0.7.1), freetype2 (2.1.3-21), Tk and GTK.
python setup.py install fails because of wrong paths to find freetype2 
ft2build.h. Darwin include paths (in setupext.py) are '/usr/local', 
'/usr', 'sw'. freetype2 include paths are :
 > locate ft2build.h
 > /sw/lib/freetype2/include/ft2build.h
 > /usr/X11R6/include/freetype2/ft2build.h
Once '/usr/X11R6' or '/sw/lib/freetype2' to setupext.py paths for 
Darwin, build process works fine. Agg, GTKAgg, and TkAgg backends are 
available as described in your documentation.
I use matplotlib with ipython (python2.3.3, IPython0.6.3), and GTKAgg 
backend crashes if pygtk (2.0.0 here) is not build with threading. I 
used
 > python setup.py build --enable-threading
Thanks for this great matplotlib product.
-------------
Loic Chevallier
ATER section 34
Observatoire de Paris - section de Meudon
Laboratoire LUTH
Groupe Noyaux actifs de galaxies et milieu insterstellaire
http://www-obs.univ-lyon1.fr/transfer/
email:loi...@ob...
tel: 01.45.07.74.29 (bureau 249)

Hi there,
another tiny patch: adding **kwargs to the errorbar function and passing them 
through to the internal plot function. This allows arguments like "color" 
used on errorbar.
Ciao,
Nobbi
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

John,
I'm trying to understand the methods
backend_gtk.ColorManagerGTK.get_color()
backend_gtk.ColorManagerGTK.get_rgb()
They convert color representations from rgb (three floats in the range
0.0 - 1.0) to gdk.Color (three integers in the range 0 - 65535)
get_rgb() divides by 65535 but get_color() multiplies by 65025. So if
I run
>>> import gtk
>>> import backend_gtk
>>> cm=backend_gtk.ColorManagerGTK()
>>> cm.set_drawing_area(gtk.DrawingArea())
>>> gdk_color=gtk.gdk.Color(1000,1000,1000)
>>> rgb_color=cm.get_rgb(gdk_color)
>>> gdk_color=cm.get_color(rgb_color)
>>> print gdk_color.red, gdk_color.green, gdk_color.blue
992 992 992
The color (1000,1000,1000) has become (992,992,992).
It looks to me like get_color() should multiply by 65535, or is there 
a special reason for using 65025?
Regards,
Steve

Here it is.
Did it slightly different by calling the option "bars_on_top=False", which is 
more descriptive.
Be aware, that this changes the default behaviour, but the difference is so 
subtle that only few people should notice at all. Still, I think this is the 
more reasonable default behaviour, since - usually - the plot line is more 
important than the errorbars and should be clearly visible.
On Friday 22 October 2004 15:24, John Hunter wrote:
> How about adding a kwarg to the signature of the errorbar function,
> which defaults to below=True (this would have the default behavior you
> want, errorbars below markers, but could be customized).
>
> Then you could add an if clause in the errorbar code which reverses
> the order of the calls.
>
> Since noone has done the zordering yet, and this issue has come up
> twice in the context of errorbars, it is probably worthwhile to add it
> now to the errorbar code.
>
> If I could impose in you one more time Norbert to submit a patch that
> allows the user to configure the order using a kwarg, I'll be happy to
> check it in.
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> Thanks for the reply. Surprises me that people would
 Norbert> really argue about this issue, but well. :-)
There's just no accounting for the taste of some people... Here are
some links to the original discussion
 http://sourceforge.net/mailarchive/forum.php?thread_id=5434727&forum_id=33405
 http://sourceforge.net/mailarchive/forum.php?thread_id=5440722&forum_id=33405
 Norbert> Attached is a slighly changed patch: effectively, it does
 Norbert> not change the layering any more, but it changes the
 Norbert> internals of errorbar() in a way, that allows to swap the
 Norbert> layering by simply swapping two blocks of code. (Which
 Norbert> was nontrivial before, since the color from the plot line
 Norbert> can only be read after it has been drawn.)
 Norbert> Whether this swapping is then done by hand, by an option
 Norbert> or an entry in the rc file can be left to the future.
 Norbert> Maybe, submitting this patch will save someone else the
 Norbert> time to figure it out himself.
How about adding a kwarg to the signature of the errorbar function,
which defaults to below=True (this would have the default behavior you
want, errorbars below markers, but could be customized).
Then you could add an if clause in the errorbar code which reverses
the order of the calls.
Since noone has done the zordering yet, and this issue has come up
twice in the context of errorbars, it is probably worthwhile to add it
now to the errorbar code.
If I could impose in you one more time Norbert to submit a patch that
allows the user to configure the order using a kwarg, I'll be happy to
check it in.
BTW, Gary, any chance I could persuade you to write a tutorial/guide
to using errorbar / bar / barh for the users guide? barh is in CVS.
If you are averse to latex, you could submit in plain text and I can
convert it. I'm mostly done with the matlab interface section and
have been working on other sections (API) and I am having trouble
motivating myself to finish some of these matlab interface sections.
Since you are the world's expert on matplotlib bar charts, I thought
you would be a good victim, er candidate, to write that section. FYI,
I looked into changing the default meaning of x in the errorbar code
to have it refer to the center, rather than the left, as we discussed.
The problem is, this broke some of the table examples, which are a bit
hairy and written by John Gill, so I put it on the back burner. For
barh, however, I did make the y axis mean the center, since we are all
in agreement that this is the more intuitive behavior.
JDH

Thanks for the reply. Surprises me that people would really argue about this 
issue, but well. :-)
Attached is a slighly changed patch: effectively, it does not change the 
layering any more, but it changes the internals of errorbar() in a way, that 
allows to swap the layering by simply swapping two blocks of code. (Which was 
nontrivial before, since the color from the plot line can only be read after 
it has been drawn.)
Whether this swapping is then done by hand, by an option or an entry in the rc 
file can be left to the future.
Maybe, submitting this patch will save someone else the time to figure it out 
himself.
Ciao,
Nobbi
On Friday 22 October 2004 12:27, gary ruben wrote:
> Hi Norbert,
> I think this is the best place to post patches like this.
> There was some discussion a while back about the layer ordering of
> errorbars and other objects in the plot window. It was decided to leave it
> unchanged for the moment since about half of users want it one way and half
> the other. Some ideas were raised like being able to specify layers as
> command parameters or change the default in the resource file. I think that
> until this is pursued, it is unlikely that anything will be done.
> Gary
>
> *********** REPLY SEPARATOR ***********
>
> On 22/10/2004 at 11:29 Norbert Nemec wrote:
> > Hi there,
> >
> > here is a small patch layering errorbars behind the line of the plot
> > itself.
> >
> > Rationale:
> > If you use ecolor and have a plot with many dense points, the errorbars
> > may be
> > covering the line itself completely. The relayering makes the line fully
> > visible and puts the errorbars as "additional information" in the
> > background.
> >
> > Greetings,
> > Norbert
> >
> > PS: If sending small patches to this mailing list is a suboptimal way of
> > submission, please tell me how to do it better.
> >
> > --
> > _________________________________________Norbert Nemec
> > Bernhardstr. 2 ... D-93053 Regensburg
> > Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
> > eMail: <No...@Ne...>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> > more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------
> Gary Ruben gr...@bi...
> <http://users.bigpond.net.au/gazzar>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi Norbert,
I think this is the best place to post patches like this.
There was some discussion a while back about the layer ordering of
errorbars and other objects in the plot window. It was decided to leave it
unchanged for the moment since about half of users want it one way and half
the other. Some ideas were raised like being able to specify layers as
command parameters or change the default in the resource file. I think that
until this is pursued, it is unlikely that anything will be done.
Gary
*********** REPLY SEPARATOR ***********
On 22/10/2004 at 11:29 Norbert Nemec wrote:
> Hi there,
> 
> here is a small patch layering errorbars behind the line of the plot
> itself. 
> 
> Rationale:
> If you use ecolor and have a plot with many dense points, the errorbars
> may be 
> covering the line itself completely. The relayering makes the line fully 
> visible and puts the errorbars as "additional information" in the
> background.
> 
> Greetings,
> Norbert
> 
> PS: If sending small patches to this mailing list is a suboptimal way of 
> submission, please tell me how to do it better.
> 
> -- 
> _________________________________________Norbert Nemec
> Bernhardstr. 2 ... D-93053 Regensburg
> Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
> eMail: <No...@Ne...>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

Hi there,
on one of my machines, matplotlib.matlab segfaults on import. On another 
machine, it works fine. I already traced the segfault to the library 
_na_transforms.so, but now I don't know how to continue from here. Can anyone 
give me a hint how to debug a python module written in C/C++?
I have plenty of experience in C/C++, but I'm just starting on python.
Thanks for help!
Ciao,
Norbert
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi there,
here is a small patch layering errorbars behind the line of the plot itself. 
Rationale:
If you use ecolor and have a plot with many dense points, the errorbars may be 
covering the line itself completely. The relayering makes the line fully 
visible and puts the errorbars as "additional information" in the background.
Greetings,
Norbert
PS: If sending small patches to this mailing list is a suboptimal way of 
submission, please tell me how to do it better.
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 
 Paul> It would be nice if they would update their documents, since
 Paul> the %%BeginFont and %%EndFont keywords are from their
 Paul> document about embedding fonts.
 Hey, give 'em a minute will you? They just released the 3.0 spec in
 '92. It's going to take them a while to get the rest of their site
 docs updated... :-)
JDH

Jochen Voss wrote:
>Hello John,
>
>On Tue, Oct 19, 2004 at 10:00:48AM -0500, John Hunter wrote:
> 
>
>>>>>>>"Jochen" == Jochen Voss <vo...@se...> writes:
>>>>>>> 
>>>>>>>
>> Jochen> None, I looked at the generated PS file out of curiosity
>> Jochen> and noticed that it does not follow the DSC conventions
>> Jochen> very well. As this is just shuffling around comments it
>> Jochen> will probably not affect many applications.
>>
>>Are there other noncompliant things in the matplotlib ps output that
>>you are aware of, other than those you already fixed?
>> 
>>
>I think the horrible ones are fixed by now.
>
>Minor issues:
>
>The DSC spec states (at page 18): "If there is a section in
>the document that corresponds to a particular comment, that comment
>*must* be used to identify that section of the document."
>
>From reading this I would guess that all the "/something { ... } bind
>def" statements and the included fonts should be inside a
>
> %%BeginPrologue
> %%EndPrologue
>
>block. But I didn't check this properly.
>
>Then page 19 "strongly suggests" to use some headers like
>"%%CreationDate" and "%%Title".
>
>Page 70 of the SDC specification states that "%%BeginFont" and
>"%%EndFont" are outdated and should be replaced by "%%BeginResource"
>and "%%EndResource" statements.
> 
>
It would be nice if they would update their documents, since the 
%%BeginFont and %%EndFont keywords are from their document about 
embedding fonts.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Hello,
the file examples/matplotlib_icon.py lacks the magic python
line at the beginning. This can be corrected with the following
patch:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -u -r1.5 matplotlib_icon.py
--- matplotlib_icon.py 10 Aug 2004 15:04:27 -0000 1.5
+++ matplotlib_icon.py 19 Oct 2004 17:48:33 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 """
 make the matplotlib svg minimization icon
 """
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello John,
On Tue, Oct 19, 2004 at 10:00:48AM -0500, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
>=20
> Jochen> None, I looked at the generated PS file out of curiosity
> Jochen> and noticed that it does not follow the DSC conventions
> Jochen> very well. As this is just shuffling around comments it
> Jochen> will probably not affect many applications.
>=20
> Are there other noncompliant things in the matplotlib ps output that
> you are aware of, other than those you already fixed?
I think the horrible ones are fixed by now.
Minor issues:
The DSC spec states (at page 18): "If there is a section in
the document that corresponds to a particular comment, that comment
*must* be used to identify that section of the document."
=46rom reading this I would guess that all the "/something { ... } bind
def" statements and the included fonts should be inside a
 %%BeginPrologue
 %%EndPrologue
block. But I didn't check this properly.
Then page 19 "strongly suggests" to use some headers like
"%%CreationDate" and "%%Title".
Page 70 of the SDC specification states that "%%BeginFont" and
"%%EndFont" are outdated and should be replaced by "%%BeginResource"
and "%%EndResource" statements.
All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> None, I looked at the generated PS file out of curiosity
 Jochen> and noticed that it does not follow the DSC conventions
 Jochen> very well. As this is just shuffling around comments it
 Jochen> will probably not affect many applications.
Are there other noncompliant things in the matplotlib ps output that
you are aware of, other than those you already fixed?
JDH

Hello John,
On Tue, Oct 19, 2004 at 09:37:37AM -0500, John Hunter wrote:
> For my information, what ps viewers/printers were giving you trouble.
None, I looked at the generated PS file out of curiosity and
noticed that it does not follow the DSC conventions very well.
As this is just shuffling around comments it will probably
not affect many applications.
> Finally, by changing the version information to
>=20
> pstype =3D 'PS-Adobe-3.0 EPSF-3.0'
>=20
> will we break devices that only support PS level II?
I do not think so. It is only a change to comments and not to the
actual PostScript code. It will only affect applications which try to
parse the DSC comments and do not understand DSC version 3.
I changed this because the document at
 http://partners.adobe.com/asn/developer/pdfs/tn/5001.DSC_Spec.pdf
which defines DSC version 3 is dated "25 September 1992", which seems
quite old to me. If you feel more comfortable using DSC version 2 we
could either try to reverse engineer the version 2 specification using
the "Changes Since Earlier Versions" chapter in above document or try
to find a DSC 2 specification somewhere.
All the best,
Jochen
--=20
http://seehuhn.de/

I submitted the site request we discussed a couple of days ago to move
the users_guide and htdocs into the matplotlib CVS root. This makes
'cvs co matplotlib' much faster. I suggest you get fresh checkouts.
The three modules are
 cvs co matplotlib
 cvs co htdocs
 cvs co users_guide
I had asked them to rename htdocs and users_guide to mpl_htdocs and
mpl_users_guide but they overlooked this and I can live with it.
On a mildly related note, I just noticed that when I submitted the
site-request to have the matplotlib python tree moved into a lib
directory, all version history was lost. Damned cvs.
JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Hello,
 Jochen> On Mon, Oct 18, 2004 at 10:19:33PM +0100, Jochen Voss wrote:
 >> -%%BeginProlog +%%%%BeginProlog /inch {72 mul} def
 >> %%%%EndProlog """
 Jochen> does anybody know: is the "inch" thing actually used
 Jochen> anywhere? Maybe it should just be removed.
No it is apparently not used anywhere. It was a def that appeared in
my postscript book and several examples I looked at, so I threw it in
for good measure. I just applied you PS patch, removed this, and
checked the changes into CVS.
For my information, what ps viewers/printers were giving you trouble.
We've occasionally had reports of some viewers having trouble with
matplotlib output and I would like to gather some anecdotal
information.
Finally, by changing the version information to
 pstype = 'PS-Adobe-3.0 EPSF-3.0'
will we break devices that only support PS level II?
JDH

Hello,
On Mon, Oct 18, 2004 at 10:19:33PM +0100, Jochen Voss wrote:
> -%%BeginProlog
> +%%%%BeginProlog
> /inch {72 mul} def
> %%%%EndProlog
> """
does anybody know: is the "inch" thing actually used anywhere?
Maybe it should just be removed.
All the best,
Jochen
--=20
http://seehuhn.de/

Hello,
I had a look at the backend_ps.py file and found that the generated
PostScript has some problems. The appended patch tries to bring the
generated output a little bit closer to the behaviour described in the
"PostScript Language Document Structuring Conventions Specification"
as found at
 http://partners.adobe.com/asn/developer/pdfs/tn/5001.DSC_Spec.pdf
I hope this helps,
Jochen
-- 
http://seehuhn.de/

Arrg!
OK, reading the docstring for axes, I find out that the 3rd and 4th 
argument are width and height, (not right and top). This all works 
fine. I was confused...
Cheers!
Andrew
Andrew Straw wrote:
> Hi All,
>
> I get what I consider to be a bug. (I think) the following code 
> should produce a 10 row, 6 column figure with identical plots. 
> However, this code (with current CVS matplotlib), displays a 10 row, 6 
> column figure with plots of apparently varying x and y limits...
>
> Even adding "set(gca(),'xlim',(1,3)); set(gca(),'ylim',(4,6))" does 
> not help.
>
> Am I confused, or is this a bug?
>
> Cheers!
> Andrew
>
> #!/usr/bin/env python
>
> from matplotlib.matlab import *
>
> n_rows = 10
> n_cols = 6
>
> row_height = 1.0/n_rows
> col_width = 1.0/n_cols
>
> figure()
> for row in range(n_rows):
> for col in range(n_cols):
> axes([ col*col_width, row*row_height,
> (col+1)*col_width, (row+1)*row_height ])
> plot([1,2,3],[4,5,6])
> show()
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi All,
I get what I consider to be a bug. (I think) the following code should 
produce a 10 row, 6 column figure with identical plots. However, this 
code (with current CVS matplotlib), displays a 10 row, 6 column figure 
with plots of apparently varying x and y limits...
Even adding "set(gca(),'xlim',(1,3)); set(gca(),'ylim',(4,6))" does not 
help.
Am I confused, or is this a bug?
Cheers!
Andrew
#!/usr/bin/env python
from matplotlib.matlab import *
n_rows = 10
n_cols = 6
row_height = 1.0/n_rows
col_width = 1.0/n_cols
figure()
for row in range(n_rows):
 for col in range(n_cols):
 axes([ col*col_width, row*row_height,
 (col+1)*col_width, (row+1)*row_height ])
 plot([1,2,3],[4,5,6])
show()

Hello John,
On Sat, Oct 16, 2004 at 09:09:22AM -0500, John Hunter wrote:
> these, and your previous bugs, have been fixed in
> CVS and the site problems should be fixed on the sf site as well.
Thanks! One more thing: two of the example lack the usual
python file header. This can be fixed with the following patch:
Index: matplotlib_icon.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matplotlib/matplotlib/examples/matplotlib_icon.py,v
retrieving revision 1.5
diff -u -r1.5 matplotlib_icon.py
--- matplotlib_icon.py 10 Aug 2004 15:04:27 -0000 1.5
+++ matplotlib_icon.py 16 Oct 2004 21:39:15 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 """
 make the matplotlib svg minimization icon
 """
Index: print_stdout.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matplotlib/matplotlib/examples/print_stdout.py,v
retrieving revision 1.1
diff -u -r1.1 print_stdout.py
--- print_stdout.py 28 Sep 2004 14:56:56 -0000 1.1
+++ print_stdout.py 16 Oct 2004 21:39:15 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 # print png to standard out
 # usage: python print_stdout.py > somefile.png
 import sys
I hope this helps,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Hello, the matplotlib tutorial at
 Jochen> http://matplotlib.sourceforge.net/tutorial.html
Thanks Jochen -- these, and your previous bugs, have been fixed in
CVS and the site problems should be fixed on the sf site as well.
JDH

Hello,
the matplotlib tutorial at
 http://matplotlib.sourceforge.net/tutorial.html
states
 If you are new to python, I recommend reading as much of the
 _python tutorial_ and _numeric python manual_ as possible before
 working with matplotlib.
"Python tutorial" and "numeric python manual" are links which both
point to the web page
 http://lists.sourceforge.net/mailman/listinfo/matplotlib-users
This is probably not where they were ment to be pointing to.
I think the link targets should be changed to be
 http://docs.python.org/tut/tut.html
and
 http://www.pfdubois.com/numpy/html2/numpy.html
respectively.
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello,
I produced a set of alternative Debian packages for matplotlib
version 0.63.4. These are based on Vittorio Palmisano's packages,
but include the following changes:
 * I fixed the dependencies and build-dependencies. The package
 should now build fine on build-daemons and such.
 * I only build the gtkagg backend, to keep the list of dependencies
 slim.
 * I made the package build without an X-server connection.
 * The package does no longer install duplicates of the Vera* TTF
 font files but uses the ones from ttf-bitstream-vera instead.
 This reduces the binary package size by several 100kb.
 * The example scripts in the -doc package are executable.
You can find my packages on my homepage at
 http://seehuhn.de/debian/
Comments and suggestions are very welcome.
Vittorio: fell free to incorporate all these changes into your
packages as you see fit.
All the best,
Jochen
--=20
http://seehuhn.de/