Overhaul make.osx in master #30
Conversation
|
Some tests fail with new freetype - see http://thread.gmane.org/gmane.comp.python.matplotlib.devel/9948/focus=9965 |
The echo was there to comment out a cp command, and things seem to work fine without the cp.
Conflicts: README.osx make.osx
|
Went back to an older freetype because of the failing tests, and merged master because of a conflict. Comments, anyone? |
|
I don't use the makefile approach myself. I use MacPorts to provide the dependencies and then the usual "python setup.py install --user". I might recommend adding an additional install target like "mpl_install_user", to support installing to user's local site-packages directory (python-2.6 and newer). Aside from that, the only comment I have is that I would have stuck with the newer freetype, it is going to be provided by other package managers anyway. |
|
Perhaps as part of this effort we should merge the two different Mac OS X makefiles in the tree? (Or as a follow on.) Just wanted to link this mailing list discussion here: http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg08055.html |
|
I think this really should get merged now, before the next release, and I agree with Mike that it should have the new freetype version. However, I have been unsuccessful in doing the merge. Every time I try, README.osx gets truncated. I could use a brute-force method, simply copying the revised versions of the two files from the branch into master and committing, but maybe someone else can figure out a more elegant solution. |
|
Yeah, I see the same thing. Rebasing yields the same result. I'd like to understand what is going on, github says this pull request can be automatically merged, but when I perform the merge locally there are conflicts that have to be resolved. Jouni, why did you merge master into this branch? |
|
Maybe its not worth worrying about, and we should just do the brute-force approach. I'm not at work today where I can test on a mac. Eric, could you take care of it? Are you familiar with 'git commit --author="Jouni K. Seppänen jks@iki.fi"'? |
|
On 06/16/2011 03:06 AM, ddale wrote:
|
Slightly modified version of a71414d from the maintenance branch.
|
Closed with 861da23. |
Flush buffer when finishing SVG file. Closes matplotlib#30.
…ib#30 lib/io/dm3_data_plugin.py BUG-FIX: DM3ImageFile.read_image_data when loading data, the natural order should be (rows, columns, ...) and not (X, Y, ...). Digital Micrograph stores Spectrum Images as: X0, Y0, Z0, X1, Y0, Z0, [...], Xn, Ym, Z0, [...] X0, Y0, Z1, [...], Xn, Ym, Zk Since X <=> column and Y <=> row the 1st two axes of the ndarray must be transposed because the natural order is: row (Y), column (X), E. MOVE: file_reader For back compatibility with the plotting libraries, the data are transposed back.
… The digital micrograph reader has been almost fully rewritten and it should now be able to read a higher number of dm3 files.
making figure legend for profiles
This is the master branch counterpart to pull request #17, which fixes some problems in make.osx on the v1.0.x maintenance branch. In addition to the changes on that branch, this pull request updates zlib, freetype and libpng to new versions.