> 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
Thanks for the great work!
On 02 Feb 2015, at 11:58 am, Jens Nielsen wrote:
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including
> the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
>
I’ve tested on OS X 10.9 with Fink Python 3.4.2, 3
On 26 Nov 2014, at 07:53 pm, Chris Barker wrote:
> On Wed, Nov 26, 2014 at 1:30 AM, Todd wrote:
>> About this, I am not expert so forgive me if this is nonsensical. However,
>> it would seem to me that these requirements are basically the same as the
>> requirements for the new default colorm
Hi Chris,
> the framework. Though, if I understand correctly, Anaconda provides a
> framework version of the interpreter
> pythonw and a non-frameworked python?
>
> This is right -- the GUI backends to matplotlib cause python to crash, but
> not pythonw. This is annoying, since the two binaries
On 15 Aug 2014, at 10:39 pm, Eric Firing wrote:
> On 2014/08/15, 9:37 AM, Derek Homeier wrote:
>
>> Just to make sure I understand - this is about whether the MPL macosx
>> backend would run with non-framework Python at all? It certainly
>> should not, as _macosx.m has
On 14 Aug 2014, at 11:40 pm, Chris Barker wrote:
> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing wrote:
> but as far as I can see, on OSX, there is no *advantage* to non-framework
> python. Is this correct?
>
> Suggestion for anaconda:
> make bin/python a link to ../python.app/Contents/MacOS
hange it.
>
But you really only can use it for one thing primarily, right? The "check all
that apply" seems out of place here.
Cheers,
Derek
--
Derek Homeier Centre de Rec
Hi Michiel,
On 16.04.2013, at 12:03AM, Michiel de Hoon wrote:
> Can you perhaps ask the Fink developers to provide a framework installation
> of Python? Most matplotlib users who ran into framework-related bugs were
> Fink users.
I've already looked for that in the list archives and it seems
Hi Michiel,
On 15.04.2013, at 6:03AM, Michiel de Hoon wrote:
> --- On Sun, 4/14/13, Derek Homeier
> wrote:
>> Of course if there are any other possible negative effects
>> besides the window handling, I'd take your point.
>
> Several bugs have been reported in t
Hi Michiel,
> This RuntimeError is there for a reason: If your Python is not installed as
> a framework, the backend will not work correctly (and if you ignore the
> RuntimeError, you won't know if any problems you encounter are real bugs, or
> simply due to your Python not being installed as
Hi Michiel,
> That is good to hear.
> The slowdown was caused by the performance of Quartz itself, but it depends
> strongly on the line width. In your example, the plot appears immediately if
> you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if
> you use linewidth=1.
Hi Michiel,
On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:
> The slow speed for long paths like the one in your example was due to a
> limitation to Quartz itself. This was solved by breaking the path up into
> subpaths of up to 100 points. But you mentioned that releases before 1.2 were
> n
On 11.04.2013, at 6:38PM, Michael Droettboom wrote:
> Congrats to everyone on a successful 1.2.1 -- there was a relatively
> small influx of bug reports following it -- perhaps a sign of improving
> quality?
Thanks and congratulations to everyone involved as well; I've built 1.2.1 on
MacOS X
On 20.09.2012, at 7:23PM, Benjamin Root wrote:
> Is it just me, or are colors looking duller?
>
> I attached before (v1.1.x) and after (v1.2.x) images.
Is this the same colour map? To me it looks like jet or rainbow vs. coolwarm.
The latter had been endorsed by a number of people here for its
On 06.07.2012, at 3:49PM, Damon McDougall wrote:
>>
>> When I tested on Mac OS X 10.6 I found that most unit tests were somehow
>> missing. Rather than try to diagnose the problem, I built a new binary
>> on 10.6, confirmed that it installed properly (with all unit tests) on
>> 10.6 and 10.7,
On 01.07.2012, at 12:17AM, Sandro Tosi wrote:
>>
>> Just out of curiosity, what is the mismatch? (I believe you, I just
>> know very little about the debian process).
>
> These are the rules: http://release.debian.org/wheezy/freeze_policy.html
>
> And none of the rules match this situation. RC
Hi Sandro,
> yes, Debian has a separate package for documentation (since it
> requires to be build just on time, whilc mpl requires to be built on
> each architecture we support, so splitting the package results in a
> lot of saved space). JFYR this is the layout of packages in Debian:
>
> python
On 26.03.2012, at 7:43PM, John Hunter wrote:
> On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen wrote:
> On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
>
> > On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> > wrote:
> >> I used the 1.1.0 version to build with t
On 24.03.2012, at 8:16PM, Sandro Tosi wrote:
>
> to run tests I use:
>
> python -c "import matplotlib as m ; m.test(verbosity=1)"
>
Ah, thanks for the reminder; that looks much more comprehensive!
Actually the fink testing command requires an exit value of 1 or higher to
detect errors, so I am
Hi Sandro,
> On Fri, Mar 23, 2012 at 03:18, John Hunter wrote:
>> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
>> are available for testing and building binaries
>>
>>
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>>
>> After th
On 16 Mar 2011, at 09:48, Georges Arsouze wrote:
> I'am working with Python3.1 under Mac Os Snow Leopard
> I download matplotlib with
> http://www.cgl.ucsf.edu/Outreach/pc204/matplotlib.html
>
> It doesn't work
> Can you help me ?
>
That package, as the site states (though maybe not clearly enoug
On 04.01.2011, at 1:49AM, Russell E. Owen wrote:
I have uploaded Mac installers for python.org Python 2.6 and 32-bit
Python 2.7.
I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In
ved the module in the fink
install,
so all I can think of is that not enabling framework and/or SDK build is
responsible.
I did not find any hint in the Mac build documentation towards this, though.
If this is a fink-related problem only, of course we'd just need to apply the
Hi again, cc'ing the matplotlib list this time,
for the latter: when building matplotlib against a fink-installed
python compiled in 64bit mode
I found the check for a framework-installed Python (rev 8365) fails,
and matplotlib fails to load,
because the MacOS module is not available in 64bit
24 matches
Mail list logo
