matplotlib-devel Mailing List for matplotlib

On Fri, Mar 4, 2011 at 13:40, Eric Firing <ef...@ha...> wrote:
> On 03/04/2011 10:30 AM, Jouni K. Seppänen wrote:
> > We have an open pull request for fixing some problems in the make.osx
> > file:
> >
> > https://github.com/matplotlib/matplotlib/pull/17
> >
> > I think it's otherwise fine, but it changes the mpl_install target by
> > removing the --prefix argument. Personally I would prefer to drop the
> > --prefix, but this is originally John's file and he may have had a good
> > reason to install in a non-standard directory. Any comments?
> >
>
> I presume a user might want to be able to build and test a development
> version without replacing a production version.
>
> What is the rationale for removing the --prefix argument? It doesn't
> prevent one from installing in the standard location.
>
> Eric
>
My rationale for removing the --prefix argument was that a user might want
to compile matplotlib from source on MacOSX instead of install it from a
package (assuming such a package exists). As it stands now, the make.osx
file has some configuration at the top and then states that you shouldn't
need to configure past a point.
I've recently gone from relying on Enthought to compiling the packages I use
from source. All of the other packages (numpy/scipy, ipython, PIL, pyserial)
install by default on the site-packages relevant to the python version used
in the install. Removing the --prefix argument would bring the same
functionality to matplotlib on OSX. This default could be modified by
developers that would rather install in a test environment.
As I mention in the pull request, though, I'm still unsure if the
dependencies are compile-time or not. I've left the PREFIX intact after
installing into the production site-packages and I haven't had any issues so
far. The reason the PREFIX is needed, as README.osx explains, is because OSX
can have different types of zlib, png and freetype installed on the system.
If this change blocks the pull request from going through, though, I could
just revert that change and open up another one once we've cleared up any
doubts about what the rationale for having the --prefix in the first place
are.
-- Fernando

On 03/04/2011 10:30 AM, Jouni K. Seppänen wrote:
> We have an open pull request for fixing some problems in the make.osx
> file:
>
> https://github.com/matplotlib/matplotlib/pull/17
>
> I think it's otherwise fine, but it changes the mpl_install target by
> removing the --prefix argument. Personally I would prefer to drop the
> --prefix, but this is originally John's file and he may have had a good
> reason to install in a non-standard directory. Any comments?
>
I presume a user might want to be able to build and test a development 
version without replacing a production version.
What is the rationale for removing the --prefix argument? It doesn't 
prevent one from installing in the standard location.
Eric

We have an open pull request for fixing some problems in the make.osx
file:
https://github.com/matplotlib/matplotlib/pull/17
I think it's otherwise fine, but it changes the mpl_install target by
removing the --prefix argument. Personally I would prefer to drop the
--prefix, but this is originally John's file and he may have had a good
reason to install in a non-standard directory. Any comments?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi Ben, Hi list,
> Exactly. That's all I found too. Nothing indicates that we need to
> change anything. We are throwing away the second part of the tuple
> which has the returned filter. The only reason I see for the new
> function is so the coder can get back the filter string, which we
> don't seem to use.
It took me a while to see the problem, too. The point is: there is one parameter
missing in the new API of getSaveFileName, called selectedFilter,
which we use, and
given that it is missing, python takes it to be the next parameter, which
must be an int, and you get a TypeError. I discussed this with
Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
(see http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
and he told me to use getSaveFileNameAndFilter.
The other option would be to change PyQt4, dunno which is best.
Greetings
Martin
-- 
Max-Born-Institut
Max-Born-Straße 2a
12489 Berlin
+49 30 6392 1234

On Thursday, March 3, 2011, Darren Dale <dsd...@gm...> wrote:
> On Thu, Mar 3, 2011 at 10:22 AM, Benjamin Root <ben...@ou...> wrote:
>> Just for completeness, I wanted to include a link to some sort of reference
>> indicating a need to change the function. I can not find any documentation
>> that says that we need to change from getSaveFileName() to
>> getSaveFileNameAndFilter(). Can you please provide a source explaining the
>> need for this change?
>
> Try here: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/python_v3.html#qfiledialog
>
Exactly. That's all I found too. Nothing indicates that we need to
change anything. We are throwing away the second part of the tuple
which has the returned filter. The only reason I see for the new
function is so the coder can get back the filter string, which we
don't seem to use.
Am I missing something?
Ben Root

On Thu, Mar 3, 2011 at 10:22 AM, Benjamin Root <ben...@ou...> wrote:
> Just for completeness, I wanted to include a link to some sort of reference
> indicating a need to change the function. I can not find any documentation
> that says that we need to change from getSaveFileName() to
> getSaveFileNameAndFilter(). Can you please provide a source explaining the
> need for this change?
Try here: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/python_v3.html#qfiledialog

I noticed that this didn't exist and I never seem to want a frame anyway 
so here's a patch. I wasn't sure if anything in doc/ needed to be changed...
I don't really like the name "legend.frameon". I'd rather have 
"legend.frame" or "legend.useframe". If people would accept changing the 
name of the keyword, then this patch probably shouldn't be committed.
M