matplotlib-devel Mailing List for matplotlib

On 2011年2月10日 17:34:32 -0500, Darren Dale wrote:
[clip]
> Unfortunately, I am getting exactly the same results: the matplotlib/
> directory is missing in the earliest history. I've tried adding
> --use-cvs and --keep-trivial-imports, to no avail. I've tried checking
> out a working copy of the cvs repo (setting CVSROOT to point to the
> directory I created using rsync), and I *thought* the right way to
> inspect the r7 working directory is to do "cvs update -R -r 7", but
> thats not right. So I'm currently having trouble determining whether the
> history even exists in CVS. Anybody have a longer memory than I do? How
> can I get cvs to perform this basic operation?
Maybe you can try skipping SVN altogether (needs "git-cvs" package on 
Ubuntu):
export CVSROOT=/rsynced/directory
test -d "$CVSROOT/CVSROOT" || echo "Wrong cvsroot..."
mkdir imported
cd imported
git cvsimport matplotlib
This at least shows some files in the first revisions. You can probably 
then just graft the two histories together at a suitable point.
Apparently, it also needs some use of "git filter-branch" to get rid of 
the top-level matplotlib/ directory.
-- 
Pauli Virtanen

On Sat, Jan 29, 2011 at 9:00 AM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Jan 29, 2011 at 3:35 AM, Andrew Straw <str...@as...> wrote:
>> On 29-Jan-11 01:08, John Hunter wrote:
>>>
>>>> cvs -z3 -d:pserver:ano...@cv...:/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 have turned off CVS for now:
>> http://sourceforge.net/blog/sourceforge-net-attack/
>
> Thanks Andrew.
>
> As much as I would like to push the git repos to github today, I think
> it is worth waiting. When SF CVS comes back up, I can attempt to
> convert the CVS repository to SVN, verify that the data has been
> preserved, and convert r1:540 to git. Then I can convert the master
> svn repo starting at r541, and graft the result onto the older
> history. When the resulting repo is postprocessed to clean it up and
> reduce the size, the graft would be made permanent (is actually
> incorporated into the history, as opposed to being a reference in
> .git/info/grafts).
Sourceforge just enabled enough access to get a copy of the cvs
repository by doing:
rsync -av matplotlib.cvs.sourceforge.net::cvsroot/matplotlib/* .
So, if I have the cvs repo in a local directory called "mpl.cvs", then I can do:
cvs2svn --encoding=utf_8 -s mpl.svn mpl.cvs
Unfortunately, I am getting exactly the same results: the matplotlib/
directory is missing in the earliest history. I've tried adding
--use-cvs and --keep-trivial-imports, to no avail. I've tried checking
out a working copy of the cvs repo (setting CVSROOT to point to the
directory I created using rsync), and I *thought* the right way to
inspect the r7 working directory is to do "cvs update -R -r 7", but
thats not right. So I'm currently having trouble determining whether
the history even exists in CVS. Anybody have a longer memory than I
do? How can I get cvs to perform this basic operation?
Darren

Hi Uri,
On Wed, Feb 9, 2011 at 12:13 PM, Uri Laserson <las...@mi...> wrote:
>
> I wrote a bit of code for plotting streamgraphs with MPL (e.g.,
> http://goo.gl/7sjcR).
Fantastic, many thanks! For anyone who is willing to shepherd this
through inclusion in MPL, I *strongly* recommend they read the paper
in the link above, titled:
"Stacked Graphs – Geometry & Aesthetics" by Lee Byron & Martin Wattenberg.
PDF link: http://www.leebyron.com/else/streamgraph/download.php?file=stackedgraphs_byron_wattenberg.pdf
In fact, I'm sure anyone who's intrested enough in data viz to be on
this list would tremendously enjoy the paper, it's a really good
piece.
> It is available on my GitHub page here:
> http://goo.gl/qGGPS
> What is the best way for me to integrate it into MPL?
Unfortunately I'm too swamped to fully help you move this through, but
a few pointers now so to get you going, and hopefully another core dev
can pitch in...
- For mpl inclusion, your code needs to be explicitly BSD licensed,
and should mention that the original code it's based on (if you read
any of the implementation) was also BSD licensed (which it is, as per
this file: https://github.com/leebyron/streamgraph_generator/blob/master/COPYRIGHT).
- I read your implementation and it looks very nice and concise,
excellent job. After reading the paper, I was just wondering if this
problem might not benefit from a bit of object orientation...
I'm just thinking out loud here, and I actually tend to always favor
holding of on the OO until a more decoupled, functional approach shows
its limitations. So perhaps your take is just fine for now. But what
I'm thinking about is that the Streamgraph construction has a number
of moving parts:
* the optimization formulation to select g_0.
* the colormap choices, which can be fairly sophisticated.
* the sorting of the time series and their assignment on the stream stack.
It might be more convenient to bundle all these into an object that
exposes the already implemented options and can be extended to other
algorithms. This is a case where I'm thinking of going OO not because
of inheritance, but simply as a way of grouping related functions and
data in a way that's easier to pass around in more complex codes.
In fact, a good solution might be to keep a number of standalone
functions and offer a wrapper object that exposes an OO interface.
For simple cases people could just call the function with some data,
but for more complex development using (and possibly extending) the
object would be cleaner.
In any case, I hope this feedback is useful, and I look forward to
streamgraphs in MPL! Sorry that I won't be able to work on the
review/merge itself in the future; as interested as I was by the paper
(many thanks for bringing it to our attention), I'm already neglecting
other things far too much :)
Regards,
f

Maybe someone has already done this? (Thanks to whomever it was!)
It looks like the download links all point to 1.0.1 now.
Mike
On 02/10/2011 02:12 AM, Paul Ivanov wrote:
> I'm guessing only the admins can change this (or at least I
> didn't find a way to do it myself on the sourceforge site) but
> the link at the top of the download page still points to 1.0.0
>
> "Loking for the latest version? Download matplotlib-1.0.0.tar.gz"
>
> This actually affects all of the direct download links that are
> scattered about (the one on the project summary page, for example)
>
> Can someone with the privileges points it to 1.0.1?
>
> best,
> 
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> 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

On 02/09/2011 09:23 PM, Marshall Ward wrote:
> Hello, first time poster,
Marshall,
Welcome! I'm sorry my first reply was a bit curt, especially 
considering that you are offering a patch. We do appreciate 
contributions. A little discussion may be required as to the future 
strategy for keyboard shortcuts, but thank you for getting started.
Eric
>
> I've made a patch to add a keyboard shortcut to close plot windows with
> the 'q' key (patchfile attached, in case it is of interest to the
> matplotlib team). But as I was finishing it up, I noticed that there was
> already something similar in the code, commented out (even using the
> same key!):
>
> #if event.key == 'q':
> # self.destroy() # how cruel to have to destroy oneself!
> # return
>
> I didn't implement it this way (I used self.close() and tried to emulate
> the other key commands), but I wondered if this was an indication that
> adding a keyboard shortcut for close() was a bad idea for any reason.
>
> Also, is it possible to a custom keyboard shortcut for particular
> backends? For example, I'd like for "command-w" to close plotting
> windows for the mac os x backend. Would this be added to backend_macosx.py?
>
> Finally, I noticed that on OS X, the plots used to be the active window
> once they were created (1.0.0, possibly earlier), but now they appear
> behind my terminal window when created (1.0.1). Is this a setting in
> backend_macosx.py, or somewhere else?
>
> Thanks for your time, and the wonderful plotting library,
> Marshall
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 02/09/2011 09:23 PM, Marshall Ward wrote:
> Hello, first time poster,
>
> I've made a patch to add a keyboard shortcut to close plot windows with
> the 'q' key (patchfile attached, in case it is of interest to the
> matplotlib team). But as I was finishing it up, I noticed that there was
> already something similar in the code, commented out (even using the
> same key!):
>
> #if event.key == 'q':
> # self.destroy() # how cruel to have to destroy oneself!
> # return
>
> I didn't implement it this way (I used self.close() and tried to emulate
> the other key commands), but I wondered if this was an indication that
> adding a keyboard shortcut for close() was a bad idea for any reason.
In my opinion, having it enabled by default is a horrible idea--it is 
too easy to hit it accidentally, and when one does so, the consequence 
is too damaging. The present default-enabled shortcuts are bad enough; 
I am tempted to change the defaults--but maybe more people would be 
displeased than pleased by that change.
>
> Also, is it possible to a custom keyboard shortcut for particular
> backends? For example, I'd like for "command-w" to close plotting
> windows for the mac os x backend. Would this be added to backend_macosx.py?
>
My dim recollection is that we don't presently have support for anything 
other than the normal keys. I don't know what is involved in adding it.
I hope Michiel de Hoon can reply regarding backend_macosx specifics.
> Finally, I noticed that on OS X, the plots used to be the active window
> once they were created (1.0.0, possibly earlier), but now they appear
> behind my terminal window when created (1.0.1). Is this a setting in
> backend_macosx.py, or somewhere else?
>
I'm pretty sure that if it is within mpl, it would be in backend_macosx. 
 It is not the sort of thing I would expect to have changed, though. 
Again, Michiel de Hoon may be able to shed light on this.
Eric
> Thanks for your time, and the wonderful plotting library,
> Marshall
>

I'm guessing only the admins can change this (or at least I
didn't find a way to do it myself on the sourceforge site) but
the link at the top of the download page still points to 1.0.0
"Loking for the latest version? Download matplotlib-1.0.0.tar.gz"
This actually affects all of the direct download links that are
scattered about (the one on the project summary page, for example) 
Can someone with the privileges points it to 1.0.1?
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7