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 wh
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 ch
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 woul
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:
>
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
>>
>&
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
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 "ungrou
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 collecte
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
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 ey
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 sca
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 matplotl
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
>
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 getti
plotlib 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,
Nor
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
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 pa
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
r 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 mad
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 genera
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-q
21 matches
Mail list logo
