Re: [matplotlib-devel] tk backend broken (somehow?)

2014-11-20 Thread Eric Firing 
On 2014/11/18, 9:55 PM, Benjamin Root wrote:
> Why do we have a function in setupext.py called
> "hardcoded_tcl_config()"? In any case, it looks like all I needed to do
> was change the default value for line 156 to be the prefix location of
> my miniconda install, and things started to work again!
>
> Perhaps we need to take another look through setupext.py, and try to get
> it using prefixes more (or at least consolidate all of these hard-coded
> values into one place!)

Ben,

Good idea; perhaps you would like to turn it into a github issue to 
reduce the likelihood it is dropped.

Eric

>
> Cheers!
> Ben Root
>
>
> On Tue, Nov 18, 2014 at 12:06 PM, Benjamin Root  > wrote:
>
> Indeed, there are some oddities, but mostly with regards to Qt and
> forcing it to build and link against (presumedly) the conda package
> of it. There is a modification of the setupext.py that happens at
> build time to replace all instances of "/usr/local" with "$PREFIX".
> Perhaps what is happening is that my local builds of matplotlib is
> compiling and linking against my system install of the tk/tcl
> headers and libraries, and that might be conflicting with the
> conda-shipped tk/tcl packages?
>
> I'll have to experiment a bit more tonight. Thanks for the suggestion!
>
> Ben Root
>
> On Mon, Nov 17, 2014 at 11:07 PM, Thomas Caswell  > wrote:
>
> Have a look at the recipe in conda-rescipes for matplotlib, they
> might be doing some funny patching.
>
> On Mon, Nov 17, 2014, 22:48 Benjamin Root  > wrote:
>
> Ok, I am just really confused now. I have confirmed that
> using the matplotlib supplied by miniconda (v1.4.2) works
> just fine. Ripping that out and building version 1.4.2 from
> source results in the traceback. Same thing for v1.3.1. I
> have even tried checking out PR#3811 which addresses the
> weird constructor issues we found today, and I still get the
> segfault.
>
> Maybe I should try getting out of the conda environment
> entirely and try EPD instead to see if that makes a difference?
>
> Ben Root
>
> On Mon, Nov 17, 2014 at 5:17 AM, Phil Elson
> mailto:[email protected]>> wrote:
>
> Mike made some changes to this recently.
> https://github.com/matplotlib/matplotlib/pull/3778
>
> May be the cause.
>
> On 16 November 2014 18:12, Benjamin Root
> mailto:[email protected]>> wrote:
>
> And with my continuing saga of backend-specific
> things...
>
> I was using conda, but because it does not ship with
> pygtk support, I had to manually install pygtk into
> the conda environment and then install matplotlib
> from source. All that seemed to work fine when I
> worked on Wx and Gtk examples for my book.
>
> I went back to a (previously working) Tk example to
> polish it, and I get all sorts of errors now. I have
> tried multiple releases of matplotlib from source
> (doing a git clean -fxd between them), all with
> similar errors. In fact, with master, the error
> causes a segfault:
>
> ben@tigger:~/Documents/InteractiveMPL$ python
> chp5/slider_tk.py
> Exception in Tkinter callback
> Traceback (most recent call last):
>File
> "/home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py",
> line 1486, in __call__
>  return self.func(*args)
>File
> 
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 278, in resize
>  self.show()
>File
> 
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 350, in draw
>  tkagg.blit(self._tkphoto,
> self.renderer._renderer, colormode=2)
>File
> 
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py",
> line 30, in blit
>  id(data), colormode, id(bbox_array))
> TclError
> alloc: invalid block: 0x2cfe3b0: 0 0
> Aborted (core dumped)
>
>

Re: [matplotlib-devel] tk backend broken (somehow?)

2014-11-20 Thread Benjamin Root 
Good idea. I'll put together something tonight.

On Thu, Nov 20, 2014 at 2:44 PM, Eric Firing  wrote:

> On 2014/11/18, 9:55 PM, Benjamin Root wrote:
> > Why do we have a function in setupext.py called
> > "hardcoded_tcl_config()"? In any case, it looks like all I needed to do
> > was change the default value for line 156 to be the prefix location of
> > my miniconda install, and things started to work again!
> >
> > Perhaps we need to take another look through setupext.py, and try to get
> > it using prefixes more (or at least consolidate all of these hard-coded
> > values into one place!)
>
> Ben,
>
> Good idea; perhaps you would like to turn it into a github issue to
> reduce the likelihood it is dropped.
>
> Eric
>
> >
> > Cheers!
> > Ben Root
> >
> >
> > On Tue, Nov 18, 2014 at 12:06 PM, Benjamin Root  > > wrote:
> >
> > Indeed, there are some oddities, but mostly with regards to Qt and
> > forcing it to build and link against (presumedly) the conda package
> > of it. There is a modification of the setupext.py that happens at
> > build time to replace all instances of "/usr/local" with "$PREFIX".
> > Perhaps what is happening is that my local builds of matplotlib is
> > compiling and linking against my system install of the tk/tcl
> > headers and libraries, and that might be conflicting with the
> > conda-shipped tk/tcl packages?
> >
> > I'll have to experiment a bit more tonight. Thanks for the
> suggestion!
> >
> > Ben Root
> >
> > On Mon, Nov 17, 2014 at 11:07 PM, Thomas Caswell  > > wrote:
> >
> > Have a look at the recipe in conda-rescipes for matplotlib, they
> > might be doing some funny patching.
> >
> > On Mon, Nov 17, 2014, 22:48 Benjamin Root  > > wrote:
> >
> > Ok, I am just really confused now. I have confirmed that
> > using the matplotlib supplied by miniconda (v1.4.2) works
> > just fine. Ripping that out and building version 1.4.2 from
> > source results in the traceback. Same thing for v1.3.1. I
> > have even tried checking out PR#3811 which addresses the
> > weird constructor issues we found today, and I still get the
> > segfault.
> >
> > Maybe I should try getting out of the conda environment
> > entirely and try EPD instead to see if that makes a
> difference?
> >
> > Ben Root
> >
> > On Mon, Nov 17, 2014 at 5:17 AM, Phil Elson
> > mailto:[email protected]>> wrote:
> >
> > Mike made some changes to this recently.
> > https://github.com/matplotlib/matplotlib/pull/3778
> >
> > May be the cause.
> >
> > On 16 November 2014 18:12, Benjamin Root
> > mailto:[email protected]>> wrote:
> >
> > And with my continuing saga of backend-specific
> > things...
> >
> > I was using conda, but because it does not ship with
> > pygtk support, I had to manually install pygtk into
> > the conda environment and then install matplotlib
> > from source. All that seemed to work fine when I
> > worked on Wx and Gtk examples for my book.
> >
> > I went back to a (previously working) Tk example to
> > polish it, and I get all sorts of errors now. I have
> > tried multiple releases of matplotlib from source
> > (doing a git clean -fxd between them), all with
> > similar errors. In fact, with master, the error
> > causes a segfault:
> >
> > ben@tigger:~/Documents/InteractiveMPL$ python
> > chp5/slider_tk.py
> > Exception in Tkinter callback
> > Traceback (most recent call last):
> >File
> >
>  "/home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py",
> > line 1486, in __call__
> >  return self.func(*args)
> >File
> >
>  
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> > line 278, in resize
> >  self.show()
> >File
> >
>  
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> > line 350, in draw
> >  tkagg.blit(self._tkphoto,
> > self.renderer._renderer, colormode=2)
> >File
> >
>  
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py",
>