matplotlib-devel Mailing List for matplotlib

Hello all,

This email is being sent out to to the lists of users+devs who regularly use
IPython's "pylab" mode or "-wthread", "-qthread", "-gthread", etc. threaded
shells.  As of today, in IPython's trunk, we have a completely new
implementation of our GUI event loop integration that dramatically improves
the stability of using the TERMINAL BASED IPython with GUI applications.
This does not affect attempts to embed IPython into GUI applications.

At this point, we need developers to begin to try out the new stuff and
adapt their projects to use the new capabilities.  Here are some things you
will get:

* Stability and robustness have been improved greatly.
* KeyboardInterrupts should work on all platforms reliably.
* No more command line flags - instead everything can be
activated/de-activated/switched at runtime.  This should allow projects like
matplotlib to enable reliable backend switching.  See the new %gui magic for
more information on this.
* We have a new developer module for working with these features
(IPython.lib.inputhook).
* Unless someone complains very loudly *and* steps up to the plate to
maintain them, the old threaded shells will be removed in the next release
of IPython.

Here are some starting points for documentation on the new features:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/docs/source/interactive/reference.txt#L1375
http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/lib/inputhook.py
http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/core/magic.py#L3542

Please let us know if you have questions - we are more than willing to help
you get started with all of this.

Cheers,

Brian

he...@us... wrote:
> Revision: 7620
>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7620&view=rev
> Author:   heeres
> Date:     2009-08-31 19:50:13 +0000 (Mon, 31 Aug 2009)

Reinier,

Thanks!  Don't forget to make a note in CHANGELOG.

Eric

On Sat, Aug 22, 2009 at 3:24 AM, Ryan May <rm...@gm...> wrote:

>
>
> On Sat, Aug 22, 2009 at 3:01 AM, Jouni K. Seppänen <jk...@ik...> wrote:
>
>> I fixed some doc typos on the v0_99_maint branch and was going to merge
>> the fixes to the trunk, but it didn't work:
>>
>> % svnmerge.py avail -S v0_99_maint
>> svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous
>> substring of a repository path, nor a working directory
>> % svnmerge.py avail
>> svnmerge: multiple sources found. Explicit source argument (-S/--source)
>> required.
>> The merge sources available are:
>>  /branches/mathtex
>>  /branches/v0_91_maint
>>  /branches/v0_98_5_maint
>>
>> I'm pretty sure that this used to work. What has changed in the
>> repository?
>
>
> Same behavior here. I had been having trouble doing any merges, but never
> had tracked it down.  I guess this is related.
>

Just to follow up and put in the archives for anyone searching.  It looks
like the svnmerge.py script was updated at some point since the last time I
downloaded it (probably to keep in sync with changes in SVN itself).  I was
having problems merging today, but updating to this latest version solved
all the problems.

Just FYI.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Things are more responsive than with python 2.5 and with qt 4.4.3, but the
lag is still noticeable--especially compared to with the addition of the
line.

On Mon, Aug 31, 2009 at 12:05 PM, Darren Dale <dsd...@gm...> wrote:

> I don't understand. With py-2.6, are things more responsive or is
> there an extremely noticeable lag?
>
> On Mon, Aug 31, 2009 at 11:51 AM, william
> ratcliff<wil...@gm...> wrote:
> > Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> > and things are more responsive...However, the difference between having
> that
> > line in and taking it out are the difference between having pan/zoom
> events
> > being extremely responsive and having an extremely noticeable lag.  I've
> > attached a test file from the web which is rather simple.  You can notice
> > the lag if you either try to pan/zoom using the toolbar, or if you try to
> > use the slider to change the sizes of the horizontal bars.
> >
> > Sigh, upgrading everything to 2.6 is going to be a chore...
> >
> >
> > Thanks,
> > William
> >
> > On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...>
> wrote:
> >>
> >> I've been using 2.6. It should be fine on windows now, but I can't
> >> attest to it since I only use windows when I have to test and make
> >> windows installers.
> >>
> >> On Mon, Aug 31, 2009 at 10:02 AM, william
> >> ratcliff<wil...@gm...> wrote:
> >> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista
> 32
> >> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
> >> > 2.5
> >> > and am wondering if anyone has noticed any difficulties with 2.6).
> >> >
> >> > Cheers,
> >> > Wiliam
> >> >
> >> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...>
> wrote:
> >> >>
> >> >> Hi William,
> >> >>
> >> >> On Mon, Aug 31, 2009 at 8:25 AM, william
> >> >> ratcliff<wil...@gm...> wrote:
> >> >> > Hi!  I just installed matplotlib version .99 (windows vista,
> >> >> > python25,
> >> >> > 32bit) and found that
> >> >> > this line was missing:
> >> >> > QtGui.qApp.processEvents()
> >> >> >
> >> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
> >> >> > still
> >> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
> >> >> > 2.1.14
> >> >> > release for my python distribution on this machine.  Could this
> line
> >> >> > be
> >> >> > added back?
> >> >>
> >> >> Unfortunately, no, that line can not be added back in. When that line
> >> >> is in place, the backend attempts to process queued events before it
> >> >> is finished processing the current event. It was leading to segfaults
> >> >> in some cases. processEvents should not be called in the middle of
> >> >> processing an event.
> >> >>
> >> >> I tested the responsiveness of panning and zooming with and without
> >> >> that call to processEvents, on Linux and windows and it looked fine.
> >> >> Maybe its an issue related to a specific Qt version on windows.
> Things
> >> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
> >> >>
> >> >> Darren
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> "In our description of nature, the purpose is not to disclose the real
> >> essence of the phenomena but only to track down, so far as it is
> >> possible, relations between the manifold aspects of our experience" -
> >> Niels Bohr
> >>
> >> "It is a bad habit of physicists to take their most successful
> >> abstractions to be real properties of our world." - N. David Mermin
> >>
> >> "Once we have granted that any physical theory is essentially only a
> >> model for the world of experience, we must renounce all hope of
> >> finding anything like the correct theory ... simply because the
> >> totality of experience is never accessible to us." - Hugh Everett III
> >
> >
>
>
>
> --
> "In our description of nature, the purpose is not to disclose the real
> essence of the phenomena but only to track down, so far as it is
> possible, relations between the manifold aspects of our experience" -
> Niels Bohr
>
> "It is a bad habit of physicists to take their most successful
> abstractions to be real properties of our world." - N. David Mermin
>
> "Once we have granted that any physical theory is essentially only a
> model for the world of experience, we must renounce all hope of
> finding anything like the correct theory ... simply because the
> totality of experience is never accessible to us." - Hugh Everett III
>

I don't understand. With py-2.6, are things more responsive or is
there an extremely noticeable lag?

On Mon, Aug 31, 2009 at 11:51 AM, william
ratcliff<wil...@gm...> wrote:
> Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> and things are more responsive...However, the difference between having that
> line in and taking it out are the difference between having pan/zoom events
> being extremely responsive and having an extremely noticeable lag.  I've
> attached a test file from the web which is rather simple.  You can notice
> the lag if you either try to pan/zoom using the toolbar, or if you try to
> use the slider to change the sizes of the horizontal bars.
>
> Sigh, upgrading everything to 2.6 is going to be a chore...
>
>
> Thanks,
> William
>
> On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...> wrote:
>>
>> I've been using 2.6. It should be fine on windows now, but I can't
>> attest to it since I only use windows when I have to test and make
>> windows installers.
>>
>> On Mon, Aug 31, 2009 at 10:02 AM, william
>> ratcliff<wil...@gm...> wrote:
>> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
>> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
>> > 2.5
>> > and am wondering if anyone has noticed any difficulties with 2.6).
>> >
>> > Cheers,
>> > Wiliam
>> >
>> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote:
>> >>
>> >> Hi William,
>> >>
>> >> On Mon, Aug 31, 2009 at 8:25 AM, william
>> >> ratcliff<wil...@gm...> wrote:
>> >> > Hi!  I just installed matplotlib version .99 (windows vista,
>> >> > python25,
>> >> > 32bit) and found that
>> >> > this line was missing:
>> >> > QtGui.qApp.processEvents()
>> >> >
>> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> >> > still
>> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> >> > 2.1.14
>> >> > release for my python distribution on this machine.  Could this line
>> >> > be
>> >> > added back?
>> >>
>> >> Unfortunately, no, that line can not be added back in. When that line
>> >> is in place, the backend attempts to process queued events before it
>> >> is finished processing the current event. It was leading to segfaults
>> >> in some cases. processEvents should not be called in the middle of
>> >> processing an event.
>> >>
>> >> I tested the responsiveness of panning and zooming with and without
>> >> that call to processEvents, on Linux and windows and it looked fine.
>> >> Maybe its an issue related to a specific Qt version on windows. Things
>> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>> >>
>> >> Darren
>> >
>> >
>>
>>
>>
>> --
>> "In our description of nature, the purpose is not to disclose the real
>> essence of the phenomena but only to track down, so far as it is
>> possible, relations between the manifold aspects of our experience" -
>> Niels Bohr
>>
>> "It is a bad habit of physicists to take their most successful
>> abstractions to be real properties of our world." - N. David Mermin
>>
>> "Once we have granted that any physical theory is essentially only a
>> model for the world of experience, we must renounce all hope of
>> finding anything like the correct theory ... simply because the
>> totality of experience is never accessible to us." - Hugh Everett III
>
>



-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is
possible, relations between the manifold aspects of our experience" -
Niels Bohr

"It is a bad habit of physicists to take their most successful
abstractions to be real properties of our world." - N. David Mermin

"Once we have granted that any physical theory is essentially only a
model for the world of experience, we must renounce all hope of
finding anything like the correct theory ... simply because the
totality of experience is never accessible to us." - Hugh Everett III

I should mention that the latest test was on a windows 32 bit xp box.

On Mon, Aug 31, 2009 at 11:51 AM, william ratcliff <
wil...@gm...> wrote:

> Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> and things are more responsive...However, the difference between having that
> line in and taking it out are the difference between having pan/zoom events
> being extremely responsive and having an extremely noticeable lag.  I've
> attached a test file from the web which is rather simple.  You can notice
> the lag if you either try to pan/zoom using the toolbar, or if you try to
> use the slider to change the sizes of the horizontal bars.
>
> Sigh, upgrading everything to 2.6 is going to be a chore...
>
>
> Thanks,
> William
>
>
> On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...> wrote:
>
>> I've been using 2.6. It should be fine on windows now, but I can't
>> attest to it since I only use windows when I have to test and make
>> windows installers.
>>
>> On Mon, Aug 31, 2009 at 10:02 AM, william
>> ratcliff<wil...@gm...> wrote:
>> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
>> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
>> 2.5
>> > and am wondering if anyone has noticed any difficulties with 2.6).
>> >
>> > Cheers,
>> > Wiliam
>> >
>> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...>
>> wrote:
>> >>
>> >> Hi William,
>> >>
>> >> On Mon, Aug 31, 2009 at 8:25 AM, william
>> >> ratcliff<wil...@gm...> wrote:
>> >> > Hi!  I just installed matplotlib version .99 (windows vista,
>> python25,
>> >> > 32bit) and found that
>> >> > this line was missing:
>> >> > QtGui.qApp.processEvents()
>> >> >
>> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> >> > still
>> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> >> > 2.1.14
>> >> > release for my python distribution on this machine.  Could this line
>> be
>> >> > added back?
>> >>
>> >> Unfortunately, no, that line can not be added back in. When that line
>> >> is in place, the backend attempts to process queued events before it
>> >> is finished processing the current event. It was leading to segfaults
>> >> in some cases. processEvents should not be called in the middle of
>> >> processing an event.
>> >>
>> >> I tested the responsiveness of panning and zooming with and without
>> >> that call to processEvents, on Linux and windows and it looked fine.
>> >> Maybe its an issue related to a specific Qt version on windows. Things
>> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>> >>
>> >> Darren
>> >
>> >
>>
>>
>>
>> --
>> "In our description of nature, the purpose is not to disclose the real
>> essence of the phenomena but only to track down, so far as it is
>> possible, relations between the manifold aspects of our experience" -
>> Niels Bohr
>>
>> "It is a bad habit of physicists to take their most successful
>> abstractions to be real properties of our world." - N. David Mermin
>>
>> "Once we have granted that any physical theory is essentially only a
>> model for the world of experience, we must renounce all hope of
>> finding anything like the correct theory ... simply because the
>> totality of experience is never accessible to us." - Hugh Everett III
>>
>
>

"""
This demo demonstrates how to embed a matplotlib (mpl) plot 
into a PyQt4 GUI application, including:

* Using the navigation toolbar
* Adding data to the plot
* Dynamically modifying the plot's properties
* Processing mpl events
* Saving the plot to a file from a menu

The main goal is to serve as a basis for developing rich PyQt GUI
applications featuring mpl plots (using the mpl OO API).

Eli Bendersky (el...@gm...)
License: this code is in the public domain
Last modified: 19.01.2009
"""
import sys, os, random
from PyQt4.QtCore import *
from PyQt4.QtGui import *

import matplotlib
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg as NavigationToolbar
from matplotlib.figure import Figure


class AppForm(QMainWindow):
    def __init__(self, parent=None):
        QMainWindow.__init__(self, parent)
        self.setWindowTitle('Demo: PyQt with matplotlib')

        self.create_menu()
        self.create_main_frame()
        self.create_status_bar()

        self.textbox.setText('1 2 3 4')
        self.on_draw()

    def save_plot(self):
        file_choices = "PNG (*.png)|*.png"
        
        path = unicode(QFileDialog.getSaveFileName(self, 
                        'Save file', '', 
                        file_choices))
        if path:
            self.canvas.print_figure(path, dpi=self.dpi)
            self.statusBar().showMessage('Saved to %s' % path, 2000)
    
    def on_about(self):
        msg = """ A demo of using PyQt with matplotlib:
        
         * Use the matplotlib navigation bar
         * Add values to the text box and press Enter (or click "Draw")
         * Show or hide the grid
         * Drag the slider to modify the width of the bars
         * Save the plot to a file using the File menu
         * Click on a bar to receive an informative message
        """
        QMessageBox.about(self, "About the demo", msg.strip())
    
    def on_pick(self, event):
        # The event received here is of the type
        # matplotlib.backend_bases.PickEvent
        #
        # It carries lots of information, of which we're using
        # only a small amount here.
        # 
        box_points = event.artist.get_bbox().get_points()
        msg = "You've clicked on a bar with coords:\n %s" % box_points
        
        QMessageBox.information(self, "Click!", msg)
    
    def on_draw(self):
        """ Redraws the figure
        """
        str = unicode(self.textbox.text())
        self.data = map(int, str.split())
        
        x = range(len(self.data))

        # clear the axes and redraw the plot anew
        #
        self.axes.clear()        
        self.axes.grid(self.grid_cb.isChecked())
        
        self.axes.bar(
            left=x, 
            height=self.data, 
            width=self.slider.value() / 100.0, 
            align='center', 
            alpha=0.44,
            picker=5)
        
        self.canvas.draw()
    
    def create_main_frame(self):
        self.main_frame = QWidget()
        
        # Create the mpl Figure and FigCanvas objects. 
        # 5x4 inches, 100 dots-per-inch
        #
        self.dpi = 100
        self.fig = Figure((5.0, 4.0), dpi=self.dpi)
        self.canvas = FigureCanvas(self.fig)
        self.canvas.setParent(self.main_frame)
        
        # Since we have only one plot, we can use add_axes 
        # instead of add_subplot, but then the subplot
        # configuration tool in the navigation toolbar wouldn't
        # work.
        #
        self.axes = self.fig.add_subplot(111)
        
        # Bind the 'pick' event for clicking on one of the bars
        #
        self.canvas.mpl_connect('pick_event', self.on_pick)
        
        # Create the navigation toolbar, tied to the canvas
        #
        self.mpl_toolbar = NavigationToolbar(self.canvas, self.main_frame)
        
        # Other GUI controls
        # 
        self.textbox = QLineEdit()
        self.textbox.setMinimumWidth(200)
        self.connect(self.textbox, SIGNAL('editingFinished ()'), self.on_draw)
        
        self.draw_button = QPushButton("&Draw")
        self.connect(self.draw_button, SIGNAL('clicked()'), self.on_draw)
        
        self.grid_cb = QCheckBox("Show &Grid")
        self.grid_cb.setChecked(False)
        self.connect(self.grid_cb, SIGNAL('stateChanged(int)'), self.on_draw)
        
        slider_label = QLabel('Bar width (%):')
        self.slider = QSlider(Qt.Horizontal)
        self.slider.setRange(1, 100)
        self.slider.setValue(20)
        self.slider.setTracking(True)
        self.slider.setTickPosition(QSlider.TicksBothSides)
        self.connect(self.slider, SIGNAL('valueChanged(int)'), self.on_draw)
        
        #
        # Layout with box sizers
        # 
        hbox = QHBoxLayout()
        
        for w in [  self.textbox, self.draw_button, self.grid_cb,
                    slider_label, self.slider]:
            hbox.addWidget(w)
            hbox.setAlignment(w, Qt.AlignVCenter)
        
        vbox = QVBoxLayout()
        vbox.addWidget(self.canvas)
        vbox.addWidget(self.mpl_toolbar)
        vbox.addLayout(hbox)
        
        self.main_frame.setLayout(vbox)
        self.setCentralWidget(self.main_frame)
    
    def create_status_bar(self):
        self.status_text = QLabel("This is a demo")
        self.statusBar().addWidget(self.status_text, 1)
        
    def create_menu(self):        
        self.file_menu = self.menuBar().addMenu("&File")
        
        load_file_action = self.create_action("&Save plot",
            shortcut="Ctrl+S", slot=self.save_plot, 
            tip="Save the plot")
        quit_action = self.create_action("&Quit", slot=self.close, 
            shortcut="Ctrl+Q", tip="Close the application")
        
        self.add_actions(self.file_menu, 
            (load_file_action, None, quit_action))
        
        self.help_menu = self.menuBar().addMenu("&Help")
        about_action = self.create_action("&About", 
            shortcut='F1', slot=self.on_about, 
            tip='About the demo')
        
        self.add_actions(self.help_menu, (about_action,))

    def add_actions(self, target, actions):
        for action in actions:
            if action is None:
                target.addSeparator()
            else:
                target.addAction(action)

    def create_action(  self, text, slot=None, shortcut=None, 
                        icon=None, tip=None, checkable=False, 
                        signal="triggered()"):
        action = QAction(text, self)
        if icon is not None:
            action.setIcon(QIcon(":/%s.png" % icon))
        if shortcut is not None:
            action.setShortcut(shortcut)
        if tip is not None:
            action.setToolTip(tip)
            action.setStatusTip(tip)
        if slot is not None:
            self.connect(action, SIGNAL(signal), slot)
        if checkable:
            action.setCheckable(True)
        return action


def main():
    app = QApplication(sys.argv)
    form = AppForm()
    form.show()
    app.exec_()


if __name__ == "__main__":
    main()

I've been using 2.6. It should be fine on windows now, but I can't
attest to it since I only use windows when I have to test and make
windows installers.

On Mon, Aug 31, 2009 at 10:02 AM, william
ratcliff<wil...@gm...> wrote:
> Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
> bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5
> and am wondering if anyone has noticed any difficulties with 2.6).
>
> Cheers,
> Wiliam
>
> On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote:
>>
>> Hi William,
>>
>> On Mon, Aug 31, 2009 at 8:25 AM, william
>> ratcliff<wil...@gm...> wrote:
>> > Hi!  I just installed matplotlib version .99 (windows vista, python25,
>> > 32bit) and found that
>> > this line was missing:
>> > QtGui.qApp.processEvents()
>> >
>> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> > still
>> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> > 2.1.14
>> > release for my python distribution on this machine.  Could this line be
>> > added back?
>>
>> Unfortunately, no, that line can not be added back in. When that line
>> is in place, the backend attempts to process queued events before it
>> is finished processing the current event. It was leading to segfaults
>> in some cases. processEvents should not be called in the middle of
>> processing an event.
>>
>> I tested the responsiveness of panning and zooming with and without
>> that call to processEvents, on Linux and windows and it looked fine.
>> Maybe its an issue related to a specific Qt version on windows. Things
>> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>>
>> Darren
>
>



-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is
possible, relations between the manifold aspects of our experience" -
Niels Bohr

"It is a bad habit of physicists to take their most successful
abstractions to be real properties of our world." - N. David Mermin

"Once we have granted that any physical theory is essentially only a
model for the world of experience, we must renounce all hope of
finding anything like the correct theory ... simply because the
totality of experience is never accessible to us." - Hugh Everett III

Michael Droettboom wrote:
> You can also turn hinting off at runtime by passing a flag to freetype.  
> matplotlib currently exposes this flag in the FT2Font extension, but we 
> don't really expose the option to the user.  It would be simple enough 
> to make it an rcParam, though, which could then be set to "no hinting" 
> by the test infrastructure just to rule out some of these moving parts.  
> Of course, this doesn't rule out differences between different version 
> numbers of freetype.
>   
I think that, for now, we're going have the buildslaves run the same
version of freetype and have hinting disabled at freetype compile time.
(Right now we're at freetype 2.3.5.) If you want to go ahead and add a
"disable hinting" rcParam, it may come in handy in the future, but I
don't think it's a high priority right now given that we have to ensure
freetype version and thus will probably be compiling by hand it for any
buildslave.
> Another thing to look into might be some sort of fuzzy or perceptual 
> diffing approach.  Freddie Witheren (our GSoC student) has been looking 
> into pdiff (http://pdiff.sf.net) for testing mathtex.  I don't know what 
> the current status of that is.  In general, I think I prefer the goal of 
> exact determinism, but if this becomes a recurring problem down the 
> road, it may be easier to just try to "gloss over" these minor font 
> differences.
>   
The image difference approach we're currently using doesn't search for
an exact duplication but just that the error is under some threshold. I
haven't looked at the algorithm, but the printout says "RMS error". Now
that all the tests are passing, I'm going to direct my energies to
expanding the test infrastructure, especially making it easy for other
devs to write tests.

We may have to revisit these issues if, once we get a greater diversity,
the buildslaves start failing again.

-Andrew

I think I agree that the rounding is necessary for raster backends, but 
is in the wrong place -- it should be in the backend itself.

It's needed for Agg to prevent "gaps" between the image and axes 
rectangle.  The axes rectangle is always drawn pixel-aligned using 
"round", so if the image is drawn by truncation to integers, there will 
be small gaps for certain values.  But yes, it makes sense to *not* do 
any rounding or truncation in the vector backends.

I'll commit something for this -- on the trunk, because it feels a bit 
too pervasive for the branch.

Mike

Jouni K. Seppänen wrote:
> Hi,
>
> Mike Fitzgerald reported bug #2832896 and has been investigating its
> causes:
>
> https://sourceforge.net/tracker/?func=detail&aid=2832896&group_id=80706&atid=560720
>
> The problem is that images are not drawn at exactly the same coordinates
> as other artists, so markers drawn on top of images are slightly off in
> pdf and eps output. Apparently this can be fixed, at least to some
> degree, by removing the round(...) operations from
>
>     renderer.draw_image(gc, round(l), round(b), im)
>
> in _AxesImageBase.draw and making a slightly more involved change in
> AxesImage.make_image (the details are in the bug report). I haven't had
> time to investigate what this does to other backends, but I imagine the
> rounding would be necessary for raster backends.
>
> Can someone who is more familiar with the image machinery comment on the
> matter? Do we need some kind of vector/raster indication in the backends,
> in addition to the get_image_magnification method?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

You can also turn hinting off at runtime by passing a flag to freetype.  
matplotlib currently exposes this flag in the FT2Font extension, but we 
don't really expose the option to the user.  It would be simple enough 
to make it an rcParam, though, which could then be set to "no hinting" 
by the test infrastructure just to rule out some of these moving parts.  
Of course, this doesn't rule out differences between different version 
numbers of freetype.

Another thing to look into might be some sort of fuzzy or perceptual 
diffing approach.  Freddie Witheren (our GSoC student) has been looking 
into pdiff (http://pdiff.sf.net) for testing mathtex.  I don't know what 
the current status of that is.  In general, I think I prefer the goal of 
exact determinism, but if this becomes a recurring problem down the 
road, it may be easier to just try to "gloss over" these minor font 
differences.

Mike

John Hunter wrote:
> On Sun, Aug 30, 2009 at 5:47 PM, Andrew Straw<str...@as...> wrote:
>   
>> John Hunter wrote:
>>     
>>> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
>>>       
>>>> According to RobK, you can reconfigure your ubuntu system to turn
>>>> these off.  He suggests:
>>>>
>>>>  To use autohinting, use the hint in this post, or just run the
>>>> following command:
>>>>
>>>>  sudo dpkg-reconfigure fontconfig-config
>>>>
>>>>  then choose “autohinter”, then choose “always”, then choose “no”
>>>>         
>>> If that doesn't work, this guy has more involved instructions on how
>>> to rebuild ubuntu libfreetype and disable the bytecode patch
>>>
>>> http://ubuntuforums.org/showthread.php?t=84359
>>>       
>> OK, I disabled all Ubuntu patches to libfreetype and recompiled and
>> re-installed it. Unfortunately, I'm still getting the same failures.
>>
>> Then I additionally installed fontconfig-config and did the
>> dpkg-reconfigure fontconfig-config step, setting everything to "Never".
>> Same failures.
>>
>> These font errors make me unhappy. I think we should test some very
>> simple pure libfreetype C program outputs generated on the various
>> machines. I've just been playing with ftview, but that doesn't seem to
>> have a command-line interface to save directly to a file.
>>     
>
> Attached is "example1.c" from the freetype tutorial.  When I wrote
> ft2font, I started with this tutorial and built around it, so some of
> the core logic is the same.  A lot has been added since then,
> including a lot of stuff Michael has added to improve hinting, so we
> may not see any differences at this level.  The program outputs an
> ascii-art file to stdout, so we could start by checking the md5 on the
> output.  Since *most* of your unit tests agree with the baseline, we
> may struggle to find a difference.
>
> I compiled the example with
>
> gcc -I/Users/jdhunter/dev/include
> -I/Users/jdhunter/dev/include/freetype2 -L/Users/jdhunter/dev/lib -o
> example1 example1.c -lfreetype
>
> and ran it with
>
> ./example1 ~/mpl/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf "this is a
> test" > run.out
>
> my md5 on the output is
>
> home:~/tmp> md5 run.out
> MD5 (run.out) = 01868827436d858b4452ff03f80f7222
>
> The example and output are attached -- we could easily replace the
> example "show_image" with a binary output file that we could read into
> numpy arrays to diff or display with imshow.
>
> I'm available to skype if you want to brainstorm this.
>
> JDH
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william
ratcliff<wil...@gm...> wrote:
> Hi!  I just installed matplotlib version .99 (windows vista, python25,
> 32bit) and found that
> this line was missing:
> QtGui.qApp.processEvents()
>
> Adding it sped the QT4Agg backend back to reasonable speeds--but it still
> seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
> release for my python distribution on this machine.  Could this line be
> added back?

Unfortunately, no, that line can not be added back in. When that line
is in place, the backend attempts to process queued events before it
is finished processing the current event. It was leading to segfaults
in some cases. processEvents should not be called in the middle of
processing an event.

I tested the responsiveness of panning and zooming with and without
that call to processEvents, on Linux and windows and it looked fine.
Maybe its an issue related to a specific Qt version on windows. Things
looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.

Darren

Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5
and am wondering if anyone has noticed any difficulties with 2.6).

Cheers,
Wiliam

On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote:

> Hi William,
>
> On Mon, Aug 31, 2009 at 8:25 AM, william
> ratcliff<wil...@gm...> wrote:
> > Hi!  I just installed matplotlib version .99 (windows vista, python25,
> > 32bit) and found that
> > this line was missing:
> > QtGui.qApp.processEvents()
> >
> > Adding it sped the QT4Agg backend back to reasonable speeds--but it still
> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
> > release for my python distribution on this machine.  Could this line be
> > added back?
>
> Unfortunately, no, that line can not be added back in. When that line
> is in place, the backend attempts to process queued events before it
> is finished processing the current event. It was leading to segfaults
> in some cases. processEvents should not be called in the middle of
> processing an event.
>
> I tested the responsiveness of panning and zooming with and without
> that call to processEvents, on Linux and windows and it looked fine.
> Maybe its an issue related to a specific Qt version on windows. Things
> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>
> Darren
>

I've been bitten by this before, too.

The current implementation of "make.py clean" is probably a remnant of 
an earlier iteration of the doc build system that really did scatter 
files all over the place.  I made some changes a few months ago to try 
to restrict "built" files to the build and examples directories.  I can 
go ahead and fix "clean" to just be a couple of "removedirs".  But I'll 
wait a day or so just to see if anyone can think of a good reason not to.

Mike

Jouni K. Seppänen wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
>
>   
>>> The current interface looks easy enough to use -- it just needs to be
>>> advertised better, eg in a FAQ ( I had to read the source to find it,
>>> which works well enough for me, but not for everyone).  If you want to
>>> write one up, I'll add it to the docs.
>>>       
>> I seem to recall that the ReST docstring of backend_pdf.PdfPages was
>> included in the documentation at some point, but it is missing now from
>> <http://matplotlib.sourceforge.net/api/index_backend_api.html>. 
>>     
>
> I added some documentation again. Here's what I think probably happened
> the previous time: I added doc/api/backend_pdf_api.rst and edited
> doc/api/index_backend_api.rst, built the documentation locally to check
> that it looks OK, then at some point ran "make.html clean" to debug some
> doc problems... which destroyed my uncommitted doc changes by running
> svn-clean.
>
> How about changing "make.html clean" to be more careful? After building
> the docs, "svn status" shows the following unversioned files:
>
> ?       build
> ?       examples
> ?       _static/matplotlibrc
> ?       _templates/gallery.html
>
> "svn status --no-ignore" adds a lot of *.pyc files in various
> subdirectories. Would removing all of these achieve the expected
> cleaning effect?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi!  I just installed matplotlib version .99 (windows vista, python25,
32bit) and found that
this line was missing:
QtGui.qApp.processEvents()

Adding it sped the QT4Agg backend back to reasonable speeds--but it still
seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
release for my python distribution on this machine.  Could this line be
added back?

Cheers,
William


On Tue, Aug 19, 2008 at 4:58 AM, Pierre Raybaut <co...@py...>wrote:

> Hi Darren,
>
> 2008/8/18 Darren Dale <dsd...@gm...>:
> > Nevermind. It turns out its not exactly poor performance, but for some
> reason
> > the gui events were not getting processed as frequently on windows. Maybe
> Qt
> > changed something in an attempt to optimize performance.
> >
> > I applied a patch in svn 6043, but its a really simple fix. At the end of
> > backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this
> line:
> >
> >        QtGui.qApp.processEvents()
> >
> > It seemed to improve things on my windows laptop,  but let me know if it
> fixes
> > the problem for you.
>
> Good work Darren, thanks, it works perfectly!
> That is great news because I found (and reported) this bug three
> months ago, so I was beginning to worry about the future of Qt4
> backend.
> Now I can consider updating PyQt in Python(x,y).
>
> > I forgot to mention, the svg icons display fine for me with windows xp,
> > matplotlib-0.98.
>
> Forget about it, I've just found out that this is related to one of my
> own-made packages.
>
> Thanks
> Pierre
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,

Mike Fitzgerald reported bug #2832896 and has been investigating its
causes:

https://sourceforge.net/tracker/?func=detail&aid=2832896&group_id=80706&atid=560720

The problem is that images are not drawn at exactly the same coordinates
as other artists, so markers drawn on top of images are slightly off in
pdf and eps output. Apparently this can be fixed, at least to some
degree, by removing the round(...) operations from

    renderer.draw_image(gc, round(l), round(b), im)

in _AxesImageBase.draw and making a slightly more involved change in
AxesImage.make_image (the details are in the bug report). I haven't had
time to investigate what this does to other backends, but I imagine the
rounding would be necessary for raster backends.

Can someone who is more familiar with the image machinery comment on the
matter? Do we need some kind of vector/raster indication in the backends,
in addition to the get_image_magnification method?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew and I just spent a couple of hours on the phone trying to
reconcile our freetype rendering discrepancies, and after much tedious
poor-man's debugging, we finally figured out what was wrong.  We
thought we were using the same version of freetype but were not.  The
fault was mine: I configured my buildbot to recognize the right
version of freetype at buildtime but not runtime.  We've fixed this,
we now both run the same version of freetype, and we are getting
identical mpl images.  We are very excited by the sea of green at

  http://mpl-buildbot.code.astraw.com/waterfall

Now that we have two bots passing the regression tests, we have big plans:

  * enable buildbots for more platforms (solaris and win32, we already
have osx and linux)

  * enable buildbots for all supported versions of python (2.4, 2.5 and 2.6)

  * make the unit testing infrastructure in the "test" dir easier to
use and extend, so it becomes trivial to drop in a new test (and then
drop in a lot of tests)

  * enable tarballs and platform specific binary installers from the
buildbots which upload to a nightly directory that users can grab
stuff from

  * send out emails on any buildbot failures to the
matplotlib-buildbot mailing list

In preparation for the last point, I have created

  https://lists.sourceforge.net/lists/listinfo/matplotlib-buildbot

so subscribe if you are interested in getting notices of failures.
Andrew is taking a break before he configures the bot to email on
failures, but he'll probably have it activated soon.  We'll probably
force a failure by uploading a bad image as a baseline to debug the
email script, so there may be some false negatives coming out on the
list over the next day or two, but once we have everything working the
list should accurately reflect unit test failures.

Thanks to Andrew for pushing this through.  It's a big step forward to
go from the poor-man's unit testing that we have in backend_driver to
a real framework doing image diffs across platforms triggered by svn
commits.

JDH

On Sun, Aug 30, 2009 at 5:47 PM, Andrew Straw<str...@as...> wrote:
> John Hunter wrote:
>> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
>>> According to RobK, you can reconfigure your ubuntu system to turn
>>> these off.  He suggests:
>>>
>>>  To use autohinting, use the hint in this post, or just run the
>>> following command:
>>>
>>>  sudo dpkg-reconfigure fontconfig-config
>>>
>>>  then choose “autohinter”, then choose “always”, then choose “no”
>>
>> If that doesn't work, this guy has more involved instructions on how
>> to rebuild ubuntu libfreetype and disable the bytecode patch
>>
>> http://ubuntuforums.org/showthread.php?t=84359
>
> OK, I disabled all Ubuntu patches to libfreetype and recompiled and
> re-installed it. Unfortunately, I'm still getting the same failures.
>
> Then I additionally installed fontconfig-config and did the
> dpkg-reconfigure fontconfig-config step, setting everything to "Never".
> Same failures.
>
> These font errors make me unhappy. I think we should test some very
> simple pure libfreetype C program outputs generated on the various
> machines. I've just been playing with ftview, but that doesn't seem to
> have a command-line interface to save directly to a file.

Attached is "example1.c" from the freetype tutorial.  When I wrote
ft2font, I started with this tutorial and built around it, so some of
the core logic is the same.  A lot has been added since then,
including a lot of stuff Michael has added to improve hinting, so we
may not see any differences at this level.  The program outputs an
ascii-art file to stdout, so we could start by checking the md5 on the
output.  Since *most* of your unit tests agree with the baseline, we
may struggle to find a difference.

I compiled the example with

gcc -I/Users/jdhunter/dev/include
-I/Users/jdhunter/dev/include/freetype2 -L/Users/jdhunter/dev/lib -o
example1 example1.c -lfreetype

and ran it with

./example1 ~/mpl/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf "this is a
test" > run.out

my md5 on the output is

home:~/tmp> md5 run.out
MD5 (run.out) = 01868827436d858b4452ff03f80f7222

The example and output are attached -- we could easily replace the
example "show_image" with a binary output file that we could read into
numpy arrays to diff or display with imshow.

I'm available to skype if you want to brainstorm this.

JDH

Reinier Heeres wrote:
> Eric, all,
> 
> Here's the latest version of my color map patch. I deferred your
> suggestion #4; perhaps we can fix that later.
> 
> Please let me know what you think; if everybody is ok with it I'll
> push to trunk.
> 
> Regards,
> Reinier

Looks good.  I haven't tested it--I trust you have taken care of that. I 
suggest one tiny change, then go ahead and commit:

In your change to cm.py, instead of importing and using the copy module, 
just do this:

+        datad[cmapname] = list(cmapspec)
+        datad[cmapname_r] = list(cmapspec)
+        datad[cmapname_r].reverse()

Simpler, more readable, possibly faster (not that speed matters here).

Thanks again.

Eric

John Hunter wrote:
> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
>> According to RobK, you can reconfigure your ubuntu system to turn
>> these off.  He suggests:
>>
>>  To use autohinting, use the hint in this post, or just run the
>> following command:
>>
>>  sudo dpkg-reconfigure fontconfig-config
>>
>>  then choose “autohinter”, then choose “always”, then choose “no”
> 
> If that doesn't work, this guy has more involved instructions on how
> to rebuild ubuntu libfreetype and disable the bytecode patch
> 
> http://ubuntuforums.org/showthread.php?t=84359

OK, I disabled all Ubuntu patches to libfreetype and recompiled and
re-installed it. Unfortunately, I'm still getting the same failures.

Then I additionally installed fontconfig-config and did the
dpkg-reconfigure fontconfig-config step, setting everything to "Never".
Same failures.

These font errors make me unhappy. I think we should test some very
simple pure libfreetype C program outputs generated on the various
machines. I've just been playing with ftview, but that doesn't seem to
have a command-line interface to save directly to a file.

-Andrew

John Hunter wrote:
> On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:
> 
>> OK, I figured this out.  The new failure was on formatter4, not
>> formatter5.  I didn't see that when I posted earlier.  It turns out
>> when we were working at scipy and I wrote that script to move new
>> saved-results into baseline, I inadvertently moved a bad formatter4
>> image into the baseline, so the baseline image was broken.  When I
>> fixed the bug, the unit test caught the difference.  I've updated the
>> baseline so now everything should be good for that particular test.
> 
> The empty_datetime continues to mystefy me.  The actual had ticks from
> 1..23 and the baseline had ticks from 2..00.  The current behavior on
> my box is 1..23 and that seems fine to me, so I re-updated the
> baseline with that file.  I'm attaching the actual and baseline from
> the last buildbot before my update.  The sage box *should* pass on the
> next build test because I've corrected the two known failures.  If
> there is anything I am missing about this empty datetime test, let me
> know

So it sounds like there have been three different behaviors: 0 to 24, 1 
to 23, and 2 to 24.  I think what we are seeing here is differences in 
floating point behavior among different platforms, and/or differences in 
datetime implementation from one python version to another.  The 
standard python library datetime is being used to generate the floating 
point xlim in days.  It looks like (2009, 1, 20) and (2009, 1, 21) can 
end up as floating point numbers a hair above or a hair below the target 
integers, and that difference of a hair is enough to determine whether a 
tick is generated or not.

A side point here is that the precision of the floating point numbers is 
lousy for most applications, because of the choice of "year 1" as the 
origin.  This is a case of mpl following a bad choice by Matlab.

One way to get around the first problem--the datetime tick dependence on 
platform--would be to put fudge factors into the autoscaling so that the 
limits would be expanded some small amount.  More generally, the 
autoscaling could have margins, which might default to the tiny amount 
necessary to prevent the datetime indeterminacy, but might be put to 
other good uses by the user.  Often one really wants the  xlim and ylim 
to be a little wider than the data range, so that symbols are plotted 
entirely within the axes, for example.  This was suggested a very long 
time ago, and it has resurfaced many times in my mind, but obviously I 
never did anything about it.

Eric

On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
> According to RobK, you can reconfigure your ubuntu system to turn
> these off.  He suggests:
>
>  To use autohinting, use the hint in this post, or just run the
> following command:
>
>  sudo dpkg-reconfigure fontconfig-config
>
>  then choose “autohinter”, then choose “always”, then choose “no”

If that doesn't work, this guy has more involved instructions on how
to rebuild ubuntu libfreetype and disable the bytecode patch

http://ubuntuforums.org/showthread.php?t=84359

JDH

Andrew, I think I may have a clue how to fix the font discrepancies.

Apple owns patents on some a byte code interpreter for hinting truetype fonts:

  http://freetype.sourceforge.net/patents.html

and freetype can be built with the patented stuff turned on but the
default is off -- freetype has non-patented auto-hinting which is what
is used by default.  However, according to a thread I found here (see
the first post by RobK) ubuntu hardy heron, which is what you are
using on the buildbot, has the patented stuff *turned on* by default:

  http://www.howtogeek.com/howto/ubuntu/enable-smooth-fonts-on-ubuntu-linux/

According to RobK, you can reconfigure your ubuntu system to turn
these off.  He suggests:

  To use autohinting, use the hint in this post, or just run the
following command:

  sudo dpkg-reconfigure fontconfig-config

  then choose “autohinter”, then choose “always”, then choose “no”

Give it a test and hopefully we will see both bots go green.

Then we can focus on more tests and nightly builds...

JDH

Eric, all,

Here's the latest version of my color map patch. I deferred your
suggestion #4; perhaps we can fix that later.

Please let me know what you think; if everybody is ok with it I'll
push to trunk.

Regards,
Reinier

On Sun, Aug 16, 2009 at 9:40 PM, Eric Firing<ef...@ha...> wrote:
> Reinier Heeres wrote:
>>
>> Hi Eric, all,
>>
>> I've attached a new patch where I also allow two extra ways to define
>> color maps:
>> - by specifying (value, color) pairs, giving a linearly interpolated map.
>> - by specifying functions (gnuplot default functions are included)
>>
>> I've added a few colormaps: afmhot, bwr, brg, gnuplot, gnuplot2,
>> ocean, rainbow, seismic, terrain
>>
>> I refactored a few others: flag, prism, gist_gray, gist_heat,
>> gist_rainbow, gist_stern, gist_yarg. This saves about ~3000 lines...
>> (And the differences are very minor)
>>
>> You can compare them with the old scales by running
>> examples/pylab_examples/show_colormaps.py both with and without the
>> attached patch.
>>
>> What do you think? If it's ok, shall I push to trunk or v99?
>
> Reinier,
>
> First, this is a feature, not a bugfix, so it should go to the trunk.
>
> Second, before it goes, I have some suggestions:
>
> 1) Avoid using the types module; it is too specific, too restrictive. e.g.
> instead of
>
> +        if type(val) is types.FunctionType:
>
> use
>        if callable(val):
>
> instead of
>
> +    if type(datad[cmapname]) is types.DictType:
>
> you might use
>    cmapspec = datad[cmapname]
>    if 'red' in cmapspec:
>        ....
>    else:
>        ....
>
> In each case, you may need to think about what kinds of arguments might be
> encountered, and what is the simplest and safest way to sort them out.
>
>
> 2) Related to the above, we really don't want to make distinctions among
> types of sequences unless there is no alternative--it is too confusing for
> users to remember that this has to be a tuple but that has to be a list, and
> the other thing has to be an ndarray.  (Such distinctions in numpy's
> indexing rules make the indexing very flexible and powerful--but it is also
> very hard to remember exactly what those rules are.  For numpy indexing,
> there was probably no alternative; for us there is.)
>
> 3) This statement from LinearSegmentedColormap.from_list
>
>        if len(colors[0]) == 2:
>
> will fail with valid inputs, e.g. ['.2', 'r'] (recall that '.2' is a
> specification for gray on a 0-1 scale.)
>
> What might work for parsing the colors argument is to take advantage of
> numpy's ability to figure out the dimensions of a possibly nested sequence:
>
>    colors = np.asarray(colors)
>    if colors.ndim == 2:
>        ...
>    else:  # assume it is 1-D, colors only
>        ...
>
> Turning arguments into ndarrays often simplifies the rest of the code, so
> long as one does not need to change the dimensions subsequently--lists are
> great for appending, deleting, etc.  Sequence operations with ndarrays may
> be slower than using lists, tuples, and zip, but this doesn't matter at all
> in this part of the code.
>
> 4) This point could be considered now, or deferred: I originally tacked on
> the from_list method.  It might make sense to deprecate it, and simply fold
> the logic into the __init__ method.  One might want to keep the logic broken
> out into a method, and call that method to process the segmentdata argument.
>  (The code in __init__ methods sometimes gets long and hard to follow;
> readability can be improved by separating parts out into methods, often
> private ones, and calling those in __init__.)
>
> 5) In _cm.py, if the maps you condensed are already identified in comments
> as to their sources, then you should add to those comments a note on how you
> modified them.
>
> Thank you for your work on this.
>
> Eric
>
>
>>
>> Regards,
>> Reinier
>>
>> On Thu, Aug 13, 2009 at 1:16 AM, Eric Firing<ef...@ha...> wrote:
>>>
>>> Reinier Heeres wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I would like to propose the attached patch to be able to use a gamma
>>>> value for color maps. This will make it simple to make your color
>>>> scale more 'sensitive' at the bottom or at the top, as can be seen in
>>>> the attached example. This could in principle also be solved by adding
>>>> a gamma normalizer, but I think that applying it to a color map is
>>>> quite coming practice, so in this case the preferred way.
>>>
>>> Your patch looks reasonable to me.
>>>>
>>>> I'd also like to add a few extra color maps (at least one plain
>>>> blue-white-red and one with darker shades at the high and low ends, as
>>>
>>> Good.
>>>
>>>> in the attachment). I also remember a particular one ('terrain') in a
>>>> measurement program called 'Igor' that would be nice.
>>>
>>> Is there any potential licensing problem?  I hope not.  I presume you
>>> would
>>> copy the effect, not any particular set of numbers extracted from Igor.
>>>
>>>> Looking at _cm.py, I would guess that could be done a bit more
>>>> efficient than the current 5880 lines as well by just specifying a few
>>>> colors and using LinearSegmentedColormap.from_list(). Is it ok if I
>>>> try to refactor that?
>>>
>>> You mean take the colormaps that have a huge number of color dictionary
>>> entries in _cm.py, and subsample them down to something reasonable?
>>> Please
>>> do!  I always hated those blocks of numbers, but never enough to motivate
>>> me
>>> to do something about them other than a little reformatting.
>>>
>>> It sounds like you are talking about going farther than that, which might
>>> be
>>> fine but might make things more complicated.  As it is now, all the
>>> built-in
>>> colormaps are associated with color dictionaries for direct use in
>>> LinearSegmentedColormap.  If you make two styles, one based on the
>>> dictionaries (which allows discontinuities) and one based on from_list
>>> (which does not), then you need to keep track of which is which.  Is it
>>> worth it?  I am inclined to stick with the cdict approach.
>>>
>>> It looks like an obvious addition would a function that takes a list of
>>> breakpoints (starting with 0 and ending with 1) and a matching list of
>>> colors and generates the corresponding cdict for continuous mapping.
>>>
>>> Eric
>>>
>>>> Let me know what you think.
>>>>
>>>> Cheers,
>>
>>
>
>



-- 
Reinier Heeres
Tel: +31 6 10852639

On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:

> OK, I figured this out.  The new failure was on formatter4, not
> formatter5.  I didn't see that when I posted earlier.  It turns out
> when we were working at scipy and I wrote that script to move new
> saved-results into baseline, I inadvertently moved a bad formatter4
> image into the baseline, so the baseline image was broken.  When I
> fixed the bug, the unit test caught the difference.  I've updated the
> baseline so now everything should be good for that particular test.

The empty_datetime continues to mystefy me.  The actual had ticks from
1..23 and the baseline had ticks from 2..00.  The current behavior on
my box is 1..23 and that seems fine to me, so I re-updated the
baseline with that file.  I'm attaching the actual and baseline from
the last buildbot before my update.  The sage box *should* pass on the
next build test because I've corrected the two known failures.  If
there is anything I am missing about this empty datetime test, let me
know