Re: [matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc
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
> Matplotlib-devel@lists.sourceforge.net
> 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem saving to eps with usetex=True
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 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 > 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 wrote: > >> Hi Jae-Joon, > >> > >> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee > 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 > wrote: > >>> > Yeah, that seems to work! thanks a lot, > >>> > Ken > >>> > > >>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee > >>> > 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 > >>> >> 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 appreci
Re: [matplotlib-devel] Problem saving to eps with usetex=True
On Thu, Apr 30, 2009 at 11:44 AM, Darren Dale 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 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 >> 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 wrote: >> >> Hi Jae-Joon, >> >> >> >> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee >> >> 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 >> >>> wrote: >> >>> > Yeah, that seems to work! thanks a lot, >> >>> > Ken >> >>> > >> >>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee >> >>> > 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 >> >>> >> wrote: >> >>> >>> I've been trying
Re: [matplotlib-devel] Problem saving to eps with usetex=True
Jae-Joon Lee 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 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc
On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc
On Thu, Apr 30, 2009 at 4:10 PM, Michael Abshoff wrote: > On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom > 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] fill_between
On Thu, Apr 30, 2009 at 2:29 PM, John Hunter wrote:
>
>
> On Thu, Apr 30, 2009 at 4:14 PM, T J 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.
Index: lib/matplotlib/pyplot.py
===
--- lib/matplotlib/pyplot.py (revision 7075)
+++ lib/matplotlib/pyplot.py (working copy)
@@ -1185,7 +1185,8 @@
figtext add text in figure coords
figure create or change active figure
fillmake filled polygons
-fill_betweenmake filled polygons
+fill_betweenmake filled polygons between two sets of y-values
+fill_betweenx make filled polygons between two sets of x-values
gca return the current axes
gcf return the current figure
gci get the current image, or None
@@ -1945,6 +1946,28 @@
# This function was autogenerated by boilerplate.py. Do not edit as
# changes will be lost
+def fill_betweenx(*args, **kwargs):
+# allow callers to override the hold state by passing hold=True|False
+b = ishold()
+h = kwargs.pop('hold', None)
+if h is not None:
+hold(h)
+try:
+ret = gca().fill_betweenx(*args, **kwargs)
+draw_if_interactive()
+except:
+hold(b)
+raise
+
+hold(b)
+return ret
+if Axes.fill_betweenx.__doc__ is not None:
+fill_betweenx.__doc__ = dedent(Axes.fill_betweenx.__doc__) + """
+
+Additional kwargs: hold = [True|False] overrides default hold state"""
+
+# This function was autogenerated by boilerplate.py. Do not edit as
+# changes will be lost
def hexbin(*args, **kwargs):
# allow callers to override the hold state by passing hold=True|False
b = ishold()
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 7075)
+++ lib/matplotlib/axes.py (working copy)
@@ -5809,10 +5809,10 @@
an N length np array of the x data
*y1*
- an N length scalar or np array of the x data
+ an N length scalar or np array of the y data
*y2*
- an N length scalar or np array of the x data
+ an N length scalar or np array of the y data
*where*
if None, default to fill between everywhere. If not None,
@@ -5827,6 +5827,12 @@
%(PolyCollection)s
.. plot:: mpl_examples/pylab_examples/fill_between.py
+
+.. seealso::
+
+:meth:`fill_betweenx`
+for filling between two sets of x-values
+
"""
# Handle united data, such as dates
self._process_unit_info(xdata=x, ydata=y1, kwargs=kwargs)
@@ -5896,6 +5902,113 @@
return collection
fill_between.__doc__ = cbook.dedent(fill_between.__doc__) % martist.kwdocd
+def fill_betweenx(self, y, x1, x2=0, where=None, **kwargs):
+"""
+call signature::
+
+ fill_between(y, x1, x2=0, where=None, **kwargs)
+
+Create a :class:`~matplotlib.collections.PolyCollection`
+filling the regions between *x1* and *x2* where
+``where==True``
+
+*y*
+ an N length np array of the y data
+
+*x1*
+ an N length scalar or np array of the x data
+
+*x2*
+ an N length scalar or np array of the x data
+
+*where*
+ if None, default to fill between everywhere. If not None,
+ it is a a N length numpy boolean array and the fill will
+ only happen over the regions where ``where==True``
+
+*kwargs*
+ keyword args passed on to the :class:`PolyCollection`
+
+kwargs control the Polygon properties:
+
+%(PolyCollection)s
+
+.. plot:: mpl_examples/pylab_examples/fill_betweenx.py
+
+.. seealso::
+
+:meth:`fill_between`
+for filling between two sets of y-values
+
+"""
+# Handle united data, such as dates
+self._process_unit_info(ydata=y, xdata=x1, kwargs=kwargs)
+self._process_unit_info(xdata=x2)
+
+# Convert the arrays so we can work with them
+y = np.asanyarray(self.convert_yunits(y))
+x1 = np.asanyarray(self.convert_xu
