[matplotlib-devel] SVN write access?
Hi there, would it be possible to get SVN write access for matplotlib (username "nnemec")? Currently, I have four open patches waiting for inclusion (see sourceforge "Patches", submitted by "nnemec") and nobody seems to have the time to put them into the SVN repo. This is particularly annoying since a number of changes were done to the same files in SVN, so I had to update the patches manually several times. I don't find the time to contribute code very often, but when I do so, I do invest some time and effort to produce high-quality code. Thanks, Norbert Nemec - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] marker color handling
Hi Eric, hi everybody, I just noticed that you, Eric, have committed r2799 to SVN which partly reverts my commit r2790. I understand that, obviously, the changes that I introduced are more controversial than I would have expected, so we should try to reach an agreement. Was your objection generally about my patch or just about some detail? I know that the patch might have broken a bit of compatibility, but since the old logic was inconsistent and hard to understand, I figured that a cleaner and simpler logic would justify a some possible break of compatibility. If you disagree with some change in principle, I would like to know your objection. If there simply was a bug introduced by the change, I appologize and hope I can fix it. In any case, I have to point out that the current state of the SVN code after the partial reversion of my commit is not self-consistent: My commit changed several files besides axes.py - only reverting this one file is bound to cause problems. Greetings, Norbert - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling
OK, I understand. I will try sort out the problem today or otherwise take back the whole patch. I had not seen the message in matplotlib-users because of the backlog of 400 messages that have kept piling up... Don't worry about additional confusion. Quickly reverting the patch was the best thing to do for the moment. Greetings, Norbert Eric Firing wrote: > Norbert, > > Your 2790 patch seems to have completely wiped out the handling of > marker colors in the simple case "N.plot(N.random.random(1000),'r.')", > as noted by Stefan Van der Walt in a message yesterday to the matplotlib > users list. I presume you are monitoring that list, and saw his message > and my reply in which I noted that I was reverting the changes to > axes.py. I looked at the changes to axes.py, and it appeared that you > had simply forgotten the marker color handling; otherwise, the changes > appeared to be code rearrangements, not API changes that would interact > with other files, so I thought that reverting that file alone would > work--that is, restore basic functionality to the svn version. My > original thought was to wait and let you fix it, and evidently I should > have, but I decided it would be better not to leave svn without the > marker color functionality in the interim, and I had no way of knowing > whether you would be able to get to it right away. In any case, I made > the change, verified that it did restore marker color handling, > committed it to svn, and left it at that. > > Of course I was too hasty, and neglected to look at the patch as a > whole; now I see that you were trying to shift the setting of marker > colors out of axes.py and into lines.py. I still don't know why > Stefan's simple example was broken, and I don't have time now to > understand your patch properly, though I wish I did. I certainly don't > object to the idea of trying to make the code cleaner and easier to follow. > > So: please either restore your patch with additional changes to fix the > problem Stefan found, or revert all of it cleanly until this can be > sorted out. > > If you think there might be incompatibilities introduced by your patch, > then it would be good to know what they are. > > Sorry to have made the situation more confusing than necessary. > > Eric > > > > > Norbert Nemec wrote: > >> Hi Eric, hi everybody, >> >> I just noticed that you, Eric, have committed r2799 to SVN which partly >> reverts my commit r2790. >> >> I understand that, obviously, the changes that I introduced are more >> controversial than I would have expected, so we should try to reach an >> agreement. >> >> Was your objection generally about my patch or just about some detail? I >> know that the patch might have broken a bit of compatibility, but since >> the old logic was inconsistent and hard to understand, I figured that a >> cleaner and simpler logic would justify a some possible break of >> compatibility. >> >> If you disagree with some change in principle, I would like to know your >> objection. If there simply was a bug introduced by the change, I >> appologize and hope I can fix it. >> >> In any case, I have to point out that the current state of the SVN code >> after the partial reversion of my commit is not self-consistent: My >> commit changed several files besides axes.py - only reverting this one >> file is bound to cause problems. >> >> Greetings, >> Norbert >> > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling
OK, I found the problem and committed a temporary fix. The real problem, however is rooted a bit deeper. First an explanation of the intended change: It used to be that marker colors were partly automatic, but not completely. I.e. plot(x,y,'-or') would set both, line color and marker color to red. However plot(x,y,color='r') would set only the line color and leave marker color to the default. My change was to introduce a special value 'auto' for markeredgecolor and markerfacecolor. This special value would cause the marker color to always follow the line color. (Which is, in 99% of the cases, what you want.) Most of the special logic in axes.py could therefore go away. mfc and mec would simply be left at 'auto' unless explicitely assigned another color. The handling of the special value would then happen in lines.py at time of plotting. (including the effect that for filled markers, the edge would default to black) The problem in r2790: I changed the default value in matplotlibrc to 'auto' and everything worked fine for me. I forgot that, of course, anybody updating from an older version, would still have the values 'blue' and 'black' in their matplotlibrc, which would not be overridden by the '.r' option that Stefan used. The (temporary) solution in r2800: I deactivated the rcfile-configurability of markeredgecolor and markerfacecolor. Assuming that hardly anybody would want to change the 'auto' behavior in their rcfile, this should be a good solution until we have solved the core problem. The core problem: The matplotlibrc file distributed with matplotlib contains all the default values in non-commented lines. This file is usually copied to the home-directory of any user, making it impossible to simply change any default value in later versions. It is not possible to find out which values in the users matplotlibrc were set on purpose and which were just left untouched from the distributed file. The better solution: place '#' at the beginning of every line in matplotlibrc.template (except for 'backend' and 'numerix' which carry important information) Any user who explicitely wants to change a value, can simply uncomment the line and set a value. Otherwise, the default value from matplotlib/__init__.py will remain active, even if changed in an update. Of course, this would only make sense, if users were informed and encouraged to replace their personal matplotlibrc The ultimate solution: The file matplotlib.template should probably be dropped completely and be auto-created from the information in matplotlib/__init__.py - this would remove quite some redundancy and potential for inconsistencies. Comments on this? Greetings, Norbert John Hunter wrote: >> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> > > Eric> So: please either restore your patch with additional changes > Eric> to fix the problem Stefan found, or revert all of it cleanly > Eric> until this can be sorted out. > > Norbert -- can you describe briefly the inconsistencies in the format > arg color handling you were trying to address in your patch? I see > this -- > http://sourceforge.net/tracker/index.php?func=detail&aid=1504387&group_id=80706&atid=560722 > -- but not much detail about the problems the changes fix. > > Also, for all developers, when making API changes > > * post here with a brief descriptions of changes and rationale > > * make a note in API_CHANGES > > * run backend_driver.py. It is a good habit to not only run the > script to make sure no exceptions are raised, but also to view > the output PNG etc files in your favorite image viewer to make > sure the output is correct > > > Thanks! > JDH > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling
Eric Firing wrote:
> Norbert Nemec wrote:
>
>> OK, I found the problem and committed a temporary fix. The real problem,
>> however is rooted a bit deeper.
>>
>> First an explanation of the intended change:
>>
>> It used to be that marker colors were partly automatic, but not
>> completely. I.e.
>>
>> plot(x,y,'-or')
>>
>> would set both, line color and marker color to red. However
>>
>> plot(x,y,color='r')
>>
>> would set only the line color and leave marker color to the default.
>> My change was to introduce a special value 'auto' for markeredgecolor and
>> markerfacecolor. This special value would cause the marker color to
>> always follow
>> the line color. (Which is, in 99% of the cases, what you want.) Most of
>> the special logic in axes.py could therefore go away. mfc and mec would
>> simply be left at 'auto' unless explicitely assigned another color. The
>> handling of the special value would then happen in lines.py at time of
>> plotting. (including the effect that for filled markers, the edge would
>> default to black)
>>
>>
>
> In your explanation above, it is not clear what happens in each of the 4
> cases: mec auto or non-auto, and mfc auto or non-auto.
>
mec and mfc are handled independently.
markeredges are drawn using:
mec, if mec!='auto'
color, if mec=='auto' and marker not in filled_markers
black, if mec=='auto' and marker in filled_marker
markerfaces are drawn using:
mfc, if mfc!='auto'
color, if mfc=='auto'
Since non-filled markers are considered 'edges' without filling, this
logic is necessary to get the correct behavior.
> In looking at your original patch, I also wondered what is the reason
> for supporting 3 different ways of specifying "_draw_nothing"? (I had
> not previously noticed that there was any such thing at all, and I guess
> I don't understand what it is for.)
> class Line2D(Artist):
> _lineStyles = {
> '-': '_draw_solid',
> '--' : '_draw_dashed',
> '-.' : '_draw_dash_dot',
> ':': '_draw_dotted',
> 'steps': '_draw_steps',
> 'None' : '_draw_nothing',
> ' ': '_draw_nothing',
> '' : '_draw_nothing',
> }
>
The idea was to be able to say something like
plot(x,y,line='',marker='o',color=(.2,.5,.8))
which seemed a bit more intuitive to me than line='None' when I created
the patch. By now, I wonder about it myself...
If there is an objection against this detail, I can revert it. I
probably should have split the patch in parts in the first place.
Unfortunately, the different parts had become more interdependent than I
would have liked.
> I was also a little uncomfortable with pushing some of the color
> decision logic all the way down into the draw method, together with a
> default value, although maybe there is no better way to get the desired
> behavior:
>
> if self._marker is not None:
> gc = renderer.new_gc()
> if (is_string_like(self._markeredgecolor) and
> self._markeredgecolor == 'auto'):
> if self._marker in self.filled_markers:
> gc.set_foreground('k')
> else:
> gc.set_foreground(self._color)
> else:
> gc.set_foreground(self._markeredgecolor)
>
This was the cleanest solution. If the decision is made earlier, one
always has to store not only the value of mec, but also, whether it was
set explicitely or automatically. Otherwise, the marker color is not
updated when set_color is called on an existing graph. (Which was the
problem that started my whole effort)
>
>
>
>> The problem in r2790: I changed the default value in matplotlibrc to
>> 'auto' and everything worked fine for me. I forgot that, of course,
>> anybody updating from an older version, would still have the values
>> 'blue' and 'black' in their matplotlibrc, which would not be overridden
>> by the '.r' option that Stefan used.
>>
>
> This is not the first time matplotlibrc has bitten us, and it won't be
> the last...
>
> But *shouldn't* '.r' override a setting in matplotlibrc, regardless of
> what that setting is? I think it should have set the mfc, or preferably
> both the mfc and the mec.
&g
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
Eric Firing wrote: > Norbert, > >>> >>> The problem in r2790: I changed the default value in matplotlibrc to 'auto' and everything worked fine for me. I forgot that, of course, anybody updating from an older version, would still have the values 'blue' and 'black' in their matplotlibrc, which would not be overridden by the '.r' option that Stefan used. >>> This is not the first time matplotlibrc has bitten us, and it won't be >>> the last... >>> >>> But *shouldn't* '.r' override a setting in matplotlibrc, regardless of >>> what that setting is? I think it should have set the mfc, or preferably >>> both the mfc and the mec. >>> >>> >> OK, that would be an alternative solution: set both mfc and mec to >> 'auto', whenever the color is specified using a format string. However, >> this would mean that the rcfile options markeredgecolor and >> markerfacecolor are often ignored, even if they were set on purpose. If >> that is the case, one could just as well deactivate them completely and >> prevent some confusion. >> >> > > Either I am not understanding you correctly, or we have fundamentally > different views of the role of matplotlibrc values. The way I see it, > function args and kwargs *always* override matplotlibrc values, which in > turn *always* override built-in defaults. So in the example above, if > the user writes "plot(x,y,'r.')", red dots should be plotted no matter > what is in matplotlibrc. It should not depend on whether something is > set to 'auto'. > I fully agree with you. Guess, the simple solution to the dilemma is to drop the idea of rcfile-configurability of markerfacecolor and markeredgecolor. That way, markers would always have the same color as the line, unless explicitely set differently by the kwargs markeredgecolor/markerfacecolor. This is, what is wanted in 99% of the cases and for every other case, a rcfile-option will not help anyway. Greetings, Norbert - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib.template now mostly commented out
Hello everybody, after discussion with Eric Firing and John Hunter (see thread "marker color handling"), I just changed matplotlib.template on SVN: All the lines duplicating the default values already set in defaultParam (lib/matplotlib/__init__.py) are now commented out in matplotlibrc.template (and therefore also in matplotlib, which is usually copied to the users home directory). These values have always been redundant and frequently caused problems when updating to newer versions. Except for the options backend and numerix, which are both set by setup.py, the file matplotlib is therefore effectively empty. If a user explicitely wants to change a value, the line can simply be uncommented to become effective. Users of matplotlib are encouraged to use the new matplotlibrc as basis for their own configuration. Greetings, Norbert Nemec - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc generation
John Hunter wrote: >> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> > > Eric> 1) generate matplotlibrc with almost everything commented > Eric> out by default > > +2 > > Hopefully, this will address the problem of all the deprecated rc > warnings people are getting, which is confusing to new users. > As you saw, I boldly implemented that change already. > Eric> 2) eliminate matplotlibrc.template by having setup.py > Eric> autogenerate matplotlibrc based on the rcParams-related code > Eric> that is presently in __init__.py. > > working code tested across platforms and python versions settles this. > It is mostly working now, but Norbert brings up a good point that if > we now go to mostly empty rc files, it will become increasingly > unlikely that the template gets out of whack. If this is important to > someone and they can come up with a good implementation, I don't have > a problem with it. > I already started working on this. Don't know when I find the time to finish, but I will post patches for testing as soon as I have something clean enough. Greetings, Norbert - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
John Hunter wrote: >> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> > > >> This is, what is wanted in 99% of the cases and for every other > >> case, a rcfile-option will not help anyway. > > Eric> This sounds ideal to me--it makes everything simpler, both > Eric> in the code and in explaining what the behavior is. > > Hmm I can imagine that there are those who want the default > markeredgecolor to be the same color as the facecolor, and those who > want the default edgecolor to be black regardless of facecolor. I am > a bit hesitant to pull this functionality, though I agree that simpler > is better. > This functionality was never there, so nobody can miss it. Before my changes, the options in matplotlibrc only allowed to specify fixed colors for mfc and mec. This is now not possible any more, but can easily be done via kwargs. Automatic coloring was just as inflexible as it is now but less consistent. I thought about this kind of configurability, but any clean solution that I could find, would have become awfully complex. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
John Hunter wrote: >>>>>> "Norbert" == Norbert Nemec <[EMAIL PROTECTED]> writes: >>>>>> > Norbert> This functionality was never there, so nobody can miss > Norbert> it. Before my changes, the options in matplotlibrc only > Norbert> allowed to specify fixed colors for mfc and mec. This is > Norbert> now not possible any more, but can easily be done via > Norbert> kwargs. Automatic coloring was just as inflexible as it > Norbert> is now but less consistent. > > Yeah, I mispoke a bit. What I meant is that I prefer black edges, and > I expect > > plot(rand(10), 'go') > > to have a green face and black edges. There is no way in the new > infrastructure for this to happen by default as far as I can see, but > I can pass mec if I want. > Actually, this is the new default behavior: for filled markers, the mfc is set to the line color and the mec is set to black. For non-filled markers, mec is set to the line color and mfc is not used at all. What is impossible to set by default are alternative settings like * mec and mfc to line color * mec to line color and mfc to white > I can live with it, but I may not be the only one, so be prepared for > griping. Or we can consider something like Eric proposed where mec > can either follow mfc or be set to a fixed color, or something along > those lines. > > JDH > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Numeric support broken?
Thanks for clearing this up. Coding with three different numeric libraries in mind certainly is tricky... :-( Eric Firing wrote: > This is fixed now in SVN. The problem was that Numeric arrays lack a > "len" attribute, and "hasattr(xmin, 'len')" was being used to find out > whether xmin is a scalar or a length-2 array (xmin, xmax). The > solution is to do the test with "iterable(xmin)" instead. The bug was > introduced in 2782. > > Eric > > Edin Salkovic wrote: >> I'm posting this because of the other thread Darren started. >> >> I managed to reinstall python (and the modules I use) several days ago >> and tried again to run matplotlib with Numeric as the default backend, >> but got the same error (the same error Darren is getting). Then I >> installed numpy, and everything was fixed :) >> >> Best, >> Edin >> >> On 10/22/06, Edin Salkovic <[EMAIL PROTECTED]> wrote: >>> Unfortunately, I forgot to do it :( >>> >>> Then, just after sending the message to the list, it sprang to my >>> mind. To make it worse, I then mistakenly entered: >>> rm -Rf /path/to/site-packages >>> >>> no matplotlib at the end, and hit enter. >>> >>> There goes my beautiful Python install. :'( >>> >>> Is there some switch to setup.py to make it remove the mpl dir or does >>> one allways have to do it by hand? >>> >>> Cheers, >>> Edin >>> >>> On 10/22/06, Darren Dale <[EMAIL PROTECTED]> wrote: Did you try deleting your old mpl directory from site-packages, remove the build directory from you mpl sources, and rebuild from scratch? On Sunday 22 October 2006 6:59 am, Edin Salkovic wrote: > Hi, > > I built and installed the latest matplotlib from SVN. > > When I type: from pylab import * plot([1,2,3]) > I get: > > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line > 2027, in plot > ret = gca().plot(*args, **kwargs) > File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line > 2131, in plotself.autoscale_view(scalex=scalex, scaley=scaley) > File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line > 985, in autoscale_view > self.set_xlim(XL) > File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line > 1227, in set_xlim > self.viewLim.intervalx().set_bounds(xmin, xmax) > TypeError: only length-1 arrays can be converted to Python scalars. > > I'm using Numeric as numerix. I'm on a Ubuntu box with python 2.4. > > - > > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job > easier Download IBM WebSphere Application Server v.1.0.1 based on > Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> - >> >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@li
Re: [matplotlib-devel] defaults and matplotlibrc
Eric Firing schrieb: > Norbert, > > Your change in commenting out almost everything in matplotlibrc was a > good one, but I think it had an unintended consequence: it changed the > way everything looks because the defaults in __init__.py were not the > same as the ones in matplotlibrc. To my eye and on my machine the > matplotlibrc defaults are better, and my guess is that this is because > over a period of time people tuned the matplotlibrc values but left the > __init__.py values alone--after all, they were normally not used. In > any case, I went ahead and changed __init__.py to match matplotlibrc. > Thanks! I only did a spot check on some of the values and did not find any differences. I agree that the values in the old matplotlibrc are likely to be the more reasonable defaults. Furthermore, anybody who didn't think about the issue would probably have used these values anyway, so your changes should give the best backwards compatibility. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
Actually, I like the idea of unit support quite a bit and could well imagine that it makes sense to support it explicitely in matplotlib. I am using physical units very frequently in my computations. Lacking a robust units package, I simply define the units as numerical constants without checks but at least with comfortable conversion. If there were a good units package, support in matplotlib would mean that the axis labels could automatically be completed with appropriate units without need for explicit conversion. I agree, though, that the units package itself should not be part of matplotlib. But this is exactly how I understand the idea by John Hunter: describe an interface to allow the use of any third-party unit package. Of course, the whole thing only makes sense is there is a units package that is fit for production use. Darren Dale wrote: > > My first impression is similar to Eric's. I don't know if there is a robust > units package for python, but I imagine it should be a part of scipy. I think > it would be better to get an array and if you wanted to plot it in different > units, you call a method on the array at plot time. Maybe I dont understand > all the intended uses. > > Darren > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] make loc="best" the default in legend?
Hi there, the loc="best" mode seems to work fairly well now. Even if it may leave room for further optimization, I would assume that it is the more reasonable default than "upper right". I believe, however, that such simple API-changes should not happen one-by-one but that they should be collected and then be done all at once at some point. Greetings, Norbert - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with svg output !?
I stumbled over the same problem over and over again, as well. I think it is difficult to blame either inkscape or matplotlib. The SVG code is correct and Inkscape displays it correctly. The difficulty is that the SVG standard does not say anything about the correct *editing* behavior. The "ungroup" of inkscape seems to handle the definitions within the group that is ungrouped in such a way that the individual elements cannot access them correctly any more. I think the best fix would be in both, matplotlib and inkscape. matplotlib has no need to put the definitions inside the group and can simply avoid that, but still inkscape should cope with this kind of (legal!) SVG code in a better way. Manuel Metz wrote: > Hi, > > I have a problem with the svg output of matplotlib. I created a > scatter plot and saved it to svg. For the scatter plot I used two > kinds of symbols to mark different types of data. Afterwards I opened > the file using Inkscape to make some minor modifications. When opening > the file it looked fine (see Screenshot1.png). However, to do the > modifications I had to 'ungroup' the axis. After that one group of the > two markers disappeared from the plot (see Screenshot2.png). The data > is however not deleted, it's just invisible in Inkscape (but not in > Firefox ;-). > > I suspect it has to do with the clipPath definition, which is defined > for the regpolycollection4 (the green triangles, which are plotted > first) but not for the regploycollection5 (the blue dots, which are > plotted second). > > Is there any reason why a clipPath is defined for only one of the > Collections? I'm not sure whether this is a bug in matplotlib svg > output or Inkscape, but naively I would say that Inkscape behaves > correct here. > > Hope this can be fixed, > Manuel > > Uuuu, btw. I'm using matplotlib 0.90.1 > > > > > > > > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > > > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Checked in major reorganization of __init__.py
Hi there, I just checked in some major reorganization work in __init__.py The main intention was to move the list of option defaults to a separate file 'rcdefaults.py' that could be imported from setup.py to access the settings with minimal dependencies on the remaining code. To do so, I had to untangle a number of unnessessary dependancies within __init__.py. I hope, the behavior of the code should not have changed in the course of doing so. In case problems arise, please contact me directly, I don't know how closely I can follow the mailing list. I hope that from this starting point, future maintenance of the option settings will be somewhat easier. Greetings, Norbert - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Checked in major reorganization of __init__.py
Hmm - let me think We already have rc rcParams rc_params rcdefaults rcParamDefaults defaultParams in the main module of maplotlib How about calling the new module 'rcdefaultparams.py', simply to make the confusion complete and because I really feel that no other name would fit the current "naming scheme" better... ;-) Greetings, Norbert John Hunter wrote: > On 6/30/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: > >> Hi there, >> >> I just checked in some major reorganization work in __init__.py >> >> The main intention was to move the list of option defaults to a separate >> file 'rcdefaults.py' that could be imported from setup.py to access the >> settings with minimal dependencies on the remaining code. >> > > I haven't tested this but I did take a brief look at it and I think > your cleaning and organizing is useful. I think we have a naming > problem though -- this __init__ module defines an rcdefaults function, > which is likely to cause confusion with the new rcdefaults module. > Eg, > > >from matplotlib import rcdefaults > > will be ambiguous. You may want to consider a new name. > > DH > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Checked in major reorganization of __init__.py
I just tried to commit a rename of 'rcdefaults.py' to 'rcsetup.py', but I got an error: - ...$ svn commit -m"renamed rcdefaults.py to rccsetup.py to avoid conflict" Sendingmatplotlib/__init__.py Deleting matplotlib/rcdefaults.py Adding matplotlib/rcsetup.py svn: Commit failed (details follow): svn: COPY of rcsetup.py: 403 Forbidden (https://svn.sourceforge.net) - If anybody knows what the reason for this might be, please let me know... Greetings, Norbert Eric Firing wrote: > Norbert Nemec wrote: > >> Hmm - let me think We already have >> rc >> rcParams >> rc_params >> rcdefaults >> rcParamDefaults >> defaultParams >> in the main module of maplotlib >> >> How about calling the new module 'rcdefaultparams.py', simply to make >> the confusion complete and because I really feel that no other name >> would fit the current "naming scheme" better... ;-) >> > > Yes, it is confusing, there are too many similar names. I suspect some > are used infrequently enough that we could change them without too much > pain. > > But the new module is really two things: 1) rc utilities (mainly > validation facilities) and 2) a set of default values. If these are > kept together the module could be called "rc_init.py" because everything > is mainly used for rc initialization, although there are things still in > mpl's __init__.py that are also part of the rc initialization. Or it > could be called "rc_utils.py" or "rcsetup.py". I would prefer any of > these to rcdefaultparams.py. > > Furthermore, even after factoring out the rc things as you have done the > mpl namespace is badly cluttered with things like checkdep_dvipng, > (which is actually part of the rc validation, so maybe it should be in > your new module) so still more refactoring and/or renaming might be in > order. I can imagine a class being used to good effect to organize the > whole business of rc handling. > > One more miscellaneous thought: shouldn't mpl.rc() be using the > validation functions instead of simply stuffing inputs into rcParams? > > I suppose this brings us back to the old "traits, properties, or > neither" question. But incremental improvements such as the one you > have made are still helpful. > > Eric > >> Greetings, >> Norbert >> >> >> >> John Hunter wrote: >> >>> On 6/30/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Hi there, >>>> >>>> I just checked in some major reorganization work in __init__.py >>>> >>>> The main intention was to move the list of option defaults to a separate >>>> file 'rcdefaults.py' that could be imported from setup.py to access the >>>> settings with minimal dependencies on the remaining code. >>>> >>>> >>> I haven't tested this but I did take a brief look at it and I think >>> your cleaning and organizing is useful. I think we have a naming >>> problem though -- this __init__ module defines an rcdefaults function, >>> which is likely to cause confusion with the new rcdefaults module. >>> Eg, >>> >>> >from matplotlib import rcdefaults >>> >>> will be ambiguous. You may want to consider a new name. >>> >>> DH >>> >>> - >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> ___ >>> Matplotlib-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >>> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >
[matplotlib-devel] Apology
Hi everybody, I think I have to apologize, especially to Eric and John, for the confusion that I caused by the commits yesterday. The whole thing started as a bit of cleaning up and then I got carried away. I think there were two points that caused confusion. One is that the new revisions would have required anybody to dump build and installation directories, so a warning on the mailing list would certainly have been appropriate. The other point was that I did not consider those people who explicitely use numerix in their own code. I always thought of numerix as an internal compatibility layer of matplotlib not a wrapper that should be used outside. Guess, I was wrong there. I will sort through the reverted code. I believe, it would be best to revert only the first of my two commits, leaving the numerix directory in its original state, but leave the second commit in place (that one cuts nearly all internal dependencies on numerix, except those in pylab.py, mlab.py and those on ma/npyma which still have to be sorted out. I did not do a full numpification (changing to "from numpy import ..." to "import numpy as npy") but only those steps necessary to cut the dependency. So, once again: Sorry for the confusion. Greetings, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Numpification - next try
Hi there, I sorted out the reverted commits (sorry once again) and tried another commit. This time trying to think of everything that was said: * the numerix/ directory is unchanged * code in matplotlib is independent of numerix * code in matplotlib imports numpy as npy * everything is triple checked, running backend_drivers completely * no files are added or removed, so installation should not pose problems What remains to be done is sorting pylab and mlab. I think quite a bit of the code in there is redundant. Question is whether pylab should offer Numeric/numarray compatibility? Hope this new version does not cause any new problems... Greetings, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Hi Eric, thanks for the warning. I had looked into the issue but never got around to start working on it. While you are at it, I would suggest that you split the graphics stuff out of pylab into a separate module (pyplot?) to be used for "interactive plotting". I believe I'm not the only user who likes the stateful plotting functionality (i.e. based on gca(), gcf() etc.) but does not want to import all the matlab-compatibility numerics-functions along. Typically, I prefer the nice and clean numpy stuff to do numerics. I would suggest to create an additional module (e.g. pyplot?) that only contains the stateful plotting routines and a module pylab that simply imports everything from pyplot and mlab. Greetings, Norbert Eric Firing wrote: > I have been gradually numpifying mlab.py; I hope this is not a > duplication of effort with someone else. I have not finished yet (and > have made no commits), and it may still take a while--there are a lot of > things to change, and I am trying to do some cleaning up and > rationalization, not just mechanical numpification. I will probably > commit a mlab1.py version so as to facilitate some extra testing before > making the switch. > > I am trying to simplify and shrink the mlab namespace, with the idea > that if a function exists in modern numpy it should simply be imported > >from there. > > Similarly, after dealing with mlab, I would like to simplify pylab. > Right now, we have a horrible tangle of namespaces in pylab. Cleaning > this up will potentially break user code; if a numpy function formerly > could be referenced with three different names and we knock that down to > one, code using the other two will not work. My guess is that in > practice the amount of breakage will be *very* small and easy for users > to deal with. > > Eric > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
