I ran into the same problem independently on an Intel Mac (I didn't read
these messages until now) and came up with the first part of Jae-Joon
Lee's fix. It does fix the problem, at least for me - I suspect the
difference may not actually be in the platform but in the exact version
of numpy (I have
On Sun, Dec 7, 2008 at 2:55 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> I just committed the change. Although the change is trivial, I didn't
> tested it in the numpy 1.2 or the svn version.
I tested on numpy svn on a couple of platforms (OS X and linux) and
this looks OK from my end.
-
On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote:
> I ran into the same problem independently on an Intel Mac (I didn't read
> these messages until now) and came up with the first part of Jae-Joon
> Lee's fix. It does fix the problem, at least for me - I suspect the
> dif
Just getting to this thread now. Since you asked for my insight -- I
can't reproduce the bug on my Linux box, but the patch looks innocent
enough if it fixes it for others.
Mike
John Hunter wrote:
> On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote:
>
>> I ran into
I don't think it's a rendering bug. The entire first row of data is 0.0
and -0.0, which maps to red. The real solution would be to map 0 and
-0.0 to different colors, but that's insane ;)
The rendering bug that bothers me, however, is the misalignment of the
ticks to the colors in the color b
John Hunter <[EMAIL PROTECTED]> writes:
> I think the version check is a good idea, so people won't get the
> annoying warning. Could you add this?
>
> Sent from my iPhone
>
> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote:
>
> > I'm currently using numpy 1.1.1 and np.h
On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I don't think it's a rendering bug. The entire first row of data is 0.0 and
> -0.0, which maps to red. The real solution would be to map 0 and -0.0 to
> different colors, but that's insane ;)
>
> The rendering bug tha
I think Jae-Joon's new figure refactoring is really great, and is a huge
improvement over the old code.
I do, however, have one concern. Since the legend border is no longer a
simple rectangle, the Agg backend's auto-pixel-alignment routine is no
longer kicking in, and the border ends up looki
On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I think Jae-Joon's new figure refactoring is really great, and is a huge
> improvement over the old code.
>
> I do, however, have one concern. Since the legend border is no longer a
> simple rectangle, the Agg backend'
John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> This may also be an argument for finally making the auto-pixel-alignment
>> code programmatic, rather than automatic. As it works now, it
>> automatically pixel-aligns when there are a) no cu
On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> The gc param would be the easy part -- I was thinking the difficult would be
> going through all the cases and making sure it's doing the right thing, and
> making sure axes and ticks etc. still look nice. Though I su
This should now be fixed in SVN. Couldn't see any regressions in the
documentation examples, but may be worth another set of eyes before the
release.
Mike
John Hunter wrote:
> On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> I don't think it's a rendering b
John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> The gc param would be the easy part -- I was thinking the difficult would be
>> going through all the cases and making sure it's doing the right thing, and
>> making sure axes and ticks etc.
On Mon, Dec 8, 2008 at 10:27 AM, John Hunter <[EMAIL PROTECTED]> wrote:
>
> I'm inclined to agree with you -- this could also be an rc option, so
> those who like the rounding can get them by default. I would be happy
> to have rectangle by default, with liberal use of rounding in the
> gallery ex
On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> On the other hand, I think it would also good if we allow a dictionary
> for the "fancybox" argument, like "bbox" in text. But maybe not in
> this release.
I would prefer not to change the meaning of the fancybox once we
r
On Mon, Dec 8, 2008 at 12:30 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>
>> On the other hand, I think it would also good if we allow a dictionary
>> for the "fancybox" argument, like "bbox" in text. But maybe not in
>> thi
Hi,
It looks like some tabs have crept into the CHANGELOG file. Is anyone opposed
to
me changing them to the equivalent (8) spaces? It messes up my editor, which
is
set to display them as 4 spaces, and makes it think that tabs are the proper
way
to indent.
Ryan
--
Ryan May
Graduate Rese
Ryan May wrote:
> Hi,
>
> It looks like some tabs have crept into the CHANGELOG file. Is anyone
> opposed to
> me changing them to the equivalent (8) spaces? It messes up my editor, which
> is
> set to display them as 4 spaces, and makes it think that tabs are the proper
> way
> to indent.
Hi,
Was just looking through the examples and noticed that
pylab_examples/dashtick.py
does not work here for me on SVN head.
Traceback (most recent call last):
File "dashtick.py", line 61, in
test_dashticklabel()
File "dashtick.py", line 40, in test_dashticklabel
fontsize=FONTS
On Mon, Dec 8, 2008 at 4:29 PM, Ryan May <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It looks like some tabs have crept into the CHANGELOG file. Is anyone
> opposed to
> me changing them to the equivalent (8) spaces? It messes up my editor, which
> is
> set to display them as 4 spaces, and makes it th
On Mon, Dec 8, 2008 at 4:19 PM, Ryan May <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Was just looking through the examples and noticed that
> pylab_examples/dashtick.py
> does not work here for me on SVN head.
>
> Traceback (most recent call last):
> File "dashtick.py", line 61, in
> test_dashtick
On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> wrote:
> Works for me. Let's aim for Saturday night so we have Sunday to test
> it out. Doable?
I've been working on a number of docstring fixes, and several other
changes and last-minute bug fixes have been coming in. I think we
22 matches
Mail list logo
