Re: [matplotlib-devel] Status of pylab example loadrec.py

[Nils Wagner]

On Wed, 10 Dec 2008 21:11:12 -0600
  "John Hunter" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
><[EMAIL PROTECTED]> wrote:
> 
>>
>>> Is it planned to adapt the example wrt xlwt ?
>>>
>>> http://pypi.python.org/pypi/xlwt
>>>
>>
>>
>> True it is no longer maintained, but it does work.  We 
>>are looking into
>> xlwt (I wasn't aware of it until today when you 
>>forwarded the message)
>>
> 
> I've added support for xlwt in svn r6560  -- give it a 
>whirl
> 
> JDH

Hi John,

I have upgraded to r6561.

python test.py --verbose-helpful
$HOME=/data/home/nwagner
CONFIGDIR=/data/home/nwagner/.matplotlib
matplotlib data path 
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /data/home/nwagner/.matplotlib/matplotlibrc
Traceback (most recent call last):
   File "test.py", line 1, in 
 import matplotlib.mlab as mlab
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 700, in 
 rcParams['text.usetex'] = 
checkdep_usetex(rcParams['text.usetex'])
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 367, in checkdep_usetex
 dvipng_v = checkdep_dvipng()
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 261, in checkdep_dvipng
 stderr=subprocess.PIPE)
   File 
"/data/home/nwagner/local/lib/python2.5/subprocess.py", 
line 593, in __init__
 errread, errwrite)
   File 
"/data/home/nwagner/local/lib/python2.5/subprocess.py", 
line 1079, in _execute_child
 raise child_exception
OSError: [Errno 2] No such file or directory
  

Any idea ?

 Nils

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[Nils Wagner]

On Thu, 11 Dec 2008 09:13:02 +0100
  "Nils Wagner" <[EMAIL PROTECTED]> wrote:
> On Wed, 10 Dec 2008 21:11:12 -0600
>  "John Hunter" <[EMAIL PROTECTED]> wrote:
>> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
>><[EMAIL PROTECTED]> wrote:
>> 
>>>
 Is it planned to adapt the example wrt xlwt ?

 http://pypi.python.org/pypi/xlwt

>>>
>>>
>>> True it is no longer maintained, but it does work.  We 
>>>are looking into
>>> xlwt (I wasn't aware of it until today when you 
>>>forwarded the message)
>>>
>> 
>> I've added support for xlwt in svn r6560  -- give it a 
>>whirl
>> 
>> JDH
> 
> Hi John,
> 
> I have upgraded to r6561.
> 
> python test.py --verbose-helpful
> $HOME=/data/home/nwagner
> CONFIGDIR=/data/home/nwagner/.matplotlib
> matplotlib data path 
> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
> loaded rc file 
>/data/home/nwagner/.matplotlib/matplotlibrc
> Traceback (most recent call last):
>   File "test.py", line 1, in 
> import matplotlib.mlab as mlab
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>  
> line 700, in 
> rcParams['text.usetex'] = 
> checkdep_usetex(rcParams['text.usetex'])
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>  
> line 367, in checkdep_usetex
> dvipng_v = checkdep_dvipng()
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>  
> line 261, in checkdep_dvipng
> stderr=subprocess.PIPE)
>   File 
> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
> line 593, in __init__
> errread, errwrite)
>   File 
> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
> line 1079, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
>  
> 
> Any idea ?
> 
> Nils
> 
  
Works for me if I disable text.usetex in 
~/.matplotlib/matplotlibrc, but for what reason ?


### LaTeX customizations. See 
http://www.scipy.org/Wiki/Cookbook/Matplotlib/UsingTex
#text.usetex : True   # use latex for all text 
handling. The following fonts

Nils

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib-0.98.4 easy_install error

[Neal Becker]

> sudo easy_install -U matplotlib
Searching for matplotlib
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Best match: matplotlib 0.98.4
Downloading 
http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.4.tar.gz?modtime=1228859358&big_mirror=0
Processing matplotlib-0.98.4.tar.gz
Running matplotlib-0.98.4/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-nLdSJf/matplotlib-0.98.4/egg-dist-tmp-n2Ro0u

BUILDING MATPLOTLIB
matplotlib: 0.98.4
python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03)  [GCC
4.3.2 20080917 (Red Hat 4.3.2-4)]
  platform: linux2

REQUIRED DEPENDENCIES
 numpy: 1.2.0
 freetype2: 9.18.3

OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.33
   Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5
* Guessing the library and include directories for
* Tcl and Tk because the tclConfig.sh and
* tkConfig.sh could not be found and/or parsed.
  wxPython: 2.8.9.1
* WxAgg extension not required for wxPython >= 2.8
  Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0,
pygobject: 2.15.4
   Mac OS X native: no
Qt: Qt: 3.3.8, PyQt: 3.17.4
   Qt4: Qt: 4.4.1, PyQt4: 4.4.3
 Cairo: 1.4.12

OPTIONAL DATE/TIMEZONE DEPENDENCIES
  datetime: present, version unknown
  dateutil: 1.4
  pytz: 2006p

OPTIONAL USETEX DEPENDENCIES
dvipng: 1.11
   ghostscript: 8.63
 latex: 3.141592

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.5.2
  enthought.traits: no

[Edit setup.cfg to suppress the above messages]

error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or 
directory
Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') 
in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') 
in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/backend_gdk.c') in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/backend_agg.cpp') in > ignored



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Darren Dale]

On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <[EMAIL PROTECTED]> wrote:

>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
>
>> There has been a report at the bugtracker complaining that matplotlib is
>> overwriting an existing installation of configobj. I had a look at the code
>> and thought the bug report must be a mistake or windows specific, but I just
>> saw similar behavior on my linux system.
>
>
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is not
> working like we expect it to.  And that is something that should be fixed if
> is broken.  If mpl is installing configobj or traits even if we are telling
> it not to via setup.cfg, then we have a problem.   This is worth knowing,
> since the last mpl release was broken vis-a-vis the default backend on
> win32, which *could* be explained by a broken setup.cfg.
>

I think I figured this our in my sleep last night. I dont think setup.cfg or
setupext.py is broken. Here is what happened:

I have a new system and I want to build mpl. I run setup.py build, with no
setup.cfg, and setupext.py tells me that I dont have configobj and mpl is
going to provide it. That's not what I want, I would rather install it with
kubuntu's package manager, so I do. Now I run setup.py build again and mpl
tells me that it found the configobj I installed with apt-get. Great, so I
run setup.py install and, wait for it, mpl installs its own configobj,
overwriting the one I just installed, because I forgot to delete my build/
which contained a configobj from the first time I ran setup.py build.

This can probably bite us when building the windows installers too,
hopefully Charlie is deletes his build as part of the standard procedure.


I would like to simply remove configobj and traits from our repository. They
>> are only used by the long-neglected experimental traited config package,
>> which is only of interest to developers who can easily install them as
>> external dependencies. Is it ok to remove them? If so, should it be done on
>> all the branches?
>>
>> How long are we going to continue to maintain the different branches? It
>> was so much easier back when we only had to worry about the trunk...
>>
>
> You can remove them from the trunk.  They should remain on the 0.91 branch
> as is (with any known bugs fixed and merged) since that is the point of the
> branch (stability for those who cannot upgrade -- in principle someone might
> be depending on the traited config, in practice unlikely).  As for the 0.98
> branch, it is slated for destruction so no worries.  I share your visceral
> reaction against branches, but my head is starting to override this bodily
> reaction, as I see the need for them in practice.  If we carefully document
> the best practices and motivations in the developerr's guide, we can use
> them advantageously.
>

At least we have a nice overview of the procedure in the developers guide.
Thanks for that.

I will remove these from the trunk, but I might not get to it until this
afternoon or evening. I have something pressing this morning at work.

>
> We have a lot of people contributing to mpl, and approaching or just after
> release time we need some mechanism for stabilizing the tested feature set
> of the release candidate while allowing other development to proceed, and
> branches are the natural mechanism for that.  That we are starting to use
> them is a reflection of the fact that we have many more active developers
> than we ever had before (12 developers contributed between 98.3 and 98.4, it
> used to be just 3 or 4 at a time).   I wouldn't be advocating branches
> otherwise, because I am an advocate of doing things as simply as possible: 
> "Make
> everything as simple as possible, but not simpler.".
>

Having worked with bzr and launchpad for a few months now, I wonder if we
might consider such an approach in the future. I know there has been some
experimentation with a git repository, is git supported on windows now?
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[Michael Droettboom]

John Hunter wrote:
>
>
> On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <[EMAIL PROTECTED] 
> > wrote:
>
> Hmm... Seems Thunderbird butchered my long URLs.
>
> Anyway, the problem is worse than I thought.  Since the branch was
> created from trunk/ to branches/v0_98_4_maint/, svnmerge.py will
> only merge from one of those to the other.  What we really want to
> be able to do is merge from branches/v0_98_4_maint/matplotlib to
> trunk/matplotlib (i.e. source tree to source tree, not from the
> whole matplotlib universe to another), so the branch must be
> created in the same way.  svnmerge does its magic by going back to
> find how the branch was created, and if the merging doesn't match
> the branch operation, it basically can't do anything.  Hope that
> description makes sense.
>
> This means, presently, in order to do a merge, one has to check
> out the whole kit-and-caboodle with htdocs, py4science etc., and
> not just the matplotlib source tree.
>
> I would suggest fixing this creating a new branch just from the
> source tree, and setting up merging from that to the trunk source
> tree, and then retiring or deleting the current v0_98_4_maint
> branch (if that's possible).
>
>
> Yes, this was just a screwup on my part when I made the branch; be 
> gentle, it was my first time.  I agree with your suggestion of just 
> deleting the branch and starting over. 
No worries.  These things can be hopelessly fiddly.
>
> Unfortunately, there is  a critical bug reported on the users list 
> where is GTKAgg is installed as the default backend on the windows 
> installer (I confirmed this for the win 2.5 win32 egg and assume the 
> problem is in the other win binaries too).  Charlie, did you perhaps 
> forget to set the tkagg backend in the setup.cfg config for the 
> windows installer (and make sure the configobj and traits are turned 
> off as Darren mentioned in another thread)?   I have deleted the win32 
> files from the sf release page. 
>
> Given that the win32 binaries have to be fixed ASAP and that the 
> branch is fubar, it may be in everyone's best interest to simply start 
> over.
> I've added Michael's font_manager and Jae-Joon's figure/subplot fixes 
> to the trunk at r6559 and bumped the version number to 0.98.5rc.  I 
> did another round of testing with these changes (including a nose test 
> for Jae-Joon's problem!) so Charlie if you have time to do another set 
> of binaries we can kill all these birds with one stone an just release 
> 0.98.5 (if you go this route, just remove the rc from the version num 
> and bump to 0.98.5)
>
> Or Charlie, if you do not have time for this in the next 24 hours, but 
> do have time to upload new win32 binaries from your existing build 
> dirs with the backend fixed, that is fine too and we can push out a 
> bug fix release with these other non-critical changes next week.  If 
> you decide to go this route, you should know that I may have 
> accidentally deleted the python 2.4 os x egg when deleting the win32 
> binaries,  because if there was one there isn't one there now :-(
>
> And if your new baby is requiring some attention and you don't have 
> time for either of these, let me know and I will simply hide the 98.4 
> release until we sort this out.
>
> And I'll try and get the maintenance branch right next time :-) 
All of the above sounds good to me.

Mike

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Michael Droettboom]

Darren Dale wrote:
>
>
> We have a lot of people contributing to mpl, and approaching or
> just after release time we need some mechanism for stabilizing the
> tested feature set  of the release candidate while allowing other
> development to proceed, and branches are the natural mechanism for
> that.  That we are starting to use them is a reflection of the
> fact that we have many more active developers than we ever had
> before (12 developers contributed between 98.3 and 98.4, it used
> to be just 3 or 4 at a time).   I wouldn't be advocating branches
> otherwise, because I am an advocate of doing things as simply as
> possible: "Make everything as simple as possible, but not
> simpler.".  
>
>
> Having worked with bzr and launchpad for a few months now, I wonder if 
> we might consider such an approach in the future. I know there has 
> been some experimentation with a git repository, is git supported on 
> windows now?
I'm not sold that bzr/hg/git makes things simpler for this development 
model.  Brett Cannon is currently developing a PEP to propose DVCS for 
CPython development.  See here:

http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64

What John is proposing for matplotlib is identical to the "Backport" use 
case in the PEP.  As you can see, hg actually makes things a lot more 
complicated than svn/svnmerge in this regard.  I don't know if bzr 
(which I have almost no experience with), or git (which I've tried to do 
this kind of thing but haven't found the magic incantation yet), are any 
better in this regard.  Perhaps they are, but it's difficult to find 
documentation on "methodologies" rather than just "methods" for these 
youngish tools.  I think it would be fantastic for anyone with enough 
knowledge able to help Brett flesh out his PEP, because then we'd all 
have a really clean comparison between the tools for specific use 
cases.  And it's a very scientific and "spin-free" way forward, IMHO.

So, I'm not meaning to jump on your suggestion specifically, Darren, but 
I think I've reached some sort of level of fatigue with people saying 
(mainly outside matplotlib) "if we just switched to X, all this 
merging/branching would be so much easier", without a specific 
description of how to migrate to and use X and how that's superior 
enough to warrant the effort.  I don't mean that rhetorically -- I 
actually believe anything is probably better than Subversion, but 
specifically why and how is so often lacking.

I happen to like svnmerge, because one developer (a VC specialist, if 
you will) can set up the branching and merge tracking and all anyone 
else needs to know is "svnmerge.py merge", if they care about merging at 
all.  It always feels like using the DVCS tools that everyone is forced 
to know the topology of the project just to do anything with it -- 
that's a matter of style more than the tool, but DVCS do seem to 
encourage a more spaghetti-branched approach from what I've seen.

Mike

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[John Hunter]

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom  wrote:

>> And I'll try and get the maintenance branch right next time :-)
>
> All of the above sounds good to me.

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days.  Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

  http://mloss.org/workshop/nips08/

JDH

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] rest table in matplotlib.lines.Line2D.set_marker

[Jae-Joon Lee]

John,

I guess the number of "=" of the first column should be 10 (now 9),
because of 'CARETRIGHT'.

I submitted the change to the TRUNK.

-JJ



On Wed, Dec 10, 2008 at 9:50 PM, John Hunter  wrote:
> In response to a question on matplotlib-users, I added some additional
> documentation for the linestyles and markers in the matplotlib.lines API
> docs.  Specifically, I added a rest table mapping the linestyle/marker to
> the meaning of the marker.  Strangely, the set_linestyle table renders fine
>
>
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_linestyle
>
> but the table in set_marker is absent
>
>
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker
>
> I've tried cleanly building and installing mpl in my src tree, running
> svn-clean to make sure no cruft is impacting me, but I have not succeeeded
> in getting the marker table to render.  Perhaps a fresh set of eyeballs can
> spot the problem.  I'm pasting the docstrings below::
>
> def set_linestyle(self, linestyle):
>
> """
> Set the linestyle of the line (also accepts
> drawstyles)
>
>
> 
> =
> linestyle
> description
> 
> =
> '-'
> solid
> '--'
> dashed
> '-.'
> dash_dot
> ':'
> dotted
> 'None'  draw
> nothing
> ' ' draw
> nothing
> ''  draw
> nothing
> =
>
>
> ..
> seealso::
>
> :meth:`set_drawstyle`
>
> ACCEPTS: [ '-' | '--' | '-.' | ':' | 'None' | ' ' | '' ]
> and
> any drawstyle in combination with a linestyle, e.g.
> 'steps--'.
> """
>
> And here is set_marker docstring::
>
> def set_marker(self, marker):
> """
> Set the line marker
>
> =  ==
> marker description
> =  ==
> '.'point
> ','pixel
> 'o'circle
> 'v'triangle_down
> '^'triangle_up
> '<'triangle_left
> '>'triangle_right
> '1'tri_down
> '2'tri_up
> '3'tri_left
> '4'tri_right
> 's'square
> 'p'pentagon
> '*'star
> 'h'hexagon1
> 'H'hexagon2
> '+'plus
> 'x'x
> 'D'diamond
> 'd'thin_diamond
> '|'vline
> '_'hline
> TICKLEFT   tickleft
> TICKRIGHT  tickright
> TICKUP tickup
> TICKDOWN   tickdown
> CARETLEFT  caretleft
> CARETRIGHT caretright
> CARETUPcaretup
> CARETDOWN  caretdown
> 'None' nothing
> ' 'nothing
> '' nothing
> =  ==
>
>
> ACCEPTS: [ '+' | '*' | ',' | '.' | '1' | '2' | '3' | '4'
>  | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd'
>  | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|'
>  | TICKUP | TICKDOWN | TICKLEFT | TICKRIGHT
>  | 'None' | ' ' | '' ]
>
> """
>
>
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[Andrew Straw]

Hi Nils. I think I fixed the issue causing the traceback with r6563. Can
you please update and try again with text.usetex enabled?

My guess is that you don't have dvipng installed, which was causing the
detection check to throw a traceback rather than return a value
signifying undetected. So, enabling usetex should again trigger the
check, but hopefully this time it will fail gracefully rather than crashing.

-Andrew

Nils Wagner wrote:
> On Thu, 11 Dec 2008 09:13:02 +0100
>   "Nils Wagner"  wrote:
>> On Wed, 10 Dec 2008 21:11:12 -0600
>>  "John Hunter"  wrote:
>>> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
>>>  wrote:
>>>
> Is it planned to adapt the example wrt xlwt ?
>
> http://pypi.python.org/pypi/xlwt
>

 True it is no longer maintained, but it does work.  We 
 are looking into
 xlwt (I wasn't aware of it until today when you 
 forwarded the message)

>>> I've added support for xlwt in svn r6560  -- give it a 
>>> whirl
>>>
>>> JDH
>> Hi John,
>>
>> I have upgraded to r6561.
>>
>> python test.py --verbose-helpful
>> $HOME=/data/home/nwagner
>> CONFIGDIR=/data/home/nwagner/.matplotlib
>> matplotlib data path 
>> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
>> loaded rc file 
>> /data/home/nwagner/.matplotlib/matplotlibrc
>> Traceback (most recent call last):
>>   File "test.py", line 1, in 
>> import matplotlib.mlab as mlab
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 700, in 
>> rcParams['text.usetex'] = 
>> checkdep_usetex(rcParams['text.usetex'])
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 367, in checkdep_usetex
>> dvipng_v = checkdep_dvipng()
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 261, in checkdep_dvipng
>> stderr=subprocess.PIPE)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 593, in __init__
>> errread, errwrite)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 1079, in _execute_child
>> raise child_exception
>> OSError: [Errno 2] No such file or directory
>>  
>>
>> Any idea ?
>>
>> Nils
>>
>   
> Works for me if I disable text.usetex in 
> ~/.matplotlib/matplotlibrc, but for what reason ?
> 
> 
> ### LaTeX customizations. See 
> http://www.scipy.org/Wiki/Cookbook/Matplotlib/UsingTex
> #text.usetex : True   # use latex for all text 
> handling. The following fonts
> 
> Nils
> 
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Andrew Straw]

Michael Droettboom wrote:
> Darren Dale wrote:
>   
>> Having worked with bzr and launchpad for a few months now, I wonder if 
>> we might consider such an approach in the future. I know there has 
>> been some experimentation with a git repository, is git supported on 
>> windows now?
>> 
> I'm not sold that bzr/hg/git makes things simpler for this development 
> model.
My thought is that matplotlib.sourceforge.net is a centralized website
making centralized, official releases and other  centralized facilities.
Thus, it seems to me that a centralized, official version control branch
is an entirely reasonable thing to have. svn provides a
least-common-denominator for this job, and I don't see the reasons to
shift to bzr/hg/git as sufficiently strong to merit such a shift. In
particular, the svn model is pretty darn simple, and therefore easy to
interface with (whether you're a human or a computer program).

Of course, part of why I think this way is that git seems to be working
pretty well for inter-operation with the official svn repository. My
experimental repository, described at
http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git
, is nicely allowing me to browse history locally, do git bisect,
maintain my own branches, commit back to the svn repository when
desired, and so on. I think there *may* be some impedance mis-matching
if we tried to really map git branches on svnmerge branches, but right
now that hasn't been an issue I've pursued.

As far as git on Windows: I think there's some kind of msys git and also
the cygwin approach. Not using windows much, though, I'm not sure. I did
hear that Microsoft just started using github for ironruby, so
presumably something works for them.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] git questions

[Michael Droettboom]

This is mostly for Andrew Straw, but thought anyone else experimenting 
with git may be interested.  I'm going through some real newbie pains 
here, and I don't think what I'm doing is all that advanced.

So, I've had a local git repository cloned from github (as per Andrew's 
instructions), made a branch, started hacking, all is well.  Now, I 
would like to update my master branch from SVN to get some of the recent 
changes others have been making.

Following the instructions in the FAQ,

  git svn rebase

actually results in a number of conflicts in files I didn't touch.  I 
shouldn't have to resolve this conflicts, right?  'git status' shows no 
local changes, nothing staged -- nothing that should conflict.

It turns out, if I do

   git pull

then,

   git svn rebase

all is well.

Any idea why?  Should I add that to the instructions in the FAQ?

Now, here's where I'm really stumped.  I finished my experimental 
branch, and I would like to commit it back to SVN.

This is what I did, with comments preceded by '#'

# Go back to the master branch
 > git checkout master
# Merge in experimental
 > git merge experimental
# Ok -- looks good: experimental new feature is integrated, there were 
no conflicts
# However...
 > git svn dcommit
Committing to 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
...
Merge conflict during commit: File or directory 
'doc/users/whats_new.rst' is out of date; try updating: resource out of 
date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
# 1) I didn't change that file, why should I care
# 2) I don't know who to update it
 > git pull
Already up-to-date.
 > git svn rebase
First, rewinding head to replay your work on top of it...
Applying: more doc adds
/home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing 
whitespace.
a lot of new features and bug-fixes. 
warning: 1 line adds whitespace errors.
Applying: added some docs for linestyles and markers
Applying: Remove trailing whitespace.
Applying: figure/subplot and font_manager bugfixes
Applying: added support for xlwt in exceltools
Applying: fixed a typo in whats_new_98_4_legend.py
Applying: fixed typo in Line2D.set_marker doc.
Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
Applying: more doc adds
/home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing 
whitespace.
a lot of new features and bug-fixes. 
error: patch failed: doc/users/whats_new.rst:10
error: doc/users/whats_new.rst: patch does not apply
Using index info to reconstruct a base tree...
:14: trailing whitespace.
a lot of new features and bug-fixes. 
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: added some docs for linestyles and markers
error: patch failed: doc/devel/coding_guide.rst:62
error: doc/devel/coding_guide.rst: patch does not apply
error: patch failed: doc/matplotlibrc:43
error: doc/matplotlibrc: patch does not apply
error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
error: patch failed: lib/matplotlib/lines.py:313
error: lib/matplotlib/lines.py: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged doc/pyplots/whats_new_98_4_legend.py
CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
Auto-merged lib/matplotlib/lines.py
Failed to merge in the changes.
Patch failed at 0010.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

rebase refs/remotes/trunk: command returned error: 1
# Ok, I'm back to merging files that don't conflict with my changes! 
# I shouldn't have to do that, right?
# And FYI:
 > git status
doc/pyplots/whats_new_98_4_legend.py: needs merge
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#modified:   lib/matplotlib/lines.py
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#
#unmerged:   doc/pyplots/whats_new_98_4_legend.py
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#lib/matplotlib/mpl-data/matplotlib.conf
#lib/matplotlib/mpl-data/matplotlibrc
#setupext.pyc
#src/backend_agg.cpp~

Now I feel stuck.  How do I "undo" the merge from experimental to master?

Sorry if these are obvious questions, but I think I've followed the 
git-svn instructions -- I must have made a mistake somewhere along the 
way, but I'm not sure how to debug and/or fix it.

Mike

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Drain, Theodore R]

John,
One thing that would help w/ a rapid delivery/response cycle would be more 
comprehensive tests.They would let other developers try out various ideas 
and see what breaks before you release it.

We’ve implemented an automated approach where we run an MPL script using Agg, 
save the output image and then compare it against a “good” image that someone 
looked at.  We use PIL to do the compare and if it’s close (that’s the hard 
part), then the test passes.  If it’s not, someone looks at the two images to 
see if the difference is benign.  Something similar to this could be done (if 
you’re not already) for the MPL examples to make sure that changes don’t cause 
plotting problems in other areas.

Having this kind of system is also a great driver for people to expand it.  For 
example – we really care about unit processing support everywhere.  Every once 
in awhile, we find a change that someone submits that breaks unit support.  So 
once of the tasks we‘re going to work on next year is to build a set of 
automated test cases that try and hit every plot function with units which can 
then run on every release.  If there were a simple to use MPL standard test 
system like this, other people might contribute more tests as a way of insuring 
that the things they care about stay working through various changes.

It would also be nice to have a test system for unit testing of components.  A 
lot of the code that does different transformations, symbol and color mapping, 
etc etc could be unit tested without the need for actually drawing anything.  
If there was a standard location, style, and system, people could slowly add to 
the tests over time.  You can also consider requiring some level of unit test 
for newly submitted code where ever it’s possible.

Just some thoughts…
Ted

From: John Hunter [mailto:jdh2...@gmail.com]
Sent: Wednesday, December 10, 2008 8:10 PM
To: Darren Dale
Cc: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] requesting permission to remove traits and 
configobj


On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale 
mailto:dsdal...@gmail.com>> wrote:
There has been a report at the bugtracker complaining that matplotlib is 
overwriting an existing installation of configobj. I had a look at the code and 
thought the bug report must be a mistake or windows specific, but I just saw 
similar behavior on my linux system.

Ignoring for a minute the question of whether we can/should flush 
configobj/traits, it sounds like the real problem is that setup.cfg is not 
working like we expect it to.  And that is something that should be fixed if is 
broken.  If mpl is installing configobj or traits even if we are telling it not 
to via setup.cfg, then we have a problem.   This is worth knowing, since the 
last mpl release was broken vis-a-vis the default backend on win32, which 
*could* be explained by a broken setup.cfg.

I would like to simply remove configobj and traits from our repository. They 
are only used by the long-neglected experimental traited config package, which 
is only of interest to developers who can easily install them as external 
dependencies. Is it ok to remove them? If so, should it be done on all the 
branches?

How long are we going to continue to maintain the different branches? It was so 
much easier back when we only had to worry about the trunk...

You can remove them from the trunk.  They should remain on the 0.91 branch as 
is (with any known bugs fixed and merged) since that is the point of the branch 
(stability for those who cannot upgrade -- in principle someone might be 
depending on the traited config, in practice unlikely).  As for the 0.98 
branch, it is slated for destruction so no worries.  I share your visceral 
reaction against branches, but my head is starting to override this bodily 
reaction, as I see the need for them in practice.  If we carefully document the 
best practices and motivations in the developerr's guide, we can use them 
advantageously.

We have a lot of people contributing to mpl, and approaching or just after 
release time we need some mechanism for stabilizing the tested feature set  of 
the release candidate while allowing other development to proceed, and branches 
are the natural mechanism for that.  That we are starting to use them is a 
reflection of the fact that we have many more active developers than we ever 
had before (12 developers contributed between 98.3 and 98.4, it used to be just 
3 or 4 at a time).   I wouldn't be advocating branches otherwise, because I am 
an advocate of doing things as simply as possible: "Make everything as simple 
as possible, but not simpler.".

In general, I am in favor of the wildest, wooliest, development process we can 
afford.  I would like to have  everyone on the trunk, making releases as often 
as possible (nightly if we can), with an attitude of "if you break it, just fix 
it an rerelease it".  This model worked fine for us for years, and I think it 
would continue t

Re: [matplotlib-devel] git questions

[Andrew Straw]

Hi Michael,

The main issue is that we can't use git "normally" because the main
history will be kept with svn. Thus, there's going to be a lot of
history rewriting going on through the rebase command. (These
complications are obviously not the ideal scenario for git newbies...)
Rather than answer your questions directly, I'll walk you through how I
do things. (This is not tried on the MPL svn repo, but some a private
svn repo. I don't see any fundamental differences, though. So this
should work.)

(Hopefully this will be cut-and-pasteable ReST, which could go in the
docs somewhere):

Making a git feature branch and committing to svn trunk
---

Start with a virgin tree in sync with the svn trunk on the git branch
"master"::

  git checkout master
  git svn rebase

To create a new, local branch called "whizbang-branch"::

  git checkout -b whizbang-branch

Do make commits to the local branch::

  # hack on a bunch of files
  git add bunch of files
  git commit -m "modified a bunch of files"
  # repeat this as necessary

Now, go back to the master branch and append the history of your branch
to the master branch, which will end up as the svn trunk::

  git checkout master
  git svn rebase # Ensure we have most recent svn
  git rebase whizbang-branch # Append whizbang changes to master branch
  git svn dcommit -n # Check that this will apply to svn
  git svn dcommit # Actually apply to svn

Finally, you may want to continue working on your whizbang-branch, so
rebase it to the new master::

  git checkout whizbang-branch
  git rebase master

Michael Droettboom wrote:
> This is mostly for Andrew Straw, but thought anyone else experimenting
> with git may be interested.  I'm going through some real newbie pains
> here, and I don't think what I'm doing is all that advanced.
> 
> So, I've had a local git repository cloned from github (as per Andrew's
> instructions), made a branch, started hacking, all is well.  Now, I
> would like to update my master branch from SVN to get some of the recent
> changes others have been making.
> 
> Following the instructions in the FAQ,
> 
>  git svn rebase
> 
> actually results in a number of conflicts in files I didn't touch.  I
> shouldn't have to resolve this conflicts, right?  'git status' shows no
> local changes, nothing staged -- nothing that should conflict.
> 
> It turns out, if I do
> 
>   git pull
> 
> then,
> 
>   git svn rebase
> 
> all is well.
> 
> Any idea why?  Should I add that to the instructions in the FAQ?
> 
> Now, here's where I'm really stumped.  I finished my experimental
> branch, and I would like to commit it back to SVN.
> 
> This is what I did, with comments preceded by '#'
> 
> # Go back to the master branch
>> git checkout master
> # Merge in experimental
>> git merge experimental
> # Ok -- looks good: experimental new feature is integrated, there were
> no conflicts
> # However...
>> git svn dcommit
> Committing to
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
> ...
> Merge conflict during commit: File or directory
> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
> # 1) I didn't change that file, why should I care
> # 2) I don't know who to update it
>> git pull
> Already up-to-date.
>> git svn rebase
> First, rewinding head to replay your work on top of it...
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Applying: added some docs for linestyles and markers
> Applying: Remove trailing whitespace.
> Applying: figure/subplot and font_manager bugfixes
> Applying: added support for xlwt in exceltools
> Applying: fixed a typo in whats_new_98_4_legend.py
> Applying: fixed typo in Line2D.set_marker doc.
> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. error: patch failed:
> doc/users/whats_new.rst:10
> error: doc/users/whats_new.rst: patch does not apply
> Using index info to reconstruct a base tree...
> :14: trailing whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Falling back to patching base and 3-way merge...
> No changes -- Patch already applied.
> Applying: added some docs for linestyles and markers
> error: patch failed: doc/devel/coding_guide.rst:62
> error: doc/devel/coding_guide.rst: patch does not apply
> error: patch failed: doc/matplotlibrc:43
> error: doc/matplotlibrc: patch does not apply
> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
> error: patch failed: lib/matplotlib/lines.py:313
> error: lib/matplotlib/li

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Jordan Mantha]

On Thu, Dec 11, 2008 at 11:20 AM, Andrew Straw  wrote:
> Michael Droettboom wrote:
>> Darren Dale wrote:
>>
>>> Having worked with bzr and launchpad for a few months now, I wonder if
>>> we might consider such an approach in the future. I know there has
>>> been some experimentation with a git repository, is git supported on
>>> windows now?
>>>
>> I'm not sold that bzr/hg/git makes things simpler for this development
>> model.
> My thought is that matplotlib.sourceforge.net is a centralized website
> making centralized, official releases and other  centralized facilities.
> Thus, it seems to me that a centralized, official version control branch
> is an entirely reasonable thing to have. svn provides a
> least-common-denominator for this job, and I don't see the reasons to
> shift to bzr/hg/git as sufficiently strong to merit such a shift. In
> particular, the svn model is pretty darn simple, and therefore easy to
> interface with (whether you're a human or a computer program).

I just wanted to interject some things from the bzr side. Bzr can work
either in a distributed or centralized model which makes it sort of
handy for SVN people, though I don't personally see that as any good
motivation to completely convert the whole thing to bzr. At this point
in time as I've had a chance to work with several projects using SVN,
git, and bzr I agree with you that SVN is a good
least-common-denominator, especially if the project is already using
SVN.

> Of course, part of why I think this way is that git seems to be working
> pretty well for inter-operation with the official svn repository. My
> experimental repository, described at
> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git
> , is nicely allowing me to browse history locally, do git bisect,
> maintain my own branches, commit back to the svn repository when
> desired, and so on. I think there *may* be some impedance mis-matching
> if we tried to really map git branches on svnmerge branches, but right
> now that hasn't been an issue I've pursued.

bzr-svn is also fantastic, I use it all the time. I also wanted to
point out that Launchpad has a bzr mirror of matplotlib going so if
you want to play around with bzr you can try that. In the past bzr has
been very slow when branching but with the latest stable release I
got:

$ time bzr branch lp:matplotlib
Branched 4100 revision(s).

real2m9.893s

Which is pretty impressive considering you're getting the entire
history. Anyway, I'm not a bzr fanatic but I just wanted to point out
the above for completeness and in case anybody was interested.

-Jordan

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Andrew Straw]

Andrew Straw wrote:

I realize I may have ignored an important question.

> Michael Droettboom wrote:

>> Now I feel stuck.  How do I "undo" the merge from experimental to master?

To do that, I actually delete the master branch with "git branch -D
master" and then re-create a new one with "git checkout -b master
028a0df8" (where I've identified commit 028a0df8 as where I want the new
master to be).

Note that before deleting the master branch, it's probably wise to
create a branch, which will probably be deleted momentarily, as a
reference to this location in case you need to get back to it. Do so
with "git checkout -b tmp/old-master". When everything is done, use "git
branch -D tmp/old-master" to delete it.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Andrew Straw]

I have also developed some image-based unit tests to compare MPL output,
and I completely agree that getting something like this into MPL is a
very good idea. As Ted writes, the hard part is defining "close" for
images. Minor changes to, for example, agg pixel alignment, cause the
tests to fail when they have low tolerances. So, such tests are a bit
more interactive than plain old unit tests when something changes, but I
think that's worth the pain.

Prabhu Ramachandran has also done similar things for mayavi2 using VTK's
image comparison (see compare_image_with_saved_image in
https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtests/mayavi/common.py
).

I'm attaching the code I use to compare images as a starting point -- it
currently uses scipy to load the images, but this could surely be worked
around.

-Andrew

Drain, Theodore R wrote:
> John,
> 
> One thing that would help w/ a rapid delivery/response cycle would be
> more comprehensive tests.They would let other developers try out
> various ideas and see what breaks before you release it.
> 
>  
> 
> We’ve implemented an automated approach where we run an MPL script using
> Agg, save the output image and then compare it against a “good” image
> that someone looked at.  We use PIL to do the compare and if it’s close
> (that’s the hard part), then the test passes.  If it’s not, someone
> looks at the two images to see if the difference is benign.  Something
> similar to this could be done (if you’re not already) for the MPL
> examples to make sure that changes don’t cause plotting problems in
> other areas. 
> 
>  
> 
> Having this kind of system is also a great driver for people to expand
> it.  For example – we really care about unit processing support
> everywhere.  Every once in awhile, we find a change that someone submits
> that breaks unit support.  So once of the tasks we‘re going to work on
> next year is to build a set of automated test cases that try and hit
> every plot function with units which can then run on every release.  If
> there were a simple to use MPL standard test system like this, other
> people might contribute more tests as a way of insuring that the things
> they care about stay working through various changes.
> 
>  
> 
> It would also be nice to have a test system for unit testing of
> components.  A lot of the code that does different transformations,
> symbol and color mapping, etc etc could be unit tested without the need
> for actually drawing anything.  If there was a standard location, style,
> and system, people could slowly add to the tests over time.  You can
> also consider requiring some level of unit test for newly submitted code
> where ever it’s possible.
> 
>  
> 
> Just some thoughts…
> 
> Ted
> 
>  
> 
> *From:* John Hunter [mailto:jdh2...@gmail.com]
> *Sent:* Wednesday, December 10, 2008 8:10 PM
> *To:* Darren Dale
> *Cc:* matplotlib-devel@lists.sourceforge.net
> *Subject:* Re: [matplotlib-devel] requesting permission to remove traits
> and configobj
> 
>  
> 
>  
> 
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale  > wrote:
> 
> There has been a report at the bugtracker complaining that matplotlib is
> overwriting an existing installation of configobj. I had a look at the
> code and thought the bug report must be a mistake or windows specific,
> but I just saw similar behavior on my linux system.
> 
> 
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is
> not working like we expect it to.  And that is something that should be
> fixed if is broken.  If mpl is installing configobj or traits even if we
> are telling it not to via setup.cfg, then we have a problem.   This is
> worth knowing, since the last mpl release was broken vis-a-vis the
> default backend on win32, which *could* be explained by a broken setup.cfg.
> 
> I would like to simply remove configobj and traits from our
> repository. They are only used by the long-neglected experimental
> traited config package, which is only of interest to developers who
> can easily install them as external dependencies. Is it ok to remove
> them? If so, should it be done on all the branches?
> 
> How long are we going to continue to maintain the different
> branches? It was so much easier back when we only had to worry about
> the trunk...
> 
> 
> You can remove them from the trunk.  They should remain on the 0.91
> branch as is (with any known bugs fixed and merged) since that is the
> point of the branch (stability for those who cannot upgrade -- in
> principle someone might be depending on the traited config, in practice
> unlikely).  As for the 0.98 branch, it is slated for destruction so no
> worries.  I share your visceral reaction against branches, but my head
> is starting to override this bodily reaction, as I see the need for them
> in practice.  If we carefully document the best practi

Re: [matplotlib-devel] git questions

[Michael Droettboom]

Andrew Straw wrote:
> Andrew Straw wrote:
>
> I realize I may have ignored an important question.
>
>   
>> Michael Droettboom wrote:
>> 
>
>   
>>> Now I feel stuck.  How do I "undo" the merge from experimental to master?
>>>   
>
> To do that, I actually delete the master branch with "git branch -D
> master" and then re-create a new one with "git checkout -b master
> 028a0df8" (where I've identified commit 028a0df8 as where I want the new
> master to be).
>   
Thanks for the suggestion.  Because I "merged", rather than "rebased" 
from my development branch, changes from the branch are interleaved with 
changes from SVN, so it's not clear to me how to remove only the changes 
that were brought in from the merge.  But that might also be the root 
cause of the problem I'm having.  I tried going back to the first SVN 
change prior to anything on my branch, the "git svn rebase", but that 
didn't solve the issue -- it still requires me to merge changes I know 
nothing about.  I think I'll follow your suggestion of "rebasing" 
development branches -- I can see how that's superior to "merge" anyway, 
since it will hide all my work/mistakes from the central SVN repository.

I'm going to declare bankruptcy at re-clone the whole repository and see 
if things work better.  Wish I understood how I painted myself in this 
corner in the first place, but maybe I'll notice it next time around.

Mike

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[Charlie Moad]

0.98.5 source and bins are posted.  Please try them out.  John can
announce at his convenience.

- Charlie

On Thu, Dec 11, 2008 at 12:15 PM, John Hunter  wrote:
> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom  wrote:
>
>>> And I'll try and get the maintenance branch right next time :-)
>>
>> All of the above sounds good to me.
>
> I will be traveling to my conference starting at noon, so will be in
> sporadic, light email contact for the next few days.  Charlie will
> look at fixing the builds tonight -- everyone else, please do what you
> can if something comes up because I would love to have a good set of
> binaries on line by the time my talk starts at noon tomorrow:
>
>  http://mloss.org/workshop/nips08/
>
> JDH
>

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[John Hunter]

Michael,

Will you create the branch and set up the svn merge properties?

Thanks Charlie,
JDH

Sent from my iPhone

On Dec 11, 2008, at 7:35 PM, "Charlie Moad"  wrote:

> 0.98.5 source and bins are posted.  Please try them out.  John can
> announce at his convenience.
>
> - Charlie
>
> On Thu, Dec 11, 2008 at 12:15 PM, John Hunter   
> wrote:
>> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom  
>>  wrote:
>>
 And I'll try and get the maintenance branch right next time :-)
>>>
>>> All of the above sounds good to me.
>>
>> I will be traveling to my conference starting at noon, so will be in
>> sporadic, light email contact for the next few days.  Charlie will
>> look at fixing the builds tonight -- everyone else, please do what  
>> you
>> can if something comes up because I would love to have a good set of
>> binaries on line by the time my talk starts at noon tomorrow:
>>
>> http://mloss.org/workshop/nips08/
>>
>> JDH
>>

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Loss of filled vs. stroked distinction by Collections

[Eric Bruning]

I think of artists as having visual properties that persist (e.g.,
filled vs. outlined, a colormap with min and max values) even as data
associated with the artist is changed. In the edge case described
below, this doesn't seem to hold true.

I have code that animates a scatter plot by sub-selecting the data
stored in a collection artist. In cases where some frames contain no
data, the scatter artist's data is temporarily empty. On subsequent
frames (once there is data again) some of the visual properties my
filled point becomes an outlined point, as in the code below.

# Filled single point with no outline
sc = scatter([1],[1],c=[1], edgecolors='none')

# Cache the data
xy=sc.get_offsets()
s=sc.get_array()

sel=s<0
sc.set_offsets(xy[sel,:])
sc.set_array(s[sel])

# No data, so nothing shown. No problem.
sc.figure.canvas.draw()

# Now restore the original data
sc.set_offsets(xy)
sc.set_array(s)

# Outlined single point with no fill
sc.figure.canvas.draw()
sc.get_edgecolors()
sc.get_facecolors()
sc.get_array()

The fix probably has to do with Collection.update_scalarmappable.
When set_array([ ]) happens,
len(self._facecolors) > 0, therefore
self._facecolors = to_rgba([  ]),
When set_array([1]) restores data,
len(self._facecolors) == 0, therefore
self._edgecolors = self.to_rgba([1])

Should is_filled vs. is_stroked be preserved in this case? If so, is
there a more elegant fix than to add is_filled and is_stroked
properties that are checked by update_scalarmappable?

Thanks,
Eric

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Gael Varoquaux]

On Thu, Dec 11, 2008 at 01:37:01PM -0800, Andrew Straw wrote:
> Prabhu Ramachandran has also done similar things for mayavi2 using VTK's
> image comparison (see compare_image_with_saved_image in
> https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtests/mayavi/common.py
> ).

Yeah, and it always fails due to the hardware rendering being slightly
different on different computers :). I think we are giving up on this
approach.

Gaël

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[Nils Wagner]

On Thu, 11 Dec 2008 10:33:20 -0800
  Andrew Straw  wrote:
> Hi Nils. I think I fixed the issue causing the traceback 
>with r6563. Can
> you please update and try again with text.usetex 
>enabled?
> 
> My guess is that you don't have dvipng installed, which 
>was causing the
> detection check to throw a traceback rather than return 
>a value
> signifying undetected. So, enabling usetex should again 
>trigger the
> check, but hopefully this time it will fail gracefully 
>rather than crashing.
> 
> -Andrew
  
Hi Andrew,

Thank you very much !
Works for me.

>>> import matplotlib.mlab as mlab
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py:371:
 
UserWarning: matplotlibrc text.usetex can not be used with 
*Agg backend unless dvipng-1.5 or later is installed on 
your system
   warnings.warn( 'matplotlibrc text.usetex can not be 
used with *Agg '

Cheers,
 Nils

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel