Re: [matplotlib-devel] New flags in IPython, of interest to matplotlib users
On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote: > You can now do this as well: > tlon[~]> ipython -wthread -pylab --nobanner > In [1]: matplotlib.rcParams['backend'] > Out[1]: 'WXAgg' Hurray, mayavi and pylab can now easily live together. Thanks heaps Fernando. Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New flags in IPython, of interest to matplotlib users
Hi all, This was posted to the ipython-dev list, but since it's specifically for MPL, I figured the cross-list spam would be forgiven. In IPython SVN, I just added the ability to manually control the pylab threading backend choice directly from the command line. So for example if by default you have: tlon[~]> ipython -pylab --nobanner In [1]: matplotlib.rcParams['backend'] Out[1]: 'TkAgg' You can now do this as well: tlon[~]> ipython -wthread -pylab --nobanner In [1]: matplotlib.rcParams['backend'] Out[1]: 'WXAgg' In [2]: Closing threads... Done. tlon[~]> ipython -gthread -pylab --nobanner In [1]: matplotlib.rcParams['backend'] Out[1]: 'GTKAgg' The feature is fairly simplistic: the -Xthread flags map automatically to the XAgg backends in MPL, with no more fine-grained choice than that. We can later look into allowing explicit backend selection if you really scream for it, but I'd rather keep this simple. This means that if you don't have the *Agg builds of the GUI backends, you'll still need to do the backend selection by hand as before (i.e. by modifying your mpl config file). This has often been requested and I'd needed it myself on multiple occasions, so it's finally in. Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding a water mark to a plot
You could add some semi-transparent text across the figure with something like: gcf().text(0.1, 0.1, "Watermark", rotation=45, fontproperties=FontProperties(size=64), alpha=0.2) Unfortunately, alpha-transparency on text is not supported in the Agg and Svg backends (more due to an oversight than it being terribly difficult to implement -- I can try to get this in for the 0.91.2 release). But it does work on Pdf and Cairo. (Supporting it in Ps will be quite difficult). There may also be external tools to do this *after* generating the plot from matplotlib, e.g.: http://www.selonen.org/arto/netbsd/watermarks.html Cheers, Mike Nils Wagner wrote: > Hi all, > > Is it possible to add a water mark to a plot ? > > Nils > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > 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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New flags in IPython, of interest to matplotlib users
I'm curious about the term 'threading backend'. Recently I posted a question about how to handle slow plots, suggesting that the backend canvas have an isabort() method so that the renderer can stop what it is doing and post the current bitmap as it stands. This is to support interactive operations such as panning and resizing on large data collections. Do you mean something similar when you say 'threading backend', and is it already supported in IPython? - Paul On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote: > Hi all, > > This was posted to the ipython-dev list, but since it's specifically > for MPL, I figured the cross-list spam would be forgiven. > > In IPython SVN, I just added the ability to manually control the pylab > threading backend choice directly from the command line. So for > example if by default you have: > > tlon[~]> ipython -pylab --nobanner > > In [1]: matplotlib.rcParams['backend'] > Out[1]: 'TkAgg' > > You can now do this as well: > > tlon[~]> ipython -wthread -pylab --nobanner > > In [1]: matplotlib.rcParams['backend'] > Out[1]: 'WXAgg' > > In [2]: > Closing threads... Done. > tlon[~]> ipython -gthread -pylab --nobanner > > In [1]: matplotlib.rcParams['backend'] > Out[1]: 'GTKAgg' > > The feature is fairly simplistic: the -Xthread flags map automatically > to the XAgg backends in MPL, with no more fine-grained choice than > that. We can later look into allowing explicit backend selection if > you really scream for it, but I'd rather keep this simple. This means > that if you don't have the *Agg builds of the GUI backends, you'll > still need to do the backend selection by hand as before (i.e. by > modifying your mpl config file). > > This has often been requested and I'd needed it myself on multiple > occasions, so it's finally in. > > Cheers, > > f > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Adding optional setuptools to setup.py
Hi, I just sent a similar e-mail to the ipython-def mailing list: I am not a big proponent of setuptools, but I must admit they have really nice feature for developpers: "python setup.py develop", which does the Python equivalent of a symlink during the install so that it uses the source code from the check out to run. I would like to add these lines to the setup.py: """ try: from setuptools import setup, find_packages except ImportError: pass """ I cannot see waht harm this can do, and I can see the benefit: I install an svn checkout of MPL with: """ sudo python setup.py develop --prefix /usr/local """ and then maintain this check out by doing "svn up", and this even in windows. What do you think? Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding optional setuptools to setup.py
We added "setupegg.py" a long time ago which does exactly this. The
line below would then be:
python setupegg.py develop
On Dec 12, 2007 12:35 PM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> > If we're going to use setuptools (actually already required for Python
> > 2.3), I think we need to do it completely and not optionally --
> > otherwise users will start to depend on its features, which simply won't
> > be there in some cases. In particular, I suspect they will make use of
> > the dependency resolution mechanisms. As I suggested on the ipython-dev
> > list this will do what you want without requiring a change to setup.py:
>
> > python -c "import setuptools; execfile('setup.py')" develop
>
> OK, I'll settle for this.
>
> Gaël
>
> -
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding optional setuptools to setup.py
On Wed, Dec 12, 2007 at 01:40:38PM -0500, Charlie Moad wrote: > We added "setupegg.py" a long time ago which does exactly this. The > line below would then be: > python setupegg.py develop Sorry. I am being really brain dead today. Thanks, Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding optional setuptools to setup.py
On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> If we're going to use setuptools (actually already required for Python
> 2.3), I think we need to do it completely and not optionally --
> otherwise users will start to depend on its features, which simply won't
> be there in some cases. In particular, I suspect they will make use of
> the dependency resolution mechanisms. As I suggested on the ipython-dev
> list this will do what you want without requiring a change to setup.py:
> python -c "import setuptools; execfile('setup.py')" develop
OK, I'll settle for this.
Gaël
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] new location of home.ppm
Hello - It seems that in the latest version (0.9.1) the location of the images, such as home.ppm, has moved to a new directory. It used to be in ...\mpl-data and now it is in ...\mpl-data\images This totally breaks my code, as I use my own toolbar that uses these images, with a hardcoded location of the ppm files. I know, I should from now on distribute these ppm files with the distribution of my own program, but there may be others that have this problem. Not sure what the best solution is. WIll it remain in this new images directory from now on? Thanks, Mark ps. Cross-posted on the users and development list ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just needed to point out this backwards incompatibility, which may just be ugly coding on my part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] new location of home.ppm
On Dec 12, 2007 1:29 PM, Mark Bakker <[EMAIL PROTECTED]> wrote: > It seems that in the latest version (0.9.1) the location of the images, such > as home.ppm, has moved to a new directory. > It used to be in ...\mpl-data and now it is in ...\mpl-data\images > > This totally breaks my code, as I use my own toolbar that uses these images, > with a hardcoded location of the ppm files. I know, I should from now on > distribute these ppm files with the distribution of my own program, but > there may be others that have this problem. > > Not sure what the best solution is. WIll it remain in this new images > directory from now on? Can't say for sure, but we have no plans to move it. You may want to follow the API_CHANGES at http://matplotlib.sf.net/API_CHANGES, which we update whenever we do something that breaks code. This move to the images subdirectory in the install directory was noted with: Moved data files into lib/matplotlib so that setuptools' develop mode works. Re-organized the mpl-data layout so that this source structure is maintained in the installation. (I.e. the 'fonts' and 'images' sub-directories are maintained in site-packages.). Suggest removing site-packages/matplotlib/mpl-data and ~/.matplotlib/ttffont.cache before installing Admittedly a bit cryptic. JDH > > Thanks, > > Mark > > ps. Cross-posted on the users and development list > ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just > needed to point out this backwards incompatibility, which may just be ugly > coding on my part > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Matplotlib-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding optional setuptools to setup.py
If we're going to use setuptools (actually already required for Python
2.3), I think we need to do it completely and not optionally --
otherwise users will start to depend on its features, which simply won't
be there in some cases. In particular, I suspect they will make use of
the dependency resolution mechanisms. As I suggested on the ipython-dev
list this will do what you want without requiring a change to setup.py:
python -c "import setuptools; execfile('setup.py')" develop
Gael Varoquaux wrote:
> Hi,
>
> I just sent a similar e-mail to the ipython-def mailing list:
> I am not a big proponent of setuptools, but I must admit they have really
> nice feature for developpers: "python setup.py develop", which does the
> Python equivalent of a symlink during the install so that it uses the
> source code from the check out to run.
>
> I would like to add these lines to the setup.py:
>
> """
> try:
> from setuptools import setup, find_packages
> except ImportError:
> pass
> """
>
> I cannot see waht harm this can do, and I can see the benefit: I install
> an svn checkout of MPL with:
>
> """
> sudo python setup.py develop --prefix /usr/local
> """
>
> and then maintain this check out by doing "svn up", and this even in
> windows.
>
> What do you think?
>
> Gaël
>
> -
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] modifying TConfig
Hi, I definetely don't like the fact that .__repr__() and repr() are used all over TConfig for eg storing to file. First of all I would like to modify __repr__ for a TConfig class to give a more synthetic view. I propose to change the current ".__repr__()" method to ".tostring()" and to implement a more readable ".__repr__()". Are the different people interested in these issues OK with that? If yes, where is the authoritative repo for TConfig? Which SVN should I start hacking? Cheers, Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote: > Hi, > > I definetely don't like the fact that .__repr__() and repr() are used all > over TConfig for eg storing to file. > > First of all I would like to modify __repr__ for a TConfig class to give > a more synthetic view. > > I propose to change the current ".__repr__()" method to ".tostring()" and > to implement a more readable ".__repr__()". > > Are the different people interested in these issues OK with that? If yes, > where is the authoritative repo for TConfig? Which SVN should I start > hacking? I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it doesnt matter in practice because I keep the two in sync. I do want to be able to save the verbose information to a file, since we want to be able to generate a commented file that people can use to learn how to make modifications. If that doesnt change, I don't have an objection to making __repr__ terse. Darren - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
On Dec 12, 2007 6:34 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > > On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote: > > Hi, > > > > I definetely don't like the fact that .__repr__() and repr() are used all > > over TConfig for eg storing to file. > > > > First of all I would like to modify __repr__ for a TConfig class to give > > a more synthetic view. > > > > I propose to change the current ".__repr__()" method to ".tostring()" and > > to implement a more readable ".__repr__()". > > > > Are the different people interested in these issues OK with that? If yes, > > where is the authoritative repo for TConfig? Which SVN should I start > > hacking? > > I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it > doesnt matter in practice because I keep the two in sync. > > I do want to be able to save the verbose information to a file, since we want > to be able to generate a commented file that people can use to learn how to > make modifications. If that doesnt change, I don't have an objection to > making __repr__ terse. On second thought though: __str__ is the one meant for 'human consumption', while __repr__ is deliberately meant to be much more machine-like. Basically the idea is that, whenever possible, one can do x == eval(repr(x)) That is true for many of the builtin data types of the language. Quoting http://docs.python.org/ref/customization.html#l2h-179 : __repr__( self) Called by the repr() built-in function and by string conversions (reverse quotes) to compute the ``official'' string representation of an object. If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value (given an appropriate environment). If this is not possible, a string of the form "<...some useful description...>" should be returned. The return value must be a string object. If a class defines __repr__() but not __str__(), then __repr__() is also used when an ``informal'' string representation of instances of that class is required. This is typically used for debugging, so it is important that the representation is information-rich and unambiguous. So Gael, would you be OK with a terser str() and leaving repr to honor this python convention? Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New flags in IPython, of interest to matplotlib users
On Dec 12, 2007 7:16 AM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > I'm curious about the term 'threading backend'. > > Recently I posted a question about how to handle slow plots, suggesting > that the backend canvas have an isabort() method so that the renderer > can stop what it is doing and post the current bitmap as it stands. > This is to support interactive operations such as panning and resizing > on large data collections. > > Do you mean something similar when you say 'threading backend', and is > it already supported in IPython? No, it just means that ipython can run in conjunction with the major GUI toolkits in a non-blocking manner. In a plain python shell, if you open a plot window (for any backend other than Tk), you can't go back to the prompt and keep typing until you close the plot. IPython allows that to happen, with Wx, GTK, Qt and Qt4. Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
On Dec 12, 2007 5:58 PM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > Hi, > > I definetely don't like the fact that .__repr__() and repr() are used all > over TConfig for eg storing to file. > > First of all I would like to modify __repr__ for a TConfig class to give > a more synthetic view. > > I propose to change the current ".__repr__()" method to ".tostring()" and > to implement a more readable ".__repr__()". > > Are the different people interested in these issues OK with that? If yes, I'm OK with it. > where is the authoritative repo for TConfig? Which SVN should I start > hacking? It's probably easier for now to use ipython, since both you and Darren both have SVN write access to it. Unless Darren has a different opinion... Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
