Hi all,
I find the usage of linestyle very _unconvenient_, since there are these
two options - linestyle='--' and linestyle='dashed' - which are not
exchangable.
I had some code where I initially used the Line2D class, so I had to use
linestyle='--'. Now I changed my code to use a LineCollectio
Sorry -- I was too thick to get the reference. Maybe if you had
included a cute picture of a kitten eating a cheeseburger or riding and
invisible bicycle or something... This list needs more of those ;)
Cheers,
Mike
Tom Holroyd wrote:
> Sorry, I just don't like that word. And the "UR ..." was
Now that the transforms branch has merged with the trunk, I'd like to
resurrect namespace packages so that toolkits will work again when
matplotlib is installed as an egg. As was discussed in a previous
thread, all __init__.py files in the toolkit hierarchy must be empty
(aside declare_namesp
Eric Firing wrote:
> Mike,
>
> In going through examples (on transforms branch immediately before you
> made the switch), it looks like there are a couple of new bugs
> in those included by backend_driver.py:
>
> 1) legend_demo.py and legend_demo2.py make spurious black blocks, which
> go away
Nils,
That's weird. I've cleared and rebuilt everything and I still don't see
this problem on my install. (See my attached copy.)
Thanks for the info. Can you send your versions (Python, numpy etc.)
and platform info? I don't really know what may be causing this difference.
Cheers,
Mike
Michael Droettboom wrote:
> Eric Firing wrote:
>> 2) there is a positioning problem with the table part of table_demo.py.
>
> I don't see this. (I must just be looking in the wrong place). Can you
> be more specific?
The problem went away. I was pretty sure I had already deleted my old
inst
It looks like the new transforms codebase does not support data that contains
NaNs the way the old trunk did:
plot([1,2,NaN,4,5]) produces a plot with no line break
plot([NaN,2,3,4,5]) produces a plot with no line
I know use of NaN's is not encouraged, and we have discussed it on this list.
But
Darren Dale wrote:
> It looks like the new transforms codebase does not support data that contains
> NaNs the way the old trunk did:
>
> plot([1,2,NaN,4,5]) produces a plot with no line break
> plot([NaN,2,3,4,5]) produces a plot with no line
>
> I know use of NaN's is not encouraged, and we hav
I think this is an oversight on my part when doing the rewrite. The old
trunk had special code to deal with NaNs in draw_lines (in some
backends, but not all). Since draw_lines disappeared (it was replaced
with draw_path), this functionality fell through the cracks. I think
somehow bringing
I have something that works in r4833. It requires a clean rebuild,
since the change was only to a header file. It produces no measurable
slowdown on my fps test. (Of course, Eric's suggestion probably
wouldn't have either...)
Please let me know how this works for you.
The nice thing about t
Thank you, Mike.
On Wednesday 09 January 2008 04:36:21 pm Michael Droettboom wrote:
> I have something that works in r4833. It requires a clean rebuild,
> since the change was only to a header file. It produces no measurable
> slowdown on my fps test. (Of course, Eric's suggestion probably
> wo
As the author of the only other known MPL toolkit (at least in the MPL
tree), I'm happy with the idea of using a namespace package for
mpl_toolkits. I understand your proposal to mean that each toolkit would
have a directory structure:
setup.py
lib/
mpl_toolkits/
__i
Does this proposal change the way people access this
functionality? We have a lot of scripts (and a lot of users with
scripts) that use basemap and it tends to be extremely annoying to
people when their scripts suddenly break.
Ted
At 03:34 PM 1/9/2008, Andrew Straw wrote:
>As the author of th
Ted Drain wrote:
> Does this proposal change the way people access this
> functionality? We have a lot of scripts (and a lot of users with
> scripts) that use basemap and it tends to be extremely annoying to
> people when their scripts suddenly break.
>
> Ted
>
Ted: Unfortunately it would
Andrew Straw wrote:
> As the author of the only other known MPL toolkit (at least in the MPL
> tree), I'm happy with the idea of using a namespace package for
> mpl_toolkits. I understand your proposal to mean that each toolkit would
> have a directory structure:
>
> setup.py
> lib/
> mpl_tool
On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
> Andrew Straw wrote:
> > As the author of the only other known MPL toolkit (at least in the MPL
> > tree), I'm happy with the idea of using a namespace package for
> > mpl_toolkits. I understand your proposal to mean that each toolkit wo
Darren Dale wrote:
> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>
>> Andrew Straw wrote:
>>
>>> As the author of the only other known MPL toolkit (at least in the MPL
>>> tree), I'm happy with the idea of using a namespace package for
>>> mpl_toolkits. I understand your pr
Jeff Whitaker wrote:
> Darren Dale wrote:
>> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>>
>>> Andrew Straw wrote:
>>>
As the author of the only other known MPL toolkit (at least in the MPL
tree), I'm happy with the idea of using a namespace package for
mpl_to
Andrew Straw wrote:
> Jeff Whitaker wrote:
>
>> Darren Dale wrote:
>>
>>> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>>>
>>>
Andrew Straw wrote:
> As the author of the only other known MPL toolkit (at least in the MPL
> tree), I
Great -- hopefully that saved you some API re-arrangement pain. No
problem on shuffling mpl_sizer around -- please go ahead do it if you
have time.
-Andrew
Jeff Whitaker wrote:
> Andrew: Thanks, you've convinced me. Is it OK with you if I go ahead
> and make those changes to mplsizer at the
20 matches
Mail list logo
