matplotlib-devel Mailing List for matplotlib (Page 2)

Hello,
I noticed several problems with the source archive
matplotlib-0.31.tar.gz.
1) The licence file confuses version 0.30 with version 0.31.
 (I mentioned this already to John.)
2) There are several editor backup files included in the archive:
 voss@plonk [~] tar tfz matplotlib-0.31.tar.gz | grep '~'
 matplotlib-0.31/matplotlib/backends/backend_gtk.py.~1.10.~
 matplotlib-0.31/matplotlib/matlab.py.~1.22.~
 matplotlib-0.31/matplotlib/axes.py.~1.14.~
 matplotlib-0.31/matplotlib/_matlab_helpers.py.~1.4.~
 matplotlib-0.31/examples/log_demo.py.~1.2.~
 matplotlib-0.31/examples/interactive2.py.~1.1.~
 matplotlib-0.31/examples/legend_demo.py.~1.5.~
 matplotlib-0.31/examples/stock_demo.py.~1.2.~
 These should be removed (i.e. not included in the next version).
3) there are two CVS directories in the source:
 voss@plonk [~] tar tfz matplotlib-0.31.tar.gz | grep CVS
 matplotlib-0.31/matplotlib/backends/CVS/
 matplotlib-0.31/matplotlib/backends/CVS/Root
 matplotlib-0.31/matplotlib/backends/CVS/Repository
 matplotlib-0.31/matplotlib/backends/CVS/Entries
 matplotlib-0.31/examples/data/CVS/
 matplotlib-0.31/examples/data/CVS/Root
 matplotlib-0.31/examples/data/CVS/Repository
 matplotlib-0.31/examples/data/CVS/Entries
 These should be removed (i.e. not included in the next version).
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hi John
On Thursday 06 November 2003 3:57 pm, John Hunter wrote:
> Jeremy> My Debian machine is Python 2.3, and it seems to work
> Jeremy> there. As I mentioned, the code seems (on Linux) to need
> Jeremy> to run in a PyCrust shell at the moment - I need to fix
> Jeremy> this, but I suspect that it means getting bogged down in
> Jeremy> details of how the event loop works, which I'd rather put
> Jeremy> off until the main backend is stable.
>
> I think this is not too hard. I created a
>
> wxapp = wxPySimpleApp()
>
> at the top of backend_wx (to solve the bitmap problem). Then in
> ShowOn.realize_windows I called wxapp.MainLoop(). With these changes
> I can call
>
> > python simple_plot.py -dWX
Thanks for fixing this. To be honest, my main focus is using matplotlib inside 
an applications, which is why I hadn't looked into this, beyond ensuring that 
it works in a PyCrust (which is my usual interactive shell, to be honest)
> Thanks for the CVS info. You'll need to get a sourceforge account if
> you don't already have one, and send me your user name. Then I'll add
> you as a developer so you can have write access to the repository.
My Sourceforge user name is jodonoghue
> I'll do some reading up on CVS. What happens if we both check out a
> copy of the wx backend and make changes to different functions in the
> same file, and then both check the code back in? Will CVS
> automagically update the separate parts of the file, or will the
> second person get an error saying "You can't check this in because the
> CVS file has changed since you checked out", or what?
CVS, like most SCM tools, doesn't help you quite this much. All it really does 
is to keep a diff every time a new file is committed, so it is quite possible 
that if you make a change to a file, and then I check in a new change without 
an update, HEAD would 'loose' your update (although it would be easy using a 
CS diff to determine the 'lost' code.
Normally CVS is configured so that files are checked out 'unlocked' - i.e. 
more than one developer can check out a file (so a check out is 'advisory' 
only).
Here's how I work in CVS:
I have a local mirror of CVS tree, which I regularly update to head. From this 
I copy files to my matplotlib development directory. When I wish to check in 
an update, I do an update on my CVS copy, and diff the new file with the CVS 
copy. There are two possibilities:
1) Any changes to HEAD are on lines I haven't changed. In this case
 (which is the most usual) I just have to do run merge between the
 files and then commit (having regression tested, of course).
2) We have made incompatible changes (e.g. both fixed the same bug
 in slightly different ways, or added new code in the same place). In this
 case I have to do a manual merge on the files, taking parts from both
 and working until regression tests pass - then commit.
One way to avoid this kind of issue is to (informally, CVS doesn't let you 
enforce this) say that only one person will normally work on a given file - 
in practice, this is how we operate at work (but then we have a 10,000 file 
source tree, so everyone would go crazy if we didn't). If someone has a fix 
for a file, they send it to the file maintainer, and ask him/her to 
incorporate the patch. This is basically how Linus maintains Linux (there are 
only a very small number of people who have commit rights to the Linux CVS 
tree - maybe 10 or 20 of the thousands of developers.
> I made a couple of small changes to your code (BTW, I don't know if
> matplotlib-devel is working because none of my emails have made it
> through). The images dir is now in the matplotlib root (where
> setup.py and the fonts dir reside). The distutils installer puts them
> in the matplotlib shared dir for data files, and I changed
> _load_bitmap to look for them there. This maintains consistency with
> how I deal with other data files, eg, font files.
All of your changes seem eminently sensible. You have done an excellent job of 
architecting matplotlib, and I'd rather let you keep things designed as you 
prefer them. We can (and should) discuss any architectural changes, but I'll 
implement whatever you finally decide.
In fact, it makes sense to say that backend_gtk should be the test bed for any 
architectural changes - when you're reasonably satisfied that things work, 
I'll implement equivalent changes in backend_wx. This will always put 
backend_wx slightly behind backend_gtk, but we can always ensure that they're 
back in sync for major releases.
By the way, based on what I've found so far, the main areas I've found which 
caused me some confusion in implementing the backend are:
- Think there should be a 'default' set of fonts with names common on each 
platform (I've implemented this)
- Should also be a set of common names for dotted lines - there are only four 
types, so no problem, I should think.
- Somehow AxisText seems to be disconnected from the way the graphics are 
done. I managed to confuse myself quite a lot here. It seems to me that 
renderer is ultimately responsible fro rendering both text and graphics (on 
the same co-ordinate system)
- I was also confused by the how scaling and co-ordinates are mapped to the 
device - this is probably a matter of documentation rather than design 
change.
Regards
Jeremy

Receiving you loud and clear.
I did receive all of the other mails at my personal address.
Jeremy
On Thursday 06 November 2003 7:13 pm, John Hunter wrote:
> OK, if you think I've been ignoring you on this list there is a reason
> -- I wasn't subscribed. I assumed because I am the list admin that I
> would automatically be subscribed. So as far as I know, despite my
> earlier complaints and tests, this list is working.
>
> Can you hear me now?
>
> JDH
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

OK, if you think I've been ignoring you on this list there is a reason
-- I wasn't subscribed. I assumed because I am the list admin that I
would automatically be subscribed. So as far as I know, despite my
earlier complaints and tests, this list is working.
Can you hear me now?
JDH

 Jeremy> My Debian machine is Python 2.3, and it seems to work
 Jeremy> there. As I mentioned, the code seems (on Linux) to need
 Jeremy> to run in a PyCrust shell at the moment - I need to fix
 Jeremy> this, but I suspect that it means getting bogged down in
 Jeremy> details of how the event loop works, which I'd rather put
 Jeremy> off until the main backend is stable.
I think this is not too hard. I created a 
 wxapp = wxPySimpleApp()
at the top of backend_wx (to solve the bitmap problem). Then in
ShowOn.realize_windows I called wxapp.MainLoop(). With these changes
I can call 
 > python simple_plot.py -dWX
and it launches!! I am very excited about this wx backend, by the
way.
 Jeremy> I have no worries about dealing with several people on CVS
 Jeremy> at the same time. At work we have about 50 developers
 Jeremy> working on the same codebase (admittedly with a slightly
 Jeremy> more heavyweight SCM tool). Basically the rules are:
Thanks for the CVS info. You'll need to get a sourceforge account if
you don't already have one, and send me your user name. Then I'll add
you as a developer so you can have write access to the repository.
I'll do some reading up on CVS. What happens if we both check out a
copy of the wx backend and make changes to different functions in the
same file, and then both check the code back in? Will CVS
automagically update the separate parts of the file, or will the
second person get an error saying "You can't check this in because the
CVS file has changed since you checked out", or what?
I made a couple of small changes to your code (BTW, I don't know if
matplotlib-devel is working because none of my emails have made it
through). The images dir is now in the matplotlib root (where
setup.py and the fonts dir reside). The distutils installer puts them
in the matplotlib shared dir for data files, and I changed
_load_bitmap to look for them there. This maintains consistency with
how I deal with other data files, eg, font files.
Also, I added a KNOWN BUGS section to backend_wx.py where I pasted in
those from your email and added some I came across while running most
of the demos. We can both use that area to keep up with known bugs
and fixes.
JDH

My last post didn't make it through. Testing 1 2 3

Hi John,
I'm getting on reasonably well with the wxWindows back-end, and would be
nearly ready to release something for 'early adopters', but for one small
problem:
I can create figures with multiple sub-plots (I've tried most of the
examples on the web page), using colour and so on...
But all of my plotted values are inverted - that's to say, the origin of
each set of axes (from the point of view of plotting) is in the top left,
with increasing values going downwards.
The axis scales are correct, and all of the patches are in the right place.
I'm sure that I have my co-ordinate conversion mixed up somewhere, but to
understand what is happening, it would be useful to have a brief
explanation of the virtual co-ordinate system used internally in
matplotlib, and (especially) how internal co-ordinates should be converted
to device co-ordinates.
This is all quite confusing - I had originally assumed that I should be
subtracting the window client area height from all y axis co-ordinates,
but this really messes things up for multiple sub-plots (BTW, wxWindows
normally sets the origin in the 'natural' (i.e. bottom left) of a window.
Thanks
Jeremy