Re: [matplotlib-devel] new release?
On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > > Should we still proceed with this now that numpy 1.1.0 is out? Any > > holdups? [...] > So let's focus on clearing these bugs (and anything else the other > devs raise), hopefully in the next couple days, and then push out the > maintenance release followed by the pre-release of the branch. > > I'll also work on getting the site docs ready to go. On tuesday we ran into a spot of trouble at work, I've been having to put in extra hours and work at home in the evening to try to handle it. Unfortunately I probably won't be in a position to help with docs and bugs until the weekend. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > > > Should we still proceed with this now that numpy 1.1.0 is out? Any > > > holdups? > > [...] > > > So let's focus on clearing these bugs (and anything else the other > > devs raise), hopefully in the next couple days, and then push out the > > maintenance release followed by the pre-release of the branch. > > > > I'll also work on getting the site docs ready to go. > > On tuesday we ran into a spot of trouble at work, I've been having to put > in extra hours and work at home in the evening to try to handle it. > Unfortunately I probably won't be in a position to help with docs and bugs > until the weekend. There is a bug in texmanager that I need to fix before we release 91.3 or 98pre. I'll try to squeeze it in this morning. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
I am trying to merge a change to texmanager from the branch to the trunk, but
something doesnt look right after I ran svnmerge.py. Look at all the markup
in the diff, I can't commit this, can I?
$ svn diff
Property changes on: .
___
Modified: svnmerge-integrated
- /branches/v0_91_maint:1-5294
+ /branches/v0_91_maint:1-5294,5299
Index: CHANGELOG
===
--- CHANGELOG (revision 5299)
+++ CHANGELOG (working copy)
@@ -1,3 +1,13 @@
+<<< .working
+===
+2008-05-29 Fixed two bugs in texmanager.py:
+ improved comparison of dvipng versions
+ fixed a bug introduced when get_grey method was added
+ - DSD
+
+2008-05-29 Implement path clipping in SVG backend - MGD
+
+>>> .merge-right.r5299
2008-05-28 Fix crashing of PDFs in xpdf and ghostscript when two-byte
characters are used with Type 3 fonts - MGD
Index: lib/matplotlib/texmanager.py
===
--- lib/matplotlib/texmanager.py(revision 5299)
+++ lib/matplotlib/texmanager.py(working copy)
@@ -33,8 +33,14 @@
"""
+<<< .working
import copy, glob, md5, os, shutil, sys
import numpy as np
+===
+import copy, glob, md5, os, shutil, sys, warnings
+import distutils.version
+import numpy as npy
+>>> .merge-right.r5299
import matplotlib as mpl
from matplotlib import rcParams
from matplotlib._image import readpng
@@ -44,14 +50,15 @@
if sys.platform.startswith('win'): cmd_split = '&'
else: cmd_split = ';'
-def get_dvipng_version():
+def dvipng_hack_alpha():
stdin, stdout = os.popen4('dvipng -version')
for line in stdout:
if line.startswith('dvipng '):
version = line.split()[-1]
mpl.verbose.report('Found dvipng version %s'% version,
'helpful')
-return version
+version = distutils.version.LooseVersion(version)
+return version < distutils.version.LooseVersion('1.6')
raise RuntimeError('Could not obtain dvipng version')
@@ -78,7 +85,7 @@
if not os.path.exists(texcache):
os.mkdir(texcache)
-dvipngVersion = get_dvipng_version()
+_dvipng_hack_alpha = dvipng_hack_alpha()
# mappable cache of
rgba_arrayd = {}
@@ -364,8 +371,28 @@
pngfile = self.make_png(tex, fontsize, dpi)
X = readpng(os.path.join(self.texcache, pngfile))
-if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
-# hack the alpha channel as described in comment above
+if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
+# hack the alpha channel
+# dvipng assumed a constant background, whereas we want to
+# overlay these rasters with antialiasing over arbitrary
+# backgrounds that may have other figure elements under them.
+# When you set dvipng -bg Transparent, it actually makes the
+# alpha channel 1 and does the background compositing and
+# antialiasing itself and puts the blended data in the rgb
+# channels. So what we do is extract the alpha information
+# from the red channel, which is a blend of the default
dvipng
+# background (white) and foreground (black). So the amount
of
+# red (or green or blue for that matter since white and black
+# blend to a grayscale) is the alpha intensity. Once we
+# extract the correct alpha information, we assign it to the
+# alpha channel properly and let the users pick their rgb.
In
+# this way, we can overlay tex strings on arbitrary
+# backgrounds with antialiasing
+#
+# red = alpha*red_foreground + (1-alpha)*red_background
+#
+# Since the foreground is black (0) and the background is
+# white (1) this reduces to red = 1-alpha or alpha = 1-red
alpha = np.sqrt(1-X[:,:,0])
else:
alpha = X[:,:,-1]
@@ -378,26 +405,6 @@
"""
Returns latex's rendering of the tex string as an rgba array
"""
-# dvipng assumes a constant background, whereas we want to
-# overlay these rasters with antialiasing over arbitrary
-# backgrounds that may have other figure elements under them.
-# When you set dvipng -bg Transparent, it actually makes the
-# alpha channel 1 and does the background compositing and
-# antialiasing itself and puts the blended data in the rgb
-# channels. So what we do is extract the alpha information
-# from the red channel, which is a blend of the default dvipng
-# background (white) and foregrou
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> I am trying to merge a change to texmanager from the branch to the trunk, but
> something doesnt look right after I ran svnmerge.py. Look at all the markup
> in the diff, I can't commit this, can I?
No. The > +<<< .working stuff means there are conflicts in the
merge between the branch and trunk, and you have to resolve them by
editing all the files which have conflicts to resolve the conflicts,
and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
like that, and then commit the fixed files.
>
> $ svn diff
>
> Property changes on: .
> ___
> Modified: svnmerge-integrated
> - /branches/v0_91_maint:1-5294
> + /branches/v0_91_maint:1-5294,5299
>
> Index: CHANGELOG
> ===
> --- CHANGELOG (revision 5299)
> +++ CHANGELOG (working copy)
> @@ -1,3 +1,13 @@
> +<<< .working
> +===
> +2008-05-29 Fixed two bugs in texmanager.py:
> + improved comparison of dvipng versions
> + fixed a bug introduced when get_grey method was added
> + - DSD
> +
> +2008-05-29 Implement path clipping in SVG backend - MGD
> +
> +>>> .merge-right.r5299
> 2008-05-28 Fix crashing of PDFs in xpdf and ghostscript when two-byte
>characters are used with Type 3 fonts - MGD
>
> Index: lib/matplotlib/texmanager.py
> ===
> --- lib/matplotlib/texmanager.py(revision 5299)
> +++ lib/matplotlib/texmanager.py(working copy)
> @@ -33,8 +33,14 @@
>
> """
>
> +<<< .working
> import copy, glob, md5, os, shutil, sys
> import numpy as np
> +===
> +import copy, glob, md5, os, shutil, sys, warnings
> +import distutils.version
> +import numpy as npy
> +>>> .merge-right.r5299
> import matplotlib as mpl
> from matplotlib import rcParams
> from matplotlib._image import readpng
> @@ -44,14 +50,15 @@
> if sys.platform.startswith('win'): cmd_split = '&'
> else: cmd_split = ';'
>
> -def get_dvipng_version():
> +def dvipng_hack_alpha():
> stdin, stdout = os.popen4('dvipng -version')
> for line in stdout:
> if line.startswith('dvipng '):
> version = line.split()[-1]
> mpl.verbose.report('Found dvipng version %s'% version,
> 'helpful')
> -return version
> +version = distutils.version.LooseVersion(version)
> +return version < distutils.version.LooseVersion('1.6')
> raise RuntimeError('Could not obtain dvipng version')
>
>
> @@ -78,7 +85,7 @@
> if not os.path.exists(texcache):
> os.mkdir(texcache)
>
> -dvipngVersion = get_dvipng_version()
> +_dvipng_hack_alpha = dvipng_hack_alpha()
>
> # mappable cache of
> rgba_arrayd = {}
> @@ -364,8 +371,28 @@
> pngfile = self.make_png(tex, fontsize, dpi)
> X = readpng(os.path.join(self.texcache, pngfile))
>
> -if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
> -# hack the alpha channel as described in comment above
> +if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
> +# hack the alpha channel
> +# dvipng assumed a constant background, whereas we want to
> +# overlay these rasters with antialiasing over arbitrary
> +# backgrounds that may have other figure elements under them.
> +# When you set dvipng -bg Transparent, it actually makes the
> +# alpha channel 1 and does the background compositing and
> +# antialiasing itself and puts the blended data in the rgb
> +# channels. So what we do is extract the alpha information
> +# from the red channel, which is a blend of the default
> dvipng
> +# background (white) and foreground (black). So the amount
> of
> +# red (or green or blue for that matter since white and black
> +# blend to a grayscale) is the alpha intensity. Once we
> +# extract the correct alpha information, we assign it to the
> +# alpha channel properly and let the users pick their rgb.
> In
> +# this way, we can overlay tex strings on arbitrary
> +# backgrounds with antialiasing
> +#
> +# red = alpha*red_foreground + (1-alpha)*red_background
> +#
> +# Since the foreground is black (0) and the background is
> +# white (1) this reduces to red = 1-alpha or alpha = 1-red
> alpha = np.sqrt(1-X[:,:,0])
> else:
> alpha = X[:,:,-1]
> @@ -378,26 +405,6 @@
> """
> Returns latex's rendering of the tex string as an rgba array
> """
> -
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thursday 29 May 2008 10:04:34 am you wrote: > On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > > I am trying to merge a change to texmanager from the branch to the trunk, > > but something doesnt look right after I ran svnmerge.py. Look at all the > > markup in the diff, I can't commit this, can I? > > No. The > +<<< .working stuff means there are conflicts in the > merge between the branch and trunk, and you have to resolve them by > editing all the files which have conflicts to resolve the conflicts, > and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff > like that, and then commit the fixed files. I dont understand. I thought the point of svnmerge.py was to sync the change, not to introduce conflicts. Is the procedure you just outlined the standard operating procedure, or did svnmerge.py encounter problems? The procedure in your original post to this thread seems much more straight forward. Say I attempt to resolve conflicts, do I then run svnmerge.py again to make sure that no additional conflicts are introduced? (arg, hg and bzr make this much easier.) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thursday 29 May 2008 10:15:07 am John Hunter wrote: > On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > > I dont understand. I thought the point of svnmerge.py was to sync the > > change, not to introduce conflicts. Is the procedure you just outlined > > the standard operating procedure, or did svnmerge.py encounter problems? > > The procedure in your original post to this thread seems much more > > straight forward. > > I think the point is to keep track of which revisions you've already > merged (and resolved conflicts in) so you don't have to resolve them > again later. Michale pointed out to me offlist that in standard > usage, you do not need to manually give the revision number so my > original instructions advocating them were wrong. I'm sorry, I just don't understand how to use this. I just got a clean checkout of the trunk, ran "svnmerge.py merge": $ svnmerge.py merge property 'svnmerge-integrated' set on '.' property 'svnmerge-blocked' deleted from '.'. --- Merging r5298 through r5299 into '.': UCHANGELOG Clib/matplotlib/texmanager.py Clib/matplotlib/backends/backend_svg.py property 'svnmerge-integrated' set on '.' property 'svnmerge-blocked' deleted from '.'. Thats not what I want, I only want to commit the changes I made to CHANGELOG and texmanager. I tried reverting the changes with svn revert, but now when I do a diff, I get: $ svn diff Property changes on: . ___ Modified: svnmerge-integrated - /branches/v0_91_maint:1-5294 + /branches/v0_91_maint:1-5299 Can I please just manually merge my changes in from the branch, without svnmerge.py? I really don't have time today to mess around with this. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thu, May 29, 2008 at 9:41 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > Thats not what I want, I only want to commit the changes I made to CHANGELOG > and texmanager. I tried reverting the changes with svn revert, but now when I > do a diff, I get: > > $ svn diff > > Property changes on: . > ___ > Modified: svnmerge-integrated > - /branches/v0_91_maint:1-5294 > + /branches/v0_91_maint:1-5299 I already screwed up everything once royally, so I'll let Michael comment on this. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
Darren Dale wrote:
> On Thursday 29 May 2008 10:04:34 am you wrote:
>
>> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]>
>>
> wrote:
>
>>> I am trying to merge a change to texmanager from the branch to the trunk,
>>> but something doesnt look right after I ran svnmerge.py. Look at all the
>>> markup in the diff, I can't commit this, can I?
>>>
>> No. The > +<<< .working stuff means there are conflicts in the
>> merge between the branch and trunk, and you have to resolve them by
>> editing all the files which have conflicts to resolve the conflicts,
>> and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
>> like that, and then commit the fixed files.
>>
Minor point: On my machine at least, I don't have to manually clean up
the conflict files -- they are removed for me on the next commit. Those
files are really just for reference. If you use a SVN frontend for
diffing (such as psvn.el or meld) they are largely unnecessary.
> I dont understand. I thought the point of svnmerge.py was to sync the change,
> not to introduce conflicts. Is the procedure you just outlined the standard
> operating procedure, or did svnmerge.py encounter problems? The procedure in
> your original post to this thread seems much more straight forward.
>
> Say I attempt to resolve conflicts, do I then run svnmerge.py again to make
> sure that no additional conflicts are introduced? (arg, hg and bzr make this
> much easier.)
>
You don't need to run svnmerge.py again. You just need to resolve the
conflicts, removing the conflict markers, tell SVN you have done so
(with "svn resolved"), and then commit ("svn commit -F
svnmerge-commit-message.txt").
There are differences in the branch and trunk (sometimes called "version
drift") that make it impossible to merge the files automatically. This
is an oft cited advantage of hg and bzr, but I don't think any tool that
doesn't do some sort of deep code introspection could help out here.
When people say "merging is easier with tool X", they usually mean that
the branch/merge tracking is better, not that it can resolve conflicts
any "smarter." SVN proper has virtually no branch/merge tracking,
svnmerge makes things a little better, but not very well integrated.
But as for conflicts, according to the bzr manpage, bzr appears to do
exactly the same thing as SVN in this case, including the creation of
three extra files (though the details are different):
http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm#id17
For instance, look at the last difference:
@@ -407,7 +414,11 @@
if Z is None:
alpha = self.get_grey(tex, fontsize, dpi)
+<<< .working
Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
+===
+Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>> .merge-right.r5299
Z[:,:,0] = r
Z[:,:,1] = g
Z[:,:,2] = b
At one point, npy was renamed to np throughout this file, on the trunk,
but not in the branch. SVN has no way of knowing (since it doesn't
understand Python syntax) that these two tokens are equivalent. You
need a human being who understands how the code is supposed to work to
resolve this.
So, this is more the fault of operating procedure (choosing not to do
the numpy renaming on the branch, for instance, which in itself was not
a bad decision in isolation), than the tool itself. Note that svnmerge
did do the right thing in your merge on about five diffs, and only two
couldn't be automatically merged. In my own experience, merges work far
more often than not, but as the trunk drifts further away from the
branch, no doubt that percentage will go down...
Cheers,
Mike
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
Darren Dale wrote: > On Thursday 29 May 2008 10:15:07 am John Hunter wrote: > >> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]> >> > wrote: > >>> I dont understand. I thought the point of svnmerge.py was to sync the >>> change, not to introduce conflicts. Is the procedure you just outlined >>> the standard operating procedure, or did svnmerge.py encounter problems? >>> The procedure in your original post to this thread seems much more >>> straight forward. >>> >> I think the point is to keep track of which revisions you've already >> merged (and resolved conflicts in) so you don't have to resolve them >> again later. Michale pointed out to me offlist that in standard >> usage, you do not need to manually give the revision number so my >> original instructions advocating them were wrong. >> > > I'm sorry, I just don't understand how to use this. I just got a clean > checkout of the trunk, ran "svnmerge.py merge": > > $ svnmerge.py merge > property 'svnmerge-integrated' set on '.' > > property 'svnmerge-blocked' deleted from '.'. > > --- Merging r5298 through r5299 into '.': > UCHANGELOG > Clib/matplotlib/texmanager.py > Clib/matplotlib/backends/backend_svg.py > > property 'svnmerge-integrated' set on '.' > > property 'svnmerge-blocked' deleted from '.'. > > Thats not what I want, I only want to commit the changes I made to CHANGELOG > and texmanager. I tried reverting the changes with svn revert, but now when I > do a diff, I get: > > $ svn diff > > Property changes on: . > ___ > Modified: svnmerge-integrated >- /branches/v0_91_maint:1-5294 >+ /branches/v0_91_maint:1-5299 > > > I'm confused by this. Did you do: svn -R revert . from the root of the tree? That should back out that property change. > Can I please just manually merge my changes in from the branch, without > svnmerge.py? I really don't have time today to mess around with this. > I can do the merge for you. [EMAIL PROTECTED] matplotlib]$ svn update U lib/matplotlib/ticker.py U CHANGELOG Updated to revision 5299. [EMAIL PROTECTED] matplotlib]$ svnmerge merge U CHANGELOG C lib/matplotlib/texmanager.py C lib/matplotlib/backends/backend_svg.py property 'svnmerge-integrated' set on '.' # We don't want to merge backend_svg.py -- we just want what's currently on the trunk [EMAIL PROTECTED] matplotlib]$ cp lib/matplotlib/backends/backend_svg.py.working lib/matplotlib/backends/backend_svg.py # Manually resolve texmanager.py [EMAIL PROTECTED] matplotlib]$ emacs -nw lib/matplotlib/texmanager.py # Mark everything as resolved [EMAIL PROTECTED] matplotlib]$ svn -R resolved . Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' # Commit [EMAIL PROTECTED] matplotlib]$ svn commit -F svnmerge-commit-message.txt Sending. SendingCHANGELOG Sendinglib/matplotlib/texmanager.py Transmitting file data .. Committed revision 5300. [EMAIL PROTECTED] matplotlib]$ Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > So, this is more the fault of operating procedure (choosing not to do the > numpy renaming on the branch, for instance, which in itself was not a bad > decision in isolation), than the tool itself. Note that svnmerge did do the > right thing in your merge on about five diffs, and only two couldn't be > automatically merged. In my own experience, merges work far more often than > not, but as the trunk drifts further away from the branch, no doubt that > percentage will go down... My (limited) experience has been same -- merges usually ""just work". Part of the drift (eg the npy, np differences) we are currently dealing with is explained by me doing things the wrong way for a while, before I go. As more of us work to keep the branch in sync where feasible, these kinds of problems should be less frequent. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
Thanks Mike. On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote: > Darren Dale wrote: > > On Thursday 29 May 2008 10:15:07 am John Hunter wrote: > >> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]> > > > > wrote: > >>> I dont understand. I thought the point of svnmerge.py was to sync the > >>> change, not to introduce conflicts. Is the procedure you just outlined > >>> the standard operating procedure, or did svnmerge.py encounter > >>> problems? The procedure in your original post to this thread seems much > >>> more straight forward. > >> > >> I think the point is to keep track of which revisions you've already > >> merged (and resolved conflicts in) so you don't have to resolve them > >> again later. Michale pointed out to me offlist that in standard > >> usage, you do not need to manually give the revision number so my > >> original instructions advocating them were wrong. > > > > I'm sorry, I just don't understand how to use this. I just got a clean > > checkout of the trunk, ran "svnmerge.py merge": > > > > $ svnmerge.py merge > > property 'svnmerge-integrated' set on '.' > > > > property 'svnmerge-blocked' deleted from '.'. > > > > --- Merging r5298 through r5299 into '.': > > UCHANGELOG > > Clib/matplotlib/texmanager.py > > Clib/matplotlib/backends/backend_svg.py > > > > property 'svnmerge-integrated' set on '.' > > > > property 'svnmerge-blocked' deleted from '.'. > > > > Thats not what I want, I only want to commit the changes I made to > > CHANGELOG and texmanager. I tried reverting the changes with svn revert, > > but now when I do a diff, I get: > > > > $ svn diff > > > > Property changes on: . > > ___ > > Modified: svnmerge-integrated > >- /branches/v0_91_maint:1-5294 > >+ /branches/v0_91_maint:1-5299 > > I'm confused by this. Did you do: > > svn -R revert . > > from the root of the tree? That should back out that property change. > > > Can I please just manually merge my changes in from the branch, without > > svnmerge.py? I really don't have time today to mess around with this. > > I can do the merge for you. > > [EMAIL PROTECTED] matplotlib]$ svn update > U lib/matplotlib/ticker.py > U CHANGELOG > Updated to revision 5299. > [EMAIL PROTECTED] matplotlib]$ svnmerge merge > U CHANGELOG > C lib/matplotlib/texmanager.py > C lib/matplotlib/backends/backend_svg.py > > property 'svnmerge-integrated' set on '.' > > # We don't want to merge backend_svg.py -- we just want what's currently > on the trunk > [EMAIL PROTECTED] matplotlib]$ cp > lib/matplotlib/backends/backend_svg.py.working > lib/matplotlib/backends/backend_svg.py > > # Manually resolve texmanager.py > [EMAIL PROTECTED] matplotlib]$ emacs -nw lib/matplotlib/texmanager.py > > # Mark everything as resolved > [EMAIL PROTECTED] matplotlib]$ svn -R resolved . > Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' > > # Commit > [EMAIL PROTECTED] matplotlib]$ svn commit -F svnmerge-commit-message.txt > Sending. > SendingCHANGELOG > Sendinglib/matplotlib/texmanager.py > Transmitting file data .. > Committed revision 5300. > [EMAIL PROTECTED] matplotlib]$ > > > Cheers, > Mike > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 [EMAIL PROTECTED] office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
John Hunter wrote: > On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> So, this is more the fault of operating procedure (choosing not to do the >> numpy renaming on the branch, for instance, which in itself was not a bad >> decision in isolation), than the tool itself. Note that svnmerge did do the >> right thing in your merge on about five diffs, and only two couldn't be >> automatically merged. In my own experience, merges work far more often than >> not, but as the trunk drifts further away from the branch, no doubt that >> percentage will go down... >> > > My (limited) experience has been same -- merges usually ""just work". > Part of the drift (eg the npy, np differences) we are currently > dealing with is explained by me doing things the wrong way for a > while, before I go. As more of us work to keep the branch in sync > where feasible, these kinds of problems should be less frequent. > > I didn't mean to imply that doing the rename only on the trunk was necessarily a bad thing. It's a balancing act: too many changes to the branch runs the risk of introducing bugs, not enough changes can mean drift. It's like all the rivers in China: dammed either way. Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > > > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > > > > Should we still proceed with this now that numpy 1.1.0 is out? Any > > > > holdups? > > > > [...] > > > > > So let's focus on clearing these bugs (and anything else the other > > > devs raise), hopefully in the next couple days, and then push out the > > > maintenance release followed by the pre-release of the branch. > > > > > > I'll also work on getting the site docs ready to go. > > > > On tuesday we ran into a spot of trouble at work, I've been having to put > > in extra hours and work at home in the evening to try to handle it. > > Unfortunately I probably won't be in a position to help with docs and > > bugs until the weekend. > > There is a bug in texmanager that I need to fix before we release 91.3 or > 98pre. I'll try to squeeze it in this morning. It looks like my problem is fixed on the branch and the trunk, thanks to Mike for helping sort out the merge. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > > > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > > > > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > > > > > Should we still proceed with this now that numpy 1.1.0 is out? Any > > > > > holdups? > > > > > > [...] > > > > > > > So let's focus on clearing these bugs (and anything else the other > > > > devs raise), hopefully in the next couple days, and then push out the > > > > maintenance release followed by the pre-release of the branch. > > > > > > > > I'll also work on getting the site docs ready to go. > > > > > > On tuesday we ran into a spot of trouble at work, I've been having to > > > put in extra hours and work at home in the evening to try to handle it. > > > Unfortunately I probably won't be in a position to help with docs and > > > bugs until the weekend. > > > > There is a bug in texmanager that I need to fix before we release 91.3 or > > 98pre. I'll try to squeeze it in this morning. > > It looks like my problem is fixed on the branch and the trunk, thanks to > Mike for helping sort out the merge. Looks like something else just turned up in ticker.py on the trunk. Somebody replaced minus signs with unicode, a good idea, but it breaks latex if unicode support is not enabled for usetex. I don't have time to fix it. File "monte_carlo.py", line 37, in show() File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", line 66, in show figManager.canvas.draw() File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", line 133, in draw FigureCanvasAgg.draw(self) File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 255, in draw self.figure.draw(self.renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in draw for a in self.axes: a.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in draw a.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in draw tick.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in draw self.label1.draw(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in draw Text.draw(self, renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in draw bbox, info = self._get_layout(renderer) File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in _get_layout line, self._fontproperties, ismath=self.is_math_text(line)) File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 127, in get_text_width_height_descent Z = texmanager.get_grey(s, size, self.dpi) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 366, in get_grey pngfile = self.make_png(tex, fontsize, dpi) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 300, in make_png dvifile = self.make_dvi(tex, fontsize) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 269, in make_dvi texfile = self.make_tex(tex, fontsize) File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 248, in make_tex fh.write(s) UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position 290: ordinal not in range(128) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thu, May 29, 2008 at 10:46 AM, Darren Dale <[EMAIL PROTECTED]> r > Looks like something else just turned up in ticker.py on the trunk. Somebody > replaced minus signs with unicode, a good idea, but it breaks latex if > unicode support is not enabled for usetex. I don't have time to fix it. I just committed a fix for this -- when you get a minute, let me know if it works for you. We should get a usetex example in backend_driver... JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
I'm happy to deal with this, but I wonder about the best path. Is it reasonable to assume that we have unicode support available in LaTeX and can just turn it on always, or do we need to (for instance) convert all the Unicode minus signs back into "-" and put the whole thing inside "$ $" (something that I suspect will be tricky in general also). Or, should we just back this minus sign stuff out (again), until we have a good general solution? BTW -- this change is only on the trunk, which is still expected to have some rough edges. Personally, I'm less concerned about fixing this asap than if it were on the maintenance branch. Cheers, Mike Darren Dale wrote: > On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > >> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: >> >>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: >>> On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> > > wrote: > >> Should we still proceed with this now that numpy 1.1.0 is out? Any >> holdups? >> [...] > So let's focus on clearing these bugs (and anything else the other > devs raise), hopefully in the next couple days, and then push out the > maintenance release followed by the pre-release of the branch. > > I'll also work on getting the site docs ready to go. > On tuesday we ran into a spot of trouble at work, I've been having to put in extra hours and work at home in the evening to try to handle it. Unfortunately I probably won't be in a position to help with docs and bugs until the weekend. >>> There is a bug in texmanager that I need to fix before we release 91.3 or >>> 98pre. I'll try to squeeze it in this morning. >>> >> It looks like my problem is fixed on the branch and the trunk, thanks to >> Mike for helping sort out the merge. >> > > Looks like something else just turned up in ticker.py on the trunk. Somebody > replaced minus signs with unicode, a good idea, but it breaks latex if > unicode support is not enabled for usetex. I don't have time to fix it. > > File "monte_carlo.py", line 37, in > show() > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", > line 66, in show > figManager.canvas.draw() > > File > "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", > line 133, in draw > FigureCanvasAgg.draw(self) > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 255, in draw > self.figure.draw(self.renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, > in > draw > for a in self.axes: a.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in > draw > a.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in > draw > tick.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in > draw > self.label1.draw(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in > draw > Text.draw(self, renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in > draw > bbox, info = self._get_layout(renderer) > File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in > _get_layout > line, self._fontproperties, ismath=self.is_math_text(line)) > > File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 127, in get_text_width_height_descent > Z = texmanager.get_grey(s, size, self.dpi) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 366, in get_grey > pngfile = self.make_png(tex, fontsize, dpi) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 300, in make_png > dvifile = self.make_dvi(tex, fontsize) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 269, in make_dvi > texfile = self.make_tex(tex, fontsize) > File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line > 248, in make_tex > fh.write(s) > UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in > position > 290: ordinal not in range(128) > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space
Re: [matplotlib-devel] new release?
Disregard this -- I think John's solution looks good. Cheers, Mike Michael Droettboom wrote: > I'm happy to deal with this, but I wonder about the best path. > > Is it reasonable to assume that we have unicode support available in > LaTeX and can just turn it on always, or do we need to (for instance) > convert all the Unicode minus signs back into "-" and put the whole > thing inside "$ $" (something that I suspect will be tricky in general > also). Or, should we just back this minus sign stuff out (again), until > we have a good general solution? > > BTW -- this change is only on the trunk, which is still expected to have > some rough edges. Personally, I'm less concerned about fixing this asap > than if it were on the maintenance branch. > > Cheers, > Mike > > Darren Dale wrote: > >> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: >> >> >>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: >>> >>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > > >> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> >> >> >> wrote: >> >> >>> Should we still proceed with this now that numpy 1.1.0 is out? Any >>> holdups? >>> >>> > [...] > > > >> So let's focus on clearing these bugs (and anything else the other >> devs raise), hopefully in the next couple days, and then push out the >> maintenance release followed by the pre-release of the branch. >> >> I'll also work on getting the site docs ready to go. >> >> > On tuesday we ran into a spot of trouble at work, I've been having to > put in extra hours and work at home in the evening to try to handle it. > Unfortunately I probably won't be in a position to help with docs and > bugs until the weekend. > > There is a bug in texmanager that I need to fix before we release 91.3 or 98pre. I'll try to squeeze it in this morning. >>> It looks like my problem is fixed on the branch and the trunk, thanks to >>> Mike for helping sort out the merge. >>> >>> >> Looks like something else just turned up in ticker.py on the trunk. Somebody >> replaced minus signs with unicode, a good idea, but it breaks latex if >> unicode support is not enabled for usetex. I don't have time to fix it. >> >> File "monte_carlo.py", line 37, in >> show() >> >> File >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", >> line 66, in show >> figManager.canvas.draw() >> >> File >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", >> line 133, in draw >> FigureCanvasAgg.draw(self) >> >> File >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", >> line 255, in draw >> self.figure.draw(self.renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, >> in >> draw >> for a in self.axes: a.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, >> in >> draw >> a.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in >> draw >> tick.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in >> draw >> self.label1.draw(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in >> draw >> Text.draw(self, renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in >> draw >> bbox, info = self._get_layout(renderer) >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in >> _get_layout >> line, self._fontproperties, ismath=self.is_math_text(line)) >> >> File >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", >> line 127, in get_text_width_height_descent >> Z = texmanager.get_grey(s, size, self.dpi) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 366, in get_grey >> pngfile = self.make_png(tex, fontsize, dpi) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 300, in make_png >> dvifile = self.make_dvi(tex, fontsize) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 269, in make_dvi >> texfile = self.make_tex(tex, fontsize) >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line >> 248, in make_tex >> fh.write(s) >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in >> position >> 290: ordinal not in range(128) >> >> - >> This SF.net email i
Re: [matplotlib-devel] new release?
I agree, this looks good. I'd really like to get a 98pre out soon, so I can distribute my own project which requires it. On Thursday 29 May 2008 12:04:29 pm Michael Droettboom wrote: > Disregard this -- I think John's solution looks good. > > Cheers, > Mike > > Michael Droettboom wrote: > > I'm happy to deal with this, but I wonder about the best path. > > > > Is it reasonable to assume that we have unicode support available in > > LaTeX and can just turn it on always, or do we need to (for instance) > > convert all the Unicode minus signs back into "-" and put the whole > > thing inside "$ $" (something that I suspect will be tricky in general > > also). Or, should we just back this minus sign stuff out (again), until > > we have a good general solution? > > > > BTW -- this change is only on the trunk, which is still expected to have > > some rough edges. Personally, I'm less concerned about fixing this asap > > than if it were on the maintenance branch. > > > > Cheers, > > Mike > > > > Darren Dale wrote: > >> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote: > >>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote: > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote: > > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote: > >> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> > >> > >> wrote: > >>> Should we still proceed with this now that numpy 1.1.0 is out? Any > >>> holdups? > > > > [...] > > > >> So let's focus on clearing these bugs (and anything else the other > >> devs raise), hopefully in the next couple days, and then push out > >> the maintenance release followed by the pre-release of the branch. > >> > >> I'll also work on getting the site docs ready to go. > > > > On tuesday we ran into a spot of trouble at work, I've been having to > > put in extra hours and work at home in the evening to try to handle > > it. Unfortunately I probably won't be in a position to help with > > docs and bugs until the weekend. > > There is a bug in texmanager that I need to fix before we release 91.3 > or 98pre. I'll try to squeeze it in this morning. > >>> > >>> It looks like my problem is fixed on the branch and the trunk, thanks > >>> to Mike for helping sort out the merge. > >> > >> Looks like something else just turned up in ticker.py on the trunk. > >> Somebody replaced minus signs with unicode, a good idea, but it breaks > >> latex if unicode support is not enabled for usetex. I don't have time to > >> fix it. > >> > >> File "monte_carlo.py", line 37, in > >> show() > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", > >> line 66, in show > >> figManager.canvas.draw() > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.p > >>y", line 133, in draw > >> FigureCanvasAgg.draw(self) > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > >> line 255, in draw > >> self.figure.draw(self.renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line > >> 792, in draw > >> for a in self.axes: a.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line > >> 1452, in draw > >> a.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line > >> 680, in draw > >> tick.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line > >> 179, in draw > >> self.label1.draw(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 761, in draw > >> Text.draw(self, renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 295, in draw > >> bbox, info = self._get_layout(renderer) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line > >> 195, in _get_layout > >> line, self._fontproperties, ismath=self.is_math_text(line)) > >> > >> File > >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", > >> line 127, in get_text_width_height_descent > >> Z = texmanager.get_grey(s, size, self.dpi) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 366, in get_grey > >> pngfile = self.make_png(tex, fontsize, dpi) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 300, in make_png > >> dvifile = self.make_dvi(tex, fontsize) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 269, in make_dvi > >> texfile = self.make_tex(tex, fontsize) > >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", > >> line 248, in make_tex > >> fh.write(s) > >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in > >> position 290: ordinal not in range(128) > >> > >> -
Re: [matplotlib-devel] new release?
On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? We are now ready to do 0.98pre -- fire when ready Charlie. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thu, May 29, 2008 at 12:09 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? > > We are now ready to do 0.98pre -- fire when ready Charlie. 91.3 is now ready too. Since there is still a bug in zoom-to-rect for images in 98pre, let's make 91.3 the default visible to the users who just click on "download" and I'll make a link to the 98pre download section in the newsbox section of the web-page. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
John Hunter wrote: > On Thu, May 29, 2008 at 12:09 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >>> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? >> We are now ready to do 0.98pre -- fire when ready Charlie. > > 91.3 is now ready too. > > Since there is still a bug in zoom-to-rect for images in 98pre, let's > make 91.3 the default visible to the users who just click on > "download" and I'll make a link to the 98pre download section in the > newsbox section of the web-page. To what bug do you refer? There seem to be related zoom-to-rect bugs in both the trunk and the branch. In both, zooming in to a region comparable to, or smaller than, a "pixel" (meaning a grid cell in the data array), gets unbearably slow. In the branch, it has the additional characteristic of fading out. I think this bug may be inherent in Agg, and has been around indefinitely. Or are you referring to some other bug? Eric > > JDH > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thu, May 29, 2008 at 1:52 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> To what bug do you refer? There seem to be related zoom-to-rect bugs in
> both the trunk and the branch. In both, zooming in to a region comparable
> to, or smaller than, a "pixel" (meaning a grid cell in the data array), gets
> unbearably slow. In the branch, it has the additional characteristic of
> fading out. I think this bug may be inherent in Agg, and has been around
> indefinitely.
Yes, this is a problem in either the _image or _backend_agg
implementation, not agg itself, and should be fixed.
But I was referring to a different problem. In the thread:
"[Matplotlib-users] matploblib communication problem, graphics
question" I wrote about a zoom to rect bug (I'll paste the relevant
bit below), but for the life of me I can't replicate it on my machine
here (TkAgg). I'll have to test at home on wxagg on OSX which is
where I was having the problems:
Here was the OP:
In testing this stuff, I found a bug bug in image handling on the
trunk -- if you zoom to part of an image with zoom-to-rect, the part
that you get zoomed to is not the part you select. This is most
apparent if you load an image with easily recognizable features, eg a
picture of a person. This problem is on the trunk but not the branch
-- here is some example code:
In [8]: fig = plt.figure()
In [9]: ax = fig.add_subplot(111)
In [10]: ax.set_aspect('auto')
In [11]: X = imread('/Users/jdhunter/Desktop/IMG_0907.JPG')
In [12]: ax.imshow(X, origin='lower', aspect='auto')
Out[12]:
In [13]: ax.figure.canvas.draw()
In [14]: ax.cla()
In [15]: ax.set_aspect('auto')
In [16]: ax.imshow(X, origin='upper', aspect='auto')
Out[16]:
In [17]: fig.canvas.draw()
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Minor point: On my machine at least, I don't have to manually clean up the > conflict files -- they are removed for me on the next commit. Those files > are really just for reference. If you use a SVN frontend for diffing (such > as psvn.el or meld) they are largely unnecessary. On my machine I do need to manually purge these -- svn commit will fail with a message like [EMAIL PROTECTED]:mpl> svn commit -F svnmerge-commit-message.txt svn: Commit failed (details follow): svn: Aborting commit: '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py' remains in conflict even if I have manually edited out all the conflicts. I then need to do [EMAIL PROTECTED]:mpl> rm lib/matplotlib/image.py.* Maybe one of your emacs modes is helping you out behind the scenes? Can you send me your emacs configs for svn? JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mplscape
For those of you who haven't had the pleasure of seeing Michael's spline paths in action, I added a new interactive demo on the trunk: examples/event_handling/path_editor.py Click and drag the vertices to edit the spline path. It needs some more work - eg I want to be able to add and delete vertices, which means tracking groups (all related CURVE4 vertices for example) and the ability to add a curve4, lineto, eg... But with a little work we'll have inkscape-lite. Just need to add some load/save features... JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
Just to confirm, I should use the version tag, "0.98pre"? - Charlie On Thu, May 29, 2008 at 1:09 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? > > We are now ready to do 0.98pre -- fire when ready Charlie. > > JDH > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
John Hunter wrote: > On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> Minor point: On my machine at least, I don't have to manually clean up the >> conflict files -- they are removed for me on the next commit. Those files >> are really just for reference. If you use a SVN frontend for diffing (such >> as psvn.el or meld) they are largely unnecessary. >> > > On my machine I do need to manually purge these -- svn commit will > fail with a message like > > [EMAIL PROTECTED]:mpl> svn commit -F svnmerge-commit-message.txt > svn: Commit failed (details follow): > svn: Aborting commit: > '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py' > remains in conflict > > > even if I have manually edited out all the conflicts. Oh -- it appears that "svn resolved" is what does this, not "svn commit". I didn't realise that just deleting the files was enough and have always used "svn resolved" as a matter of course. The convenient thing about "svn resolved" is you can do "svn -R resolved ." to resolve the whole tree once you're sure you're done. > I then need to do > > [EMAIL PROTECTED]:mpl> rm lib/matplotlib/image.py.* > > Maybe one of your emacs modes is helping you out behind the scenes? > Can you send me your emacs configs for svn? > I use psvn.el, which is far easier to use IMHO than the built-in pcl-svn. You can get it here -- I haven't set any customizations on it. http://www.xsteve.at/prg/vc_svn/ My favorite feature is the integration with ediff -- press 'E' in the svn-status buffer and it brings up an ediff session between your working copy and the SVN revision it came from. Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge.py - keeping the maintenance branch and trunk in sync
Michael Droettboom wrote: > John Hunter wrote: > >> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> >> wrote: >> >> >> >>> Minor point: On my machine at least, I don't have to manually clean up the >>> conflict files -- they are removed for me on the next commit. Those files >>> are really just for reference. If you use a SVN frontend for diffing (such >>> as psvn.el or meld) they are largely unnecessary. >>> >>> >> On my machine I do need to manually purge these -- svn commit will >> fail with a message like >> >> [EMAIL PROTECTED]:mpl> svn commit -F svnmerge-commit-message.txt >> svn: Commit failed (details follow): >> svn: Aborting commit: >> '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py' >> remains in conflict >> >> >> even if I have manually edited out all the conflicts. >> > Oh -- it appears that "svn resolved" is what does this, not "svn > commit". I didn't realise that just deleting the files was enough and > have always used "svn resolved" as a matter of course. The convenient > thing about "svn resolved" is you can do "svn -R resolved ." to resolve > the whole tree once you're sure you're done. > >> I then need to do >> >> [EMAIL PROTECTED]:mpl> rm lib/matplotlib/image.py.* >> >> Maybe one of your emacs modes is helping you out behind the scenes? >> Can you send me your emacs configs for svn? >> >> > > I use psvn.el, which is far easier to use IMHO than the built-in > pcl-svn. You can get it here -- I haven't set any customizations on it. > I lied. There is one keyboard mapping I added that I've found pretty useful: (global-set-key (kbd "s-s") 'svn-status-switch-to-status-buffer) (define-key svn-status-mode-map (kbd "s-s") 'svn-status-bury-buffer) This lets me toggle between the file I'm editing and the svn-status buffer using "Super-s" (Windows key-s). Makes it very convenient to edit a file, check the differences against the repository, and check them in. Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Just to confirm, I should use the version tag, "0.98pre"? My preference is to call it 0.98.0 unless Michael is feeling extra cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever ... JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
I went ahead and called it 0.98.0. I am getting a parallels image updated so I can do the windows builds, but it is getting late. I will get those cranked out tomorrow. The source and mac builds are up though. I got two internal compiler errors on the 0.98.0 build, which I fixed by replacing -O3 with -Os on those two commands only. I also updated the MANIFEST.in file to include agg24 instead of agg23. - Charlie On Thu, May 29, 2008 at 10:06 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> Just to confirm, I should use the version tag, "0.98pre"? > > My preference is to call it 0.98.0 unless Michael is feeling extra > cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever > ... > > JDH > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
