[matplotlib-devel] Patchs for changing ticks messing up mplot3d and tick-get/setters
I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud mpl3d-ticks-fix.diff Description: Binary data mpl3d-ticks-fix-add-methods.diff Description: Binary data -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] HTML5 Matplotlib Backend
(Michael Droettboom)
>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not in
>> data units. ?It would be great if this could display data units, though
>> being general enough to support custom scales (eg. log) and projections (eg.
>> polar) may be tricky without making a round-trip to the server.
(Simon Ratcliffe)
>As you mentioned, the trick is in giving the client some view on how
>pixels should map to data values without fetching these for each mouse
>movement. For simple cartesian plots this is probably pretty
>straightforward. It is something we need to get working for our
>internal use so it should get solved at some stage.
I have accomplished this in one of my applications as follows:
Axes =figure.get_axes()
#The transform used in this axis is Composite Generic Transform, so get the two
affine transformation matricies
MatrixA = axes[0].transData.inverted()._a.get_matrix()
MatrixB = axes[0].transData.inverted()._b.get_matrix()
I use an Ajax or WebSockets call to get MatrixA and MatrixB to the client
(javascript) side, and then do the affine transform in the mousemove callback:
function ev_mousemove(ev){
if(affineMatrixPopulated){
//First convert the browser coordinates to the form MPL uses
var x, y, x2, y2;
x = ev.clientX - canvas.offsetLeft;
y = canvas.height - (ev.clientY - canvas.offsetTop);
//Now it's just a couple matrix multiplications:
// I flattened the Matrix when transferring from the server
process, so affineMatrixA[2] is MatrixA[0,2]
// affineMatrixA[4] is MatrixA[1,1] etc...
x2 = affineMatrixA[0] * x + affineMatrixA[1] * y +
affineMatrixA[2];
y2 = affineMatrixA[3] * x + affineMatrixA[4] * y +
affineMatrixA[5];
x2 = affineMatrixB[0] * x2 + affineMatrixB[1] * y2 +
affineMatrixB[2];
y2 = affineMatrixB[3] * x2 + affineMatrixB[4] * y2 +
affineMatrixB[5];
document.getElementById('cursor_info').innerText = "Cursor at: "
+ x2 + "," + y2;
}
}
The simple affine transformation can be accomplished by leaving off the MatrixB
part. Non affine will probably be similar to the above followed by a log or
exponential operation.
Ryan Wagner | Senior Technical Support Engineer |
Rogue Wave Software, Inc.
5500 Flatiron Parkway, Suite 200, Boulder, CO 80301
ryan.wag...@roguewave.com
www.roguewave.com
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] HTML5 Matplotlib Backend
On Fri, Jul 16, 2010 at 10:21 AM, Ryan Wagner wrote: > (Michael Droettboom) > >>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not >>> in > >>> data units. ?It would be great if this could display data units, though > >>> being general enough to support custom scales (eg. log) and projections >>> (eg. > >>> polar) may be tricky without making a round-trip to the server. > > > > (Simon Ratcliffe) > >>As you mentioned, the trick is in giving the client some view on how > >>pixels should map to data values without fetching these for each mouse > >>movement. For simple cartesian plots this is probably pretty > >>straightforward. It is something we need to get working for our > >>internal use so it should get solved at some stage. > > > > I have accomplished this in one of my applications as follows: > > > > Axes =figure.get_axes() > > #The transform used in this axis is Composite Generic Transform, so get the > two affine transformation matricies > > MatrixA = axes[0].transData.inverted()._a.get_matrix() > > MatrixB = axes[0].transData.inverted()._b.get_matrix() [...] > The simple affine transformation can be accomplished by leaving off the > MatrixB part. Non affine will probably be similar to the above followed by a > log or exponential operation. The other option, which would be somewhat less accurate but would avoid reimplementing every projection in javascript, would be to build a mesh (e.g., a grid) over the client's viewport region, sample the value of the projection at each point on the grid, send that to the client, and then let the client do linear interpolation to estimate points in between grid points. -- Nathaniel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rendering problem in mplot3d
On Sun, Jul 18, 2010 at 6:16 PM, Benjamin Root wrote: > A few corrections. First, I wrong, it is unusual. The second axes that I > noticed in a 2d case came from a colorbar being added. Second, in the 3d > case, it was the Axes3DSubplot object being added twice, not the regular > object like I originally said. > > The cause of this is due to the Axes3D initializer adding itself to the > figure object being passed in. This initializer is called when > add_subplot() is called, so add_subplot also adds the axes when it is > finished making it. For normal projections, the initializer does not add > itself to the axes. > > Removing the add_axes in the Axes3D initializer would "solve" the issue > outright, however, there are plenty of legacy code where Axes3D is called > with a figure passed in in order to create the axes, and this would break > that use pattern. I think the fact that add_axes will just blindly add a duplicate axes is a bug. So why not have add_axes do something like the following: if ax not in axes_list: axes_list.append(ax) Anyone see anything wrong with this approach? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] refactoring of show
I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::
import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')
from matplotlib.pyplot import scatter,show
from numpy.random import randn
%gui -a whateverguiname
scatter(*randn(2,100))
show()
that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line. Below are my results for the
various backends:
*wx:
w/o %gui: nothing appears until show(), show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
*qt4:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() does NOT block.
*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior
*tk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...
On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing wrote:
> All,
>
> John noticed that my changes to show() prior to 1.0 had broken a use
> case with tkagg and ipython -pylab, so I fixed that yesterday in
> maintenance branch and trunk. Today, in 8562 and 8563, I did some
> refactoring to try to make show() behavior more understandable across
> backends, and easier to modify if necessary. Specifically, we need to
> work with the ipython people to make sure the ipython 0.11 refactoring
> of interactive support works as intended. I haven't done any testing
> with the development version of 0.11 yet.
>
> At present, all interactive backends start a blocking mainloop only if
> ipython has not attached a _needmain flag to show(), and if mpl is not
> in interactive mode.
>
> Under all script and ipython conditions, multiple calls to show in a
> session or script are permitted.
>
> All interactive backends behave the same when run with ipython -pylab,
> version 0.10: show is non-blocking, regardless of whether it is executed
> on the command line (completely unnecessary) or is found in a script.
>
> Under raw ipython (no -pylab or other threading flags provided), with
> mpl in non-interactive mode, all backends behave the same: show() is
> needed and blocks, but may be called multiple times. With mpl in
> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
> qt4agg behave the same as in -pylab mode, so there so no longer any real
> need for the special threading modes; but wx* and qtagg do not behave in
> a useful way, so they still need the special threading.
>
> All of the above is based on quick tests with my own system, ubuntu
> 10.04. I expect it will be the same for other supported systems, with
> the exception that behavior in raw ipython mode, with mpl in interactive
> mode, may not work with some earlier versions of gui toolkits--but I
> suspect we will not actually encounter this for supported versions.
>
> I have not built or tested anything under Windows or OS X. For the
> latter, testing of the macosx backend is needed. I expect cocoaagg to
> behave differently than the others, but no differently than it did
> before my changes.
>
> Eric
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to exclude some examples to be built for doc?
Hello, you know this question might seems strange, but I'd like to avoid some examples to be built when creating documentation. Those examples are the one using mpl.cbook.get_sample_data() to retrieve data files from the remote svn. In Debian we are not allowed to prepare a package that downloads "stuff" from the web, so I have to avoid this. The fastest solution I see is to actually exclude them from the list of the examples to build (but still install them, for users to use), but I didn't understand how :) Another solution would be for you to ship those datafile into the released tarball, so that it's all consistent and then point the example to those files, but how? if you find this in some way unacceptable, I can also download those files separately and add them when preparing the Debian package, but I have to find a way to tell get_sample_data() to point to that location... ...and so I'm asking you: what would you feel to be the best solution? Thanks in advance for your help and suggestions, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to exclude some examples to be built for doc?
On 07/19/2010 11:10 AM, Sandro Tosi wrote: > Hello, > you know this question might seems strange, but I'd like to avoid some > examples to be built when creating documentation. > > Those examples are the one using mpl.cbook.get_sample_data() to > retrieve data files from the remote svn. In Debian we are not allowed > to prepare a package that downloads "stuff" from the web, so I have to > avoid this. Good policy! > > The fastest solution I see is to actually exclude them from the list > of the examples to build (but still install them, for users to use), > but I didn't understand how :) > > Another solution would be for you to ship those datafile into the > released tarball, so that it's all consistent and then point the > example to those files, but how? if you find this in some way > unacceptable, I can also download those files separately and add them > when preparing the Debian package, but I have to find a way to tell > get_sample_data() to point to that location... > > ...and so I'm asking you: what would you feel to be the best solution? I think we should include any necessary data, and also eliminate the downloading from the examples run by the standard backend_driver. The caching doesn't seem to work right, and there are long timeouts. This was a problem for me recently when I was out on a ship, working on mpl on a computer without a live internet connection. It would be OK to retain some examples with live downloading, but they should not be required for doc generation or for basic testing of mpl. They don't contribute anything essential to either. Eric > > Thanks in advance for your help and suggestions, -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] refactoring of show
On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname
>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line. Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(), show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...
Erik,
Thanks for the testing. I was also starting to test with ipython 0.11
yesterday, and had reached the opposite conclusion--but I was using a
different procedure. So I will track down the difference. My results
were quite different...
Please verify: were you using the latest mpl from svn?
Eric
>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk. Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary. Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended. I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times. With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04. I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X. For the
>> latter, testing of the macosx backend is needed. I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> Eric
>>
>> --
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.co
Re: [matplotlib-devel] refactoring of show
On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname
Aha!
Please leave out the -a. It is harmful, not helpful, for mpl. This may
mean we need to change mpl and/or ipython, or the documentation, to
prevent problems with the -a option; but I think you will find that if
you leave out that option, the behavior will be more consistent and the
need for Ctrl-C will go away. Without %gui, there will still be an
inconsistency between wx and the others--but that's what the %gui magic
is for, to make wx use PyOS_InputHook like the others.
Eric
>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line. Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(), show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...
>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk. Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary. Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended. I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times. With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04. I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X. For the
>> latter, testing of the macosx backend is needed. I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> Eric
>>
>> --
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
Re: [matplotlib-devel] refactoring of show
Hey guys, On Mon, Jul 19, 2010 at 4:07 PM, Eric Firing wrote: > > Please leave out the -a. It is harmful, not helpful, for mpl. This may > mean we need to change mpl and/or ipython, or the documentation, to > prevent problems with the -a option; but I think you will find that if > you leave out that option, the behavior will be more consistent and the > need for Ctrl-C will go away. Without %gui, there will still be an > inconsistency between wx and the others--but that's what the %gui magic > is for, to make wx use PyOS_InputHook like the others. I just wanted to say thanks a LOT for this testing. Right now we're not quite in the gui code, but it's *very* useful for us to have this information. And please keep in mind that if you find out that from the ipython side we're doing something silly/backwards regarding this, we're more than happy to change it. We ultimately want the gui integration to be as painless as possible. One extra twist to consider: we're moving to a 2-process model for most of ipython, so that user interface and code execution live in separate processes. It will continue to be possible to use a one-process ipython, but we think most users will prefer the two-process model. One quirk there will be that %gui now uses PyOSInputHook to talk to the GUI event loop, but this is only called by Python if stdin is waiting for input. In a server process (like we are starting to develop), there is no interactive input (the input comes over a socket) so we'll need to worry about letting the GUI event loop work while keeping the network event loop also responsive. As our picture becomes clearer we'll make sure to update you folks as well, so we can work from both ends (ipython/mpl) to ensure a good end-user experience with minimal fuss and all relevant backends. Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to exclude some examples to be built for doc?
On Mon, Jul 19, 2010 at 5:22 PM, Eric Firing wrote: > It would be OK to retain some examples with live downloading, but they > should not be required for doc generation or for basic testing of mpl. > They don't contribute anything essential to either. The primary motivation for the get_sample_data code arose from my observation that the gallery had become extremely popular, and appeared to be the way most people learned/experimented with mpl. I wanted some way to make it easy for a user to download and run any example from the gallery. One could say, "grab this tarball or zipfile and unpack it before running this example", but getting the relative paths right, especially on windows, is difficult for new users. I completely agree that we can and should support a mechanism for users / distributors who want to circumvent the download phase. One could have an rc param "sampledata.localonly" that would check the mpl config dir for a sample_data dir (which is where it looks already) and forgo all the revision control stuff: if the file is there load it, else raise. Or we could support a special MPLSAMPLEDATA env var which could point to a dir or even a tar/zip file. Then one could get a svn co of sample_data, zip it up when going out to sea or packaging mpl, and configure mpl, presumably via the rc mechanism or env vars to use the hardcopy. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
