matplotlib-devel Mailing List for matplotlib

Looking forward, supporting the Python 3 compatible PyQt API is likely the 
way to go.
Le , Gerald Storer <gd...@mr...> a écrit :
> On 28/03/2011 1:10 AM, Peter Butterworth wrote:
> Wouldn't it be possible to use a single backend compatible with both
> PyQt and Pyside ?
> The current Qt mpl backend uses the old PyQt slots/signals API which 
> PySide doesn't really support (there are some macros but they don't work 
> 100% the same). From a quick glance at the IPython implementation it 
> looks like they are using the new API which means older versions (<4.5) 
> of PyQt won't be supported. This might be ok, I don't know.
> If it isn't then, there will need to be some try...excepts around the 
> place or separate back ends. If you ignore the PySide bugs I had to work 
> around I've only changed ~4 lines in the main backend.
> Pierre's formlayout is also using an obsolete method that isn't present 
> in PySide. I've opted to emulate it, but it would be best to change the 
> code to use the alternative method available in both PyQt and PySide. 
> formlayout also uses the old QString implementation of PyQt, PySide only 
> supports the new implementation where QString is transparently convert 
> to/from str/unicode. Setting QString = unicode seems to work though.
> Gerald.

On Mon, Mar 28, 2011 at 2:02 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
>
> > I tried to merge my changes into master with the no-op "ours" strategy
> > to prevent exactly this kind of problems while waiting for the other
> > request to move forward, but apparently I didn't do it right. I'll take
> > a look tonight (but right now I must attend to other things).
>
> So I had merged the *feature branch* on which the README.osx and
> make.osx changes were into master with --strategy ours, but not the
> *merge commit* where I merged that feature branch into v1.0.x. I now
> merged the merge commit as well, and it seems to have helped: I was
> able to merge v1.0.x into master with only the conflict in
> installing_faq.rst.
>
> Sorry about the confusion.
>
>
No problem. Thanks for helping with that. The commit looks good to me.
Ben Root

Jouni K. Seppänen <jk...@ik...> writes:
> I tried to merge my changes into master with the no-op "ours" strategy
> to prevent exactly this kind of problems while waiting for the other
> request to move forward, but apparently I didn't do it right. I'll take
> a look tonight (but right now I must attend to other things).
So I had merged the *feature branch* on which the README.osx and
make.osx changes were into master with --strategy ours, but not the
*merge commit* where I merged that feature branch into v1.0.x. I now
merged the merge commit as well, and it seems to have helped: I was 
able to merge v1.0.x into master with only the conflict in
installing_faq.rst.
Sorry about the confusion.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Benjamin Root <ben...@ou...> writes:
> I managed to merge my docfix/improve_description branch over to v1.0.x, but
> I am having trouble merging correctly over to master. It appears that the
> README.osx and make.osx files were changed in v1.0.x, but not in
> master. 
That was me: those changes don't apply cleanly to master, so I have
another pull request with the corresponding changes. I made some changes
it to recently, and it had not received any comments after that, so I
was hesitant to merge it yet.
I tried to merge my changes into master with the no-op "ours" strategy
to prevent exactly this kind of problems while waiting for the other
request to move forward, but apparently I didn't do it right. I'll take
a look tonight (but right now I must attend to other things).
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I don't know if a cherry-pick is required -- just someone who understands the changes and knows how the merge should be performed. Back in the SVN days, we encouraged the authors making changes on the maintenance branch to merge into trunk (master), since they were best equipped to make judgment calls. Any thoughts on this from the git masters?
Mike
________________________________
From: Benjamin Root [ben...@ou...]
Sent: Monday, March 28, 2011 10:19 AM
To: matplotlib development list
Subject: [matplotlib-devel] problems merging docfixs to master from v1.0.x
Hello all,
I managed to merge my docfix/improve_description branch over to v1.0.x, but I am having trouble merging correctly over to master. It appears that the README.osx and make.osx files were changed in v1.0.x, but not in master. So my merge wants me to resolve these differences -- which I am not about ready to do. There is also some sort of conflict with doc/faq/installing_faq.rst, but that conflict is easy to resolve (change build_dep to build-dep).
Maybe we need to cherry-pick the changes to README.osx and make.osx from v1.0.x to master first?
Thanks,
Ben Root

Hello all,
I just noticed a small change in behavior with 3d plots. If one creates the
plot in the old way (i.e., "ax = Axes3D(fig)"), the plot will start out
using the entire figure region as it should. However, once you start to
manipulate it (rotate or whatever), the plot loses its horizontal extent
(but not vertical extent). The horizontal extent it switches to matches the
default extents for regular subplot axes.
I am sure there is partly some sort of issue in mplot3d that is triggering
this, but I have to wonder if this would impact anybody else using custom
extents for their axes objects.
Thanks,
Ben Root

Yo,
On Mon, Mar 28, 2011 at 8:17 AM, Michael Droettboom <md...@st...> wrote:
> There's also this git command I just discovered. It seems to solve all of these issues, and the documentation is written in the same crystal-clear style of the other git manpages:
>
> http://wingolog.org/archives/2011/03/28/git-brunch1
It is indeed a stylistic masterpiece. And then you have the aptly
named and actually useful:
http://git-wt-commit.rubyforge.org/git-wtf
Matthew

There's also this git command I just discovered. It seems to solve all of these issues, and the documentation is written in the same crystal-clear style of the other git manpages:
http://wingolog.org/archives/2011/03/28/git-brunch1
Mike
________________________________________
From: Paul Ivanov [piv...@gm...]
Sent: Thursday, March 24, 2011 8:20 PM
To: mat...@li...
Subject: Re: [matplotlib-devel] I screwed up matplotlib/master on github
Matthew Brett, on 2011年03月24日 16:37, wrote:
> Welcome to the wonderful world of git and DVCS!
Thanks, I wish I could claim that I only started using git
recently, but I've just sort of been uncomfortably trying my best
to not cause too much trouble for the past year and a half...
>
> I think you could have solved this one by:
>
> git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989
>
> and pushing that. Assuming you had that commit, which I guess you would have.
This actually wasn't the case - I hadn't pulled from
matplotlib/master for a few days, hence the stale commit become a
head after my push.
> The way I try and avoid doing that very easy thing is
>
> 1) Having a moderately frightening name for the upstream remote like
> 'upstream-rw'.
> 2) Having a moderately frightening name for the tracking branch like:
>
> git co -b main-master --track upstream-rw/master
good tips, thanks.
>
> 3) Making sure I've got the git-completion bash command line
> completion tools working, so I can always see my branch name
This was actually the case for me - I wasn't working on master,
but a seperate branch called 'one-figure' which didn't have a
remote branch affiliated with it (or a wrong one). I had
previously pushed it using 'git push ivanov one-figure', and
*wrongly* assumed that this state was preserved somewhere
16:46@matplotlib(one-figure)$
> 4) Never working on main-master, always branching, and merging when I'm sure.
> 5) Deleting my own master branch to avoid confusion. This involves:
>
> Going to your github fork, choosing Admin, set default branch to be
> something other than 'master'
>
> git co that-other-branch
> git branch -D master # delete locally
> git push origin :master # delete on github
>
> Every error, is a jewel.
Wise words, but if that were true, De Beers and Tiffany's
couldn't hope to compete with me.
best,
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Yes. IPython certainly has what looks like a reasonable "recipe" to 
support PySide and PyQt4. I would much prefer this approach. Anything 
to keep the number of code paths down in the different backends is well 
worth the effort.
Mike
________________________________________
From: Peter Butterworth [bu...@gm...]
Sent: Sunday, March 27, 2011 1:10 PM
To: matplotlib-devel
Subject: Re: [matplotlib-devel] Backend for Pyside
Wouldn't it be possible to use a single backend compatible with both
PyQt and Pyside ?
Other projects (enthought, ipython, spyderlib) seem to be able to
handle the issue by importing from a proxy qt module that does the
right imports and handles the incompatibilities. The preferred backend
is set through an environment variable.
>>> Re: Backend for Pyside
by Gerald Storer Mar 23, 2011; 08:33am :: Rate this Message: - Use
ratings to moderate (?)
I've just noticed that its possible to use an external package as a
back end so I moved my changes into their own package. This is
sufficient for my own use but I'm guessing others may find is useful
as well (and it might speed official support).
Attached is the package. (pysidempl)
Regards,
Gerald.
--
thanks,
peter butterworth
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello all,
I managed to merge my docfix/improve_description branch over to v1.0.x, but
I am having trouble merging correctly over to master. It appears that the
README.osx and make.osx files were changed in v1.0.x, but not in master. So
my merge wants me to resolve these differences -- which I am not about ready
to do. There is also some sort of conflict with doc/faq/installing_faq.rst,
but that conflict is easy to resolve (change build_dep to build-dep).
Maybe we need to cherry-pick the changes to README.osx and make.osx from
v1.0.x to master first?
Thanks,
Ben Root

I have been able to get pygtk installed on OSX by following these
instructions, and it works fine:
http://kedeligdata.blogspot.com/2011/03/building-pygtk-for-mac.html
I would really like to get GTK working on OSX since I have done some app
development using GTK and Glade, and I can get GTK and Glade working without
problems on both Windows and Linux machines. OSX is the thorn in my side at
the moment.
FYI: In make.osx, the path for the libpng install is no longer any good, the
correct full path should be
http://sourceforge.net/projects/libpng/files/libpng12/1.2.44/libpng-1.2.44.tar.gz/download
The linpng folks seem to have relocated their installation files on the
sourceforge server.
When altering the paths for GTK, what modifications are required? How can I
help the matplotlib install find the GTK files?
Regards,
Ian
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626