matplotlib-devel Mailing List for matplotlib

On Thu, Apr 30, 2009 at 2:29 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Thu, Apr 30, 2009 at 4:14 PM, T J <tj...@gm...> wrote:
>>
>> Fill between is for filling between two y-values over a range of
>> x-values. Is there anything which fills between to x-values over a
>> range of y-values?
>
> Nothing with the ease of use of fill_between, but you can always write your
> own PolyCollection, which is what fill_between does (see the function
> implementation for details) or create a Polygon for a simple region. My use
> cases are typically in the time series world where I have datetime on the
> x-axis and some range of values on the y. If folks think it is sufficiently
> useful to have a fill_betweenx function with a similar interface, you could
> probably fairly easy port fill_between to fill_betweenx.
>
>  http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
>
Done. Attached diff is against rev7075.

On Thu, Apr 30, 2009 at 4:10 PM, Michael Abshoff <mab...@go...>wrote:
> On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...>
> wrote:
> > Thanks. I have committed this to the 0.98.x branch and the trunk, so
> > this fix will make it into the next release.
> >
> > Mike
>
> Excellent. For the record this is/was also a problem on some FreeBSD
> releases, so I am glad it was cleanly fixed.
>
> I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build
> fix. Is it still time to get those into 0.98.x?
There is certainly time to get it into the trunk -- if you want to put it in
as a bugfix on the branch, you must be pretty sure that this will not break
anything because it is a bugfix release.
JDH

On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...> wrote:
> Thanks. I have committed this to the 0.98.x branch and the trunk, so
> this fix will make it into the next release.
>
> Mike
Excellent. For the record this is/was also a problem on some FreeBSD
releases, so I am glad it was cleanly fixed.
I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build
fix. Is it still time to get those into 0.98.x?
Cheers,
Michael

Jae-Joon Lee <lee...@gm...> writes:
> I don't see such any error and I'm not sure if the error is related
> with my patch since the ps backend does not use dviread module.
Darren didn't include the complete traceback, but it seems that dviread
does get used by TexManager.get_text_width_height_descent unless the
text.latex.preview parameter is set. So if preview.sty is available,
setting the parameter might help with that particular problem.
> On Thu, Apr 30, 2009 at 11:44 AM, Darren Dale <dsd...@gm...> wrote:
>>  File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
>>   data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
>> OSError: [Errno 4] Interrupted system call
I thought subprocess.el handled EINTR, but apparently not:
http://bugs.python.org/issue1068268
I guess the reason why some people run into this and others don't is
that (some) GUI toolkits make use of signals, and the probability of
receiving a signal while reading from the subprocess pipe depends on
various system-specific details.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Thu, Apr 30, 2009 at 11:44 AM, Darren Dale <dsd...@gm...> wrote:
> I have to make several attempts before the test script will run to
> completion, I get errors like:
>
>  File "/usr/lib64/python2.6/site-packages/matplotlib/dviread.py", line 812,
> in find_tex_file
>   pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
>  File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
>   errread, errwrite)
>  File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
>   data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
> OSError: [Errno 4] Interrupted system call
>
I don't see such any error and I'm not sure if the error is related
with my patch since the ps backend does not use dviread module.
Anyhow, I just committed the patch for the landscape mode, so that
others can test.
I'll revert the changes if they seem to cause more harm than good.
Regards,
-JJ
> Aside from that, the results from this patch look better. Thanks,
> Darren
>
> On Wed, Apr 29, 2009 at 5:57 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> Argg, attached a wrong patch. This one should work
>>
>>     # set the paper size to the figure size if isEPSF. The
>>     # resulting ps file has the given size with correct bounding
>>     # box so that there is no need to call 'pstoeps'
>>    if isEPSF:
>>       paperWidth, paperHeight = self.figure.get_size_inches()
>> +      if isLandscape:
>> +        paperWidth, paperHeight = paperHeight, paperWidth
>>     else:
>>       temp_papertype = _get_papertype(width, height)
>>       if papertype=='auto':
>>
>>
>>
>> On Wed, Apr 29, 2009 at 5:55 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>> > Thanks Darren,
>> >
>> > I believe that my patch only affects eps output with usetex=True,
>> > i.e., only those "tex_*.eps" files are affected.
>> >
>> > I found that my previous patch didn't treated the orientation of the
>> > paper correctly.
>> > So the bounding box of all the landscape eps outputs are incorrect.
>> > This can be easily fixed.
>> >
>> > Index: lib/matplotlib/backends/backend_ps.py
>> > ===================================================================
>> > --- lib/matplotlib/backends/backend_ps.py    (revision 7071)
>> > +++ lib/matplotlib/backends/backend_ps.py    (working copy)
>> > @@ -1100,8 +1100,11 @@
>> >     # set the paper size to the figure size if isEPSF. The
>> >     # resulting ps file has the given size with correct bounding
>> >     # box so that there is no need to call 'pstoeps'
>> >       paperWidth, paperHeight = self.figure.get_size_inches()
>> > +      if isLandscape:
>> > +        paperWidth, paperHeight = paperHeight, paperWidth
>> >     else:
>> >       temp_papertype = _get_papertype(width, height)
>> >       if papertype=='auto':
>> >
>> >
>> >
>> >
>> > Anyhow, after the landscape fix, all eps output looks fine to me.
>> > Can you check this?
>> >
>> > Regards,
>> >
>> > -JJ
>> >
>> >
>> >
>> > On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
>> >> Hi Jae-Joon,
>> >>
>> >> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...>
>> >> wrote:
>> >>>
>> >>> This patch is now committed to the trunk (r7068).
>> >>
>> >> I think these changes have had unintended consequences. I attached a
>> >> test
>> >> file I used to inspect the results when I wrote the original code that
>> >> you
>> >> recently tried to improve. There are lots of combinations of large and
>> >> small
>> >> figures, with usetex and without, and with no distiller, gs distiller,
>> >> of
>> >> xpdf (pdftops) distiller. You have to visually inspect all of the
>> >> ps/eps
>> >> files that are generated. At one time, all of these files looked
>> >> acceptable,
>> >> but that was a couple years ago and I don't remember what version of
>> >> ghostscript I was using at the time (I'm sure there is a record of it
>> >> somewhere on this mailing list). WIth r7067, most of the files look
>> >> fine, a
>> >> few of the large files (large paper sizes) have problems. With r7068,
>> >> quite
>> >> a few examples have problems.
>> >>
>> >> Darren
>> >>
>> >>
>> >>>
>> >>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...>
>> >>> wrote:
>> >>> > Yeah, that seems to work! thanks a lot,
>> >>> > Ken
>> >>> >
>> >>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
>> >>> > wrote:
>> >>> >> ps backend, when usetex=True, uses latex with psfrag package to
>> >>> >> generate the output (with some extra steps).
>> >>> >> It seems that the bounding box information is not correctly
>> >>> >> recovered
>> >>> >> during this process.
>> >>> >> I first thought that it would be quite difficult to get this
>> >>> >> correct,
>> >>> >> however the attached (relatively simple) patch seems to work fine.
>> >>> >>
>> >>> >> Ken, can you try the patch and see if it works?
>> >>> >>
>> >>> >> -JJ
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte <kts...@gm...>
>> >>> >> wrote:
>> >>> >>> I've been trying to track down some strange behavior I was
>> >>> >>> getting,
>> >>> >>> and I think narrowed it down to some code that I'll paste below.
>> >>> >>>
>> >>> >>> I'm trying to write to .eps files, and when I have usetex=True,
>> >>> >>> something is screwed up with the padding on the left, and
>> >>> >>> eventually
>> >>> >>> the whole image is just white.
>> >>> >>>
>> >>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*'
>> >>> >>> does
>> >>> >>> not. The same problem happens even if I remove the ticklabels.
>> >>> >>>
>> >>> >>> Any tips would be appreciated.
>> >>> >>> thanks,
>> >>> >>> Ken
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> ------------------------------------------------
>> >>> >>> import matplotlib.pyplot as plt
>> >>> >>> import numpy as np
>> >>> >>> from matplotlib import rc
>> >>> >>>
>> >>> >>> fig = plt.figure()
>> >>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
>> >>> >>>
>> >>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>> >>> >>>
>> >>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
>> >>> >>>
>> >>> >>> def go(name):
>> >>> >>>
>> >>> >>>  for d in (1,2,3,4):
>> >>> >>>
>> >>> >>>    w = d*5
>> >>> >>>    h = d
>> >>> >>>
>> >>> >>>    fig.set_size_inches(w,h)
>> >>> >>>    fig.savefig("%s-%d.eps" % (name,d))
>> >>> >>>
>> >>> >>> rc('text', usetex=False)
>> >>> >>> go("testA")
>> >>> >>>
>> >>> >>> rc('text', usetex=True)
>> >>> >>> go("testB")
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> ------------------------------------------------------------------------------
>> >>> >>> Crystal Reports &#45; New Free Runtime and 30 Day Trial
>> >>> >>> Check out the new simplified licensign option that enables
>> >>> >>> unlimited
>> >>> >>> royalty&#45;free distribution of the report engine for externally
>> >>> >>> facing
>> >>> >>> server and web deployment.
>> >>> >>> http://p.sf.net/sfu/businessobjects
>> >>> >>> _______________________________________________
>> >>> >>> Matplotlib-devel mailing list
>> >>> >>> Mat...@li...
>> >>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>> >>>
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>
>> >>
>> >>
>> >>>
>> >>> Register Now & Save for Velocity, the Web Performance & Operations
>> >>> Conference from O'Reilly Media. Velocity features a full day of
>> >>> expert-led, hands-on workshops and two days of sessions from industry
>> >>> leaders in dedicated Performance & Operations tracks. Use code
>> >>> vel09scf
>> >>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >>> _______________________________________________
>> >>> Matplotlib-devel mailing list
>> >>> Mat...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >>
>> >
>
>

I have to make several attempts before the test script will run to
completion, I get errors like:
 File "/usr/lib64/python2.6/site-packages/matplotlib/dviread.py", line 812,
in find_tex_file
 pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
 File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
 errread, errwrite)
 File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
 data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
OSError: [Errno 4] Interrupted system call
Aside from that, the results from this patch look better. Thanks,
Darren
On Wed, Apr 29, 2009 at 5:57 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Argg, attached a wrong patch. This one should work
>
> # set the paper size to the figure size if isEPSF. The
> # resulting ps file has the given size with correct bounding
> # box so that there is no need to call 'pstoeps'
> if isEPSF:
> paperWidth, paperHeight = self.figure.get_size_inches()
> + if isLandscape:
> + paperWidth, paperHeight = paperHeight, paperWidth
> else:
> temp_papertype = _get_papertype(width, height)
> if papertype=='auto':
>
>
>
> On Wed, Apr 29, 2009 at 5:55 PM, Jae-Joon Lee <lee...@gm...>
> wrote:
> > Thanks Darren,
> >
> > I believe that my patch only affects eps output with usetex=True,
> > i.e., only those "tex_*.eps" files are affected.
> >
> > I found that my previous patch didn't treated the orientation of the
> > paper correctly.
> > So the bounding box of all the landscape eps outputs are incorrect.
> > This can be easily fixed.
> >
> > Index: lib/matplotlib/backends/backend_ps.py
> > ===================================================================
> > --- lib/matplotlib/backends/backend_ps.py (revision 7071)
> > +++ lib/matplotlib/backends/backend_ps.py (working copy)
> > @@ -1100,8 +1100,11 @@
> > # set the paper size to the figure size if isEPSF. The
> > # resulting ps file has the given size with correct bounding
> > # box so that there is no need to call 'pstoeps'
> > paperWidth, paperHeight = self.figure.get_size_inches()
> > + if isLandscape:
> > + paperWidth, paperHeight = paperHeight, paperWidth
> > else:
> > temp_papertype = _get_papertype(width, height)
> > if papertype=='auto':
> >
> >
> >
> >
> > Anyhow, after the landscape fix, all eps output looks fine to me.
> > Can you check this?
> >
> > Regards,
> >
> > -JJ
> >
> >
> >
> > On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
> >> Hi Jae-Joon,
> >>
> >> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...>
> wrote:
> >>>
> >>> This patch is now committed to the trunk (r7068).
> >>
> >> I think these changes have had unintended consequences. I attached a
> test
> >> file I used to inspect the results when I wrote the original code that
> you
> >> recently tried to improve. There are lots of combinations of large and
> small
> >> figures, with usetex and without, and with no distiller, gs distiller,
> of
> >> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
> >> files that are generated. At one time, all of these files looked
> acceptable,
> >> but that was a couple years ago and I don't remember what version of
> >> ghostscript I was using at the time (I'm sure there is a record of it
> >> somewhere on this mailing list). WIth r7067, most of the files look
> fine, a
> >> few of the large files (large paper sizes) have problems. With r7068,
> quite
> >> a few examples have problems.
> >>
> >> Darren
> >>
> >>
> >>>
> >>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...>
> wrote:
> >>> > Yeah, that seems to work! thanks a lot,
> >>> > Ken
> >>> >
> >>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
> >>> > wrote:
> >>> >> ps backend, when usetex=True, uses latex with psfrag package to
> >>> >> generate the output (with some extra steps).
> >>> >> It seems that the bounding box information is not correctly
> recovered
> >>> >> during this process.
> >>> >> I first thought that it would be quite difficult to get this
> correct,
> >>> >> however the attached (relatively simple) patch seems to work fine.
> >>> >>
> >>> >> Ken, can you try the patch and see if it works?
> >>> >>
> >>> >> -JJ
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte <kts...@gm...>
> >>> >> wrote:
> >>> >>> I've been trying to track down some strange behavior I was getting,
> >>> >>> and I think narrowed it down to some code that I'll paste below.
> >>> >>>
> >>> >>> I'm trying to write to .eps files, and when I have usetex=True,
> >>> >>> something is screwed up with the padding on the left, and
> eventually
> >>> >>> the whole image is just white.
> >>> >>>
> >>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*'
> does
> >>> >>> not. The same problem happens even if I remove the ticklabels.
> >>> >>>
> >>> >>> Any tips would be appreciated.
> >>> >>> thanks,
> >>> >>> Ken
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> ------------------------------------------------
> >>> >>> import matplotlib.pyplot as plt
> >>> >>> import numpy as np
> >>> >>> from matplotlib import rc
> >>> >>>
> >>> >>> fig = plt.figure()
> >>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
> >>> >>>
> >>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
> >>> >>>
> >>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
> >>> >>>
> >>> >>> def go(name):
> >>> >>>
> >>> >>> for d in (1,2,3,4):
> >>> >>>
> >>> >>> w = d*5
> >>> >>> h = d
> >>> >>>
> >>> >>> fig.set_size_inches(w,h)
> >>> >>> fig.savefig("%s-%d.eps" % (name,d))
> >>> >>>
> >>> >>> rc('text', usetex=False)
> >>> >>> go("testA")
> >>> >>>
> >>> >>> rc('text', usetex=True)
> >>> >>> go("testB")
> >>> >>>
> >>> >>>
> >>> >>>
> ------------------------------------------------------------------------------
> >>> >>> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> >>> >>> Check out the new simplified licensign option that enables
> unlimited
> >>> >>> royalty&#45;free distribution of the report engine for externally
> >>> >>> facing
> >>> >>> server and web deployment.
> >>> >>> http://p.sf.net/sfu/businessobjects
> >>> >>> _______________________________________________
> >>> >>> Matplotlib-devel mailing list
> >>> >>> Mat...@li...
> >>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>
> >>
> >>
> >>>
> >>> Register Now & Save for Velocity, the Web Performance & Operations
> >>> Conference from O'Reilly Media. Velocity features a full day of
> >>> expert-led, hands-on workshops and two days of sessions from industry
> >>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> >>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >
>

Thanks. I have committed this to the 0.98.x branch and the trunk, so 
this fix will make it into the next release.
Mike
Dave Peterson wrote:
> When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC 
> 4.3.3, I get an error:
>
> ttconv/pprdrv_tt2.cpp: In member function ‘void 
> GlyphToType3::stack(TTStreamWriter&, int)’:
> ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member 
> named ‘putc’
>
> So I tried invoking GCC with the -E flag to get the output of the 
> preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
> stream.putc(('{'), (&__iob[1]));
> so it seems that something in GCC 4.3.3 on Solaris is defining a 
> putchar macro that is doing this, but not correspondingly being 
> applied to the pprdrv.h.
>
> Searching the list archives, I see that back in July & August, 2008 
> there was a brief thread between Peter Norton and Mike Droettboom 
> about this and a proposal was made to rename TTStreamWriter::putchar 
> to TTStreamWriter:put_char. I just looked at the trunk and it looks 
> like this has never been done. Was there some other work-around that 
> didn't make it into the thread that obviated the need for the 
> mentioned change?
>
> I can confirm that the renaming of putchar to put_char does solve the 
> problem. I've attached a patch file, though it is against 0.98.5.2.
>
>
> -- Dave
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA