matplotlib-devel Mailing List for matplotlib (Page 6)

Here is a patch to add linestyles to patches.py. I have tried it with 
unfilled step histograms (important for b/w print and colour blind 
people).

What do you think?

Cheers,
Olle

hist(histtype="step") worked fine in rev5412, but in the latest I get

>>> hist(randn(1000), histtype="step")
Traceback (most recent call last):
/.../
     raise TypeError, 'There is no patch property "%s"'%key
TypeError: There is no patch property "closed"


Changing
closed = kwargs.get('closed', True)
back to
closed = kwargs.pop('closed')

in axes.py helps (but there was probably a reason for the change in the 
first place)

Cheers,
Olle

Hi Mike,

I just updated to r5595 and both rgrids and thetagrids work perfectly.

Thanks for your help.
-Tony


On Jun 19, 2008, at 9:24 AM, Michael Droettboom wrote:

> That's a bug created by not updating thetagrids and rgrids after the  
> recent transformation refactoring.
>
> I believe it is not fixed in r5594.  Can you update and let me know  
> if you're still having trouble?
>
> Thanks,
> Mike
>
> Tony Yu wrote:
>> I was playing around with polar plots and trying to alter the grid  
>> labels when I ran into some weird errors. Whenever I call  
>> pyplot.thetagrids() (and similarly with rgrids) I get:
>>
>> *>>> AttributeError:* 'PolarAxesSubplot' object has no attribute  
>> 'thetagridlines
>>
>> After searching the MPL directory, it didn't seem like  
>> thetagridlines was defined anywhere. Alternatively, If I call  
>> thetagrids with an argument [e.g. thetagrids(range(45,360,90))], I  
>> get
>>
>> *>>> TypeError:* 'NoneType' object is not iterable
>>
>> which comes from the following line in pyplot:
>>
>> >>> lines, labels = ax.set_thetagrids(*args, **kwargs)
>>
>> Strangely, the set_thetagrids method of PolarAxes doesn't return  
>> any values and this is causing the TypeError above.
>>
>> I'm really confused about these errors. Any help would be greatly  
>> appreciated.
>>
>> -Tony
>>
>> PS: Full tracebacks are shown below. I'm on MPL trunk, r5588.
>>
>> CASE 1:
>> ------------
>> Traceback (most recent call last):
>>  File "polar.py", line 19, in <module>
>>    lines, labels = thetagrids()
>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
>> matplotlib/pyplot.py", line 984, in thetagrids
>>    lines = ax.thetagridlines()
>> AttributeError: 'PolarAxesSubplot' object has no attribute  
>> 'thetagridlines'
>>
>> CASE 2:
>> ------------
>> Traceback (most recent call last):
>>  File "polar.py", line 19, in <module>
>>    lines, labels = thetagrids(range(45,360,90))
>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
>> matplotlib/pyplot.py", line 987, in thetagrids
>>    lines, labels = ax.set_thetagrids(*args, **kwargs)
>> TypeError: 'NoneType' object is not iterable
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> 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
>

That's a bug created by not updating thetagrids and rgrids after the 
recent transformation refactoring.

I believe it is not fixed in r5594.  Can you update and let me know if 
you're still having trouble?

Thanks,
Mike

Tony Yu wrote:
> I was playing around with polar plots and trying to alter the grid 
> labels when I ran into some weird errors. Whenever I call 
> pyplot.thetagrids() (and similarly with rgrids) I get:
>
> *>>> AttributeError:* 'PolarAxesSubplot' object has no attribute 
> 'thetagridlines
>
> After searching the MPL directory, it didn't seem like thetagridlines 
> was defined anywhere. Alternatively, If I call thetagrids with an 
> argument [e.g. thetagrids(range(45,360,90))], I get
>
> *>>> TypeError:* 'NoneType' object is not iterable
>
> which comes from the following line in pyplot:
>
> >>> lines, labels = ax.set_thetagrids(*args, **kwargs)
>
> Strangely, the set_thetagrids method of PolarAxes doesn't return any 
> values and this is causing the TypeError above.
>
> I'm really confused about these errors. Any help would be greatly 
> appreciated.
>
> -Tony
>
> PS: Full tracebacks are shown below. 
> I'm on MPL trunk, r5588.
>
> CASE 1:
> ------------
> Traceback (most recent call last):
>   File "polar.py", line 19, in <module>
>     lines, labels = thetagrids()
>   File 
> "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/pyplot.py", 
> line 984, in thetagrids
>     lines = ax.thetagridlines()
> AttributeError: 'PolarAxesSubplot' object has no attribute 
> 'thetagridlines'
>
> CASE 2:
> ------------
> Traceback (most recent call last):
>   File "polar.py", line 19, in <module>
>     lines, labels = thetagrids(range(45,360,90))
>   File 
> "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/pyplot.py", 
> line 987, in thetagrids
>     lines, labels = ax.set_thetagrids(*args, **kwargs)
> TypeError: 'NoneType' object is not iterable
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> 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

I was playing around with polar plots and trying to alter the grid  
labels when I ran into some weird errors. Whenever I call  
pyplot.thetagrids() (and similarly with rgrids) I get:

 >>> AttributeError: 'PolarAxesSubplot' object has no attribute  
'thetagridlines

After searching the MPL directory, it didn't seem like thetagridlines  
was defined anywhere. Alternatively, If I call thetagrids with an  
argument [e.g. thetagrids(range(45,360,90))], I get

 >>> TypeError: 'NoneType' object is not iterable

which comes from the following line in pyplot:

 >>> lines, labels = ax.set_thetagrids(*args, **kwargs)

Strangely, the set_thetagrids method of PolarAxes doesn't return any  
values and this is causing the TypeError above.

I'm really confused about these errors. Any help would be greatly  
appreciated.

-Tony

PS: Full tracebacks are shown below.
I'm on MPL trunk, r5588.

CASE 1:
------------
Traceback (most recent call last):
   File "polar.py", line 19, in <module>
     lines, labels = thetagrids()
   File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
pyplot.py", line 984, in thetagrids
     lines = ax.thetagridlines()
AttributeError: 'PolarAxesSubplot' object has no attribute  
'thetagridlines'

CASE 2:
------------
Traceback (most recent call last):
   File "polar.py", line 19, in <module>
     lines, labels = thetagrids(range(45,360,90))
   File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
pyplot.py", line 987, in thetagrids
     lines, labels = ax.set_thetagrids(*args, **kwargs)
TypeError: 'NoneType' object is not iterable

Of course, this depends on what you mean by transparency.  If you mean 
to change the alpha of the entire PNG, then yes, the global parameter 
(or postprocessing) is the way to go.  But I'm not sure how useful that 
is -- that will still lighten things behind the figure and axes patch. 

A more useful option, IMHO, would be to just make the figure patch and 
axes patch fully transparent and leave everything else "as is".  That 
avoids the "white box on a colored background" problem.

Cheers,
Mike

Christopher Barker wrote:
> Nils Wagner wrote:
>   
>>   "John Hunter" <jd...@gm...> wrote:
>>     
>>> I wonder if we should support a global rc alpha....
>>>       
>
> I'd make it an optional parameter to savefig(), but I like the idea.
>
> Of course one could pretty easily post-process it as well.
>
> -CHB
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Nils Wagner wrote:
>   "John Hunter" <jd...@gm...> wrote:
>> I wonder if we should support a global rc alpha....

I'd make it an optional parameter to savefig(), but I like the idea.

Of course one could pretty easily post-process it as well.

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Wed, 18 Jun 2008 09:17:27 -0500
  "John Hunter" <jd...@gm...> wrote:
> On Wed, Jun 18, 2008 at 8:56 AM, Nils Wagner
> <nw...@ia...> wrote:
> 
>> Is it possible to produce transparent png's with mpl ?
> 
> Yes, but you must explicitly set the transparency on 
>every object you
> want to be transparent::
> 
>  fig = plt.figure()
>  fig.figurePatch.set_alpha(0.5)
> 
>  ax = fig.add_subplot(111)
>  ax.axesPatch.set_alpha(0.5)
> 
>  l, = ax.plot(x, y, alpha=0.8)
> 
>  t = ax.set_xlabel('hi', alpha=0.8)
> 
> and so on....
> 
> I wonder if we should support a global rc alpha....
> 
   +1

  Nils

On Wed, Jun 18, 2008 at 8:56 AM, Nils Wagner
<nw...@ia...> wrote:

> Is it possible to produce transparent png's with mpl ?

Yes, but you must explicitly set the transparency on every object you
want to be transparent::

  fig = plt.figure()
  fig.figurePatch.set_alpha(0.5)

  ax = fig.add_subplot(111)
  ax.axesPatch.set_alpha(0.5)

  l, = ax.plot(x, y, alpha=0.8)

  t = ax.set_xlabel('hi', alpha=0.8)

and so on....

I wonder if we should support a global rc alpha....

JDH

PS: these kinds of questions are best for the users list.  In general:
"how do I?" or "does such a feature exist?" or "why doesn't this
work?" or "can you add this feature?" should go on users.  "this is
broken in svn" or "will you accept this patch" or "shouldn't the
function x do something else?" and the like should be on the devel

Hi all,

Is it possible to produce transparent png's with mpl ?

Nils

On Tue, Jun 17, 2008 at 5:47 PM, John Hunter <jd...@gm...> wrote:

> There are significant changes to image handling, how they are copied
> etc, between the prior sphinx version and HEAD, so I suspect we need
> to figure out if we need to do something different or if it is a
> plain-ol-bug.  I suspect the latter.
>
> I'll post on the sphinx list.

This bug is fixed in sphinx svn so another svn up is required.

JDH

On Tue, Jun 17, 2008 at 1:56 PM, Eric Firing <ef...@ha...> wrote:

> I did svn up on sphinx(0.3dev-20080617) and mpl (r5583), reinstalled
> both, and tried to build the docs.

I see this tool.  This looks like a sphinx change that we are not
accounting for (or a bug).  There is a sphinx log message:

    r64295 | georg.brandl | 2008-06-15 07:31:16 -0700 (Sun, 15 Jun
2008) | 2 lines

   Add image format handling.

There are significant changes to image handling, how they are copied
etc, between the prior sphinx version and HEAD, so I suspect we need
to figure out if we need to do something different or if it is a
plain-ol-bug.  I suspect the latter.

I'll post on the sphinx list.

JDH

I did svn up on sphinx(0.3dev-20080617) and mpl (r5583), reinstalled 
both, and tried to build the docs.

It got through the html and failed on the latex:

...

[4]
Chapter 2.
(/usr/share/texmf-texlive/tex/latex/txfonts/ot1txr.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsya.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyb.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxmia.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyc.fd)

LaTeX Warning: File `../pyplots/pyplot_simple.pdf' not found on input 
line 209.



!pdfTeX error: pdflatex (file ../pyplots/pyplot_simple.pdf): cannot find 
image
file
  ==> Fatal error occurred, no output PDF file produced!
Rendering LaTeX failed.

The file it is complaining about exists in several places:

efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ find . -name 
'pyplot_simple*'
./build/html/_images/pyplot_simple.png
./build/html/_images/pyplot_simple.pdf
./build/html/pyplots/.svn/text-base/pyplot_simple.py.svn-base
./build/html/pyplots/pyplot_simple.py
./build/html/pyplots/pyplot_simple.png
./build/html/pyplots/pyplot_simple.pdf
./build/html/pyplots/pyplot_simple.hires.png
./build/latex/pyplot_simple.png
./build/latex/pyplot_simple.pdf
./pyplots/.svn/text-base/pyplot_simple.py.svn-base
./pyplots/pyplot_simple.py
./pyplots/pyplot_simple.png
./pyplots/pyplot_simple.pdf
./pyplots/pyplot_simple.hires.png
./users/figures/pyplot_simple.png


And it is indeed a pdf:

efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ find . -name 
'pyplot_simple.pdf' -exec file {} \;
./build/html/_images/pyplot_simple.pdf: PDF document, version 1.4
./build/html/pyplots/pyplot_simple.pdf: PDF document, version 1.4
./build/latex/pyplot_simple.pdf: PDF document, version 1.4
./pyplots/pyplot_simple.pdf: PDF document, version 1.4

Eric

My patch to show the base classes of each class in Sphinx autodoc has 
been accepted.

http://groups.google.com/group/sphinx-dev/browse_thread/thread/cc9c3d80a4e483b9

I've updated our docs to use this feature (it requires adding the 
'show-inheritance' option to the autodoc directives).  This requires 
that everyone generating the docs does a "svn up" on Sphinx.  Our 
documentation instructions already say to use SVN Sphinx, so this isn't 
really a new requirement, and hopefully before long this will be part of 
a Sphinx release.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,

thank you for the fix. It works great now.


Mátyás János


On Mon, 16 Jun 2008 08:15:39 -0400
Michael Droettboom <md...@st...> wrote:

> Thanks.  mpl was applying the default alpha of 1.0 to the set of
> colors rather than ignoring it when an alpha is provided for each
> color.  This is now fixed in SVN r5554
> 
> Cheers,
> Mike
> 
> Mátyás János wrote:
> > Hi,
> >
> > setting colors with transparency no longer works for me in
> > 0.98.0, but worked before in 0.91.3:
> >
> > c = matplotlib.collections.LineCollection(lines, colors =
> > lineColors)
> >
> > This shows the lines only with the base colors without transparency.
> >
> > However, if I modify the code to the following, the colors shows
> > properly with transparency:
> >
> > c = matplotlib.collections.LineCollection(lines)
> > c.set_color(lineColors)
> >
> >
> > Mátyás János

On Tue, Jun 17, 2008 at 9:58 AM, Sandro Tosi <mat...@gm...> wrote:

> My plan (as one of maintainers of matplotlib in Debian) is to keep
> uploading 0.91.x in unstable, so it can migrate to testing (the
> staging area to prepare the next stable release) when needed, and
> prepare the 0.98.x package into experimental. I need this since 0.98
> introduced API changes, and I need to let depending packages check if
> they are compatible with this new version (if not, adapting them)
> before uploading to unstable and break things.
>
> Since numpy in unstable is already at 1.1.0 (scheduled to be migrated
> in testing in few days), I try my best to have 0.98.x in unstable
> asap, so to let lenny (the upcoming stable release) ship 0.98.x!

Hi Sandro, thanks for writing and all the work packaging matplotlib
for debian.

Just to be clear on the API changes: every release of matplotlib
pretty much has some API changes which are documented in the
API_CHANGES file).  They are usually quite minor, and 95% of our users
interact with matplotlib through the pylab/pyplot interface, which is
*extremely* stable, and pretty much hasn't changed since 0.1 and
probably will never change much.

The changes affect folks who use the matplotlib API directly, which
are probably 5% of our users, who are almost by definition the power
users.  0.98 introduced significantly more API changes (and features)
than a typical major release (hence the big bump in version number)
but nonetheless these have a very minor user facing impact.  We have
nearly 100 figure generating tests in our regression suite and all of
them are passing.  The major changes to the API occur for people
manipulating transformations directly, which is almost noone.

We are certainly discovering and fixing issues now that we are getting
some users on it with the 0.98.0 release, but the majority of these
are not API issues, but plain-ol-bugs or backend version issues,
etc...  We are trying to get a bug fix release out ASAP to address
these, but we want to balance getting as many bug reports in before we
do this since none of the bugs reported thus far have been critical.

Thanks again,
JDH

Hi guys,
sorry to have spotted it out late (the thread subject don't help :)
and thanks to Manuel to have notified me about this thread.

>   the debian maintainers are already aware of the new versions, see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486074
>
> According to them, matplotlib 0.98.x will be uploaded to experimental
> first, before it migrates to unstable. Unstable has been updated to
> 0.91.3 some days ago.

My plan (as one of maintainers of matplotlib in Debian) is to keep
uploading 0.91.x in unstable, so it can migrate to testing (the
staging area to prepare the next stable release) when needed, and
prepare the 0.98.x package into experimental. I need this since 0.98
introduced API changes, and I need to let depending packages check if
they are compatible with this new version (if not, adapting them)
before uploading to unstable and break things.

Since numpy in unstable is already at 1.1.0 (scheduled to be migrated
in testing in few days), I try my best to have 0.98.x in unstable
asap, so to let lenny (the upcoming stable release) ship 0.98.x!

Cheers,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi John

2008/6/12 John Hunter <jd...@gm...>:
> On Thu, Jun 12, 2008 at 7:56 AM, Stéfan van der Walt <st...@su...> wrote:
>
>> linestyle 'x' ---> legend  '   x   '
>> linestyle '-x' ---> legend '---x---'
>>
>> Has this been considered before?  If not, I'll write a patch.
>
> I think this is just something that has been overlooked.  The legend
> code is quite old, so don't be surprised if it looks a little crusty
> in there, as it was one of the early features, and it has been updated
> piecemeal with new features.  A patch would be great.

The idea I had was to plot two lines on top of each other: one for the
line-style, and one for the bullets.  Unfortunately, I can't get the
lines to co-incide.  Could you look at the attached toy-patch and tell
me where I am going wrong?  Note how the X is somewhat below the line.

Thanks
Stéfan

Chris Walker wrote:
> "John Hunter" <jd...@gm...> writes:
> 
>> On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker
>> <ch...@ch...> wrote:
>>
>>>> So if we want to support stable, *and*
>>>> the latest releases, we've got a lot of ongoing compatibility work to
>>>> do.  For backend maintainers willing to do it, I think that will be
>>>> good.  But I am hesitant to target such a slow moving repository as a
>>>> requirement.
>>> Would the next debian release (lenny) be a better target for
>>> development versions of matplotlib?
>>>
>>> What version of matplotlib do you want to go into the next debian release?
>> Hi Chris -- thanks for all the information.  
> 
> Pleasure, Hope it was useful, but please note I don't speak for the
> Debian Matplotlib maintainers.
> 
> There are some things I need to clarify though.
> 
> 
>> Since 0.98 requires numpy
>> 1.1, 0.98.1 (a bugfix release slated for next week or the week after)
>> should be in unstable and 0.91.4 (again a bugfix scheduled for next
>> week or the week after) should be in testing 
> 
> Ah, I think you may have misunderstood how debian
> stable/testing/unstable works.
> 
> A grossly oversimplified view[1] is as follows.
> 
> 1) A new version of the package is uploaded to sid (unstable) 
> 
> 2) When the package has been in sid (unstable) for 10 days, it is a
>    candidate for moving to lenny (testing). when they can do so
>    without breaking other packages lenny (testing).
> 
> 3) Eventually, lenny is released as the stable distribution, and you
>    are stuck with it for a year or two (except security or dataloss
>    bugs). 
> 
> so it sounds like 0.98.x should be what is uploaded to unstable (from
> where it will migrate to testing).
> 
>> and 0.91.2 should be in
>> stable.  
> 
> The version in etch (stable) is only likely to be upgraded (from
> 0.87.7-0.3) if there are major bugs (such as security problems or data
> loss issues). See http://www.debian.org/security/
> 
> 
>> I find this a bit conservative, since I think numpy 1.1
>> should be in testing 
> 
> It was only uploaded 3 days ago, so in theory could migrate in 7 days
> time.
> 
>> along with matplotlib 0.98.1, 
> 
> http://packages.qa.debian.org/m/matplotlib.html gives debian package
> information on matplotlib - including which versions are in
> stable,testing and unstable. Hopefully 0.98.0 or 0.98.1 packages will
> be uploaded soon. If not, then giving the maintainers a push to ensure
> they are in the next debian stable would be a good idea.

Hi,
   the debian maintainers are already aware of the new versions, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486074

According to them, matplotlib 0.98.x will be uploaded to experimental 
first, before it migrates to unstable. Unstable has been updated to 
0.91.3 some days ago.

Manuel

Eric Firing wrote:
> Mike,
>
> John's mention of an upcoming bugfix release brought to mind a glitch 
> in 0.98: the default position of the polar plot title is too low (as 
> is the default position of the title on an ordinary plot with 
> tick_top()).
>
> It looks like you were working on this with your autoLayout option, 
> but when I try enabling that, I get (last part of traceback only, and 
> for the Cartesian axes case):
>
> /usr/local/lib/python2.5/site-packages/matplotlib/axes.pyc in 
> update_layout(self, renderer)
>    1421         x0, y0, x1, y1 = self.get_position(True).extents
>    1422         # Adjust the title
> -> 1423         self.titleOffsetTrans.clear().translate(
>    1424             0, original_t_text + pad_pixels * 2.0)
>    1425
>
> AttributeError: 'ScaledTranslation' object has no attribute 'clear'
>
>
> It looks like this would be prevented if ScaledTranslation were 
> reformulated to inherit from Affine2D instead of Affine2DBase.
>
> Is this the right solution?
No -- Affine2D is for mutable transformations, and a 
ScaledTransformation is automatic (it really doesn't make sense to clear 
it).  The real bug here is that the auto layout code has grown stale.  
It should probably remove it, since it was basically an aborted 
experiment and I don't want to create confusion.  It turned out to be 
too difficult (perhaps impossible) to do the right thing in the general 
case given the current MATLAB-based APIs for laying out a figure.  The 
real solution will need to provide a new API (which would be an 
alternative to the current one) that works somewhat like the box layout 
APIs in many GUI toolkits.  Once I got to that point, I realised that 
would take more time beyond what I had allotted.
>
> Regardless of the status of the autoLayout code, I thought it would be 
> nice to improve the default title behavior of the polar_demo, at least.
I've changed it so it behaves identically to 0.91.x, which is not great 
(since it puts the title too close to the edge of the figure), but at 
least it isn't a regression.

Cheers,
Mike


-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This probably isn't the "real" solution, but I've been using svn-clean 
to clean my doc directory.  Though I agree with John, we should have a 
clear demarkation between svn content and generated content.

Cheers,
Mike

Darren Dale wrote:
> On Friday 13 June 2008 9:54:58 pm you wrote:
>   
>> On Fri, Jun 13, 2008 at 3:20 PM, Darren Dale <dar...@co...> 
>>     
> wrote:
>   
>>> I just deleted the static_figs directory from svn, and moved the contents
>>> into pyplots. The generated figures were committed to svn as well, so
>>> they should not be auto-generated. This way we can consistently use the
>>> nice plot directive to include all of our figures. I think there should
>>> be no problems with this transition, but if you see one, please let me
>>> know.
>>>       
>> I think we can make it work, but there are some minor hurdles.  It is
>> a little brittle in my view to include auto-generated PNGs alongside
>> svn pngs because it makes cleaning hard (we currently have the same
>> problem in the _static dir with the mathtext pngs).
>>     
>
> How often does cleaning need to be done? Can "svn up" be a part of the 
> cleaning process?
>
>   
>> The other problem 
>> is that when I went to implement your svg suggestion, which is a good
>> one (ditto for ps links), I bumped into some not implemented errors
>> since we don't have draw_tex for svg and some latex runtime problems
>> when I tried to build the ps since I don't have the right fonts.  All
>> of this can be worked around, but it will take a little work.  I have
>> to run now...
>>
>> We could have a little extra meta data stored, tagging certain files
>> that should not be auto-generated for certain extensions....
>> Perhaps we should introduce a new plot directive option, much like
>> include-source, which  could be used to suppress auto-gen, or exclude
>> certain targets.
>>
>> .. plot:: tex_unicode_demo.py
>>
>>    :include-source:
>>    :no-autogen:
>>
>> .. plot:: tex_unicode_demo.py
>>
>>    :include-source:
>>    :exclude-backends: svg, gdk
>>
>> I'll ponder this over the weekend.
>>     
>
> May I suggest a third alternative, :exclude-formats: instead of backends.
>
> Darren
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks.  mpl was applying the default alpha of 1.0 to the set of colors 
rather than ignoring it when an alpha is provided for each color.  This 
is now fixed in SVN r5554

Cheers,
Mike

Mátyás János wrote:
> Hi,
>
> setting colors with transparency no longer works for me in
> 0.98.0, but worked before in 0.91.3:
>
> c = matplotlib.collections.LineCollection(lines, colors = lineColors)
>
> This shows the lines only with the base colors without transparency.
>
> However, if I modify the code to the following, the colors shows
> properly with transparency:
>
> c = matplotlib.collections.LineCollection(lines)
> c.set_color(lineColors)
>
>
> Mátyás János
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> 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

On Saturday 14 June 2008 20:11:00 T J wrote:
> I can't seem to get 3d plotting to work from the latest svn.  I
> submitted a bug on this:
>
>   
> http://sourceforge.net/tracker/index.php?func=detail&aid=1994049&group_id=8
>0706&atid=560720
>
> but I think the issue is more fundamental than an 'import' issue as I
> described it.  Is this a quick fix or does there need to be a more
> substantial rewrite to get 3d plotting working again.

3D plotting is not supported, and so it probably did not survive the 
transition to the new transforms in 0.98. Patches are welcome, but in the case 
of unsupported features, bug reports will probably not be addressed.

I can't seem to get 3d plotting to work from the latest svn.  I
submitted a bug on this:

   http://sourceforge.net/tracker/index.php?func=detail&aid=1994049&group_id=80706&atid=560720

but I think the issue is more fundamental than an 'import' issue as I
described it.  Is this a quick fix or does there need to be a more
substantial rewrite to get 3d plotting working again.

John Hunter wrote:
> On Fri, Jun 13, 2008 at 3:28 PM, Ryan May <rm...@gm...> wrote:
> 
>>> Ryan:  I'm sure you could do it, and it would be a nice contribution to
>>> the community.  There's some IDL code here
> 
>> Thanks.  I also managed to find a matlab implementation, which was
>> straightforward to port over.  I'm working on fleshing out the full
> 
> Just a note of caution: if you want to write something that will be
> included in matplotlib or a toolkit, you need to be mindful of the
> licenses of code you are looking at.  While matplotlib has replicated
> to an extent the names and signatures of many matlab functions, we
> haven't looked at any of their code.  A lot of  IDL and matlab code
> comes with restrictive licenses, so make sure you are not violating
> the terms of those licenses for any code that might be suitable for
> contribution.

Yeah, I'm aware of this.  The code I mention, however, is taken from 
meteorology class assignment.  Also, in this case, I'm really only using 
it for a reference on how to do the "skew" calculation.  The code is 
*far* too ugly to directly port. :)

I can appreciate the need for caution however.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma