setupext bug in matplotlib

I looked a little bit at this problem before (I have the

    > same issue) and I saw that the test on suse 10 (at least)
    > give a bad answer and so matplotlib can't find the
    > header. This is the result of the test on the suse install
    > in my lab:

    > In [1]: import Tkinter

    > In [2]: tk=Tkinter.Tk()

    > In [3]: tk.getvar('tcl_library') Out[3]:
    > '/usr/share/tcl/tcl8.4'

    > In [4]: tk.getvar('tk_library') Out[4]:
    > u'/usr/share/tcl/tk8.4'

    > In [5]: tk.getvar('tk_library') Out[5]:
    > u'/usr/share/tcl/tk8.4'

This looks like what Eric is getting (offlist).

Can you confirm your tcl.h and tk.h are in /usr/include? Do the dirs
/usr/include/tcl8.4 and /usr/include/tk8.4 exist?

It looks like the Suse tcl/tl/Tkinter install is broken -- is this an
official package? We should check the effbot's latest code (which is
where this is borrowed from) to see if he has a fix in for this.

JDH

John Hunter wrote:

    > I looked a little bit at this problem before (I have the
    > same issue) and I saw that the test on suse 10 (at least)
    > give a bad answer and so matplotlib can't find the
    > header. This is the result of the test on the suse install
    > in my lab:

    > In [1]: import Tkinter

    > In [2]: tk=Tkinter.Tk()

    > In [3]: tk.getvar('tcl_library') Out[3]:
    > '/usr/share/tcl/tcl8.4'

    > In [4]: tk.getvar('tk_library') Out[4]:
    > u'/usr/share/tcl/tk8.4'

    > In [5]: tk.getvar('tk_library') Out[5]:
    > u'/usr/share/tcl/tk8.4'

This looks like what Eric is getting (offlist).

Can you confirm your tcl.h and tk.h are in /usr/include?

confirm

Do the dirs
/usr/include/tcl8.4 and /usr/include/tk8.4 exist?

no they doesn't exist. All the header for tcl/tk are install in /usr/include

It looks like the Suse tcl/tl/Tkinter install is broken -- is this an
official package? We should check the effbot's latest code (which is
where this is borrowed from) to see if he has a fix in for this.

I think so but like I told before it's not the only package a little bit strange on Suse...

N.

···

JDH

John Hunter wrote:

"Humufr" == Humufr <humufr@...136...> writes:

    > I looked a little bit at this problem before (I have the
    > same issue) and I saw that the test on suse 10 (at least)
    > give a bad answer and so matplotlib can't find the
    > header. This is the result of the test on the suse install
    > in my lab:

    > In [1]: import Tkinter

    > In [2]: tk=Tkinter.Tk()

    > In [3]: tk.getvar('tcl_library') Out[3]:
    > '/usr/share/tcl/tcl8.4'

    > In [4]: tk.getvar('tk_library') Out[4]:
    > u'/usr/share/tcl/tk8.4'

    > In [5]: tk.getvar('tk_library') Out[5]:
    > u'/usr/share/tcl/tk8.4'

It looks like the Suse tcl/tl/Tkinter install is broken -- is this an
official package? We should check the effbot's latest code (which is
where this is borrowed from) to see if he has a fix in for this.

JDH

This may not be such a rare event.
I see the same problem on MacOSX 10.3: python, tcl/tk
(X11 based) compiled in a local directory (and is one of the reasons I don't
use the original setupext on MacOSX).

>>> tk.getvar('tcl_library')
'/usr/stsci/pyssgdev/lib/tcl8.4'

but

>>> tk.getvar('tk_library')
u'/usr/stsci/pyssgdev/lib/tk8.4'

I haven't had time to try to understand it but I believe the installation
I have is correct and this is a python/Tkinter problem.
(The first thing that comes to mind is 'unicode':))

Nadia

>>> tk.getvar('tk_library')
u'/usr/stsci/pyssgdev/lib/tk8.4'

(The first thing that comes to mind is 'unicode':))

Hmm, turns out this is not a joke.

On a linux machine I get

python

Python 2.4.3 (#2, Apr 17 2006, 10:36:38)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> tk=Tkinter.Tk()
>>> type(tk.getvar('tk_library'))
<type 'str'>
>>> type(tk.getvar('tcl_library'))
<type 'str'>

The same example on MacOSX (python, tcl/tk are X11 based, built in
a local directory) gives:

>>> type(tk.getvar('tk_library'))
<type 'unicode'>
>>> type(tk.getvar('tcl_library'))
<type 'str'>

I'm using tcl/tk 8.3 on linux and tcl/tk 8.4 on the mac.
Is anyone aware of any changes to Tk 8.4 that could cause this
behavior?

A possible workaround is

tk.getvar('tk_library').encode('utf8')

Nadia

This might be related to a unicode bug in python too. I saw a mention
somewhere that python-2.4.3 would include some unicode bug fixes.

···

On Tuesday 25 April 2006 17:27, Nadia Dencheva wrote:

> >>> tk.getvar('tk_library')
>
> u'/usr/stsci/pyssgdev/lib/tk8.4'
>
> (The first thing that comes to mind is 'unicode':))

Hmm, turns out this is not a joke.

On a linux machine I get

> python
Python 2.4.3 (#2, Apr 17 2006, 10:36:38)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import Tkinter
>>> tk=Tkinter.Tk()
>>> type(tk.getvar('tk_library'))

<type 'str'>

>>> type(tk.getvar('tcl_library'))

<type 'str'>

The same example on MacOSX (python, tcl/tk are X11 based, built in

a local directory) gives:
>>> type(tk.getvar('tk_library'))

<type 'unicode'>

>>> type(tk.getvar('tcl_library'))

<type 'str'>

I'm using tcl/tk 8.3 on linux and tcl/tk 8.4 on the mac.
Is anyone aware of any changes to Tk 8.4 that could cause this
behavior?

A possible workaround is

tk.getvar('tk_library').encode('utf8')