[matplotlib-devel] Bug in Qt4 backend (navigation toolbar destroy method)
Hi all, I'm posting to report the following bug in 'backend_qt4.py', class 'NavigationToolbar2QT' l. 309 : When using Qt4 as default backend, if you type 'plot(x,y)' and then 'close()', you'll obtain an attribute error because 'NavigationToolbar2QT' has no 'toolitem' attribute (see line 310). I think that 'toolitem' was used in the previous Qt4 backend implementation. To make things work, I simply removed this 'destroy' method which is probably deprecated. Regards, Pierre Raybaut - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
Hate to say "me too", but I don't really understand text with dash either... I'll have a look when I have adequate time to devote to it, if no one else volunteers. Cheers, Mike Manuel Metz wrote: > John Hunter wrote: > >> Manuel and Michael worked on fixing a bug with TextWithDash, but this >> introduced a bug will all tick labels so I reverted the changes. The >> problem is that the text layout code in Text (eg draw, >> get_window_extent) is using "get_position" which in TextWithDash is >> the dash position, according to the doc string and the original impl. >> On the branch, the draw and layout methods of Text use _get_xy_display >> which TextWithDash overrides. That is why it works on the branch and >> not the trunk. The changes of M&M to make set_position and >> get_position refer to the x and y locs fixed dash with text for >> reasons that are not completely clear t me, but broke tick labels >> which are also TextWithDash instances. >> >> I did not write TextWithDash so cannot vouch for its conventions, but >> I don't have time to dig deeply enough right now to fix this, so I >> wanted to revert the changes so regular plots would work again and >> give a head's up here so Manuel, Michael and I would not be doing and >> undoing each other's changes w/o some understanding of where the >> discerpancy was arising. >> > > Hm, the patch I applied was exactly because I got also problems with the > tick labels -- they were all squashed to one place -- and I thought to > have fixed that. Now, it seems this wasn't quite correct ;-) >As I have also no deeper understanding what's _really_ going on in > TextWithDash, I will now better keep my hands off TextWithDash ... > > Manuel > > >> Thanks, >> JDH >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > [email protected] > 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 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in scale.py
Yes. Thank you for finding this. Fixed in SVN. Cheers, Mike Ryan May wrote: > Hi, > > I think I found a bug while looking over scale.py: > > 127 class InvertedNaturalLogTransform(Transform): > 128 input_dims = 1 > 129 output_dims = 1 > 130 is_separable = True > 131 base = np.e > 132 > 133 def transform(self, a): > 134 return ma.power(np.e, a) / np.e > 135 > 136 def inverted(self): > 137 return LogScale.Log2Transform() > > Shouldn't line 137 instead read: > return LogScale.NaturalLogTransform() > > Ryan > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Hate to say "me too", but I don't really understand text with dash > either... I'll have a look when I have adequate time to devote to it, > if no one else volunteers. Daishi, I don't know if this is still the right email address for you, but if so could you let us know if you could look at the TextWithDash implementation in matplotlib svn trunk. Our transformations have undergone a bit of refactoring, and some relatively minor changes were made in the Text base class positioning code, but these were enough to break the TextWithDash layout. Let us know if you have a minute to look at this and perhaps provide a patch to bring TextWithDash functionality back. Thanks, JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in Qt4 backend (navigation toolbar destroy method)
Hi Pierre, On Monday 30 June 2008 06:25:42 am Pierre Raybaut wrote: > Hi all, > > I'm posting to report the following bug in 'backend_qt4.py', class > 'NavigationToolbar2QT' l. 309 : > > When using Qt4 as default backend, if you type 'plot(x,y)' and then > 'close()', you'll obtain an attribute error because 'NavigationToolbar2QT' > has no 'toolitem' attribute (see line 310). I think that 'toolitem' was > used in the previous Qt4 backend implementation. > > To make things work, I simply removed this 'destroy' method which is > probably deprecated. Thank you for the report. This is fixed in svn. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
On Monday 30 June 2008 09:06:59 am John Hunter wrote: > On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > Hate to say "me too", but I don't really understand text with dash > > either... I'll have a look when I have adequate time to devote to it, > > if no one else volunteers. > > Daishi, > > I don't know if this is still the right email address for you, but if > so could you let us know if you could look at the TextWithDash > implementation in matplotlib svn trunk. Our transformations have > undergone a bit of refactoring, and some relatively minor changes were > made in the Text base class positioning code, but these were enough to > break the TextWithDash layout. Let us know if you have a minute to > look at this and perhaps provide a patch to bring TextWithDash > functionality back. Daishi's original contribution of TextWithDash used delegation, which was causing some trouble with object introspection and the dynamically generated list of properties. I refactored his work way back in March 2006, svn 2226: http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd55%40cornell.edu Sorry I'm just now getting to this thread. I recall the behavior of get_position referring to the dash position was strange for a subclass of Text, but this was simply a continuation of the original implimentation. I was only concerned with exposing all of TextWithDash's methods to object introspection when I made my contribution. I also recall seeing strange behavior like what Manuel posted. I'll have a look when I get a chance, hopefully this evening. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] axes_class in add_subplot()?
Hi, I sometimes use a custom Axes class, and want to use it with add_subplot() command. As a matter of fact, it IS possible with current version of matplotlib but it seems a bit inconvenient to me. Here is what I do. class MyAxes(maxes.Axes): name="myaxes" - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes_class in add_subplot()?
Sorry, I accidentally sent an incomplete email. here is a complete one. I sometimes use a custom Axes class, and want to use it with add_subplot() command. As a matter of fact, it IS possible with current version of matplotlib but it seems a bit inconvenient to me. Here is what I may do. import matplotlib.axes as maxes class MyAxes(maxes.Axes): name="myaxes" # some definitions import matplotlib.projections matplotlib.projections.register_projection(MyAxes) F = figure() ax = F.add_subplot(1,2,2, projection="myaxes") But it would much better if I can simply do something like class MyAxes(maxes.Axes): # some definitions F = figure() ax = F.add_subplot(1,2,2, axes_class=MyAxes) It seems rather straight forward to implement "axes_class" keyword in add_subplot() and I may make a patch for it. So, how does others think? Regards, -JJ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Python/Sage minisymposium at SIAM Annual meeting July 9/10 2008
Hi all, this is just a reminder, in case you'll be attending the SIAM 2008 annual meeting next week in San Diego, that there will be a 3-part minisymposium focusing on the uses of Python and Sage in scientific computing: http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447 We hope to see many of you there! Regards, Fernando and Randy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
On Monday 30 June 2008 10:40:27 Darren Dale wrote: > On Monday 30 June 2008 09:06:59 am John Hunter wrote: > > On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > > Hate to say "me too", but I don't really understand text with dash > > > either... I'll have a look when I have adequate time to devote to it, > > > if no one else volunteers. > > > > Daishi, > > > > I don't know if this is still the right email address for you, but if > > so could you let us know if you could look at the TextWithDash > > implementation in matplotlib svn trunk. Our transformations have > > undergone a bit of refactoring, and some relatively minor changes were > > made in the Text base class positioning code, but these were enough to > > break the TextWithDash layout. Let us know if you have a minute to > > look at this and perhaps provide a patch to bring TextWithDash > > functionality back. > > Daishi's original contribution of TextWithDash used delegation, which was > causing some trouble with object introspection and the dynamically > generated list of properties. I refactored his work way back in March 2006, > svn 2226: > http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd >55%40cornell.edu > > Sorry I'm just now getting to this thread. I recall the behavior of > get_position referring to the dash position was strange for a subclass of > Text, but this was simply a continuation of the original implimentation. I > was only concerned with exposing all of TextWithDash's methods to object > introspection when I made my contribution. I also recall seeing strange > behavior like what Manuel posted. I'll have a look when I get a chance, > hopefully this evening. I *think* I found a simple fix: use the Text._x and ._y directly in draw, rather than get_position which refers to the text position in Text and the Dash position in TextWith Dash (thank you for pointing this out, John). Please let me know if something is still amiss, svn 5701. I had another working solution which let get/set_position refer to the text position, and added get/set_dashposition. I didn't like it as much, because the text position could be set by the user and would then be overridden by update_coords. But maybe it was a more coherent way to do it. set_position could recalculate the dash length, and set_dashlength/pad/push would recalculate the text position. (The dash position is always the reference.) I think it might be more trouble than its worth, it would take a lot of work and would cause API breakage. Darren - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
Darren Dale wrote: > > On Monday 30 June 2008 10:40:27 Darren Dale wrote: >> On Monday 30 June 2008 09:06:59 am John Hunter wrote: >>> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <[EMAIL PROTECTED]> > wrote: Hate to say "me too", but I don't really understand text with dash either... I'll have a look when I have adequate time to devote to it, if no one else volunteers. >>> Daishi, >>> >>> I don't know if this is still the right email address for you, but if >>> so could you let us know if you could look at the TextWithDash >>> implementation in matplotlib svn trunk. Our transformations have >>> undergone a bit of refactoring, and some relatively minor changes were >>> made in the Text base class positioning code, but these were enough to >>> break the TextWithDash layout. Let us know if you have a minute to >>> look at this and perhaps provide a patch to bring TextWithDash >>> functionality back. >> Daishi's original contribution of TextWithDash used delegation, which was >> causing some trouble with object introspection and the dynamically >> generated list of properties. I refactored his work way back in March 2006, >> svn 2226: >> http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd >> 55%40cornell.edu >> >> Sorry I'm just now getting to this thread. I recall the behavior of >> get_position referring to the dash position was strange for a subclass of >> Text, but this was simply a continuation of the original implimentation. I >> was only concerned with exposing all of TextWithDash's methods to object >> introspection when I made my contribution. I also recall seeing strange >> behavior like what Manuel posted. I'll have a look when I get a chance, >> hopefully this evening. > > I *think* I found a simple fix: use the Text._x and ._y directly in draw, > rather than get_position which refers to the text position in Text and the > Dash position in TextWith Dash (thank you for pointing this out, John). > Please > let me know if something is still amiss, svn 5701. > > I had another working solution which let get/set_position refer to the text > position, and added get/set_dashposition. I didn't like it as much, because > the text position could be set by the user and would then be overridden by > update_coords. But maybe it was a more coherent way to do it. set_position > could recalculate the dash length, and set_dashlength/pad/push would > recalculate the text position. (The dash position is always the reference.) I > think it might be more trouble than its worth, it would take a lot of work > and > would cause API breakage. With that patch everything is working for me: dashpointlabel is working, tick labels are also correctly drawn, and the dashtick example now also works fine again (both GUI and png output) ! Manuel > Darren > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Latex Documentation build errors - possibly scale_docs
When building the docs using make.py in the doc directory, Latex hangs.
I'm using the svn version of the docs on a debian system with
matplotlib 0.98.1 and sphinx 0.4.
Latex hangs ( but can be made to continue by pressing return) at the
following point:
Underfull \hbox (badness 1) in paragraph at lines 17819--17822
[]\T1/txr/m/n/10.95 A dic-tio-nary with key-word ar-gu-ments ac-cepted by the
[181] [182]
Underfull \hbox (badness 1) in paragraph at lines 18251--18254
[][][]\T1/txtt/m/n/10.95 semilogx()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of [][]\T1/txtt/m/n/10.95 plot()[][] \T1/txr/m/n/10.95 and
[183]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18443--18444
[][]
Underfull \hbox (badness 1) in paragraph at lines 18458--18461
[][][]\T1/txtt/m/n/10.95 semilogy()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of \T1/txtt/m/n/10.95 plot() \T1/txr/m/n/10.95 and
[184]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18650--18651
[][]
[185]
Overfull \hbox (92.41579pt too wide) in paragraph at lines 18760--18761
[][]
[186]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19150--19151
[][]
[187]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19351--19352
[][]
[188] [189]
! LaTeX Error: Too deeply nested.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.19440 [EMAIL PROTECTED]
?
This corresponds to the following latex code where a second
\begin{quote} is opened before closing the first. Commenting out one
of these \begin{quote} (and the corresponding \end{quote} fixes the
problem:
Set the scaling of the y-axis: `linear' | `log' | `symlog'
ACCEPTS: {[}'linear' | `log' | `symlog'{]}
Different kwargs are accepted, depending on the scale:
`linear'
\begin{quote}
`log'
\begin{quote}
\begin{description}
\item[\emph{basex}/\emph{basey}:]
The base of the logarithm
\item[\emph{subsx}/\emph{subsy}:]
Where to place the subticks between each major tick.
Should be a sequence of integers. For example, in a log10
scale:
This latex seems to be generated by the following lines in axes.py -
but I haven't worked out how to fix it.
def set_yscale(self, value, **kwargs):
"""
call signature::
set_yscale(value)
Set the scaling of the y-axis: %(scale)s
ACCEPTS: [%(scale)s]
Different kwargs are accepted, depending on the scale:
%(scale_docs)s
"""
self.yaxis.set_scale(value, **kwargs)
self.autoscale_view()
self._update_transScale()
set_yscale.__doc__ = cbook.dedent(set_yscale.__doc__) % {
'scale': ' | '.join([repr(x) for x in mscale.get_scale_names()]),
'scale_docs': mscale.get_scale_docs().strip()}
Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] text with dash problems
On Mon, Jun 30, 2008 at 6:34 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > I *think* I found a simple fix: use the Text._x and ._y directly in draw, > rather than get_position which refers to the text position in Text and the > Dash position in TextWith Dash (thank you for pointing this out, John). Please > let me know if something is still amiss, svn 5701. That seems like an easy enough fix, and my simple tests are working fine, but it speaks well of you that you found it, because the dash with text innards are sufficiently confusing that it left Michael, Manuel and I scratching our heads. All the better because my email to Daishi bounced. Thanks, Darren. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes_class in add_subplot()?
On Mon, Jun 30, 2008 at 2:31 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > It seems rather straight forward to implement "axes_class" keyword in > add_subplot() and I may make a patch for it. > So, how does others think? Seems totally reasonable an we'd be happy to accept a patch. Thanks, JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] GTK pylab console
On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier <[EMAIL PROTECTED]> wrote: > > > Thanks John, I've update the new version with your code. > > It is now available at: > http://www.loria.fr/~rougier/pylab.html > > You can now choose between python and ipython (option -s python > or -s ipython) and all user events on a figure should be handled > properly (mouse, scroll and key). > > Concerning the toolbar, is is quite easy to add but it is not > very pleasant to the eyes. I'm looking for a more asethetic solution. I've only had a limited chance to test this but it looks very exciting. I am amazed by how quickly you go the ipython shell incorporated. I am still a bit vexed by the lack of support for emacs key bindings (I guess having ipython and readline support are not enough, but I bet there is some gtk console code out there to support them). I do miss my CTRL-a and CTRL-k and friends. As for the toolbar, I think functionality over aesthetics carries the day because it is easy to make it pretty after you make it work (and you can always make it optional with a flag), but note that you do not need to use the standard gtk toolbar widget -- you can write your own that works however you want. There is only minimal overhead for the toolbar writer that is fairly well documented in backend_bases.py. One option is to draw no toolbar at all but just just set up key bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect mode, etc, or draw your own toolbar or whatever. But having the functionality is a killer feature, in my opinion. Keep us posted. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Latex Documentation build errors - possibly scale_docs
On Mon, Jun 30, 2008 at 8:40 PM, Chris Walker <[EMAIL PROTECTED]> wrote: > When building the docs using make.py in the doc directory, Latex hangs. > > > I'm using the svn version of the docs on a debian system with > matplotlib 0.98.1 and sphinx 0.4. > > Latex hangs ( but can be made to continue by pressing return) at the > following point: I'm pretty sure this is fixed in svn -- I made some docstring edits to fix this bug a while back. I've tried to emphasize that the docs are a very fast moving target, slated for release end of summer, so should be considered bleeding-edge only. In other words, if you expect them to build, you should be ready to use mpl svn and/or svn from any of the packages they depend on (sphinx, pygments, ) JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
