> On 7 Feb 2015, at 10:18 pm, Thomas Caswell wrote:
>
> raise ValueError(msg % style)
> ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style
> library and input is not a valid URL or path. See `style.available` for list
> of available styles.
>
> Is your computer
Sorry about the bad tarball, I forgot to clean my git directory before
generating it. Another point in favor of using the gh tarball, I can't
screw it up.
This is the first I have seen that CVE.
That PR is not included in 1.4.3 because it completely over-hauls how the
Agg rendering works (and ge
I think I figured it out... the linestyles are a list of tuples. When they
get coerced to a numpy array, and then coerced back to a list, you get a
list of lists instead of a list of tuples!
There must be some code deep down in the agg that is expecting a tuple, and
choking on a list.
Ben Root
O
Please ignore my test failure report. I was accidentally running an older
install of matplotlib from the same branch.
Ben Root
On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root wrote:
> I am getting some test failures here and on master in the collections
> module.
>
> =
Hi,
On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell wrote:
> Sandro,
>
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
the release tarball contains __pycache__ directories and
I am experimenting with my idea for utilizing a _draworder attribute in
Collection objects. Since not everything in a collection is guaranteed to
be the same length or even be numpy arrays, I have to add some logic to
coerce everything to numpy arrays and tile their data so that the length of
their
On 2015/02/08 12:05 PM, Thomas Caswell wrote:
> The goal of pulling pyplot out of backend_bases is exactly that, to be
> able to do everything using the OO interface in a convenient way.
>
https://github.com/matplotlib/matplotlib/pull/4082
The above PR is an illustration of one approach to making
To overhauling all of the default colors, I think that is still in the
cards, but some one who is not me needs to drive that.
The goal of pulling pyplot out of backend_bases is exactly that, to be able
to do everything using the OO interface in a convenient way.
Tom
On Sun Feb 08 2015 at 4:50:51
On Feb 8, 2015 1:13 AM, "Thomas Caswell" wrote:
>
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking c
Ah, no I mean the exact opposite!
My proposal is to cut 2.0 off of what ever the current stable release is
(ex, 1.4.3) and then merge that into master. The next minor release would
then be 2.1 and there would be no new 1.Y releases.
Tom
On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi wrote:
>
Hi all!
On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell wrote:
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color map.
> I think that when we pick that we should cut 2.0 off of the last release and
> then the next minor release turns into 2.1. If we want to do
On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell wrote:
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
>
> If you want to tracking GH for debian instead of SF I don't think that
12 matches
Mail list logo
