Re: [matplotlib-devel] Adding Backends
Eric Firing wrote: > Ryan May wrote: > >> Eric Firing wrote: >> >>> rcsetup can't get it from backends/__init__.py because that would set >>> a backend selection in stone. But backends/__init__.py can get it >>> from rcsetup, and I am in the process of making that change on the >>> trunk. This duplication had annoyed me earlier, but I didn't do >>> anything about it then. Thanks for the prompt. >>> >> Good to know. If you can't get to it, let me know and I'll take a stab. >> > > It's done now. > > >>> Are you actually looking into adding a new backend? >>> >> Yeah. I'm finally getting back around to the OpenGL backend I've been >> kicking around for awhile now, based (right now) on Gtk. gtkglext >> (which has python bindings) will let you render to a pixmap, so that >> should make it easy to integrate into the current matplotlib way of >> doing things. If things go well, I should have more on this after awhile. >> > > Is the motivation 3D plotting? > I am all ears ;) JCT > Eric > > - > 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 > - 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] future of mpl documentation
On Monday 02 June 2008 08:33:55 Michael Droettboom wrote:
> Darren Dale wrote:
> > On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
> >> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
> >>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <[EMAIL PROTECTED]>
> >
> > I tracked this down by checking the contents of the generated
> > build/latex/Matplotlib.tex, line 954. It is from the following code from
> >
> > mathtext.rst:
> >> When using the STIX fonts, you also have the choice of:
> >>
> >> =
> >> Command Result
> >> =
> >> ``\mathbb`` :math:`\mathbb{Blackboard}`
> >> ``\mathcircled`` :math:`\mathcircled{Circled}`
> >> ``\mathfrak``:math:`\mathfrak{Fraktur}`
> >> ``\mathsf`` :math:`\mathsf{sans-serif}`
> >> =
> >
> > I'm not sure this is being properly rendered in the HTML output for me,
> > either. Mike, are you able to compile this into a pdf on your machine,
> > and if so, would you tell us how to configure STIX support? I commented
> > this block out in svn for now.
>
> Sorry about that. It requires the amssymb and/or amsmath LaTeX packages
> to render correctly. Perhaps it is better to not require the LaTeX
> installation to have anything special though. I think the best course
> of action is to just include pre-generated images in the documentation
> source for this. I'll go ahead and do that.
I added doc/static_figs to hold scripts that require optional dependencies to
generate images for the docs. I would like to be able to keep track of how the
images are generated, so if we lose one we know how to recreate it. I added
two scripts (softlinks actually) a README and a make.py to that directory.
make.py saves the images to doc/_static.
-
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] future of mpl documentation
On Monday 02 June 2008 09:12:45 Michael Droettboom wrote: > John Hunter wrote: > > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > >> I'll be working on converting docstrings to rest this weekend. Should > >> any of this be done on the branch? Or should we just focus on the trunk? > > > > As far as I am concerned, the documentation effort is for the trunk. > > The only reason to do them on the branch too is to make merges of > > other code changes easier, which may be a compelling reason. If the > > docstrings get far out of whack, it may make merging other changes > > very painful. But at the same time, I don't want the burden of > > trying to keep the two in sync stopping you from getting the work done > > that you need to do. Maybe you can try it and see how hard it is, and > > if proves to be too much of an impediment, just concentrate on the > > trunk. Michael, any advice here? > > I was away on the weekend, so just getting back. Darren: you rock. The > documentation is looking great! I agree, the documentation is coming along nicely. But I don't think I should be singled out for credit, there's lots of good stuff appearing that I haven't had anything to do with. - 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] [Enthought-dev] Python novice stumped by ImportError
Hey guys, Just got back from 3 weeks holydays (that feels really good, I should try this more often). I a fighting with a mountain of emails, but I just wanted to give a little heads up. Tout is working on the codebase that I originally wrote and got me addicted to the ETS, at the university of Toronto. He tried updating and did run in some minor incompatibility (some ".api" added, not the end of the word, I believe). However, more working (Darren Dale is Cced about that) is that matplotib includes its own version of Traits and tends to be quite light on the policy to decide when to overide the system one. As a result, and recent version of MPL make the code base die in the ETS parts. I have already mentioned this problem, and I believe it is a really evil one. I don't have time to do some lobbying about this right now, could someone make sure this is solved (Darren?). IMHO one temporary solution, less ugly then the current one, is the one we used in nipy: define a matplotlib.externals.traits that can point either to a system-wide traits, or to the embedded traits. Using some code in matplotlib.externals similar to: """ def import_traits(): """ Import traits, either from a system-wide location, or from our copy. """ try: from enthought import traits except ImportError: from matplotlib.externals.enthought import traits return traits traits = import_traits() """ You can put as much logics as you want in "import_traits" to check eg for version numbers. If in MPL you only import traits from matplotlib.traits, you can thus use traits and not have side effects on other libraries. IMHO, the current situation is untenable. Cheers, Gaël On Tue, Jun 03, 2008 at 01:51:40PM -0500, Dave Peterson wrote: >Tout Wang wrote: > That worked to resolve the ImportError for View but now it gets stuck > at ui. I think ui is still imported from enthought.traits.ui because > from enthought.traits.ui import ui > works just fine. It seems that the main problem is that the latest > version of Enthought has changed how things are imported, which is a > little annoying because I expected that newer versions would be almost > entirely backwards compatible. I wonder why this is? > Anyway, I have reverted to Enthon 1.0.0 (Python 2.4.3) and everything > imports just fine now from TraitsUI with the original code. >Enthon 1.0.0 was released in August of 2006. At that time (about 7,000 >svn revisions ago!) Traits was reporting itself as version 1.0.2. EPD >includes enthought.traits 2.0.4 as you've already seen. Even though our >policy on version numbers didn't come into being until well after Enthon >1.0.0 was released, I think it reasonable that there would be some >API-incompatible changes between version 1 and version 2. >IIRC, the changes between these versions are more about adding features >than they are about breaking or leaving behind functionality. Yes, the >locations of where to import some things may have changed (centralized to >an api.py rather than in __init__.py) but in general most everything else >should work pretty much the same. - 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] [Enthought-dev] Python novice stumped by ImportError
On Sunday 08 June 2008 16:57:56 Gael Varoquaux wrote: > Hey guys, > > Just got back from 3 weeks holydays (that feels really good, I should try > this more often). I a fighting with a mountain of emails, but I just > wanted to give a little heads up. Tout is working on the codebase that I > originally wrote and got me addicted to the ETS, at the university of > Toronto. > > He tried updating and did run in some minor incompatibility (some ".api" > added, not the end of the word, I believe). > > However, more working (Darren Dale is Cced about that) is that matplotib > includes its own version of Traits and tends to be quite light on the > policy to decide when to overide the system one. As a result, and recent > version of MPL make the code base die in the ETS parts. I have already > mentioned this problem, and I believe it is a really evil one. I don't > have time to do some lobbying about this right now, could someone make > sure this is solved (Darren?). Matplotlib's setup scripts are designed to avoid this problem. There are three conditions under which we install traits: 1) Traits is not installed 2) A previous version of traits is installed, but it is a version installed by matplotlib. I added an "-mpl" to the end of traits __version__ string so we can keep track. 3) The user explicitly askes for it in setup.cfg So if matplotlib is overwriting traits when it should not, I want to fix it. But I need more information about what is causing it, because I don't see how it could happen. > IMHO one temporary solution, less ugly then the current one, is the one > we used in nipy: define a matplotlib.externals.traits that can point either > to a system-wide traits, or to the embedded traits. Using some code in > matplotlib.externals similar to: > > """ > def import_traits(): > """ Import traits, either from a system-wide location, or from our > copy. > """ > try: > from enthought import traits > except ImportError: > from matplotlib.externals.enthought import traits > return traits > > traits = import_traits() > """ > > You can put as much logics as you want in "import_traits" to check eg for > version numbers. If in MPL you only import traits from matplotlib.traits, > you can thus use traits and not have side effects on other libraries. I tried this when I first started working with TConfig, and concluded that it was not possible because there are too many places where traits expects enthought to be a top level package. There were all kind of errors, exceptions being raised that were not named as expected, extension code that would need to be modified, so we settled on the current solution. > IMHO, the current situation is untenable. Please, provide details so I can understand the problem. Darren - 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] imshow() extent issues with svn and 0.98.0
Andrew,
Yes, and it looks like there is more to it: the draw() method doesn't
seem to be working (or getting called at the right time) in interactive
mode, but no exception is being raised, either. I will look into it.
Eric
Andrew Straw wrote:
> Hi (Eric?),
>
> Re-running an older script of mine today, I notice a change of behavior
> with imshow(). The script below produces the attached 2 figures for MPL
> 0.91.3 and svn from today (labeled "0.98.0"). I believe that the
> behavior of 0.91.3 was correct -- the image is not cropped, its aspect
> ratio is maintained, and the data coordinates correspond to the pixel
> coordinates. I am also including the original image used in this example.
>
> import matplotlib, pylab
> import Image
>
> im = Image.open('eye_map.gif')
> im_extent = (0, im.size[0], 0, im.size[1])
> pylab.imshow(im,origin='lower',
> extent=im_extent,
> aspect='equal')
> fname = 'extent_bug_%s.png'%matplotlib.__version__
> pylab.savefig(fname)
>
> Please let me know if I can do more. Note that I have shifted the image
> mode to an 8-bit palette for the .pngs with GIMP to save space in this
> email, but otherwise the images are exactly as emitted by MPL.
>
> Thanks,
> Andrew
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> 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
-
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] [Enthought-dev] Python novice stumped by ImportError
On Sun, Jun 08, 2008 at 06:13:24PM -0400, Darren Dale wrote: > Matplotlib's setup scripts are designed to avoid this problem. There are > three > conditions under which we install traits: > 1) Traits is not installed > 2) A previous version of traits is installed, but it is a version installed > by > matplotlib. I added an "-mpl" to the end of traits __version__ string so we > can keep track. > 3) The user explicitly askes for it in setup.cfg > So if matplotlib is overwriting traits when it should not, I want to fix it. > But I need more information about what is causing it, because I don't see how > it could happen. If Traits is installed after MPL, if I get it right, then the problem occurs. IIRC, this is the problem I stumbled upon once. > I tried this when I first started working with TConfig, and concluded > that it was not possible because there are too many places where traits > expects enthought to be a top level package. There were all kind of > errors, exceptions being raised that were not named as expected, > extension code that would need to be modified, so we settled on the > current solution. OK. You are right. In nipy I modified enthought.traits and enthought.etsconfig. This was not a beautiful job, I must admit. Maybe monkey patching sys.path is the option (it is the way eggs do it) thought I must admit I hate it, because it puts a lot of magic, that will take the user by surprise. Anyway, the criteria for monkey-patching sys.path must be improved, I feel. If I understand things correctly, the current problem can be described by: * User has an old version of ETS, (the one in Enthon 1.0.4, that is a very old one), his code needs the old version. * User installs a new version of MPL. * His code stops working. I agree that as you describe things, this should not happen. Maybe I have gotten wrong the order in which the user did things. I have the feeling things shouldn't be dependent on the order in which you do the steps (maybe the test for monkey-patching sys.path should not be at install time, but at load time). Maybe the test fails for a very old version of traits. I wanted to have a quick look at this code, but I can't find it after a quick scan of the MPL source, and I can't devote much time to this right now. Cheers, Gaël - 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
