Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Overhaul make.osx in master#30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Some tests fail with new freetype - seehttp://thread.gmane.org/gmane.comp.python.matplotlib.devel/9948/focus=9965 |
The echo was there to comment out a cp command, and things seem towork fine without the cp.
Conflicts:README.osxmake.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änenjks@iki.fi"'? |
On 06/16/2011 03:06 AM, ddale wrote:
|
Slightly modified version ofa71414d from the maintenance branch.
Closed with861da23. |
Flush buffer when finishing SVG file.Closesmatplotlib#30.
…ib#30lib/io/dm3_data_plugin.pyBUG-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 micrographreader has been almost fully rewritten and it should now be able to reada 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.