[matplotlib-devel] Patch: Building TkAgg backend without a running X server
Hi, I've reworked the Tcl/Tk checking code in setupext.py (see attached patch). It is now possible to build matplotlib with Tk support without requiring a running X server. This is useful for doing autobuilds (e.g. as done by Debian) and for building a package on one machine to be installed and used on another. This seems to be an old issue... (see matplotlib-devel, "building matplotlib without X-server connection," 11 Nov 2004) The patch also fixes a potential hang, which happens when I try to build the latest matplotlib on Debian Etch with Python 2.4, on a system with libtk8.4-dev installed but no running X server. The build should have continued without TkAgg support, but it hangs. The hang occurs because the Tcl/Tk checking code calls Tkinter.Tk() multiple times, which is not a good idea. In fact, just running the following snippet hangs the interpreter in this scenario: import Tkinter tk = Tkinter.Tk() tk = Tkinter.Tk() The patch applies to setupext.py in revision r3975. I checked it with matplotlib r4064, using Python 2.4 on Debian Etch, and Python 2.5 on Mac OS X 10.4.10. Could someone please check it with Python 2.3 and on Windows? Regards, Ludwig setupext.py.patch Description: Binary data - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ghostscript version fix
Hi all,
I just installed mpl on ubuntu gutsy, and got errors after setting
text.usetex : True and ps.usedistiller : ghostscript. The problem seems
to be in checkdep_ghostscript() in __init__.py, specifically the command 'gs
-v' (should be replaced by 'gs --version').
For my system I get:
$ gs -v
GPL Ghostscript SVN PRE-RELEASE 8.61 (2007-08-02)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
and:
$ gs --version
8.61
Below I give a modified version of checkdep_ghostscript() that should work
for all version of ghostscript.
Cheers,
Ralf
def checkdep_ghostscript():
try:
if sys.platform == 'win32':
command = 'gswin32c -v'
else:
command = 'gs --version'
stdin, stdout = os.popen4(command)
line = stdout.readlines()[0]
vtest = '.'.join(line.split('.')[:2]) # deal with version numbers like '
7.07.1'
float(vtest)
return vtest
except (IndexError, ValueError):
return None
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ghostscript version fix
On Tuesday 30 October 2007 09:33:53 pm Ralf Gommers wrote:
> Hi all,
>
> I just installed mpl on ubuntu gutsy, and got errors after setting
> text.usetex : True and ps.usedistiller : ghostscript. The problem seems
> to be in checkdep_ghostscript() in __init__.py, specifically the command
> 'gs -v' (should be replaced by 'gs --version').
> For my system I get:
> $ gs -v
> GPL Ghostscript SVN PRE-RELEASE 8.61 (2007-08-02)
> Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
>
> and:
> $ gs --version
> 8.61
>
> Below I give a modified version of checkdep_ghostscript() that should work
> for all version of ghostscript.
>
> Cheers,
> Ralf
>
>
>
> def checkdep_ghostscript():
> try:
> if sys.platform == 'win32':
> command = 'gswin32c -v'
> else:
> command = 'gs --version'
> stdin, stdout = os.popen4(command)
> line = stdout.readlines()[0]
> vtest = '.'.join(line.split('.')[:2]) # deal with version numbers like
> ' 7.07.1'
> float(vtest)
> return vtest
> except (IndexError, ValueError):
> return None
Thanks for the report. This was already fixed in svn, but not using --version,
which looks like a better solution. Could someone using AFPL ghostscript let
us know what is the output of gs --version?
Darren
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote: > As some of you probably know, I've been working on a fairly major > refactoring of matplotlib. It's now getting to the point where I think > more people may want to check it out and kick the tires. It is > definitely not ready for real work -- I guarantee the first thing you > try will break ;) The first thing I tried was to enable the new config package and run backend_driver. I'm impressed, I saw only one error that doesnt occur in the trunk: driving mri_with_eeg.py Traceback (most recent call last): File "_tmp_mri_with_eeg.py", line 13, in from matplotlib.transforms import get_bbox_transform, Point, Value, Bbox,\ ImportError: cannot import name get_bbox_transform backend_driver was a little slow to run on the transforms branch: Backend Agg took 2.94 minutes to complete template ratio 1.527, template residual 1.015 Backend PS took 1.80 minutes to complete template ratio 0.933, template residual -0.129 Backend Template took 1.92 minutes to complete template ratio 1.000, template residual 0.000 Backend PDF took 2.17 minutes to complete template ratio 1.129, template residual 0.248 Backend SVG took 2.08 minutes to complete template ratio 1.082, template residual 0.158 as compared to the trunk: Backend Agg took 1.53 minutes to complete template ratio 1.628, template residual 0.589 Backend PS took 1.34 minutes to complete template ratio 1.426, template residual 0.399 Backend Template took 0.94 minutes to complete template ratio 1.000, template residual 0.000 Backend PDF took 1.62 minutes to complete template ratio 1.726, template residual 0.680 Backend SVG took 1.45 minutes to complete template ratio 1.548, template residual 0.514 > However, it is passing the vast majority of examples in examples/ (with > some major exceptions). The only working backends are Agg and all > Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been > attempted, and I'm certain is broken. There's a very good chance that > external tools like basemap will not work at all. If you care about any > of these missing things, you may not want to try the branch yet, or > better yet, you may want to check out the branch and get those things > working ;) Or, please let me know if the changes make any of those > things much harder to do, so the design can be refined while we still > have the chance ;) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote: > > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > >> When I go to the enthought web site, the most recent traits release I > >> see is 1.1, from August 2006. That doesn't make me optimistic about > >> traits as an external dependency any time soon. > > That's because the website is unmaintained. There have been two releases > > lately. One during scipy, and one mainly bug fix and small improvements, > > last week. > > This shows that enthought is really bad at communicating there work, > > something that I have come to realize, and that is a major prolblem. > > The software it self is pretty good, it just lacks packaging (I have more > > and more doubts about eggs), good release plans, and testing with > > different uses than enthought's. > During the last Scipy conference, Fernando Perez and (I think) Dave > Peterson tracked down the source of a performance hit when we use our new > config package, which uses traits. They determined it was an issue with > setuptools. Do you know what is enthought's current thinking about using > setuptools? Their official thinking is to stick to it, and to improve it. But I have started release tarball that require setuptools only to build, but not at run-time. They are being used to package traits, traitsUI and mayavi2 in Debian. I would be happy to guive more info about that, but I am currently travelling, and my internet access is very poor. Beta versions of tarballs are on http://code.enthought.com/downloads/source . I will make cleaner tarballs of the release that was done last week when I get back home. These tarballscan be used for eg packaging, or integrating the dependency, as Fernando does in ipython. Cheers, Gael - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > When I go to the enthought web site, the most recent traits release I > see is 1.1, from August 2006. That doesn't make me optimistic about > traits as an external dependency any time soon. That's because the website is unmaintained. There have been two releases lately. One during scipy, and one mainly bug fix and small improvements, last week. This shows that enthought is really bad at communicating there work, something that I have come to realize, and that is a major prolblem. The software it self is pretty good, it just lacks packaging (I have more and more doubts about eggs), good release plans, and testing with different uses than enthought's. Gael - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Wednesday 31 October 2007 12:07:12 pm Gael Varoquaux wrote: > On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote: > > > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > > >> When I go to the enthought web site, the most recent traits release I > > >> see is 1.1, from August 2006. That doesn't make me optimistic about > > >> traits as an external dependency any time soon. > > > > > > That's because the website is unmaintained. There have been two > > > releases lately. One during scipy, and one mainly bug fix and small > > > improvements, last week. > > > > > > This shows that enthought is really bad at communicating there work, > > > something that I have come to realize, and that is a major prolblem. > > > > > > The software it self is pretty good, it just lacks packaging (I have > > > more and more doubts about eggs), good release plans, and testing with > > > different uses than enthought's. > > > > During the last Scipy conference, Fernando Perez and (I think) Dave > > Peterson tracked down the source of a performance hit when we use our new > > config package, which uses traits. They determined it was an issue with > > setuptools. Do you know what is enthought's current thinking about using > > setuptools? > > Their official thinking is to stick to it, and to improve it. But I have > started release tarball that require setuptools only to build, but not at > run-time. They are being used to package traits, traitsUI and mayavi2 in > Debian. I would be happy to guive more info about that, but I am > currently travelling, and my internet access is very poor. > > Beta versions of tarballs are on > http://code.enthought.com/downloads/source . I will make cleaner tarballs > of the release that was done last week when I get back home. These > tarballscan be used for eg packaging, or integrating the dependency, as > Fernando does in ipython. This is just what we are looking for. Please let me know when the new tarballs are available. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] STIX fonts
The STIX fonts issued their first beta release today. I added the fonts to mpl-data/fonts/otf. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
On 10/31/07, Darren Dale <[EMAIL PROTECTED]> wrote: > The STIX fonts issued their first beta release today. Darren, today is Halloween, not April Fools. We are not that gullible. :-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
On Wednesday 31 October 2007 03:48:20 pm John Hunter wrote: > On 10/31/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > The STIX fonts issued their first beta release today. > > Darren, today is Halloween, not April Fools. We are not that gullible. > > :-) They didn't include a copy of their license agreement in the zip file. I added a copy in license/ and fonts/otf/ Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
