matplotlib-devel Mailing List for matplotlib (Page 3)

Should we still proceed with this now that numpy 1.1.0 is out?  Any holdups?

- Charlie

On Wed, May 7, 2008 at 11:07 AM, Jeff Whitaker <js...@fa...> wrote:
>
> What do people think of releasing 0.98 after numpy 1.1 is released this
> weekend?
>
> The main reason I'd like to do this (instead of releasing another
> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is
> installed as an egg basemap (or any other toolkit) cannot be installed.
>
> -Jeff
>
> --
> Jeffrey S. Whitaker         Phone  : (303)497-6313
> Meteorologist               FAX    : (303)497-6449
> NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
> 325 Broadway                Office : Skaggs Research Cntr 1D-124
> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I seem to have found a fix.  The key point was this comment in 
pprdrv_tt2.cpp:

        else            /* The tt spec. does not clearly indicate */
            {            /* whether these values are signed or not. */
              arg1 = *(signed char *)(glyph++);
              arg2 = *(signed char *)(glyph++);
        }

By adding the cast to (signed char *), things seem to work.  I guess 
that's what the spec does in practice!  This doesn't seem to break Latin 
compound glyphs that used to work (the only thing that has been 
extensively tested up until now), so I'm pretty confident that's the 
correct fix.  This has been fixed in SVN.  Please try with more Korean 
characters and let me know if you still see anything strange.

Cheers,
Mike

Michael Droettboom wrote:
> Correction -- no need to send the image.  You said png output was 
> correct, so I'll just compare against that.
>
> Michael Droettboom wrote:
>   
>> The code that generates the Type 3 fonts for us is fairly old (1995), 
>> and certainly predates the widespread adoption of Unicode, so I'm 
>> somewhat not surprised this doesn't work.  I'll have a brief look to see 
>> if there are any obvious fixes, but we're unlikely to implement a 
>> full-fledged Unicode rendering system (like Pango) any time soon.  Since 
>> I don't read Korean, can you provide an image file of what the resulting 
>> compound glyph is supposed to look like?
>>
>> As a workaround, you could try using the Cairo backend to generate 
>> Postscript and PDF.  It may do a better job.  You could also try other 
>> Korean fonts -- they may not use compound glyph composition.
>>  
>> Cheers,
>> Mike
>>
>> Jae-Joon Lee wrote:
>>   
>>     
>>> Hello,
>>>
>>> I wanted to render some Korean text in my matplotlib figure and this
>>> is how I did (with python2.5 and trunk version of matplotlib).
>>>
>>> # -*- coding: utf-8 -*-
>>> from pylab import *
>>>
>>> import matplotlib.font_manager as fm
>>> fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf", size=100)
>>>
>>> plot([1,2,3])
>>> text(1.,1.5, u'이', fontproperties=fp)
>>> savefig("test.eps")
>>> show()
>>>
>>>
>>> It works fine with GtkAgg (and saving to png file also).
>>> But ps (fonttype=3) and pdf backends seem to render the characters incorrectly.
>>> Rendering with ps backends (fonttype=42) IS correct on the other hand.
>>> See attached eps and pdf files. "test_correct.eps" is the correct one
>>> made with ps fonttype=42.
>>> "test_wrong.eps" is from fonttype=3.
>>>
>>> Just in case, my rc file contains
>>> text.usetex         : False
>>> ps.useafm         : False
>>>
>>>
>>> If I use ps backend with fonttype=3 (the wrong one), the embedded font
>>> in the output eps file for the above character is defined as follows.
>>>
>>>  /uniC774{917 0 67 -2 833 678 _sc
>>> gsave 0 343 translate
>>> false CharStrings /cho12-1 get exec
>>> grestore false CharStrings /jung21-1 get exec
>>> }_d
>>>
>>> It is a composition of two glyphs (/cho12-1 and /jung21-1), and my
>>> guess is the first glyph is somehow misplaced. If I manually change
>>> the translation of the first glyph to something like (0, -150) instead
>>> the current value of (0, 343), the output looks okay.
>>>
>>> I tried a few other Korean fonts but the results were similar. Some of
>>> the glyphs are misplaced (in ps(type=3) and pdf backends).
>>> Although I cannot rule out that the fonts I used have wrong font
>>> information, but my inclination is this could be a bug in
>>> "pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h).
>>>
>>> The translation of each glyphs seems to be handled by following code
>>> (around line 594 of pprdrv_tt2.cpp).
>>>
>>> 	    if( flags & ARGS_ARE_XY_VALUES )
>>> 		{
>>> 		    if( arg1 != 0 || arg2 != 0 )
>>> 			stream.printf("gsave %d %d translate\n", topost(arg1), topost(arg2) );
>>> 		}
>>>
>>> It would be great if someone who is expert on this font issue can look
>>> into this.
>>> Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600
>>> for this particular glyph.
>>> The later two are used inside "topost".
>>> Regards,
>>>
>>> -JJ
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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

Correction -- no need to send the image.  You said png output was 
correct, so I'll just compare against that.

Michael Droettboom wrote:
> The code that generates the Type 3 fonts for us is fairly old (1995), 
> and certainly predates the widespread adoption of Unicode, so I'm 
> somewhat not surprised this doesn't work.  I'll have a brief look to see 
> if there are any obvious fixes, but we're unlikely to implement a 
> full-fledged Unicode rendering system (like Pango) any time soon.  Since 
> I don't read Korean, can you provide an image file of what the resulting 
> compound glyph is supposed to look like?
>
> As a workaround, you could try using the Cairo backend to generate 
> Postscript and PDF.  It may do a better job.  You could also try other 
> Korean fonts -- they may not use compound glyph composition.
>  
> Cheers,
> Mike
>
> Jae-Joon Lee wrote:
>   
>> Hello,
>>
>> I wanted to render some Korean text in my matplotlib figure and this
>> is how I did (with python2.5 and trunk version of matplotlib).
>>
>> # -*- coding: utf-8 -*-
>> from pylab import *
>>
>> import matplotlib.font_manager as fm
>> fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf", size=100)
>>
>> plot([1,2,3])
>> text(1.,1.5, u'이', fontproperties=fp)
>> savefig("test.eps")
>> show()
>>
>>
>> It works fine with GtkAgg (and saving to png file also).
>> But ps (fonttype=3) and pdf backends seem to render the characters incorrectly.
>> Rendering with ps backends (fonttype=42) IS correct on the other hand.
>> See attached eps and pdf files. "test_correct.eps" is the correct one
>> made with ps fonttype=42.
>> "test_wrong.eps" is from fonttype=3.
>>
>> Just in case, my rc file contains
>> text.usetex         : False
>> ps.useafm         : False
>>
>>
>> If I use ps backend with fonttype=3 (the wrong one), the embedded font
>> in the output eps file for the above character is defined as follows.
>>
>>  /uniC774{917 0 67 -2 833 678 _sc
>> gsave 0 343 translate
>> false CharStrings /cho12-1 get exec
>> grestore false CharStrings /jung21-1 get exec
>> }_d
>>
>> It is a composition of two glyphs (/cho12-1 and /jung21-1), and my
>> guess is the first glyph is somehow misplaced. If I manually change
>> the translation of the first glyph to something like (0, -150) instead
>> the current value of (0, 343), the output looks okay.
>>
>> I tried a few other Korean fonts but the results were similar. Some of
>> the glyphs are misplaced (in ps(type=3) and pdf backends).
>> Although I cannot rule out that the fonts I used have wrong font
>> information, but my inclination is this could be a bug in
>> "pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h).
>>
>> The translation of each glyphs seems to be handled by following code
>> (around line 594 of pprdrv_tt2.cpp).
>>
>> 	    if( flags & ARGS_ARE_XY_VALUES )
>> 		{
>> 		    if( arg1 != 0 || arg2 != 0 )
>> 			stream.printf("gsave %d %d translate\n", topost(arg1), topost(arg2) );
>> 		}
>>
>> It would be great if someone who is expert on this font issue can look
>> into this.
>> Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600
>> for this particular glyph.
>> The later two are used inside "topost".
>> Regards,
>>
>> -JJ
>>   
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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

The code that generates the Type 3 fonts for us is fairly old (1995), 
and certainly predates the widespread adoption of Unicode, so I'm 
somewhat not surprised this doesn't work.  I'll have a brief look to see 
if there are any obvious fixes, but we're unlikely to implement a 
full-fledged Unicode rendering system (like Pango) any time soon.  Since 
I don't read Korean, can you provide an image file of what the resulting 
compound glyph is supposed to look like?

As a workaround, you could try using the Cairo backend to generate 
Postscript and PDF.  It may do a better job.  You could also try other 
Korean fonts -- they may not use compound glyph composition.
 
Cheers,
Mike

Jae-Joon Lee wrote:
> Hello,
>
> I wanted to render some Korean text in my matplotlib figure and this
> is how I did (with python2.5 and trunk version of matplotlib).
>
> # -*- coding: utf-8 -*-
> from pylab import *
>
> import matplotlib.font_manager as fm
> fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf", size=100)
>
> plot([1,2,3])
> text(1.,1.5, u'이', fontproperties=fp)
> savefig("test.eps")
> show()
>
>
> It works fine with GtkAgg (and saving to png file also).
> But ps (fonttype=3) and pdf backends seem to render the characters incorrectly.
> Rendering with ps backends (fonttype=42) IS correct on the other hand.
> See attached eps and pdf files. "test_correct.eps" is the correct one
> made with ps fonttype=42.
> "test_wrong.eps" is from fonttype=3.
>
> Just in case, my rc file contains
> text.usetex         : False
> ps.useafm         : False
>
>
> If I use ps backend with fonttype=3 (the wrong one), the embedded font
> in the output eps file for the above character is defined as follows.
>
>  /uniC774{917 0 67 -2 833 678 _sc
> gsave 0 343 translate
> false CharStrings /cho12-1 get exec
> grestore false CharStrings /jung21-1 get exec
> }_d
>
> It is a composition of two glyphs (/cho12-1 and /jung21-1), and my
> guess is the first glyph is somehow misplaced. If I manually change
> the translation of the first glyph to something like (0, -150) instead
> the current value of (0, 343), the output looks okay.
>
> I tried a few other Korean fonts but the results were similar. Some of
> the glyphs are misplaced (in ps(type=3) and pdf backends).
> Although I cannot rule out that the fonts I used have wrong font
> information, but my inclination is this could be a bug in
> "pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h).
>
> The translation of each glyphs seems to be handled by following code
> (around line 594 of pprdrv_tt2.cpp).
>
> 	    if( flags & ARGS_ARE_XY_VALUES )
> 		{
> 		    if( arg1 != 0 || arg2 != 0 )
> 			stream.printf("gsave %d %d translate\n", topost(arg1), topost(arg2) );
> 		}
>
> It would be great if someone who is expert on this font issue can look
> into this.
> Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600
> for this particular glyph.
> The later two are used inside "topost".
> Regards,
>
> -JJ
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

John Hunter wrote:

> The problem is with the image.AxesImage._rgbacache -- it is not being
> cleared with a set_clim or a set_cmap.  I am going to commit a
> preliminary fix which simply resets this on any call to
> image.AxesImage.changed and if there is a better place to do the reset
> vis-a-vis the optimization you are trying to capture, please modify as
> necessary.

John,

As far as I can see, you found the right solution.  I don't think it 
interferes in any way with the optimizations.

Thank you.

Eric

> 
> JDH

In the interest of simplifying/unifying the API for callbacks in mpl,
I ported the cm.ScalarMappable callback API to the
cbook.CallbackRegistry functionality which is what we use (on the
trunk) for the toolbar event handling and the Axes xlim/ylim
notification.  At a minimum, all callbacks (with one exception that I
am aware of in widgets.py) in mpl are now handled with the
cbook.CallbackRegistry, which is a start.  backend_driver.py is
passing as are a few interactive tests I tried, but make sure it looks
OK on your end.

JDH

On Tue, May 27, 2008 at 6:40 PM, Eric Firing <ef...@ha...> wrote:

> If I fouled it up--as evidently I did--I would like to fix it.  I will
> take a first look at it this evening.

FYI, this bug is only exposed in interactive use since the caching is
triggered by the first draw.

The problem is with the image.AxesImage._rgbacache -- it is not being
cleared with a set_clim or a set_cmap.  I am going to commit a
preliminary fix which simply resets this on any call to
image.AxesImage.changed and if there is a better place to do the reset
vis-a-vis the optimization you are trying to capture, please modify as
necessary.

JDH

On Tue, 2008-05-27 at 18:44 -0400, Darren Dale wrote:
> On Tuesday 27 May 2008 5:22:00 pm John Hunter wrote:
> > On Tue, May 27, 2008 at 3:55 PM, Darren Dale <dar...@co...> 
> wrote:
> > > On the trunk, the following script will show an image but will not
> > > rescale it:
> > >
> > > im=imshow(rand(10,10))
> > > im.set_clim(0,0.2)
> > > draw()
> >
> > I see that too -- and another image related bug:
> [...]
> > which does indeed stop the exception but there is the same problem you
> > point to: the image is not updated.  I don't have time to drill into
> > this one right now, but they are probably the same bug.  I'm
> > committing the is_gray lut bugfix and punting on the deeper bug for
> > now.
> 
> It truns out this was introduced a while back, in commit 5042. Eric, according 
> to the changelog you were working on speeding up panning and zooming of dense 
> images, do you have time to revisit it?

If I fouled it up--as evidently I did--I would like to fix it.  I will
take a first look at it this evening.

Eric
> 
> Darren

Hello,

I wanted to render some Korean text in my matplotlib figure and this
is how I did (with python2.5 and trunk version of matplotlib).

# -*- coding: utf-8 -*-
from pylab import *

import matplotlib.font_manager as fm
fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf", size=100)

plot([1,2,3])
text(1.,1.5, u'이', fontproperties=fp)
savefig("test.eps")
show()


It works fine with GtkAgg (and saving to png file also).
But ps (fonttype=3) and pdf backends seem to render the characters incorrectly.
Rendering with ps backends (fonttype=42) IS correct on the other hand.
See attached eps and pdf files. "test_correct.eps" is the correct one
made with ps fonttype=42.
"test_wrong.eps" is from fonttype=3.

Just in case, my rc file contains
text.usetex         : False
ps.useafm         : False


If I use ps backend with fonttype=3 (the wrong one), the embedded font
in the output eps file for the above character is defined as follows.

 /uniC774{917 0 67 -2 833 678 _sc
gsave 0 343 translate
false CharStrings /cho12-1 get exec
grestore false CharStrings /jung21-1 get exec
}_d

It is a composition of two glyphs (/cho12-1 and /jung21-1), and my
guess is the first glyph is somehow misplaced. If I manually change
the translation of the first glyph to something like (0, -150) instead
the current value of (0, 343), the output looks okay.

I tried a few other Korean fonts but the results were similar. Some of
the glyphs are misplaced (in ps(type=3) and pdf backends).
Although I cannot rule out that the fonts I used have wrong font
information, but my inclination is this could be a bug in
"pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h).

The translation of each glyphs seems to be handled by following code
(around line 594 of pprdrv_tt2.cpp).

	    if( flags & ARGS_ARE_XY_VALUES )
		{
		    if( arg1 != 0 || arg2 != 0 )
			stream.printf("gsave %d %d translate\n", topost(arg1), topost(arg2) );
		}

It would be great if someone who is expert on this font issue can look
into this.
Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600
for this particular glyph.
The later two are used inside "topost".
Regards,

-JJ

On Tuesday 27 May 2008 5:22:00 pm John Hunter wrote:
> On Tue, May 27, 2008 at 3:55 PM, Darren Dale <dar...@co...> 
wrote:
> > On the trunk, the following script will show an image but will not
> > rescale it:
> >
> > im=imshow(rand(10,10))
> > im.set_clim(0,0.2)
> > draw()
>
> I see that too -- and another image related bug:
[...]
> which does indeed stop the exception but there is the same problem you
> point to: the image is not updated.  I don't have time to drill into
> this one right now, but they are probably the same bug.  I'm
> committing the is_gray lut bugfix and punting on the deeper bug for
> now.

It truns out this was introduced a while back, in commit 5042. Eric, according 
to the changelog you were working on speeding up panning and zooming of dense 
images, do you have time to revisit it?

Darren

On Tue, May 27, 2008 at 3:55 PM, Darren Dale <dar...@co...> wrote:

> On the trunk, the following script will show an image but will not rescale it:
>
> im=imshow(rand(10,10))
> im.set_clim(0,0.2)
> draw()

I see that too -- and another image related bug:

In [177]: imshow(rand(10,10))
Out[177]: <matplotlib.image.AxesImage object at 0x1003acec>

In [178]: hot()

    Traceback (most recent call last):
      File "<ipython console>", line 1, in ?
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 2305, in hot
        draw_if_interactive()
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
line 58, in draw_if_interactive
        figManager.show()
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
line 338, in show
        self.canvas.draw()
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
line 191, in draw
        FigureCanvasAgg.draw(self)
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py",
line 255, in draw
        self.figure.draw(self.renderer)
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 792, in draw
        for a in self.axes: a.draw(renderer)
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1394, in draw
        im.draw(renderer)
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/image.py",
line 226, in draw
        im = self.make_image(renderer.get_image_magnification())
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/image.py",
line 182, in make_image
        im.is_grayscale = self.cmap.is_gray()
      File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colors.py",
line 504, in is_gray
        return (np.alltrue(self._lut[:,0] == self._lut[:,1])
    AttributeError: LinearSegmentedColormap instance has no attribute '_lut'

I thought at first all I would need to do is add an _init call in is_gray:

    def is_gray(self):
        if not self._isinit: self._init()
        return (np.alltrue(self._lut[:,0] == self._lut[:,1])
                    and np.alltrue(self._lut[:,0] == self._lut[:,2]))

which does indeed stop the exception but there is the same problem you
point to: the image is not updated.  I don't have time to drill into
this one right now, but they are probably the same bug.  I'm
committing the is_gray lut bugfix and punting on the deeper bug for
now.

On the trunk, the following script will show an image but will not rescale it:

im=imshow(rand(10,10))
im.set_clim(0,0.2)
draw()

It works on the maintenance branch.

Ludwig Schwardt wrote:
> Hi,
>
> Fernando wrote:
>   
>> The code for this path detection is obviously rather convoluted and
>> brittle, since there seems to be no clear API provided by Tk for this
>> information, unfortunately.
>>     
>
> Michael wrote:
>   
>> I know the Tcl/Tk header lookup mechanism is inherently complex.
>> Could someone who knows what's going on there have a look?
>>     
>
> I last rewrote the Tcl/Tk detection routines, but did not touch
> add_tk_flags(), which is definitely the grungy heart of this problem.
> On that function I am unfortunately as clueless as the rest.
>
> Jon wrote:
>   
>>  I thought you are expected to pick up the correct include directories from
>>  the files tclConfig.sh and tkConfig.sh, which are found in the lib
>>  directory returned from your query_tcltk function?
>>     
>
> In response to Jon's comment: Many systems have broken t*Config.sh
> scripts, for example way back on cygwin. My current Mac OS X 10.4.11
> installation has the following in tkConfig.sh:
>
> TK_PREFIX='/Users/andreask/dbn/lba/night/builds/macosx-ix86/out'
>   
I take it andreask is not you? ;)  That seems like a broken build of Tk 
and should be reported to the packager.  Fortunately, the TK_PREFIX 
isn't really relevant.
> Mmmm. So exclusive use of these files are also not an option... We
> need to deduce the include dir from the library dir returned by the
> tk.getvar() or tcl.getvar() calls in some robust(?) way.
>   
Thanks for this background.

I don't know if that is possible --

on RHEL4:

  tcl_library: /usr/share/tcl8.4
  TCL_INCLUDE_SPEC: /usr/include
  tclConfig.sh: /usr/lib/tclConfig.sh

on Ubuntu 8.04:

  tcl_library: /usr/share/tcltk/tcl8.4
  TCL_INCLUDE_SPEC: /usr/include/tcl8.4
  tclConfig.sh: /usr/share/tcltk/tcl8.4/tclConfig.sh

So, with these two examples, at least, the relative location of 
tcl_library and TCL_INCLUDE_SPEC is not fixed -- that is the assumption 
of the currently released code that falls down on Ubuntu 8.04.  Notice 
that even the location of tclConfig.sh is not fixed, and my new code has 
to check both tcl_library and "/usr/lib".

Unfortunately, Googling hasn't revealed the "right" way to do this, 
yet.  It's a wonder that anything ever gets built against Tcl/Tk at 
all... ;)

A note about my changes -- if using the tclConfig.sh fails to find a 
"tk.h" file, it falls back on the old way of working, which by all 
reports works for most people except on Ubuntu 8.04, so hopefully we're 
reasonably covered until the next cycle of distros comes along ;)

Cheers,
Mike
 

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

Hi,

Fernando wrote:
> The code for this path detection is obviously rather convoluted and
> brittle, since there seems to be no clear API provided by Tk for this
> information, unfortunately.

Michael wrote:
> I know the Tcl/Tk header lookup mechanism is inherently complex.
> Could someone who knows what's going on there have a look?

I last rewrote the Tcl/Tk detection routines, but did not touch
add_tk_flags(), which is definitely the grungy heart of this problem.
On that function I am unfortunately as clueless as the rest.

Jon wrote:
>  I thought you are expected to pick up the correct include directories from
>  the files tclConfig.sh and tkConfig.sh, which are found in the lib
>  directory returned from your query_tcltk function?

In response to Jon's comment: Many systems have broken t*Config.sh
scripts, for example way back on cygwin. My current Mac OS X 10.4.11
installation has the following in tkConfig.sh:

TK_PREFIX='/Users/andreask/dbn/lba/night/builds/macosx-ix86/out'

Mmmm. So exclusive use of these files are also not an option... We
need to deduce the include dir from the library dir returned by the
tk.getvar() or tcl.getvar() calls in some robust(?) way.

Regards,
Ludwig

Should be working now on the trunk.  The line transformation wasn't 
getting invalidated when the scale changed.

Cheers,
Mike

John Hunter wrote:
> On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <ol...@fy...> wrote:
>
>   
>> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
>> trunk! I use it a lot.
>>
>> I suggest restoring it with something like
>>
>> if self.get_yscale() is ("log" or "linear"):
>>    self.toggle_log_lineary()
>> else: pass
>>
>> I think most of time most people use log or linear scales.
>>     
>
>
> This seems reasonable, but when I tried to implement it it looked like
> the nan mask for the simple_plot.py example was sticky, eg when I
> toggled back to linear the negative values were still masked.  I tried
> a simpler example still (all positive y data) and got something very
> strange: the plotted y values appear to change on a toggle from log
> and back to linear:
>
> In [18]: import matplotlib.pyplot as plt
>
> In [19]: plt.close('all')
>
> In [20]: ax = plt.subplot(111)
>
> In [21]: ax.plot(np.random.rand(20))
> Out[21]: [<matplotlib.lines.Line2D object at 0x123082f0>]
>
> In [22]: ax.set_yscale('linear'); ax.figure.canvas.draw()
>
> In [23]: ax.set_yscale('log'); ax.figure.canvas.draw()
>
> In [24]: ax.set_yscale('linear'); ax.figure.canvas.draw()  # the y
> data are now plotted differently
>
>
> I am not sure what is going on yet, but I'm sure Michael will chime in
> since I think we are seeing some funkiness in the new transforms and
> path infrastructure.
>
>
>   
>> The new hist() function looks really good, I especially welcome the "step"
>> mode. A couple of comments:
>>
>> The latest svn incarnation doesn't allow for log scale in step-mode
>> (unless you set it manually).
>>
>> Also, I think the step-mode should have fill=False as default, otherwise
>> it does not look that much different from bar-mode. The nice thing about
>> step histograms is that you can put several of them in the same plot while
>> keeping it intelligible!
>>     
>
> Manuel is the developer behind these nice new changes to hist --
> hopefully he can help you here.
>
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

I think I have a fix in for this now.

As Jonathan Wright suggested, it parses tclConfig.sh and tkConfig.sh to 
find the include and lib directories.  If any of that fails, it falls 
back to the old method (which is based on the assumption that the build 
and lib directories are relative to the tcl data directories).  I'm 
afraid this makes the code more convoluted, not less, but perhaps with 
enough testing we can be confident that the old way can be eliminated.

Please try this on as many Linux distributions as you can.  (This does 
not affect Windows and Mac).  If in the build logs you see the message:

    Guessing the library and include directories for Tcl and Tk because the
    tclConfig.sh and tkConfig.sh could not be found and/or parsed.

that means the old method is still being used.  Please let me know about 
that, and what distro you are running -- it would be great to merge to a 
single lookup method if possible.

I'm keeping this on the trunk for now, but if we're confident in the 
change, this is a good candidate to be merged to the maintenance branch.

Cheers,
Mike

Michael Droettboom wrote:
> Alas, PIL SVN head fails to build on Ubuntu 8.04 (without 
> Ubuntu-specific patches) as well...
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Tue, May 27, 2008 at 9:27 AM, Michael Droettboom <md...@st...> wrote:
>>   
>>     
>>> Thanks, Jonathan.  The tclConfig.sh stuff was news to me (I didn't write
>>> the original Tcl/Tk header finding stuff, though).
>>>
>>> Everyone else: I'm on this and will let you know how it goes.
>>>     
>>>       
>> Just a reminder that a lot of the tcl/tk finder code was lifted from
>> the PIL setup, so you may want to see if there have been any updates
>> over there and re-lift them.
>>
>> JDH
>>   
>>     
>
>   

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

Alas, PIL SVN head fails to build on Ubuntu 8.04 (without 
Ubuntu-specific patches) as well...

Cheers,
Mike

John Hunter wrote:
> On Tue, May 27, 2008 at 9:27 AM, Michael Droettboom <md...@st...> wrote:
>   
>> Thanks, Jonathan.  The tclConfig.sh stuff was news to me (I didn't write
>> the original Tcl/Tk header finding stuff, though).
>>
>> Everyone else: I'm on this and will let you know how it goes.
>>     
>
> Just a reminder that a lot of the tcl/tk finder code was lifted from
> the PIL setup, so you may want to see if there have been any updates
> over there and re-lift them.
>
> JDH
>   

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

On Tue, May 27, 2008 at 9:27 AM, Michael Droettboom <md...@st...> wrote:
> Thanks, Jonathan.  The tclConfig.sh stuff was news to me (I didn't write
> the original Tcl/Tk header finding stuff, though).
>
> Everyone else: I'm on this and will let you know how it goes.

Just a reminder that a lot of the tcl/tk finder code was lifted from
the PIL setup, so you may want to see if there have been any updates
over there and re-lift them.

JDH

Thanks, Jonathan.  The tclConfig.sh stuff was news to me (I didn't write 
the original Tcl/Tk header finding stuff, though).

Everyone else: I'm on this and will let you know how it goes.

Cheers,
Mike

Jonathan Wright wrote:
> Hi Mike,
>
> OK, I've just done the svn co of v0_91_maint and get the output here:
>
> ============================================================================ 
>
> BUILDING MATPLOTLIB
>             matplotlib: 0.91.2svn
>                 python: 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)  [GCC
>                         4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
>               platform: linux2
>
> REQUIRED DEPENDENCIES
>                  numpy: 1.0.4
>              freetype2: 9.16.3
>
> OPTIONAL BACKEND DEPENDENCIES
>                 libpng: 1.2.15beta5
>                Tkinter: no
>                         * Tkinter present, but header files are not 
> found.
>                         * You may need to install development packages.
>               wxPython: 2.8.7.1
>                         * WxAgg extension not required for wxPython >= 
> 2.8
>                   Gtk+: gtk+: 2.12.9, glib: 2.16.3, pygtk: 2.12.1,
>                         pygobject: 2.14.1
>                         * Could not find Gtk+ headers in any of
>                         * '/usr/local/include', '/usr/include', '.'
>                     Qt: Qt: 3.3.8, PyQt: 3.17.4
>                    Qt4: Qt: 4.3.4, PyQt4: 4.3.3
>                  Cairo: 1.4.0
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>               datetime: present, version unknown
>               dateutil: 1.3
>                   pytz: 2007k
>
> OPTIONAL USETEX DEPENDENCIES
>                 dvipng: 1.9
>            ghostscript: 8.61
>                  latex: 3.141592
>                pdftops: 3.00
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
>              configobj: 4.4.0
>       enthought.traits: 2.0.1b1
>
> =========================================================================
>
> I then added the python-gtk2-dev package and it built the _gtkagg.so 
> backend by default. This looks fine, but it is not making TkAgg. So I 
> added "tkagg = True" to setup.cfg and it gets up to:
>
> =========================================================================
> building 'matplotlib.backends._tkagg' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fPIC -I/usr/share/include -I/usr/share/include 
> -I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -Isrc 
> -Iswig -Iagg23/include -I. -I/usr/include/freetype2 
> -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c 
> src/_tkagg.cpp -o build/temp.linux-i686-2.5/src/_tkagg.o
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid 
> for Ada/C/ObjC but not for C++
> src/_tkagg.cpp:28:18: error: tk.h: No such file or directory
> src/_tkagg.cpp:36: error: ISO C++ forbids declaration of Tcl_Interp 
> with no type
> src/_tkagg.cpp:36: error: expected ; before * token
> [snip - more errors ...]
> ========================================================================
>
> It has missed tk.h. I have the tk-dev and tcl-dev packages (and of 
> course the "build-essential" which gives standard headers etc).
>
> `locate tk.h` gives /usr/include/tcl8.4/tk.h
>
> so I edited setupext.py to give:
>
> svn diff
> Index: setupext.py
> ===================================================================
> --- setupext.py (revision 5276)
> +++ setupext.py (working copy)
> @@ -977,6 +977,12 @@
>                      os.path.exists('/usr/include/tk.h')):
>                      tcl_inc = '/usr/include'
>                      tk_inc = '/usr/include'
> +                # Ubuntu 8.04
> +                if (sys.platform.startswith('linux') and
> +                    os.path.exists('/usr/include/tcl8.4/tcl.h') and
> +                    os.path.exists('/usr/include/tcl8.4/tk.h')):
> +                    tcl_inc = '/usr/include/tcl8.4'
> +                    tk_inc = '/usr/include/tcl8.4'
>          else:
>              message = """\
>  Using default library and include directories for Tcl and Tk because a
> ==================================================================
>
> ... and now it builds and seems to work. With this patch it says:
>
> =============================================================
> ...
> OPTIONAL BACKEND DEPENDENCIES
> ...
>                Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
> =============================================================
>
>
>
> I thought you are expected to pick up the correct include directories 
> from the files tclConfig.sh and tkConfig.sh, which are found in the 
> lib directory returned from your query_tcltk function? Obviously, my 
> solution is going to give problems for people who are not using 8.4, 
> or who have something else different etc. Parsing tclConfig.sh seems 
> like overkill - maybe try asking the python/distutils folks?
>
> Best
>
> Jon
>
>
>
>
>
>
>
>
> On Tue, 27 May 2008, Michael Droettboom wrote:
>
>> I'm moving this second question onto the matplotlib-devel list.
>>
>> It seems that a user is unable to build the tkagg extension from 
>> source on Ubuntu 8.04.  I know the Tcl/Tk header lookup mechanism is 
>> inherently complex.  Could someone who knows what's going on there 
>> have a look?
>>
>> Jonathan: Could you please provide the output of a compile without 
>> your modifications to make it work?  We'd like this to work 
>> automatically.
>>
>> Cheers,
>> Mike
>>
>> Jonathan Wright wrote:
>>> Mike,
>>>
>>> That fixes things for me - many thanks. Unrelated, but to build from 
>>> SVN I had to go diving in setupext.py to say that the tk include 
>>> files are in:
>>>
>>> /usr/include/tcl8.4
>>>
>>> ... while the tcl install home is /usr/share/tcltk. The command 
>>> "locate tk.h" was particularly useful.
>>>
>>> Many thanks again,
>>>
>>> Jon
>>>
>>> Michael Droettboom wrote:
>>>> I assume you're using the matplotlib 0.91.2 that's distributed with 
>>>> Ubuntu 8.04.
>>>>
>>>> There was a recent fix for segfaulting in the exact same place 
>>>> (outside of any sort of freezing apparatus).  Since it was related 
>>>> to the interpretation of a pointer, it's possible that you would 
>>>> see this inside of cx-freeze and not outside on the same machine, 
>>>> just because things get loaded into different parts of memory.  I 
>>>> would try that fix first, and then look at problems related to 
>>>> freezing.
>>>>
>>>> We should have a new release out shortly, but it's unclear how long 
>>>> that will take to trickle down into Ubuntu repositories.
>>>>
>>>> You can check out the SVN maintenance branch from here (which has 
>>>> this bugfix):
>>>>
>>>>  svn co 
>>>> https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint 
>>>> matplotlib-0.91.x
>>>>
>>>> Let us know how that works for you.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Jonathan Wright wrote:
>>>>> Hello,
>>>>>
>>>>> I am getting segmentation faults when I try to freeze a script 
>>>>> which uses the TkAgg backend, on python2.5.2, gcc 4.2.3 (ubuntu 
>>>>> 8.04, hardy heron).  A trial script is:
>>>>>
>>>>> import matplotlib
>>>>> matplotlib.use("TkAgg")  # unless you have it in matplotlibrc
>>>>> import matplotlib.backends.backend_tkagg # explicit for freezer
>>>>> from matplotlib.pylab import plot, show
>>>>> plot(range(10), range(10), "+")
>>>>> show()
>>>>>
>>>>> Is anyone already familiar with the problem? Things seem to work 
>>>>> with the GTkAgg backend, but sadly many years ago I decided to use 
>>>>> Tk as I thought it'd be easier to distribute. In order to 
>>>>> reproduce the problem with bbfreeze you should just need this 
>>>>> freezing script:
>>>>>
>>>>> from bbfreeze import Freezer
>>>>> f = Freezer("dist",
>>>>>            includes=("matplotlib",
>>>>>                      "matplotlib.numerix.fft",
>>>>>                      "matplotlib.numerix.linear_algebra",
>>>>>                      "matplotlib.numerix.ma",
>>>>>                      "matplotlib.numerix.mlab",
>>>>>                      "matplotlib.numerix.random_array"))
>>>>> f.addScript("t.py")
>>>>> f()
>>>>>
>>>>> For reproducing the problem with cx-freeze you need to (a) install 
>>>>> it by patching the cx-freeze setup.py [so that (2, 5) -> (2, 6)] 
>>>>> and (b) add an import for numpy.linalg.lapack_lite and edit your 
>>>>> numpy.__init__ to remove numpy.test.
>>>>>
>>>>> Thanks for any advice,
>>>>>
>>>>> Jon
>>>>> ---
>>>>>
>>>>> PS: gdb  says
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> [Switching to Thread 0xb7c806b0 (LWP 8158)]
>>>>> 0xb6e145a0 in ?? () from 
>>>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>>> (gdb) bt
>>>>> #0  0xb6e145a0 in ?? () from 
>>>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>>> #1  0xb6badb6e in TclInvokeStringCommand () from 
>>>>> /usr/lib/libtcl8.4.so.0
>>>>> #2  0xb6baee56 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
>>>>> #3  0xb6baf0db in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
>>>>> #4  0xb6ef96c6 in ?? () from 
>>>>> /home/wright/testcx/build/exe.linux-i686-2.5/_tkinter.so
>>>>> #5  0x0827a0c8 in ?? ()
>>>>> #6  0x00000005 in ?? ()
>>>>> ...
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>> This SF.net email is sponsored by: Microsoft Defy all challenges. 
>>>>> Microsoft(R) Visual Studio 2008. 
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>
>>>
>>
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>

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

FWIW -- this is what the Ubuntu package diff does to setupext.py.  We 
may want to do the same:

+@@ -960,6 +960,9 @@ def add_tk_flags(module):
+             if not os.path.exists(tk_inc):
+                 tk_inc = os.path.normpath(os.path.join(tk_lib_dir,
+                                           '../../include'))
++            if not os.path.exists(tk_inc):
++                tk_inc = os.path.normpath(os.path.join(tk_lib_dir,
++                                          '../../../include/tcl' + 
tk_ver))
+            
+             if ((not os.path.exists(os.path.join(tk_inc,'tk.h'))) and
+                 os.path.exists(os.path.join(tcl_inc,'tk.h'))):
+

For more info, see here:

https://launchpad.net/ubuntu/+source/matplotlib/0.91.2-0ubuntu1

Cheers,
Mike

Fernando Perez wrote:
> Hi all,
>
> just a heads up: current MPL from SVN won't build the Tk backend on an
> ubuntu hardy installation (32 bit) because the location of certain
> paths seems to have changed.  I got it down to this snippet:
>
> import Tkinter
> tk = Tkinter.Tk()
> tk.withdraw()
> print tk.getvar('tcl_library')
>
> On a gutsy box I get:
> /usr/lib/tcl8.4
>
> but hardy now reports:
> /usr/share/tcltk/tcl8.4
>
> This seems to foul up the path handling code in add_tk_flags(), so in
> the end the created extension module object (in check_for_tk) ends up
> with:
>
> In [21]: module.include_dirs
> Out[21]: ['/usr/share/include', '/usr/share/include']
>
> This obviously means that the headers for Tk aren't found, since they
> live in /usr/include:
>
> /usr/include/tcl8.4/tk.h
>
> The code for this path detection is obviously rather convoluted and
> brittle, since there seems to be no clear API provided by Tk for this
> information, unfortunately. This could be a Hardy bug, for all I know.
>  I just wanted to let you guys know, for now I'll brute-force patch my
> local copy so I can build.
>
> Cheers,
>
> f
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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 Mike,

OK, I've just done the svn co of v0_91_maint and get the output here:

============================================================================
BUILDING MATPLOTLIB
             matplotlib: 0.91.2svn
                 python: 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)  [GCC
                         4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
               platform: linux2

REQUIRED DEPENDENCIES
                  numpy: 1.0.4
              freetype2: 9.16.3

OPTIONAL BACKEND DEPENDENCIES
                 libpng: 1.2.15beta5
                Tkinter: no
                         * Tkinter present, but header files are not found.
                         * You may need to install development packages.
               wxPython: 2.8.7.1
                         * WxAgg extension not required for wxPython >= 2.8
                   Gtk+: gtk+: 2.12.9, glib: 2.16.3, pygtk: 2.12.1,
                         pygobject: 2.14.1
                         * Could not find Gtk+ headers in any of
                         * '/usr/local/include', '/usr/include', '.'
                     Qt: Qt: 3.3.8, PyQt: 3.17.4
                    Qt4: Qt: 4.3.4, PyQt4: 4.3.3
                  Cairo: 1.4.0

OPTIONAL DATE/TIMEZONE DEPENDENCIES
               datetime: present, version unknown
               dateutil: 1.3
                   pytz: 2007k

OPTIONAL USETEX DEPENDENCIES
                 dvipng: 1.9
            ghostscript: 8.61
                  latex: 3.141592
                pdftops: 3.00

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
              configobj: 4.4.0
       enthought.traits: 2.0.1b1

=========================================================================

I then added the python-gtk2-dev package and it built the _gtkagg.so 
backend by default. This looks fine, but it is not making TkAgg. So I 
added "tkagg = True" to setup.cfg and it gets up to:

=========================================================================
building 'matplotlib.backends._tkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/share/include -I/usr/share/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -Isrc 
-Iswig -Iagg23/include -I. -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.5 -c src/_tkagg.cpp -o 
build/temp.linux-i686-2.5/src/_tkagg.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
src/_tkagg.cpp:28:18: error: tk.h: No such file or directory
src/_tkagg.cpp:36: error: ISO C++ forbids declaration of Tcl_Interp with 
no type
src/_tkagg.cpp:36: error: expected ; before * token
[snip - more errors ...]
========================================================================

It has missed tk.h. I have the tk-dev and tcl-dev packages (and of course 
the "build-essential" which gives standard headers etc).

`locate tk.h` gives /usr/include/tcl8.4/tk.h

so I edited setupext.py to give:

svn diff
Index: setupext.py
===================================================================
--- setupext.py (revision 5276)
+++ setupext.py (working copy)
@@ -977,6 +977,12 @@
                      os.path.exists('/usr/include/tk.h')):
                      tcl_inc = '/usr/include'
                      tk_inc = '/usr/include'
+                # Ubuntu 8.04
+                if (sys.platform.startswith('linux') and
+                    os.path.exists('/usr/include/tcl8.4/tcl.h') and
+                    os.path.exists('/usr/include/tcl8.4/tk.h')):
+                    tcl_inc = '/usr/include/tcl8.4'
+                    tk_inc = '/usr/include/tcl8.4'
          else:
              message = """\
  Using default library and include directories for Tcl and Tk because a
==================================================================

... and now it builds and seems to work. With this patch it says:

=============================================================
...
OPTIONAL BACKEND DEPENDENCIES
...
                Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
=============================================================



I thought you are expected to pick up the correct include directories from 
the files tclConfig.sh and tkConfig.sh, which are found in the lib 
directory returned from your query_tcltk function? Obviously, my solution 
is going to give problems for people who are not using 8.4, or who have 
something else different etc. Parsing tclConfig.sh seems like overkill - 
maybe try asking the python/distutils folks?

Best

Jon








On Tue, 27 May 2008, Michael Droettboom wrote:

> I'm moving this second question onto the matplotlib-devel list.
>
> It seems that a user is unable to build the tkagg extension from source on 
> Ubuntu 8.04.  I know the Tcl/Tk header lookup mechanism is inherently 
> complex.  Could someone who knows what's going on there have a look?
>
> Jonathan: Could you please provide the output of a compile without your 
> modifications to make it work?  We'd like this to work automatically.
>
> Cheers,
> Mike
>
> Jonathan Wright wrote:
>> Mike,
>> 
>> That fixes things for me - many thanks. Unrelated, but to build from SVN I 
>> had to go diving in setupext.py to say that the tk include files are in:
>> 
>> /usr/include/tcl8.4
>> 
>> ... while the tcl install home is /usr/share/tcltk. The command "locate 
>> tk.h" was particularly useful.
>> 
>> Many thanks again,
>> 
>> Jon
>> 
>> Michael Droettboom wrote:
>>> I assume you're using the matplotlib 0.91.2 that's distributed with 
>>> Ubuntu 8.04.
>>> 
>>> There was a recent fix for segfaulting in the exact same place (outside 
>>> of any sort of freezing apparatus).  Since it was related to the 
>>> interpretation of a pointer, it's possible that you would see this 
>>> inside of cx-freeze and not outside on the same machine, just because 
>>> things get loaded into different parts of memory.  I would try that fix 
>>> first, and then look at problems related to freezing.
>>> 
>>> We should have a new release out shortly, but it's unclear how long that 
>>> will take to trickle down into Ubuntu repositories.
>>> 
>>> You can check out the SVN maintenance branch from here (which has this 
>>> bugfix):
>>> 
>>>  svn co 
>>> https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint 
>>> matplotlib-0.91.x
>>> 
>>> Let us know how that works for you.
>>> 
>>> Cheers,
>>> Mike
>>> 
>>> Jonathan Wright wrote:
>>>> Hello,
>>>> 
>>>> I am getting segmentation faults when I try to freeze a script which 
>>>> uses the TkAgg backend, on python2.5.2, gcc 4.2.3 (ubuntu 8.04, hardy 
>>>> heron).  A trial script is:
>>>> 
>>>> import matplotlib
>>>> matplotlib.use("TkAgg")  # unless you have it in matplotlibrc
>>>> import matplotlib.backends.backend_tkagg # explicit for freezer
>>>> from matplotlib.pylab import plot, show
>>>> plot(range(10), range(10), "+")
>>>> show()
>>>> 
>>>> Is anyone already familiar with the problem? Things seem to work with 
>>>> the GTkAgg backend, but sadly many years ago I decided to use Tk as I 
>>>> thought it'd be easier to distribute. In order to reproduce the 
>>>> problem with bbfreeze you should just need this freezing script:
>>>> 
>>>> from bbfreeze import Freezer
>>>> f = Freezer("dist",
>>>>            includes=("matplotlib",
>>>>                      "matplotlib.numerix.fft",
>>>>                      "matplotlib.numerix.linear_algebra",
>>>>                      "matplotlib.numerix.ma",
>>>>                      "matplotlib.numerix.mlab",
>>>>                      "matplotlib.numerix.random_array"))
>>>> f.addScript("t.py")
>>>> f()
>>>> 
>>>> For reproducing the problem with cx-freeze you need to (a) install it 
>>>> by patching the cx-freeze setup.py [so that (2, 5) -> (2, 6)] and (b) 
>>>> add an import for numpy.linalg.lapack_lite and edit your 
>>>> numpy.__init__ to remove numpy.test.
>>>> 
>>>> Thanks for any advice,
>>>> 
>>>> Jon
>>>> ---
>>>> 
>>>> PS: gdb  says
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> [Switching to Thread 0xb7c806b0 (LWP 8158)]
>>>> 0xb6e145a0 in ?? () from 
>>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>> (gdb) bt
>>>> #0  0xb6e145a0 in ?? () from 
>>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>> #1  0xb6badb6e in TclInvokeStringCommand () from 
>>>> /usr/lib/libtcl8.4.so.0
>>>> #2  0xb6baee56 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
>>>> #3  0xb6baf0db in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
>>>> #4  0xb6ef96c6 in ?? () from 
>>>> /home/wright/testcx/build/exe.linux-i686-2.5/_tkinter.so
>>>> #5  0x0827a0c8 in ?? ()
>>>> #6  0x00000005 in ?? ()
>>>> ...
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------- 
>>>> This SF.net email is sponsored by: Microsoft Defy all challenges. 
>>>> Microsoft(R) Visual Studio 2008. 
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>> 
>>> 
>> 
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

I'm moving this second question onto the matplotlib-devel list.

It seems that a user is unable to build the tkagg extension from source 
on Ubuntu 8.04.  I know the Tcl/Tk header lookup mechanism is inherently 
complex.  Could someone who knows what's going on there have a look?

Jonathan: Could you please provide the output of a compile without your 
modifications to make it work?  We'd like this to work automatically.

Cheers,
Mike

Jonathan Wright wrote:
> Mike,
>
> That fixes things for me - many thanks. Unrelated, but to build from 
> SVN I had to go diving in setupext.py to say that the tk include files 
> are in:
>
> /usr/include/tcl8.4
>
> ... while the tcl install home is /usr/share/tcltk. The command 
> "locate tk.h" was particularly useful.
>
> Many thanks again,
>
> Jon
>
> Michael Droettboom wrote:
>> I assume you're using the matplotlib 0.91.2 that's distributed with 
>> Ubuntu 8.04.
>>
>> There was a recent fix for segfaulting in the exact same place 
>> (outside of any sort of freezing apparatus).  Since it was related to 
>> the interpretation of a pointer, it's possible that you would see 
>> this inside of cx-freeze and not outside on the same machine, just 
>> because things get loaded into different parts of memory.  I would 
>> try that fix first, and then look at problems related to freezing.
>>
>> We should have a new release out shortly, but it's unclear how long 
>> that will take to trickle down into Ubuntu repositories.
>>
>> You can check out the SVN maintenance branch from here (which has 
>> this bugfix):
>>
>>  svn co 
>> https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint 
>> matplotlib-0.91.x
>>
>> Let us know how that works for you.
>>
>> Cheers,
>> Mike
>>
>> Jonathan Wright wrote:
>>> Hello,
>>>
>>> I am getting segmentation faults when I try to freeze a script which 
>>> uses the TkAgg backend, on python2.5.2, gcc 4.2.3 (ubuntu 8.04, 
>>> hardy heron).  A trial script is:
>>>
>>> import matplotlib
>>> matplotlib.use("TkAgg")  # unless you have it in matplotlibrc
>>> import matplotlib.backends.backend_tkagg # explicit for freezer
>>> from matplotlib.pylab import plot, show
>>> plot(range(10), range(10), "+")
>>> show()
>>>
>>> Is anyone already familiar with the problem? Things seem to work 
>>> with the GTkAgg backend, but sadly many years ago I decided to use 
>>> Tk as I thought it'd be easier to distribute. In order to reproduce 
>>> the problem with bbfreeze you should just need this freezing script:
>>>
>>> from bbfreeze import Freezer
>>> f = Freezer("dist",
>>>            includes=("matplotlib",
>>>                      "matplotlib.numerix.fft",
>>>                      "matplotlib.numerix.linear_algebra",
>>>                      "matplotlib.numerix.ma",
>>>                      "matplotlib.numerix.mlab",
>>>                      "matplotlib.numerix.random_array"))
>>> f.addScript("t.py")
>>> f()
>>>
>>> For reproducing the problem with cx-freeze you need to (a) install 
>>> it by patching the cx-freeze setup.py [so that (2, 5) -> (2, 6)] and 
>>> (b) add an import for numpy.linalg.lapack_lite and edit your 
>>> numpy.__init__ to remove numpy.test.
>>>
>>> Thanks for any advice,
>>>
>>> Jon
>>> ---
>>>
>>> PS: gdb  says
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 0xb7c806b0 (LWP 8158)]
>>> 0xb6e145a0 in ?? () from 
>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>
>>> (gdb) bt
>>> #0  0xb6e145a0 in ?? () from 
>>> /home/wright/testcx/build/exe.linux-i686-2.5/matplotlib.backends._tkagg.so 
>>>
>>> #1  0xb6badb6e in TclInvokeStringCommand () from 
>>> /usr/lib/libtcl8.4.so.0
>>> #2  0xb6baee56 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
>>> #3  0xb6baf0db in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
>>> #4  0xb6ef96c6 in ?? () from 
>>> /home/wright/testcx/build/exe.linux-i686-2.5/_tkinter.so
>>> #5  0x0827a0c8 in ?? ()
>>> #6  0x00000005 in ?? ()
>>> ...
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Microsoft Defy all challenges. 
>>> Microsoft(R) Visual Studio 2008. 
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>   
>>
>

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

Hi all,

just a heads up: current MPL from SVN won't build the Tk backend on an
ubuntu hardy installation (32 bit) because the location of certain
paths seems to have changed.  I got it down to this snippet:

import Tkinter
tk = Tkinter.Tk()
tk.withdraw()
print tk.getvar('tcl_library')

On a gutsy box I get:
/usr/lib/tcl8.4

but hardy now reports:
/usr/share/tcltk/tcl8.4

This seems to foul up the path handling code in add_tk_flags(), so in
the end the created extension module object (in check_for_tk) ends up
with:

In [21]: module.include_dirs
Out[21]: ['/usr/share/include', '/usr/share/include']

This obviously means that the headers for Tk aren't found, since they
live in /usr/include:

/usr/include/tcl8.4/tk.h

The code for this path detection is obviously rather convoluted and
brittle, since there seems to be no clear API provided by Tk for this
information, unfortunately. This could be a Hardy bug, for all I know.
 I just wanted to let you guys know, for now I'll brute-force patch my
local copy so I can build.

Cheers,

f

On May 25, 2008, at 1:01 PM, John Hunter wrote:
>
> You need to be on the trunk and I think I was a commit behind -- try  
> it now.
>
> We will probably want to set the various ticklabel and title sizes to
> something really small using rc
>
> import matplotlib
> matplotlib.rcParams['xtick.labelsize']  = 6

Unfortunately, I'm not running the trunk right now because I use numpy  
1.0.4 (not 1.1).

I played around with the script, but in the process I ended up  
rewriting it a bunch. I'm sure I've violated come coding guidelines  
along the way; my apologies.

My 2 cents:
I think it looks better if you reduce the number of histogram bins from 
50 down to 15 or 20.
Gary R.

John Hunter wrote:
> I played around with this a bit this morning -- it may be too busy for
> your OS X sensibilities, but let me know if you think think this is an
> approach wotrh pursuing.  I've added the mathtext background and a few
> axes and there are a few more axes to do.  In svn as
> examples/api/logo2.py