matplotlib-devel Mailing List for matplotlib (Page 3)

On Mon, Jun 13, 2011 at 5:33 PM, Xavier Gnata <xav...@gm...> wrote:
> On 06/13/2011 07:38 PM, Darren Dale wrote:
>>
>> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<md...@st...>
>> wrote:
>>>
>>> This was recently discussed in the thread "v1.0.x branch seems confused."
>>>
>>> I (believe) the consensus was to get out another v1.0.x maintenance
>>> release out in the near future (which would not support py3k, but would
>>> still support Python 2.4), and then merge the py3 branch into master so
>>> it starts to get some more testing before making the next major release.
>>>
>>> I'm just today merging master into py3 so that when we are ready to do
>>> the merge the other way most of the hard work will have already been
>>> done.
>>
>> Are there features already in master that should be supported by
>> <python-2.6? If so, I think we should consider releasing 1.1.0 and
>> making a 1.1.x maintenance branch before merging the py3 stuff back
>> into master. Then mpl-1.2 could be the first to support py3.
>>
>> Should we move this discussion to the mpl-dev mailing list?
>>
>> Darren
>
> Ho I wasn't aware of an mpl-dev mailing list. Sorry.
> py3 is already ok with python3 *and* python2 isn't it?
With python-2.6 and python-2.7, yes, but not with older versions.
There will be some outstanding issues with python3, like certain
backends that will not work because the gui toolkits have not been
ported.
> Maybe the website should advertise a bit on the needs to test the py3
> branch.
> Users used to compile mpl from git should be able to produce valuable
> technical feedback, shoudn't they?
I think we should wait until we merge py3 back into the main repo.
Darren

On 06/13/2011 07:38 PM, Darren Dale wrote:
> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<md...@st...> wrote:
>> This was recently discussed in the thread "v1.0.x branch seems confused."
>>
>> I (believe) the consensus was to get out another v1.0.x maintenance
>> release out in the near future (which would not support py3k, but would
>> still support Python 2.4), and then merge the py3 branch into master so
>> it starts to get some more testing before making the next major release.
>>
>> I'm just today merging master into py3 so that when we are ready to do
>> the merge the other way most of the hard work will have already been done.
> Are there features already in master that should be supported by
> <python-2.6? If so, I think we should consider releasing 1.1.0 and
> making a 1.1.x maintenance branch before merging the py3 stuff back
> into master. Then mpl-1.2 could be the first to support py3.
>
> Should we move this discussion to the mpl-dev mailing list?
>
> Darren
Ho I wasn't aware of an mpl-dev mailing list. Sorry.
py3 is already ok with python3 *and* python2 isn't it?
Maybe the website should advertise a bit on the needs to test the py3 
branch.
Users used to compile mpl from git should be able to produce valuable 
technical feedback, shoudn't they?
Xavier

On 06/13/2011 10:07 AM, Simon Ratcliffe wrote:
> Hey Mike,
>
> Thanks for your informative assessment of Canvas vs SVG. Indeed it
> encapsulates much of the thinking and horse trading
> done when we decided on Canvas as a delivery technology for mplh5canvas.
>
> I particularly agree with you that sending smaller encapsulated
> updates is less bandwidth intensive (although not necessarily faster
> to re-rasterise the
> client display). We have also spent a lot of time tearing our hair out
> at the primitive drawing commands, the lack of dashed lines in
> particular
> is pretty painful.
>
> For us the plus points for Canvas came down to our perception of
> better future browser support, and that most of the browsers seemed to
> be putting
> a large push into Canvas performance. Coupled with the use of
> WebSockets, we felt an all HTML5 solution may be more universally
> supported
> in the long run. (although who can tell what the browser vendors are
> actually thinking :)
>
> Our initial testing showed that DOM manipulation was a surprising
> bottleneck in SVG animations and that, particularly as the SVG object
> count increased,
> Canvas performance (time to raster) was better. Also the rendering of
> the imshow inline png's was a lot quicker than the SVG equivalent in
> our initial testing.
> Obviously the vector strengths of SVG are highlighted with higher
> output DPI, and this is certainly an area of interest.
>
> This mail is mostly to give others a bit of background about our
> choice, I think it could easily have gone either way, and perhaps it
> should.
>
> Most of the client/server code could easily be factored out with a
> common API that accepts either an SVG or Canvas drawing object for
> display on the client side.
> This would give us the best of both worlds (raster and vector) in a
> number of situations (i.e. lower DPI / high animation rate using
> Canvas, high DPI with lots of interactivity using SVG etc...).
> Interactivity would need a tweak on the browser side (much easier to
> do with SVG than Canvas).
>
> As suggested, perhaps Brian Refsdal would be interested in looking at
> producing a more generic mplweb backend.
Great! I am interested in developing some of these ideas. I 
particularly like the idea to keep the transport design independent of 
the payload. I am also looking to expand on the collaborative element 
in mplh5canvas, and one of my first thoughts is to move the server code 
to the cloud. This way all communication can travel over port 80 or 443 
for maximum compatibility between networks/ISPs and the instance running 
matplotlib does not have to serve up pages (latency is a concern, have 
you found multiple ports to be superior for throughput?). I am also 
looking to reduce UI request contention with multiple users and develop 
a session space. Something akin to doodle or imgur where users can 
anonymously generate unique URLs to share.
I have written some prototype code that separates the canvas backend 
from the web server and websocket server to test for latency issues, but 
I am open to new ideas.
-Brian
>
> How about an imshow hybrid, with a canvas for the bitmap and SVG axes
> and surrounds :)
>
> Cheers,
>
> Simon Ratcliffe / Ludwig Schwardt
>
> SKA South Africa
> www.ska.ac.za
>
>> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for
>> any of the use cases I could dream up, and that in fact SVG is a more
>> appropriate choice for interactive graphics. The browser support for
>> each technology is fairly equivalent at this point, with IE9 finally
>> getting on the SVG bandwagon. The main problem with Canvas (from the
>> point of view of matplotlib) is that it doesn't support persistence,
>> (without building such a layer on top in JavaScript), so if you want to
>> update the figure, you have to send the whole thing over the wire each
>> time. SVG, on the other hand, maintains a tree of objects that can be
>> tweaked at any time (and the performance in the current generation of
>> browsers is stunning). One could send all of the large data objects as
>> SVG from matplotlib to the browser and using XML ids to maintain
>> relationships between the client and the server. Then, do scale the
>> data (in many common cases), it is just a matter of updating the affiine
>> transform on that object, (as well as updating the ticks etc, but that's
>> peanuts), which requires very little bandwidth. I have some hackish
>> "proof of concept" code doing this kind of thing, but it's a long way
>> from there to something that truly works.
>>
>> This all glosses over the path simplification stuff that matplotlib does
>> -- the assumption here is that the browser would have access to *all* of
>> the data, and there are probably practical limits on how big that data
>> can be.
>>
>> I recently did a lot of cleanup to the SVG backend to pave the way for
>> having persistent objects etc. -- though there is no client/server code
>> at all in master at the moment. All of that is "to be written", perhaps
>> by you if you're interested.
>>
>> Cheers,
>> Mike
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 06/13/2011 01:38 PM, Darren Dale wrote:
> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<md...@st...> wrote:
>> This was recently discussed in the thread "v1.0.x branch seems confused."
>>
>> I (believe) the consensus was to get out another v1.0.x maintenance
>> release out in the near future (which would not support py3k, but would
>> still support Python 2.4), and then merge the py3 branch into master so
>> it starts to get some more testing before making the next major release.
>>
>> I'm just today merging master into py3 so that when we are ready to do
>> the merge the other way most of the hard work will have already been done.
> Are there features already in master that should be supported by
> <python-2.6? If so, I think we should consider releasing 1.1.0 and
> making a 1.1.x maintenance branch before merging the py3 stuff back
> into master. Then mpl-1.2 could be the first to support py3.
That's a good question. We're now *officially* on 2.7 in my 
environment, so I don't have any compulsion to raise my hand here. But 
others may. Speak up! :)
> Should we move this discussion to the mpl-dev mailing list?
Sure.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom <md...@st...> wrote:
> This was recently discussed in the thread "v1.0.x branch seems confused."
>
> I (believe) the consensus was to get out another v1.0.x maintenance
> release out in the near future (which would not support py3k, but would
> still support Python 2.4), and then merge the py3 branch into master so
> it starts to get some more testing before making the next major release.
>
> I'm just today merging master into py3 so that when we are ready to do
> the merge the other way most of the hard work will have already been done.
Are there features already in master that should be supported by
<python-2.6? If so, I think we should consider releasing 1.1.0 and
making a 1.1.x maintenance branch before merging the py3 stuff back
into master. Then mpl-1.2 could be the first to support py3.
Should we move this discussion to the mpl-dev mailing list?
Darren

On 06/13/2011 10:07 AM, Simon Ratcliffe wrote:
> Hey Mike,
>
> Thanks for your informative assessment of Canvas vs SVG. Indeed it
> encapsulates much of the thinking and horse trading
> done when we decided on Canvas as a delivery technology for mplh5canvas.
>
> For us the plus points for Canvas came down to our perception of
> better future browser support, and that most of the browsers seemed to
> be putting
> a large push into Canvas performance. Coupled with the use of
> WebSockets, we felt an all HTML5 solution may be more universally
> supported
> in the long run. (although who can tell what the browser vendors are
> actually thinking :)
Yeah. I'll start implementing the "crystal ball" backend so we can 
answer that question ;)
> Our initial testing showed that DOM manipulation was a surprising
> bottleneck in SVG animations and that, particularly as the SVG object
> count increased,
> Canvas performance (time to raster) was better.
Interesting result. I wonder if browsers differ in that respect. I've 
been using Firefox 4 primarily, but testing with Chrome as well, and 
have been nothing but impressed with SVG performance -- but I'm only 
doing getElementById and then tweaking attributes, not actually changing 
tree morphology.
> Also the rendering of
> the imshow inline png's was a lot quicker than the SVG equivalent in
> our initial testing.
Have you tried non-inline PNGs? The only need for inline PNGs is to 
have a self-contained SVG file. When one has a webapp server available 
that is no longer necessary. I suspect the encoding to/from base64 adds 
some overhead.
> Obviously the vector strengths of SVG are highlighted with higher
> output DPI, and this is certainly an area of interest.
True. Of course, given that we already have a static SVG backend that 
works, it should be simple enough to have a "Print" button that 
generates SVG only when printing (much like Google Docs generates a PDF 
when printing).
> This mail is mostly to give others a bit of background about our
> choice, I think it could easily have gone either way, and perhaps it
> should.
Yes -- perhaps still an open question.
I should probably also add: I have sort of a bias toward a smart 
server/dumb client approach to continue to leverage the existing 
matplotlib code as much as possible -- which is kind of at odds with the 
ideal arrangement for best interactive performance, which would be to 
move a bunch of logic into Javascript. I don't have anything against 
plotting with Javascript -- there are some great packages out there -- 
but then it becomes a very different beast. I think your work has that 
assumption behind it as well, but speaking to some folks at Sage Days, 
it's not always implied when people start drafting a plan to do this.
Cheers,
Mike
> SKA South Africa
> www.ska.ac.za
>
>> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for
>> any of the use cases I could dream up, and that in fact SVG is a more
>> appropriate choice for interactive graphics. The browser support for
>> each technology is fairly equivalent at this point, with IE9 finally
>> getting on the SVG bandwagon. The main problem with Canvas (from the
>> point of view of matplotlib) is that it doesn't support persistence,
>> (without building such a layer on top in JavaScript), so if you want to
>> update the figure, you have to send the whole thing over the wire each
>> time. SVG, on the other hand, maintains a tree of objects that can be
>> tweaked at any time (and the performance in the current generation of
>> browsers is stunning). One could send all of the large data objects as
>> SVG from matplotlib to the browser and using XML ids to maintain
>> relationships between the client and the server. Then, do scale the
>> data (in many common cases), it is just a matter of updating the affiine
>> transform on that object, (as well as updating the ticks etc, but that's
>> peanuts), which requires very little bandwidth. I have some hackish
>> "proof of concept" code doing this kind of thing, but it's a long way
>> from there to something that truly works.
>>
>> This all glosses over the path simplification stuff that matplotlib does
>> -- the assumption here is that the browser would have access to *all* of
>> the data, and there are probably practical limits on how big that data
>> can be.
>>
>> I recently did a lot of cleanup to the SVG backend to pave the way for
>> having persistent objects etc. -- though there is no client/server code
>> at all in master at the moment. All of that is "to be written", perhaps
>> by you if you're interested.
>>
>> Cheers,
>> Mike
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hey Mike,
Thanks for your informative assessment of Canvas vs SVG. Indeed it
encapsulates much of the thinking and horse trading
done when we decided on Canvas as a delivery technology for mplh5canvas.
I particularly agree with you that sending smaller encapsulated
updates is less bandwidth intensive (although not necessarily faster
to re-rasterise the
client display). We have also spent a lot of time tearing our hair out
at the primitive drawing commands, the lack of dashed lines in
particular
is pretty painful.
For us the plus points for Canvas came down to our perception of
better future browser support, and that most of the browsers seemed to
be putting
a large push into Canvas performance. Coupled with the use of
WebSockets, we felt an all HTML5 solution may be more universally
supported
in the long run. (although who can tell what the browser vendors are
actually thinking :)
Our initial testing showed that DOM manipulation was a surprising
bottleneck in SVG animations and that, particularly as the SVG object
count increased,
Canvas performance (time to raster) was better. Also the rendering of
the imshow inline png's was a lot quicker than the SVG equivalent in
our initial testing.
Obviously the vector strengths of SVG are highlighted with higher
output DPI, and this is certainly an area of interest.
This mail is mostly to give others a bit of background about our
choice, I think it could easily have gone either way, and perhaps it
should.
Most of the client/server code could easily be factored out with a
common API that accepts either an SVG or Canvas drawing object for
display on the client side.
This would give us the best of both worlds (raster and vector) in a
number of situations (i.e. lower DPI / high animation rate using
Canvas, high DPI with lots of interactivity using SVG etc...).
Interactivity would need a tweak on the browser side (much easier to
do with SVG than Canvas).
As suggested, perhaps Brian Refsdal would be interested in looking at
producing a more generic mplweb backend.
How about an imshow hybrid, with a canvas for the bitmap and SVG axes
and surrounds :)
Cheers,
Simon Ratcliffe / Ludwig Schwardt
SKA South Africa
www.ska.ac.za
> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for
> any of the use cases I could dream up, and that in fact SVG is a more
> appropriate choice for interactive graphics. The browser support for
> each technology is fairly equivalent at this point, with IE9 finally
> getting on the SVG bandwagon. The main problem with Canvas (from the
> point of view of matplotlib) is that it doesn't support persistence,
> (without building such a layer on top in JavaScript), so if you want to
> update the figure, you have to send the whole thing over the wire each
> time. SVG, on the other hand, maintains a tree of objects that can be
> tweaked at any time (and the performance in the current generation of
> browsers is stunning). One could send all of the large data objects as
> SVG from matplotlib to the browser and using XML ids to maintain
> relationships between the client and the server. Then, do scale the
> data (in many common cases), it is just a matter of updating the affiine
> transform on that object, (as well as updating the ticks etc, but that's
> peanuts), which requires very little bandwidth. I have some hackish
> "proof of concept" code doing this kind of thing, but it's a long way
> from there to something that truly works.
>
> This all glosses over the path simplification stuff that matplotlib does
> -- the assumption here is that the browser would have access to *all* of
> the data, and there are probably practical limits on how big that data
> can be.
>
> I recently did a lot of cleanup to the SVG backend to pave the way for
> having persistent objects etc. -- though there is no client/server code
> at all in master at the moment. All of that is "to be written", perhaps
> by you if you're interested.
>
> Cheers,
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 06/06/2011 02:06 PM, Brian Refsdal wrote:
> Hello,
>
> I've been following the updates to mplh5canvas for some time now, since
> its debut at SciPy 2010. I am interested in working to extend
> mplh5canvas into a cloud-based web service as a thesis project. I have
> not found anybody whose is currently working on this path. Are there
> any active projects working on this? Specifically, I am referring to
> Michael Droettboom's comments of a possible web application and Simon
> Ratcliffe's comments about using Flex. If anyone is interested I would
> be happy to talk in person at SciPy next month.
I did a little exploratory work with this at the Sage Days sprint in 
Seattle back in March.
My (humble) assessment is that HTML 5 Canvas doesn't make much sense for 
any of the use cases I could dream up, and that in fact SVG is a more 
appropriate choice for interactive graphics. The browser support for 
each technology is fairly equivalent at this point, with IE9 finally 
getting on the SVG bandwagon. The main problem with Canvas (from the 
point of view of matplotlib) is that it doesn't support persistence, 
(without building such a layer on top in JavaScript), so if you want to 
update the figure, you have to send the whole thing over the wire each 
time. SVG, on the other hand, maintains a tree of objects that can be 
tweaked at any time (and the performance in the current generation of 
browsers is stunning). One could send all of the large data objects as 
SVG from matplotlib to the browser and using XML ids to maintain 
relationships between the client and the server. Then, do scale the 
data (in many common cases), it is just a matter of updating the affiine 
transform on that object, (as well as updating the ticks etc, but that's 
peanuts), which requires very little bandwidth. I have some hackish 
"proof of concept" code doing this kind of thing, but it's a long way 
from there to something that truly works.
This all glosses over the path simplification stuff that matplotlib does 
-- the assumption here is that the browser would have access to *all* of 
the data, and there are probably practical limits on how big that data 
can be.
I recently did a lot of cleanup to the SVG backend to pave the way for 
having persistent objects etc. -- though there is no client/server code 
at all in master at the moment. All of that is "to be written", perhaps 
by you if you're interested.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Sorry for the delayed reply -- I've been on vacation.
Thanks so much for untangling this mess. It looks great.
Mike
On 06/02/2011 07:46 PM, Darren Dale wrote:
> Folks,
>
> We had some minor confusion with a merge a few weeks back, which
> pulled much of the master branch into the v1.0.x maintenance branch. I
> created a new v1.0.x-maint branch that rolled back all of the changes
> from that point on, and cherry-picked all of the changes that were
> actually intended for the v1.0.x branch.
>
> Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
> repository (though I'll keep a local copy for a few weeks as a backup,
> just in case).
>
> If you have any changes that branched from v1.0.x after May 6 2011,
> please contact me off list so we can correctly apply those changes on
> top of v1.0.x-maint.
>
> Darren
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hello,
I've been following the updates to mplh5canvas for some time now, since 
its debut at SciPy 2010. I am interested in working to extend 
mplh5canvas into a cloud-based web service as a thesis project. I have 
not found anybody whose is currently working on this path. Are there 
any active projects working on this? Specifically, I am referring to 
Michael Droettboom's comments of a possible web application and Simon 
Ratcliffe's comments about using Flex. If anyone is interested I would 
be happy to talk in person at SciPy next month.
Cheers,
Brian

On Mon, Jun 6, 2011 at 1:29 AM, Eric Firing <ef...@ha...> wrote:
> Now I see where the problem came from: 86774fc290, back in February.
>
> Fixed in de39c798e0.
Thanks much, Eric!
Best,
f

On 06/05/2011 06:00 PM, Fernando Perez wrote:
> Hi all,
>
> I think there's a problem with scatter() that didn't use to be there,
> as in current HEAD it seems to not be computing xlim/ylim correctly:
>
> scatter(range(100),rand(100))
>
> sets a plot with a (0,1) window on x/y, which is obviously the wrong
> range. Is anyone else seeing this?
Now I see where the problem came from: 86774fc290, back in February.
Fixed in de39c798e0.
Eric
>
> Thanks,
>
> f
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 06/05/2011 06:00 PM, Fernando Perez wrote:
> Hi all,
>
> I think there's a problem with scatter() that didn't use to be there,
> as in current HEAD it seems to not be computing xlim/ylim correctly:
>
> scatter(range(100),rand(100))
>
> sets a plot with a (0,1) window on x/y, which is obviously the wrong
> range. Is anyone else seeing this?
Yes, I see it. It is not in the reconstituted maintenance branch.
Eric
>
> Thanks,
>
> f
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,
I think there's a problem with scatter() that didn't use to be there,
as in current HEAD it seems to not be computing xlim/ylim correctly:
scatter(range(100),rand(100))
sets a plot with a (0,1) window on x/y, which is obviously the wrong
range. Is anyone else seeing this?
Thanks,
f

On Saturday, June 4, 2011, Eric Firing <ef...@ha...> wrote:
> On 06/04/2011 06:05 AM, Benjamin Root wrote:
>> On Sat, Jun 4, 2011 at 9:09 AM, Phil Elson <phi...@ho...
>> <mailto:phi...@ho...>> wrote:
>>
>>
>>   The first line of code on the page
>>   http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests
>>   that it is possible to give the projection directly to
>>   mpl.pyplot.plot but
>>   this does not work for me.
>>
>>   Should this functionality exist? I am aware that the pyplot.plot
>>   function is
>>   autogenerated by boilerplate.py, but I am a little weary of
>>   modifying that.
>>
>>   Any help gratefully received.
>>
>>
>> Hmm, this doesn't seem 100% logically correct. I think the only case
>> where this would work correctly is if the plot command would also
>> trigger the creation of a new axes object. If the axes object already
>> exists, then I seriously doubt this would work as advertised. Is that
>> the case with your code?
>>
>> Ben Root
>
> Ben,
>
> The first paragraph of that doc page needs repair. Trivially, there are
> two references to set_xscale. The problem pointed out above is more
> serious. plot() has no facility for handling a projection kwarg, and I
> don't think it would make sense to try to add one. pyplot functions
> that accept the projection kwarg are axes, subplot, and subplots.
>
> Do you want to fix the paragraph, or should I?
>
I can take a look at it tonight.
> Independently, I want to redo the FAQ discussion of draw(), show(), and
> interactive versus non-interactive mode. It is possible that this topic
> needs more attention elsewhere as well, but I want to start with the FAQ.
>
> Eric
>
Agreed, these are some fundamental functions and probably be set apart
in a "getting started" section, maybe?
Ben Root

On 06/04/2011 09:45 AM, Phil Elson wrote:
> > I think the only case where this would work correctly is if the plot
> command would also trigger the creation of a new axes object.
> Can't see how this can ever happen given the pyplot.plot code, which
> creates a standard axes without passing through any arguments.
>
> I agree that there are situations when it doesn't make sense to define
> the projection when doing a plt.plot, maybe best to fix the projections
> documentation instead of providing a keyword which is not always valid.
> Either that, or plt.plot with a projection always makes a new axes?
>
> Attempting to pass the projection currently to plot results in an exception:
>
> plt>>> plt.plot(range(10), projection='polar')
> ...
> TypeError: There is no line property "projection"
>
Yes, the behavior makes sense, the documentation doesn't; it will be fixed.
Eric

On 06/04/2011 09:08 AM, Eric Firing wrote:
> Independently, I want to redo the FAQ discussion of draw(), show(), and
> interactive versus non-interactive mode. It is possible that this topic
> needs more attention elsewhere as well, but I want to start with the FAQ.
I think I will move the "show" section entirely out of howto and put the 
revision in "usage".
Eric
>
> Eric

> I think the only case where this would work correctly is if the plot command would also trigger the creation of a new axes object. 
Can't see how this can ever happen given the pyplot.plot code, which creates a standard axes without passing through any arguments.
I agree that there are situations when it doesn't make sense to define the projection when doing a plt.plot, maybe best to fix the projections documentation instead of providing a keyword which is not always valid. Either that, or plt.plot with a projection always makes a new axes?
Attempting to pass the projection currently to plot results in an exception:
plt>>> plt.plot(range(10), projection='polar')
...
TypeError: There is no line property "projection"
 		 	 		 

On 06/04/2011 06:05 AM, Benjamin Root wrote:
> On Sat, Jun 4, 2011 at 9:09 AM, Phil Elson <phi...@ho...
> <mailto:phi...@ho...>> wrote:
>
>
> The first line of code on the page
> http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests
> that it is possible to give the projection directly to
> mpl.pyplot.plot but
> this does not work for me.
>
> Should this functionality exist? I am aware that the pyplot.plot
> function is
> autogenerated by boilerplate.py, but I am a little weary of
> modifying that.
>
> Any help gratefully received.
>
>
> Hmm, this doesn't seem 100% logically correct. I think the only case
> where this would work correctly is if the plot command would also
> trigger the creation of a new axes object. If the axes object already
> exists, then I seriously doubt this would work as advertised. Is that
> the case with your code?
>
> Ben Root
Ben,
The first paragraph of that doc page needs repair. Trivially, there are 
two references to set_xscale. The problem pointed out above is more 
serious. plot() has no facility for handling a projection kwarg, and I 
don't think it would make sense to try to add one. pyplot functions 
that accept the projection kwarg are axes, subplot, and subplots.
Do you want to fix the paragraph, or should I?
Independently, I want to redo the FAQ discussion of draw(), show(), and 
interactive versus non-interactive mode. It is possible that this topic 
needs more attention elsewhere as well, but I want to start with the FAQ.
Eric

On Sat, Jun 4, 2011 at 11:09 AM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Jun 3, 2011 at 6:15 PM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>> By the way, whoever is the one to push the docs up to sourceforge, you
>>> can now do so from the v1.0.x-maint branch. I have built it on my computer
>>> and all of my own changes appear correct. I couldn't test *everything* (my
>>> LaTeX setup isn't quite right), but everything I intended to change appears
>>> to be there.
>>>
>>> I just pushed the doc build from the maint branch up to sf. Take it for
>> a test drive. Thanks for pushing through on the doc fix patch.
>>
>> JDH
>>
>>
> No problem, glad to be of service. The pages look fine so far (although I
> want to see if I can get it to be more friendly to people with smaller
> screens such as an EeePC). There will be some additional work I will put in
> to improve the docs for the 1.1.0 release. If anybody has a wishlist or
> complaints about the current docs, just let me know.
>
> I have also tried building the docs from master after merging, and the
> debugger problem happened again using the latest from sphinx. I will look
> into it further to see if I can turn that "feature" off.
>
> Ben Root
>
Looks like it is a feature, not a bug. sphinx-build has a command-line
option "-P" which fires off pdb whenever there is an unhandled exception.
Removing that keeps the pdb from firing off, but this still doesn't solve
our problem. The multiprocessing pool does not exit out and the process
still hangs.
Right now, I am trying to figure out why the --small option to make.py is
causing an unhandled exception in master with the latest sphinx. It seems
like bad command-line parsing by sphinx.
Ben Root

On Fri, Jun 3, 2011 at 6:15 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben...@ou...> wrote:
>
>> By the way, whoever is the one to push the docs up to sourceforge, you can
>> now do so from the v1.0.x-maint branch. I have built it on my computer and
>> all of my own changes appear correct. I couldn't test *everything* (my
>> LaTeX setup isn't quite right), but everything I intended to change appears
>> to be there.
>>
>> I just pushed the doc build from the maint branch up to sf. Take it for a
> test drive. Thanks for pushing through on the doc fix patch.
>
> JDH
>
>
No problem, glad to be of service. The pages look fine so far (although I
want to see if I can get it to be more friendly to people with smaller
screens such as an EeePC). There will be some additional work I will put in
to improve the docs for the 1.1.0 release. If anybody has a wishlist or
complaints about the current docs, just let me know.
I have also tried building the docs from master after merging, and the
debugger problem happened again using the latest from sphinx. I will look
into it further to see if I can turn that "feature" off.
Ben Root

On Sat, Jun 4, 2011 at 9:09 AM, Phil Elson <phi...@ho...> wrote:
>
> The first line of code on the page
> http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests
> that it is possible to give the projection directly to mpl.pyplot.plot but
> this does not work for me.
>
> Should this functionality exist? I am aware that the pyplot.plot function
> is
> autogenerated by boilerplate.py, but I am a little weary of modifying that.
>
> Any help gratefully received.
>
Hmm, this doesn't seem 100% logically correct. I think the only case where
this would work correctly is if the plot command would also trigger the
creation of a new axes object. If the axes object already exists, then I
seriously doubt this would work as advertised. Is that the case with your
code?
Ben Root

The first line of code on the page
http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests
that it is possible to give the projection directly to mpl.pyplot.plot but
this does not work for me.
Should this functionality exist? I am aware that the pyplot.plot function is
autogenerated by boilerplate.py, but I am a little weary of modifying that.
Any help gratefully received.
-- 
View this message in context: http://old.nabble.com/plt.plot-projection-kwarg-tp31772544p31772544.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben...@ou...> wrote:
> By the way, whoever is the one to push the docs up to sourceforge, you can
> now do so from the v1.0.x-maint branch. I have built it on my computer and
> all of my own changes appear correct. I couldn't test *everything* (my
> LaTeX setup isn't quite right), but everything I intended to change appears
> to be there.
>
> I just pushed the doc build from the maint branch up to sf. Take it for a
test drive. Thanks for pushing through on the doc fix patch.
JDH

On Fri, Jun 3, 2011 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
> On 06/03/2011 07:21 AM, Benjamin Root wrote:
>
> > P.S. : As an interesting aside to what caused me to find this mistake...
> > My docs were still not building correctly, although now that the v1.0.x
> > branch is fixed, it didn't have the multiprocessing trick that is in
> > master. Therefore, when the error occurred, a message was able to be
> > printed to my screen, which allows me to trace it down.
> >
> > What happens is that eventually, the python debugger is fired off by
> > sphinx. If possible, it would probably be wise to disable this behavior
>
> Ben,
>
> So this part of the problem sounds like a bad design in sphinx, correct?
> Do you know whether it is present in the current version of sphinx?
> If so, you might send the sphinx people a bug report. My suspicion is
> that the triggering of pdb was intended to be temporary (or at least
> optional), but got left in the sphinx code by mistake--if that is indeed
> where the fault lies.
>
> Eric
>
I will investigate that further. Currently I am using v1.0.1 of sphinx.
After the current round of docs are tested and pushed up, I will take a
deeper look.
By the way, whoever is the one to push the docs up to sourceforge, you can
now do so from the v1.0.x-maint branch. I have built it on my computer and
all of my own changes appear correct. I couldn't test *everything* (my
LaTeX setup isn't quite right), but everything I intended to change appears
to be there.
Ben Root