Hi,
I'm trying to get something like texture mapping to work. (I don't need
anything fancy transforms between texel location and image location,
though. I'm happy to specify just a 2D grid of pixel colors that appear
onto a rectangle positioned in 3D space.)
Given that, I made a demo based on pco
David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
>
OK, I managed to clone your repo -- I cloned mine, then added yours as a
r
Michael Droettboom wrote:
> I've committed support for comparing SVG files using Inkscape and
> verifying them against the official SVG DTD using xmllint.
>
Man, are we standards compliant around here or what? :) Cool.
> Michael Droettboom wrote:
>
&
Gellule Xg wrote:
>>> This is a bug report for matplotlib version 0.99.1.1
>>>
>>> The clip_path keyword of imshow() does not work when setting it to
>>> (Path, Transform) for two reasons:
>>>
>> Hi, Thanks for the report. Do you have a simple test script that we can
>> use to see the probl
Jouni K. Seppänen wrote:
> I am thinking about adding pdf comparison ability to compare_images. One
> simple way to do this would be to convert pdf files to pngs using
> Ghostscript: if we store reference pdf files, and both the reference
> file and the result of the test are converted using with e
Michael Droettboom wrote:
> I've committed support for comparing SVG files using Inkscape and
> verifying them against the official SVG DTD using xmllint.
I just noticed the test_axes/hexbin_extent.svg baseline image is more
than 5 MB. I wonder if we can somehow simplify the svg generated to
re
Jouni K. Seppänen wrote:
> Andrew Straw writes:
>
>
>> Sorry for not noticing this earlier, but I'm looking in the baseline
>> image directory, and I see a bunch of *_pdf.png files. I guess these
>> have been convered to png from pdf on the tester's ma
Hi All,
I have addressed what I think is a long-standing wart: zorder is mostly
ignored for imshow(). (See e.g.
http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
) The question is whether I should apply the attached patch.
The worry is that someone is rel
John Hunter wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw wrote:
>
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--ims
Jae-Joon Lee wrote:
> On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing wrote:
>
>> PS backend already does things differently from others because it doesn't
>> handle alpha, correct? Does the patch make this situation any worse?
>>
>>
>
> When there are multiple Images and render.option_image
Andrew Straw wrote:
> John Hunter wrote:
>
>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw wrote:
>>
>>
>>> Hi All,
>>>
>>> I have addressed what I think is a long-standing wart: zorder is mostly
>>> ignored for imshow().
Jae-Joon Lee wrote:
> I also committed a small patch that makes zorders respected among
> images (not with other artists) for noncomposit backends.
>
That looks fine to me. Thanks.
> Anyhow, can we get rid of the second items in the "dsu" list? My guess
> is that this is to make the sort stable,
>
> On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw wrote:
>
>> > I had a patch waiting in the wings for that, but I wanted to see the dust
>> > settle before committing it. I think the dust is officially settled, so
>> > please commit yours or else I'l
Hi All,
I just spent an hour or two tracking down some problems with the
buildbot test images that crept in unnoticed with the pdf backend
testing. I think I now fixed all the issues with the buildbot testing,
which required a few changes to the MPL source and a few on the buildbot
server to b
Michael Droettboom wrote:
> I know it's been a while since you announced this, but I'm just looking
> into this now.
Also, I got some ways in making the buildbot build with numscons, but I
stopped at a bug where it looked like the matplotlib.tests.* modules
were not getting installed:
http:/
David Cournapeau wrote:
> Andrew Straw wrote:
>
>> Michael Droettboom wrote:
>>
>>> I know it's been a while since you announced this, but I'm just
>>> looking into this now.
>>>
>> Also, I got some ways in making the
David Cournapeau wrote:
> Andrew Straw wrote:
>
>> I looked a little further, and it depends on the directory that the
>> tests are run from -- if I manually log into the build slave, I can
>> get the tests to run (in fact, one segfaults) if I try from a
>> diffe
Tony S Yu wrote:
>
> On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
>> However, with svn r7985, the trunk fails to find the tests. This is so
>> weird. There's nothing in that commit that I can see that should cause
>> the failure, but it seems repeatable. r7984 does
Andrew Straw wrote:
> I'm a little mystified as to the actual cause, but it
> again looks like some freetype problem. Mike, do you think it could
> somehow be related to your recent font work?
>
>
OK, in the absence of a fix, I just checked in the images that were
b
Jae-Joon Lee wrote:
> The recent zorder-related changes broke the some of the rasterization
> feature, and I just committed a fix.
Thanks Jae-Joon.
Is it easy to turn this into a test so that it never unintentionally
crops up again?
Thanks,
Andrew
--
The following (uncommitted) test currently fails. The reason is that
mlab.prctile(x,50) doesn't handle even length sequences according to the
numpy and wikipedia convention for the definition of median. Do we agree
that it should pass?
Not only would I commit the test, but I also have a fix to
Hi,
I've been reading about box plots and examining the source code for
boxplot() lately. While there doesn't seem to be a convention about what
the notch specifies, I can't find any justification (or text describing)
what exactly the MPL notch is. The source code is:
# get median and quart
Jae-Joon Lee wrote:
> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen wrote:
>
>> While the backend API is being changed, would it be similarly easy to
>> support arbitrary affine transformations? It would make the API more
>> symmetric, since many other draw_* methods take an affine
>> tra
Jae-Joon Lee wrote:
> What I have in my mind is to extend the "extent" keyword of the imshow
> and make it optionally take a tuple of 6 numbers, which are (x1,
> x_lrc, x2, y1, y_lrc, y2).
> x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
> y_lrc) represent the coordinate of the l
Fernando Perez wrote:
> Note that the code below does:
>
> if notch_max > q3:
> notch_max = q3
> if notch_min < q1:
> notch_min = q1
>
> though matlab explicitly states in:
>
> http://www.mathworks.com/access/helpdesk/help/tool
Andrew Straw wrote:
> The following (uncommitted) test currently fails. The reason is that
> mlab.prctile(x,50) doesn't handle even length sequences according to the
> numpy and wikipedia convention for the definition of median. Do we agree
> that it should pass?
>
I&#x
Fernando Perez wrote:
> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw wrote:
>
>> (This still leaves open the question of what the notches actually _are_...)
>>
>
> No idea. I'd still leave the code instead written as
>
> notch_max = med + (iq/
Pierre GM wrote:
> On Dec 18, 2009, at 10:34 PM, Andrew Straw wrote:
>
>> Fernando Perez wrote:
>>
>>> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw wrote:
>>>
>>>
>>>> (This still leaves open the question of what the notche
John Hunter wrote:
> On Fri, Aug 7, 2009 at 11:54 AM, Andrew Straw wrote:
>
>
>>> But would this also make the spine have the larger limits? Basically,
>>> I want know if the spines can be used to create Tufte-style
>>> range-frames. Am I correct in thi
Andrew Straw wrote:
> Also, I think that formula is only for normally distributed data. Which,
> especially if you're using boxplots, medians, and quartiles, may not be
> a valid assumption.
>
> Maybe we should at least raise a warning when someone uses notch=1. The
>
Andrew Straw wrote:
> Also, I think that formula is only for normally distributed data. Which,
> especially if you're using boxplots, medians, and quartiles, may not be
> a valid assumption.
>
> Maybe we should at least raise a warning when someone uses notch=1. The
>
Gary Ruben wrote:
> This looks nice Andrew,
> I haven't tried it, but I wonder whether it's possible to add a
> keyword arg to suppress the 0's at the origin which are cut through by
> the axes in the zeroed case (and/or possibly shift the 0 on the
> horizontal axis left). The same thing is happ
Stefan Schwarzburg wrote:
> Hi,
> I would like to add a comment from the user perspective:
>
> - the main reason why I'm not satisfied with pypi/distutils/etc. and
> why I will not be satisfied with toydist (with the features you
> listed), is that they break my installation (debian/ubuntu). The ma
Hi all,
I added a recipe for to build a copy of the documentation after every
svn commit. The results may be seen at
http://matplotlib.sourceforge.net/trunk-docs/ (we can change the
location easily if desired).
This is just the result of another buildbot recipe, so any troubles that
crop up when
David Cournapeau wrote:
> On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
> wrote:
>
>> On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
>>
>>> [snip]
>>> - supporting different variants of the same package in the
>>> dependency graph at install time
>>>
>>> [snip]
Andrew Straw wrote:
> In fact, does anyone know what could be wrong? The last lines of the
> LaTeX output are below.
>
OK, this cropped up on another buildbot for another project of mine --
it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
is some issue that was
Andrew Straw wrote:
> Andrew Straw wrote:
>
>> In fact, does anyone know what could be wrong? The last lines of the
>> LaTeX output are below.
>>
>>
> OK, this cropped up on another buildbot for another project of mine --
> it looks with a Sph
Hi,
With the recent regression fixed in Pygments, the doc auto-builder is
closer to completing successfully. However, there's a new bug. The build
ends with:
LaTeX Warning: File `/home/mpl-chslave/slave-py25/build_docs/build/doc/build/pl
ot_directive/mpl_examples/pylab_examples/barb_demo.pdf' not
Michael Droettboom wrote:
> Cleaning the docs first seems to have fixed it.
>
> Is there a way to download the build products (i.e. the PDF file
> produced)?
That, and testing for doc build failures, is the point, although I
managed to screw up the uploading until now. However, I believe I have
Nico Schlömer wrote:
> Hey, and is there any sort of matplotlib market place where I could
> put the file for general bashing/downloading once it can do more than
> a sin-plot?
>
Well, github is my suggestion. If it's a patchset of the MPL source,
then fork the MPL repository at http://github.c
Neil Crighton wrote:
> Hi,
>
> I posted a patch that makes some small changes to minor tick autoscaling:
>
> http://sourceforge.net/tracker/?
> func=detail&aid=2924245&group_id=80706&atid=560722
>
> If someone could check it's ok and apply it, that would be great.
>
I can't see the harm, so I ap
Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>
>> Basemap offers many projections, but is missing two of the most useful ones:
>>
>> - For satellite applications, it would be helpful to have a "camera"
>> projection, i.e., a projection that shows the Earth as viewed from a
>> specified p
Fernando Perez wrote:
> Hi all,
>
> would anyone mind if I commit the attached patch?
>
> It's 100% backwards compatible and allows for turning plot directive
> errors into fatal exceptions easily, so one can make sure that docs
> either build correctly or not at all. This is useful for having
> e
[email protected] wrote:
> Hey folks,
>
> I recently modified the Axes method boxplot so that the confidence intervals
> around the mean are computed not with a static formula, but by bootstrapping
> the median as many times as the user specifies. Also, I commented out the
> lines that preve
s this something that would be worth including in matplotlib? I've
>>>
>> never contributed to a project like this before and my code is probably
>> pretty sloppy by MPL standards. I'm not really sure what's appropriate to
>> contribute and what'
Brian32 wrote:
> Hello,
>
> I am currently displaying plots on a web page using matplotlib by creating
> .png files. I would like have the ability for people to have access to the
> interactive plot feature (Zoom,Save) when they look at the plots on the web
> page. I do not care if the plot is a
Nadia Dencheva wrote:
> Hi MPL developers,
>
> I use an older matplotlib version but this code is the same in SVN, so I
> thought
> I'll mention it.
>
> ImportError: numpy 1.1 or later is required; you have 2.0.0.dev8107
Thanks Nadia. Fixed in svn r8128.
-Andrew
John Hunter wrote:
> Andrew, the failure is on the font cache again -- is this the race
> condition you've mentioned in the past?
>
> matplotlib.tests.test_mathtext.test_mathtext_stixsans ... ok
> Failure: IOError ([Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache
Eric Firing wrote:
> All,
>
> I think the git migration deserves its own thread on the devel list, so
> here is a start.
>
To the uninitiated - a decision is being made that MPL is moving to git
and github. We hope that this move will foster greater contributions
from the community and a blurri
John Hunter wrote:
> On Mon, Mar 15, 2010 at 3:16 PM, klukas wrote:
>
>> It's my understanding that there is no built-in method for generating a
>> "broken axis" (where you skip over some range of values, indicating this
>> with some graphical mark). I wanted to do this, so I've put together a
On Sat, 29 May 2010 12:28:40 -1000, Eric Firing wrote:
> 3) Is it really a good idea to delay the release until the we make the
> github transition? Given how long it has been since a release, and the
> possibility that there will be some turbulence until we have had some
> experience with githu
Hi Ondrej,
If I was in your shoes, the first thing I'd do is emit your data to plot
as a json object and then plot that data using javascript with one of
the libraries you've listed. Then, after gaining some familiarity with
Python->json->javascript I'd think about how such an MPL backend might
wo
John Hunter wrote:
> On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee wrote:
>
>> The issue was related with the change in Sphinx v1.0b2, which I think
>> I fixed in r8447.
>> At least, the html are built fine and uploaded fine.
>>
>> However, the link to trunk-docs still does not work.
>>
>> http
On 07/01/2010 10:24 AM, Sandro Tosi wrote:
> Hello,
> while preparing a test debian pacakge with mpl 1.0rc1, I noticed
> doc/make.py clean fails if the directories to remove are missing.
>
> The simple attached patch (svn diff against tr...@8480) resolves it;
>
Thanks, committed as r8481.
-
On 7/20/10 8:06 PM, Fernando Perez wrote:
> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter wrote:
>
>> The major issues I am aware of are:
>>
>> * what do to about all the various subdirs of the mpl trunk
>> (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to
>> one tags all wi
Hi MPL devs,
I think I've fixed a long-standing issue we've had with the buildbot
where sometimes a false alarm was issued when two tests stepped on each
others' toes. Specifically, I've fixed up the MPL buildbot environment
on the virtual machine that runs both the Python 2.4 and 2.5 tests so
On 8/1/10 7:11 PM, Eric Firing wrote:
On 07/31/2010 08:51 PM, Andrew Straw wrote:
Hi MPL devs,
I think I've fixed a long-standing issue we've had with the buildbot
where sometimes a false alarm was issued when two tests stepped on each
others' toes. Specifically, I'
Michael Droettboom wrote:
> On 08/14/2010 07:22 PM, Eric Firing wrote:
>
>> Mike,
>>
>> Is there any reason why the Path.unit_* methods shouldn't include the
>> codes, so that they can all have CLOSEPOLY? Or shouldn't they at
>> least have a kwarg to allow that as an option? In working on pa
Eric Firing wrote:
> On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>
>> I'm guessing some of Eric's recent changes to alpha handling in paths
>> require modifications to the MacOS X backend?
>>
>
> Correct. I'll fix it.
>
I see the Mac OS X buildbot is back online now, so perhaps we cou
On 8/21/10 12:08 PM, Eric Firing wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest
> changing as in the attached diff. It looks to me like the three *Tick
> methods, set_view_interval(), get_minpos(), get
On 09/12/2010 07:10 AM, Jouni K. Seppänen wrote:
> A while ago there was a discussion [1] about how using the
> get_sample_data function in building the documentation is a problem for
> Debian packagers. Let me see if I understand the goals of
> get_sample_data correctly:
>
> * we want to enable us
On 10/2/2010 8:33 PM, Mitchell Jon Stanton-Cook wrote:
> Hello,
>
> I have been trying to modify the custom projection example
> (http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html)
> to plot a Sanson Flamsteed Projection (Sinusoidal projection).
Dear Mitchell,
Can yo
On 10/23/2010 04:59, John Hunter wrote:
> I would be happy to do a release early next week. Is anyone aware of
> any show stopper bugs that need to be fixed first?
I think we should really get the build bot to all green again before
doing a release. Currently, the last that happened was October
On 23-Jan-11 04:05, John Hunter wrote:
>
> Darren
> if you are ready to "flip the switch" and make an official github repo
> under this organization, go for it. Once we get the trunk active,
> we'll worry about the rest, like migrating the release branch. Of
> course, if Andrew as the original fo
On 29-Jan-11 01:08, John Hunter wrote:
>
>> cvs -z3 -d:pserver:[email protected]:/cvsroot/matplotlib co -P
>> matplotlib
> cvs [checkout aborted]: connect to
> cvs.sourceforge.net(216.34.181.96):2401 failed: Connection refused
>
> Amazing how fragile digital data is!
SF may simply hav
On 07-Feb-11 17:13, Darren Dale wrote:
> The git migration is still on hold, pending the return of CVS service
> at sourceforge. According to someone on the sourceforge IRC channel,
> CVS is estimated to return this week, but it might slip to next week.
Thanks for the update.
At some point, one c
John Hunter wrote:
>>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
>>
>>
>
>Eric> Correction: I did fix the first problem, and the second
>Eric> problem is not at all what I thought. Instead, the
>Eric> examples/data/lena.jpg file in my svn mpl directory is
I just updated DEVNOTES with the following item:
Make sure sdist builds setuptools-compatible release: Remove setup.cfg
(or, if more than the [egg_info] section is in this file, remove the
[egg_info] section). See
http://mail.python.org/pipermail/distutils-sig/2006-July/006561.html for
more info.
Due to repeated emails by Eric Firing about how something like this
would be nice to have, I finally got around to packaging a little
utility I wrote. I uploaded it to the MPL source repository. The basic
idea is to create a layout engine for matplotlib. Not wanting to
(re-)invent an API, I decided
Hi Ken,
Thanks for your comments.
Ken McIvor wrote:
>1. It appears that as_sizer_element() uses the _axes_sizer_elements
>dictionary to cache MplAxesSizerElement instances. Using a
>WeakKeyDictionary from the "weakref" module instead of a regular
>dictionary may be necessary to allow the
Dear Abraham,
I'm sorry it's taken so long to get back to you. I didn't see any other
responses on the list, but I think this is a super idea (although I have
yet to look at the code). In particular I like your idea to save to your
XML format. Then we could plot to an XML file, and replot (later)
Hey Charlie, I totally appreciate the effort you put into making these
releases, particularly on Windows, where I must admit, I have a faint
heart...
But I found a couple issues (neither require a re-release, but just to
be aware of them next time):
1) there are several .pyc files left in the .ta
Andrew Straw wrote:
> 1) there are several .pyc files left in the .tar.gz release
> 2) the setup.cfg file in the release specifies, in the egg_info section,
> "tag_svn_revision = 1", which makes any further attempts to do python
> setup.py sdist with setuptools result
Gael Varoquaux wrote:
> On Sun, Nov 05, 2006 at 06:07:50PM +0100, Nicolas Grilly wrote:
>
>> I'm hacking the PDF backend because I need this format to import
>> charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use
>> to produce PDF reports).
>>
>
> I am all for a good PDF
John Hunter wrote:
> That said, I would always be happy to include a (mostly) full featured
> backend for a format a large number of users want. Short of that, I
> think distributing it through another channel, or making a sandbox in
> the mpl distribution,
FWIW, Jeff Whitaker 's basemap and my m
It looks like we're on the hook for some bugs associated with our use of
setuptools... I'm forwarding an email from the distutils-sig.
The short of it is that Phillip Eby suggests we move matplotlib.toolkits
to matplotlib_toolkits to save ourselves some grief. This does seem
easier than the ap
Jouni K. Seppänen wrote:
> "Nicolas Grilly" <[EMAIL PROTECTED]> writes:
>
>
>> When you are working on matplotlib, after a checkout from the SVN
>> repository, which method do you use to compile extensions without
>> re-building and re-installing everything each time?
>>
>
> I use "python s
John Hunter wrote:
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that.
+1
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done qui
John Hunter wrote:
> On 2/12/07, Charlie Moad <[EMAIL PROTECTED]> wrote:
>
>> You're changing positions on me now, John! ;)
>
> It's better that way -- that way I can be right both times :-) Or is
> it wrong both times? hmmm...
>
>> I asked about moving everything into the module, but you didn't
Looking in detail at the contents of the mpl-directory, I notice that
A) the gui/ subdirectory off the main MPL source direcotry (the one with
setup.py) does not exist in SVN
B) the file "lineprops.glade" referenced by
backends/backend_gtk/DialogLineprops.py
does not exist in SVN
Is it safe to
Charlie Moad wrote:
>> Although my understanding of setup* is minimal, I agree; I think that
>> keeping some organization in the data will be helpful. It looks like
>> get_data_path() is not called in many places, so if that is essentially
>> what has to be fixed, it should not be very difficult.
Great, thanks for checking that in.
It looks like images/*.png didn't make it in.
John Hunter wrote:
> On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>> So, I sent the patch file to John, who'll hopefully commit it if he
>> approves. To paraphras
Andrew Straw wrote:
> Great, thanks for checking that in.
>
> It looks like images/*.png didn't make it in.
>
And, grr, I can't put them in, either:
$ svn commit -m "added .png files that didn't make it into new mpl-data
location" images
Adding (bin
(Picking up this thread a bit late... And I just wrote a longer email
which got munched due to email configuration issues...)
I'm responsible for the "package_data" keyword being added to setup.py.
The bottom line is Python 2.3 is still supported. I simply didn't
realize that it would screw thi
Robert Kern wrote:
> Andrew Straw wrote:
>
>> 1) revert to the old way. The primary issues with this are a)
>> "package_data" is supported as standard Python from 2.4 on, and the old
>> way required carrying our own distutils command and b) we switched the
I think David Cournapeau's email to the -user list (included below)
brings up the general issue of whether and how and when we want to go
about deprecating the use of Numeric and numarray in MPL. Their
continued inclusion in the core of MPL increases complexity (thereby
slowing development and
Robert Kern wrote:
> John Hunter wrote:
>
>> On 4/5/07, Edin Salkovic <[EMAIL PROTECTED]> wrote:
>>
>>
>>> This would make installing setuptools even easier, since the newest
>>> ez_setup/seuptools would be downloaded by the user/developer every
>>> time a "svn update;python setup.py instal
Robert Kern wrote:
> Oh, you're requiring setuptools now? I didn't notice that. Cool.
>
Just for Python 2.3 so that we could sanitize the setup.py a little.
(Namely for the backport of the package_data field to setup().) It's not
required for Python >= 2.4 since package_data is already in stock
Hi All (esp. Darren),
The attached patch adds unicode support for LaTeX. Given the recent
discussion about adding preambles, I thought I'd run it past here first.
Anyone opposed if I check this in?
Note that I specifically added the rcParam text.latex.unicode to enable
this and a default False va
OK, here's the patch! :)
Andrew Straw wrote:
> Hi All (esp. Darren),
>
> The attached patch adds unicode support for LaTeX. Given the recent
> discussion about adding preambles, I thought I'd run it past here first.
> Anyone opposed if I check this in?
>
> Not
pdate the wiki page when I get back.
-Andrew
Darren Dale wrote:
> Hi Andrew,
>
> On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
>> OK, here's the patch! :)
>>
>> Andrew Straw wrote:
>>> Hi All (esp. Darren),
>>>
>>> The attached pat
Timothy wrote:
> Please let me know if there is a
> better way to submit the code.
>
Hi Timothy,
If you make it into a complete example that plots something, send it as
an attachment to the list (so their are no line-break issues), I will
commit it into the examples directory. From there, we c
I've been running MPL 0.90 rev3250 since April 18 on numerous computers
around here using the wxAgg backend using stock wx on both Ubuntu Edgy
and Ubuntu Feisty. A quick look into exactly what that means shows that
Edgy is using 2.6 by default and 2.8 is used by Feisty. Therefore, I
conclude that,
Charlie Moad wrote:
> I have time to cut a release tomorrow. Are there any outstanding
> issues that I should wait on?
>
I just committed a change that raises a DeprecationWarning on use of
numarray or Numeric as the numerix backend -- we agreed on this back in
early April.
-Andrew
--
Hi,
I just turned off the building of the Numeric and numarray extensions in
setup.py. (As is always good practice, you may have to delete your build
and install directories to insure the old extensions are not kept in place.)
I didn't clean up any infrastructure at this point, but I presume we
Dear Tim,
I checked in a similar patch from Tocer a couple days ago. Does your
version do anything different? Does the version in svn work for you?
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/__init__.py?r1=3391&r2=3418
(Sorry, I don't really use Windo
grr. that's probably my fault. I just fiddled with the definition of
npy. I tested this on linux and thought I copied it pretty directly from
numpy, so I assumed it would work elsewhere, but it's not. I'll see what
I can do...
Rob Hetland wrote:
> First of all, Qt4 does appear to work fine.
>
> S
John Hunter wrote:
> On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> grr. that's probably my fault. I just fiddled with the definition of
>> npy. I tested this on linux and thought I copied it pretty directly from
>> numpy, so I assumed it would work elsewh
I think I figured out and fixed the situation with isnan.
>From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
>
> Basically the story is this:
> isnan() is a C99 extension to standard C.
> Standard C++ is based on an older standard of C.
> Hence isnan() is not part of standa
Can you stick this in the top of src/_transforms.cpp and see if you
still get the problem?
#define _GLIBCPP_USE_C99
-Andrew
John Hunter wrote:
> On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> I think I figured out and fixed the situation with isnan.
>>
>> &
101 - 200 of 244 matches
Mail list logo
