Ryan May wrote: > John Hunter wrote: >> On Sat, Jul 19, 2008 at 11:09 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> >>> The only issue I've seen is that scaling with PS is way too big. I've >>> attached ps and pdf files from the same run to show the problem. >> The only thing I can think of is since you are using a identity >> transform and drawing in pixels, you are seeing the effect of the >> savefig dpi in pdf and png but not in ps, which hardcodes the dpi to >> 72. If this is correct, you should not see the effect if you pass >> dpi=72 to savefig when saving the PS and PDF. You will probably want >> to modify the patch to make sure your barbs scales are dpi >> independent. I have only looked briefly at the barbs code so I could >> be missing something obvious, but this is the first thing that comes >> to mind. > > I don't think an IdentityTransform() implies drawing in pixels. My > length 9 barb is a lot longer than 9 pixels. It looks more like ~50. I > really was looking for (and thought I found) a way to draw in a > resolution independant fashion. Axes coordinates are close, but > unfortunately, as you stretch a figure, this can distort things. > >>> It should apply fine to SVN, but there are commented lines that should be >>> switched with the ones there when set/get_offsets() are added to >>> Collections. >>> >>> Comments and Suggestions? >>> >>> How do you guys manage committing only parts of your working copy, >>> especially when you want to commit part of a file? I figure there's got to >>> be a better way than multiple SVN checkouts and manually editing diffs. >> svn should do this automagically; it only commits the diff from your >> current working version and the svn HEAD. >> >>> svn up >> # do some work >>> svn diff # these are the changes that will be committed, just preview them >>> svn commit -m 'my log message' # the diff will be committed > > I'm more interested how you guys handle having multiple lines of > development going on in a single working copy, like working on multiple > separate additions to axes.py. Trying to commit only a subset of those > changes is difficult as far as I can tell. Or is the advice "don't do > that" and use separate working copies? What if I'm working on something > big and then have a small bug fix to do on the same file? Additional > working copies wouldn't be a big deal, but it seems to take forever to > do a fresh checkout from sourceforge. > > Ryan >
I think you could have a master checkout, and then use a local rsync to make copies of it for hacking around on different parts. (This is the sort of thing that is made very fast and easy with mercurial, but the mercurial-svn interface mechanisms seem to be a bit clumsy, unfortunately. Mike recently mentioned doing this sort of thing with git. I haven't looked into git much; it has the reputation of being rather hard to understand, and I have been happily using mercurial for my local work for quite a long time, so I am not eager to start getting confused by an alternative.) Eric ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
