Hello,
I was having trouble getting matplotlib to link to the correct Tcl and
Tk, and as a result uncovered what I would call a bug, or at least
unpredictable behavior.
Basically, I have a custom Tcl/Tk installation, and I setup python to
correctly find them, so I have the expectation that Matplotlib would
use the same Tk. It can be pretty easily figured out just by
importing Tkinter. Anyway, I looked through the matplotlib
setupext.py and discovered that there is a function that does this,
and correctly: query_tcltk
anyway, the logic in the setupext file is such that if the
sys.platform is 'darwin' then it will look for a Framework first
(maybe only), and since there is always an ancient system version of
Tcl and Tk, it will always pick those before anywhere else.
The system frameworks are not complete, and I know you all recommend
installing a binary with everything in it. Unfortunately, I did not
have this option for unimportant reasons.
Either way, I do believe that it is a bug that it does not choose the
Tk that is being used by Python or at least trying to before using
other available libraries and frameworks. This is easy enough for me
to fix just for myself and at work, but I believe that you all should
consider using Python's Tk for these reasons:
1). If python was installed from source, this is the one that the
user configured python to use, and therefore is the one they trust.
2). If the Tk/Tcl libraries were installed from source instead of
using the binaries you suggested installing, then it will just use the
wrong system Framework anyway. I bet people using macports and other
unix-like package managers on mac end up submitting a lot of bug
reports over this.
3). It is just more predictable and sustainable if modules set Python
as their standard base. Besides, it isn't much work as you already
wrote a function to find the correct tcl and tk.
4). I don't mind helping write the patch. I am only worried about
not knowing the intricacies of all the random supported platforms that
you all look out for. For example: I know jack about Windows linking.
Either way, I'll update it if you have someone look at it. I'll work
on it sometimes this week when I'm not too busy at work and send it
in.
Anyway,
I am hoping that I convinced you all, and look forward to helping fix this.
Have a great rest-of-the-week!
Jayson
I should also add that the reason it won't find my tclConfig.sh and
tkConfig.sh files is because they were configured/installed with the
--prefix option, but with the information from Python this is easily
resolvable.
Jayson
···
On Wed, Feb 4, 2009 at 3:08 PM, Jayson Barr <jbarr@...694...> wrote:
Hello,
I was having trouble getting matplotlib to link to the correct Tcl and
Tk, and as a result uncovered what I would call a bug, or at least
unpredictable behavior.
Basically, I have a custom Tcl/Tk installation, and I setup python to
correctly find them, so I have the expectation that Matplotlib would
use the same Tk. It can be pretty easily figured out just by
importing Tkinter. Anyway, I looked through the matplotlib
setupext.py and discovered that there is a function that does this,
and correctly: query_tcltk
anyway, the logic in the setupext file is such that if the
sys.platform is 'darwin' then it will look for a Framework first
(maybe only), and since there is always an ancient system version of
Tcl and Tk, it will always pick those before anywhere else.
The system frameworks are not complete, and I know you all recommend
installing a binary with everything in it. Unfortunately, I did not
have this option for unimportant reasons.
Either way, I do believe that it is a bug that it does not choose the
Tk that is being used by Python or at least trying to before using
other available libraries and frameworks. This is easy enough for me
to fix just for myself and at work, but I believe that you all should
consider using Python's Tk for these reasons:
1). If python was installed from source, this is the one that the
user configured python to use, and therefore is the one they trust.
2). If the Tk/Tcl libraries were installed from source instead of
using the binaries you suggested installing, then it will just use the
wrong system Framework anyway. I bet people using macports and other
unix-like package managers on mac end up submitting a lot of bug
reports over this.
3). It is just more predictable and sustainable if modules set Python
as their standard base. Besides, it isn't much work as you already
wrote a function to find the correct tcl and tk.
4). I don't mind helping write the patch. I am only worried about
not knowing the intricacies of all the random supported platforms that
you all look out for. For example: I know jack about Windows linking.
Either way, I'll update it if you have someone look at it. I'll work
on it sometimes this week when I'm not too busy at work and send it
in.
Anyway,
I am hoping that I convinced you all, and look forward to helping fix this.
Have a great rest-of-the-week!
Jayson
It did for MacPorts, there where a lot of strange segfaults reported.
I have since hacked round this to force it to link against the
MacPorts provided Tcl/Tk
http://trac.macports.org/browser/trunk/dports/python/py25-matplotlib/files/patch-setupext.py.diff
Its messy but it works.
Cheers
Adam
···
On Wed, Feb 4, 2009 at 17:08, Jayson Barr <jbarr@...694...> wrote:
2). If the Tk/Tcl libraries were installed from source instead of
using the binaries you suggested installing, then it will just use the
wrong system Framework anyway. I bet people using macports and other
unix-like package managers on mac end up submitting a lot of bug
reports over this.
The problem is that the code is already messy, and Adam describes his
solution as messy, and it is difficult if not impossible to get people
to test on all the required platforms. I can test on OS X w/o
macports and a linux box, Charlie would probably be able to test on
win32, and Adam can test on macports. Perhaps you and Adam can
collaborate on a patch and we'll see if we can get it properly tested.
There are lots of tcl/tk combinations out there on different
platforms, so it is a trick issue.
JDH
···
On Wed, Feb 4, 2009 at 5:08 PM, Jayson Barr <jbarr@...694...> wrote:
4). I don't mind helping write the patch. I am only worried about
not knowing the intricacies of all the random supported platforms that
you all look out for. For example: I know jack about Windows linking.
Either way, I'll update it if you have someone look at it. I'll work
on it sometimes this week when I'm not too busy at work and send it
in.
Hi all,
I agree with JDH.
Unfortunately, work has been exceptionally hectic so I haven't begun
the patch (if you don't count the hack job I did to install it for
myself).
Hi Adam,
As noted above, I haven't started a patch yet but I would be up for
working with you on one. It sounds like we can get this tested pretty
well.
Thanks,
and talk to you soon,
Jayson
···
On Sat, Feb 7, 2009 at 7:44 AM, John Hunter <jdh2358@...149...> wrote:
On Wed, Feb 4, 2009 at 5:08 PM, Jayson Barr <jbarr@...694...> wrote:
4). I don't mind helping write the patch. I am only worried about
not knowing the intricacies of all the random supported platforms that
you all look out for. For example: I know jack about Windows linking.
Either way, I'll update it if you have someone look at it. I'll work
on it sometimes this week when I'm not too busy at work and send it
in.
The problem is that the code is already messy, and Adam describes his
solution as messy, and it is difficult if not impossible to get people
to test on all the required platforms. I can test on OS X w/o
macports and a linux box, Charlie would probably be able to test on
win32, and Adam can test on macports. Perhaps you and Adam can
collaborate on a patch and we'll see if we can get it properly tested.
There are lots of tcl/tk combinations out there on different
platforms, so it is a trick issue.
JDH
I agree with JDH.
Likewise.
Unfortunately, work has been exceptionally hectic so I haven't begun
the patch (if you don't count the hack job I did to install it for
myself).
Same here, I'm really busy with work and don't have much time to look
into this at the moment.
Hi Adam,
As noted above, I haven't started a patch yet but I would be up for
working with you on one. It sounds like we can get this tested pretty
well.
Its on my todo list, so when I get chance I'm going to investigate a
better solution. I'll keep you posted.
Cheers
Adam
···
On Mon, Feb 9, 2009 at 17:08, Jayson Barr <jbarr@...694...> wrote: