Re: [matplotlib-devel] make.osx: should it set --prefix=$PREFIX ?
On Sat, Mar 5, 2011 at 23:52, Jouni K. Seppänen wrote: > Thanks; pull request #17 is IMHO ready for merging into v1.0.x, but > let's wait to see if anyone has further comments. I created pull request > #30 for merging into master; that one also has newer dependency versions > as suggested by Eric. > Do you know if these changes will trickle to the py3 repo after merging into master? I initially came up with the patch while compiling the old py3k branch and when I realized it also applied to matplotlib Darren suggested I submit the pull request there. I'm asking this because there's another tiny change that pertains to the py3 version of the patch and I wonder whether I should wait or start the pull process now. -- Fernando -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] make.osx: should it set --prefix=$PREFIX ?
Fernando Garcia Bermudez writes: > Do you know if these changes will trickle to the py3 repo after > merging into master? I don't know if we have a process in place for that. It depends on how you view the py3 repo: if it's just another feature branch, it shouldn't do any merges from master just for the sake of it, but if it's kind of like "next" or "pu" (proposed updates) in some workflows, it makes sense for it to be occasionally brought up to date (possibly even by rebasing). But it's fine for even feature branches to merge from master, e.g. if there is a feature in master that the branch is going to depend on. -- Jouni K. Seppänen http://www.iki.fi/jks -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] buggy legend behavior with "_nolegend_" label?
Hi, According to the legend doc, If label is set to '_nolegend_', the item will not be shown in legend. But I think the documented behavior a bit ambiguous. For example, consider the example below. l1, = plot([1,2,3], label="_nolegend_") l2, = plot([2,3,1]) legend(["my line"]) I suppose the legend should show *l2* with "my line" label. But the current master branch shows "l1" with "my line" label. In other words, in the current implementation, when the legend command is called with a single nonkeyword argument (which is interpreted as a list of labels), the given labels are applied to all the artists regardless whether the artist has a label of "_nolegend_" or not. While there could be some cases that have relied on this behavior, I'm inclined to fix this so that artists w/ "_nolegend_" are ignored. However, fixing this requires "hist" command to be modified (there could be more commands that need modification). Unless there is no objection from other developers, I'll go ahead and commit the patch to fix this. Regards, -JJ -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] make.osx: should it set --prefix=$PREFIX ?
On Sun, Mar 6, 2011 at 4:46 AM, Jouni K. Seppänen wrote: > Fernando Garcia Bermudez writes: > >> Do you know if these changes will trickle to the py3 repo after >> merging into master? > > I don't know if we have a process in place for that. It depends on how > you view the py3 repo: if it's just another feature branch, it shouldn't > do any merges from master just for the sake of it, but if it's kind of > like "next" or "pu" (proposed updates) in some workflows, it makes sense > for it to be occasionally brought up to date (possibly even by > rebasing). I guess the py3 master will not be merged back into the matplotlib repo until the last maintenance branch supporting python-2.5 and older has been created (perhaps 1.1.x or 1.2.x). Since it is a long-running line of development, I think it makes sense to occasionally bring it up to date with the master branch. I've already done this once or twice. I don't think we want to deal with rebasing. I rebased the py3 master branch once right after you merged the maintenance branches with --strategy=ours, since that provided a much improved point of reference, but it was a headache to coordinate with even one other dev to deal with any unmerged branches out there effected by the rebase. Maybe once the osx make binaries issue is resolved and the make.osx branch is merged into master, someone with a working windows build environment could test building binaries with python-2.6 and 2.7. If it looks ok, that might be a good point to merge matplotlib/master into py3/master. Darren -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Freetype 2.4.4
On 03/06/2011 02:08 AM, Jouni K. Seppänen wrote: > Eric Firing writes: > >> Newer versions of the libraries can also be used, although this is not >> critical. v1.0.x still needs the 1.2 series of libpng, but master can >> now handle >> >> ZLIBVERSION=1.2.5 >> PNGVERSION=1.5.1 >> FREETYPEVERSION=2.4.4 > > With the old versions (including freetype 2.3.11) the test suite passes > for me (163 tests, 50 knownfail because I don't have a working inkscape > on my Mac), but with the new versions I get 18 failures. All seem to be > caused by text being rendered in different locations, or with different > fonts. I'm attaching two examples of this: in the font_styles test, two > of the styles do not work, and in image_clip the text inside the circle > is in completely different coordinates. > > > > > > Is this a known problem? Again, with the old libraries all tests pass > for me, except for the svg images for which I don't have comparison > tools, so I believe this to be caused by the dependencies, most likely > freetype. I have to admit I did not do these tests; I was experimenting with a borrowed machine, and I ran out of time. However, I have run nosetests on a build of master on Ubuntu 10.10, with freetype 2.4.2, and I see the same failure that you showed on the font_styles test. Same test on a build of v1.0.x, same failure. Fails for png and svg; passes for pdf, but the images being compared are ugly low-res bitmapped things. The major change between the freetype 2.3 series and 2.4 seems to be "In addition to many bugfixes, the TrueType bytecode interpreter is now enabled by default. All users should upgrade." Eric -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Freetype 2.4.4
Eric Firing writes: > However, I have run nosetests on a build of master on Ubuntu 10.10, with > freetype 2.4.2, and I see the same failure that you showed on the > font_styles test. Same test on a build of v1.0.x, same failure. Fails > for png and svg; passes for pdf, but the images being compared are ugly > low-res bitmapped things. The pdf comparison is designed that way: the baseline image and the test result are rendered at test time with ghostscript without antialiasing, and while it looks ugly it's both pretty fast and a good comparison, since the files are rendered by exactly the same version of ghostscript with the same settings. It's not surprising that the pdf tests pass, since freetype is used only for finding some font information that needs to be output into the pdf file, and all font rendering is done by the pdf engine of the end user. > The major change between the freetype 2.3 series and 2.4 seems to be "In > addition to many bugfixes, the TrueType bytecode interpreter is now > enabled by default. All users should upgrade." It could be that we have inadvertently relied on bugs, or that truetype hints cause differences that big. -- Jouni K. Seppänen http://www.iki.fi/jks -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
