matplotlib-devel Mailing List for matplotlib

On Fri, Dec 16, 2011 at 3:34 PM, Eric Firing <ef...@ha...> wrote:
> If you are willing and able to do it, please go ahead.  I can't think of
> any problem it would create.  (But I don't know whether the repo is
> writable.)

Great, thanks.  I'll see if I can push and will report back.  If it
doesn't work, we'll see if John can later restore write access to it.

Cheers,

f

On 12/16/2011 10:20 AM, Fernando Perez wrote:
> Hi all,
>
> I just added the stinkbug.png file to the sample_data repo so the
> Image tutorial and other examples using this image could be run by
> users making cbook.get_sample_data calls.  But while it works fine
> with a reasonably recent MPL, I tested with the system one in Ubuntu
> 11.10, and it does not find the file.  The reason is simply that this
> version of mpl still had the old SVN sample_data repo URL:
>
> baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/'
>
> So the problem is that any users of 11.10 are now stuck with a 'frozen
> in time' sample_data repo.
>
> We can fix this easily by simply pushing over to sample_data an update
> with any new files in the github one.  Since that repo changes fairly
> slowly and the changes typically involve just putting new files in and
> no actual code, it should be fairly easy to do manually.
>
> What do folks think?  If you agree, I'm happy to push an update now
> (I'm assuming the SVN repo is still writable, which might not be the
> case...).

Fernando,

If you are willing and able to do it, please go ahead.  I can't think of 
any problem it would create.  (But I don't know whether the repo is 
writable.)

Eric

>
> Cheers,
>
> f
>

Hi all,

I just added the stinkbug.png file to the sample_data repo so the
Image tutorial and other examples using this image could be run by
users making cbook.get_sample_data calls.  But while it works fine
with a reasonably recent MPL, I tested with the system one in Ubuntu
11.10, and it does not find the file.  The reason is simply that this
version of mpl still had the old SVN sample_data repo URL:

baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/'

So the problem is that any users of 11.10 are now stuck with a 'frozen
in time' sample_data repo.

We can fix this easily by simply pushing over to sample_data an update
with any new files in the github one.  Since that repo changes fairly
slowly and the changes typically involve just putting new files in and
no actual code, it should be fairly easy to do manually.

What do folks think?  If you agree, I'm happy to push an update now
(I'm assuming the SVN repo is still writable, which might not be the
case...).

Cheers,

f

On 12/15/2011 11:44 PM, Jason Grout wrote:
> On 12/15/11 8:03 PM, Michael Droettboom wrote:
>> On 12/07/2011 11:36 PM, Jason Grout wrote:
>>> On 12/7/11 10:27 PM, Chris Barker wrote:
>>>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>>>> Has anyone ever worked on a backend that generates javascript code for
>>>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>>>> accompany it with the javascript code to trace the function, etc.
>>>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>>>> the thread "Using the Agg renderer by itself"
>>>>
>>>> Here's a cut and paste:
>>>>
>>>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>>>>      >
>>>>      >     Ben is referring to mplh5canvas, available at
>>>>      >     http://code.google.com/p/mplh5canvas/. The main advantage of this
>>>>      >     approach is interactive zooming of plots within the browser. If this is
>>>>      >     not important to you, it will probably be faster to generate static PNGs
>>>>      >     or SVGs.
>>>>      >
>>>>      >     The HTML5 backend should be easy to try out, as it is a pure Python
>>>>      >     package with no onerous dependencies.
>>>>      >
>>> Michael Droettboom played with this a little at the Sage Days in March,
>>> IIRC, and I seem to think he also whipped up an interactive demo using
>>> svg plots.  Michael, do you remember what your conclusions were?
>>>
>> My conclusion was basically that the current crop of browsers are plenty
>> fast and its generally feasible.  But rewriting all that Python code in
>> Javascript ain't a small project ;)
> So maybe pyjamas or pyjs might help?
>
> http://pyjs.org/
>
> http://stackoverflow.com/questions/683462/best-way-to-integrate-python-and-javascript
> gives a few other python->javascript compilers.  I don't know if any are
> currently active, though.
>
> I thought you also had some conclusion about using SVG instead of HTML5
> canvas...
>
Yes.  In the case where you want to create a bunch of graphics objects 
that may be transformed (i.e. zoomed and panned) later, SVG is much more 
efficient.  Canvas forces JavaScript to run through the entire drawing 
stack with each update, whereas SVG rendering allows a single object to 
be manipulated and only the parts of the drawing that change will be 
updated (and that all happens in the browser's renderer, not JavaScript 
so is therefore much faster).

Mike

On 12/15/11 8:03 PM, Michael Droettboom wrote:
> On 12/07/2011 11:36 PM, Jason Grout wrote:
>> On 12/7/11 10:27 PM, Chris Barker wrote:
>>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>>> Has anyone ever worked on a backend that generates javascript code for
>>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>>> accompany it with the javascript code to trace the function, etc.
>>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>>> the thread "Using the Agg renderer by itself"
>>>
>>> Here's a cut and paste:
>>>
>>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>>>     >
>>>     >    Ben is referring to mplh5canvas, available at
>>>     >    http://code.google.com/p/mplh5canvas/. The main advantage of this
>>>     >    approach is interactive zooming of plots within the browser. If this is
>>>     >    not important to you, it will probably be faster to generate static PNGs
>>>     >    or SVGs.
>>>     >
>>>     >    The HTML5 backend should be easy to try out, as it is a pure Python
>>>     >    package with no onerous dependencies.
>>>     >
>> Michael Droettboom played with this a little at the Sage Days in March,
>> IIRC, and I seem to think he also whipped up an interactive demo using
>> svg plots.  Michael, do you remember what your conclusions were?
>>
> My conclusion was basically that the current crop of browsers are plenty
> fast and its generally feasible.  But rewriting all that Python code in
> Javascript ain't a small project ;)

So maybe pyjamas or pyjs might help?

http://pyjs.org/

http://stackoverflow.com/questions/683462/best-way-to-integrate-python-and-javascript 
gives a few other python->javascript compilers.  I don't know if any are 
currently active, though.

I thought you also had some conclusion about using SVG instead of HTML5 
canvas...

Jason

On 12/07/2011 11:36 PM, Jason Grout wrote:
> On 12/7/11 10:27 PM, Chris Barker wrote:
>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>> Has anyone ever worked on a backend that generates javascript code for
>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>> accompany it with the javascript code to trace the function, etc.
>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>> the thread "Using the Agg renderer by itself"
>>
>> Here's a cut and paste:
>>
>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>>    >
>>    >   Ben is referring to mplh5canvas, available at
>>    >   http://code.google.com/p/mplh5canvas/. The main advantage of this
>>    >   approach is interactive zooming of plots within the browser. If this is
>>    >   not important to you, it will probably be faster to generate static PNGs
>>    >   or SVGs.
>>    >
>>    >   The HTML5 backend should be easy to try out, as it is a pure Python
>>    >   package with no onerous dependencies.
>>    >
> Michael Droettboom played with this a little at the Sage Days in March,
> IIRC, and I seem to think he also whipped up an interactive demo using
> svg plots.  Michael, do you remember what your conclusions were?
>
My conclusion was basically that the current crop of browsers are plenty 
fast and its generally feasible.  But rewriting all that Python code in 
Javascript ain't a small project ;)

Mike