Re: [matplotlib-devel] memory leak: gtk.gdk.Pixbuf and gtk.gdk.GCX11 with gtkagg backend

[Michael Droettboom]

Agreed.  I'm not sure how this bug could be resolved only on the 
matplotlib side.  See if you can make a standalone (pygtk-only) example 
that demonstrates this bug and send it to their mailing list.  Also, if 
it's possible, try updating pygtk.  There was a very similar bug in an 
earlier version (sorry, I can't find the reference), that was resolved.

Cheers,
Mike

Eric Firing wrote:
> Mátyás János wrote:
>   
>> Hi,
>>
>> I'm looking for memory leaks in a python application and found leaks in
>> matplotlib. The application is graphic intensive. Each time it updates
>> the screen, matplotlib allocates another 5-10 megabytes memory for the
>> new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does not free up the buffers
>> allocated for the previous content.
>>
>> 
>
> This sounds to me like a pygtk bug, not a matplotlib bug; a gtk object 
> is hanging around after its reference has been deleted. What versions of 
> gtk and pygtk are you using?  This sounds dimly familiar.  I don't know 
> enough about gtk and pygtk to help, but I am sure the people who do know 
> more will want to know the version.
>
> Eric
>
>   
>> I switched on garbage collection debugging with:
>>
>> import gc
>> gc.enable()
>> gc.set_debug(gc.DEBUG_LEAK)
>>
>> and tried to delete the leaking objects:
>>
>> --- ./lib/matplotlib/backends/backend_gtkagg.py 2008-06-23
>> 04:09:29.0 +0200 ++
>> + 
>> /usr/lib/python2.4/site-packages/matplotlib-0.91.4-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py
>> 2008-10-02 00:05:32.0 +0200 @@ -3,6 +3,7 @@ """
>>  from __future__ import division
>>  import os
>> +import gc
>>
>>  import matplotlib
>>  from matplotlib.figure import Figure
>> @@ -82,8 +83,17 @@
>>  h = int(ren.height)
>>  pixbuf = gtk.gdk.pixbuf_new_from_data(
>>  buf, gtk.gdk.COLORSPACE_RGB,  True, 8, w, h, w*4)
>> -pixmap.draw_pixbuf(pixmap.new_gc(), pixbuf, 0, 0, 0, 0, w, h,
>> +   g = pixmap.new_gc()
>> +pixmap.draw_pixbuf(g, pixbuf, 0, 0, 0, 0, w, h,
>> gtk.gdk.RGB_DITHER_NONE, 0, 0)
>> +
>> +   print "XX", pixbuf,
>> g,pixbuf.__grefcount__,g.__grefcount__
>> +   print gc.get_referrers(pixbuf)
>> +   print gc.get_referrers(g)
>> +   del pixbuf
>> +   del g
>> +   gc.collect()
>> +
>>  if DEBUG: print 'FigureCanvasGTKAgg.render_figure done'
>>
>>  def blit(self, bbox=None):
>>
>>
>> The __grefcount__ values are 1 but the memory is not freed up even after
>> gc.collect().
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
>
> -----
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Python 2.6

[Michael Droettboom]

matplotlib SVN trunk appears to be running backend_driver.py fine under 
Python-2.6 with Numpy SVN and TkAgg backend.

I had to make a handful of changes to remove deprecation warnings, none 
of which changes our "still supporting Python 2.4" policy.  One change 
was required to pytz, which I've communicated upstream to its author.

In case anyone is wondering, there don't seem to be any measurable 
performance increases... :(

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Axes.add_line() is oddly slow?

[Michael Droettboom]

According to lsprofcalltree, the slowness appears to be entirely in the 
units code by a wide margin -- which is unfortunately code I understand 
very little about.  The difference in timing before and after adding the 
line to the axes appears to be because the unit conversion is not 
invalidated until the line has been added to an axes.


In units.get_converter(), it iterates through every *value* in the data 
to see if any of them require unit conversion, and returns the first one 
it finds.  It seems like if we're passing in a numpy array of numbers 
(i.e. not array of objects), then we're pretty much guaranteed from the 
get-go not to find a single value that requires unit conversion so we 
might as well not look.  Am I making the wrong assumption?


However, for lists, it also seems that, since the code returns the first 
converter it finds, maybe it could just look at the first element of the 
sequence, rather than the entire sequence.  It the first is not in the 
same unit as everything else, then the result will be broken anyway.  
For example, if I hack evans_test.py to contain a single int amongst the 
list of "Foo" objects in the data, I get an exception anyway, even as 
the code stands now.


I have attached a patch against unit.py to speed up the first case 
(passing Numpy arrays).  I think I need more feedback from the units 
experts whether my suggestion for lists (to only look at the first 
element) is reasonable.


Feel free to commit the patch if it seems reasonable to those who know 
more about units than I do.


Mike

Eric Firing wrote:
I am getting very inconsistent timings when looking into plotting a line 
with a very large number of points.  Axes.add_line() is very slow, and 
the time is taken by Axes._update_line_limits().  But when I simply run 
the latter, on a Line2D of the same dimensions, it can be fast.


import matplotlib
matplotlib.use('template')
import numpy as np
import matplotlib.lines as mlines
import matplotlib.pyplot as plt
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
from time import time
t = time(); ax.add_line(LL); time()-t
###16.621543884277344
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax.add_line(LL); time()-t
###16.579419136047363
## We added two identical lines, each took 16 seconds.

LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.1733548641204834
## But when we made another identical line, updating the limits was
## fast.

# Below are similar experiments:
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.18362092971801758

## with a fresh axes:
plt.clf()
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.22244811058044434

t = time(); ax.add_line(LL); time()-t
###16.724560976028442

What is going on?  I used print statements inside add_line() to verify 
that all the time is in _update_line_limits(), which runs one or two 
orders of magnitude slower when run inside of add_line than when run 
outside--even if I run the preceding parts of add_line first.


Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  


--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Index: lib/matplotlib/units.py
===
--- lib/matplotlib/units.py (revision 6142)
+++ lib/matplotlib/units.py (working copy)
@@ -44,6 +44,7 @@

 """
 from matplotlib.cbook import iterable, is_numlike
+import numpy as np

 class AxisInfo:
 'information to support default axis labeling and tick labeling'
@@ -127,6 +128,9 @@
 converter = self.get(classx)

 if converter is None and iterable(x):
+if isinstance(x, np.ndarray) and x.dtype != np.object:
+return None
+
 for thisx in x:
 converter = self.get_converter( thisx )
 if converter: break
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an O

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6166] trunk/matplotlib/lib/matplotlib/units.py

[Michael Droettboom]

This isn't quite what I was suggesting (and seems to be equivalent to 
the code as before).  In the common case where there are no units in the 
data, this will still traverse the entire list.

I think replacing the whole loop with:

  converter = self.get_converter(iter(x).next())

would be even better.  (Since lists of data should not be heterogeneous 
anyway...)

Mike

[EMAIL PROTECTED] wrote:
> Revision: 6166
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6166&view=rev
> Author:   jdh2358
> Date: 2008-10-07 15:13:53 + (Tue, 07 Oct 2008)
>
> Log Message:
> ---
> added michaels unit detection optimization for arrays
>
> Modified Paths:
> --
> trunk/matplotlib/lib/matplotlib/units.py
>
> Modified: trunk/matplotlib/lib/matplotlib/units.py
> ===
> --- trunk/matplotlib/lib/matplotlib/units.py  2008-10-07 15:13:13 UTC (rev 
> 6165)
> +++ trunk/matplotlib/lib/matplotlib/units.py  2008-10-07 15:13:53 UTC (rev 
> 6166)
> @@ -135,7 +135,7 @@
>  
>  for thisx in x:
>  converter = self.get_converter( thisx )
> -if converter: break
> +return converter
>  
>  #DISABLED self._cached[idx] = converter
>  return converter
>
>
> This was sent by the SourceForge.net collaborative development platform, the 
> world's largest Open Source development site.
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______
> Matplotlib-checkins mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

Eric Firing wrote:
> Mike, John,
>
> Because path simplification does not work with anything but a 
> continuous line, it is turned off if there are any nans in the path.  
> The result is that if one does this:
>
> import numpy as np
> xx = np.arange(20)
> yy = np.random.rand(20)
> #plot(xx, yy)
> yy[1000] = np.nan
> plot(xx, yy)
>
> the plot fails with an incomplete rendering and general 
> unresponsiveness; apparently some mysterious agg limit is quietly 
> exceeded.
The limit in question is "cell_block_limit" in 
agg_rasterizer_cells_aa.h.  The relationship between the number vertices 
and the number of rasterization cells I suspect depends on the nature of 
the values. 

However, if we want to increase the limit, each "cell_block" is 4096 
cells, each with 16 bytes, and currently it maxes out at 1024 cell 
blocks, for a total of 67,108,864 bytes.  So, the question is, how much 
memory should be devoted to rasterization, when the data set is large 
like this?  I think we could safely quadruple this number for a lot of 
modern machines, and this maximum won't affect people plotting smaller 
data sets, since the memory is dynamically allocated anyway.  It works 
for me, but I have 4GB RAM here at work.
> With or without the nan, this test case also shows the bizarre 
> slowness of add_line that I asked about in a message yesterday, and 
> that has me completely baffled.
lsprofcalltree is my friend!
>
> Both of these are major problems for real-world use.
>
> Do you have any thoughts on timing and strategy for solving this 
> problem?  A few weeks ago, when the problem with nans and path 
> simplification turned up, I tried to figure out what was going on and 
> how to fix it, but I did not get very far.  I could try again, but as 
> you know I don't get along well with C++.
That simplification code is pretty hairy, particularly because it tries 
to avoid a copy by doing everything in an iterator/generator way.  I 
think even just supporting MOVETOs there would be tricky, but probably 
the easiest first thing.
>
> I am also wondering whether more than straightforward path 
> simplification with nan/moveto might be needed.  Suppose there is a 
> nightmarish time series with every third point being bad, so it is 
> essentially a sequence of 2-point line segments.  The simplest form of 
> path simplification fix might be to reset the calculation whenever a 
> moveto is encountered, but this would yield no simplification in this 
> case.  I assume Agg would still choke. Is there a need for some sort 
> of automatic chunking of the rendering operation in addition to path 
> simplification?
>
Chunking is probably something worth looking into (for lines, at least), 
as it might also reduce memory usage vs. the "increase the 
cell_block_limit" scenario.

I also think for the special case of high-resolution time series data, 
where x if uniform, there is an opportunity to do something completely 
different that should be far faster.  Audio editors (such as Audacity), 
draw each column of pixels based on the min/max and/or mean and/or RMS 
of the values within that column.  This makes the rendering extremely 
fast and simple.  See:

http://audacity.sourceforge.net/about/images/audacity-macosx.png

Of course, that would mean writing a bunch of new code, but it shouldn't 
be incredibly tricky new code.  It could convert the time series data to 
an image and plot that, or to a filled polygon whose vertices are 
downsampled from the original data.  The latter may be nicer for Ps/Pdf 
output.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6166] trunk/matplotlib/lib/matplotlib/units.py

[Michael Droettboom]

Sorry.  I didn't read carefully enough.  That's right -- the "if 
converter: break" was replaced with "return converter".

You're right.  This is fine.

Mike

John Hunter wrote:
> On Tue, Oct 7, 2008 at 11:26 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> This isn't quite what I was suggesting (and seems to be equivalent to
>> the code as before).  In the common case where there are no units in the
>> data, this will still traverse the entire list.
>>
>> I think replacing the whole loop with:
>>
>>  converter = self.get_converter(iter(x).next())
>>
>> would be even better.  (Since lists of data should not be heterogeneous
>> anyway...)
>> 
>
> Hmm, I don't see how it would traverse the entire list
>
> for thisx in x:
> converter = self.get_converter( thisx )
> return converter
>
> since it will return after the first element in the loop.  I have no
> problem with the iter approach, but am not seeing what the problem is
> with this usage.
>
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>> Eric Firing wrote:
>>> Mike, John,
>>>
>>> Because path simplification does not work with anything but a 
>>> continuous line, it is turned off if there are any nans in the 
>>> path.  The result is that if one does this:
>>>
>>> import numpy as np
>>> xx = np.arange(20)
>>> yy = np.random.rand(20)
>>> #plot(xx, yy)
>>> yy[1000] = np.nan
>>> plot(xx, yy)
>>>
>>> the plot fails with an incomplete rendering and general 
>>> unresponsiveness; apparently some mysterious agg limit is quietly 
>>> exceeded.
>> The limit in question is "cell_block_limit" in 
>> agg_rasterizer_cells_aa.h.  The relationship between the number 
>> vertices and the number of rasterization cells I suspect depends on 
>> the nature of the values.
>> However, if we want to increase the limit, each "cell_block" is 4096 
>> cells, each with 16 bytes, and currently it maxes out at 1024 cell 
>> blocks, for a total of 67,108,864 bytes.  So, the question is, how 
>> much memory should be devoted to rasterization, when the data set is 
>> large like this?  I think we could safely quadruple this number for a 
>> lot of modern machines, and this maximum won't affect people plotting 
>> smaller data sets, since the memory is dynamically allocated anyway.  
>> It works for me, but I have 4GB RAM here at work.
>
> It sounds like we have little to lose by increasing the limit as you 
> suggest here.  In addition, it would be nice if hitting that limit 
> triggered an informative exception instead of a puzzling and quiet 
> failure, but maybe that would be hard to arrange.  I have no idea how 
> to approach it.
Agreed.  But also, I'm not sure how to do that. I can see where the 
limit is tested and no more memory is allocated, but not where it shuts 
down drawing after that.  If we can find that point, we should be able 
to throw an exception back to Python somehow.
>
>>> With or without the nan, this test case also shows the bizarre 
>>> slowness of add_line that I asked about in a message yesterday, and 
>>> that has me completely baffled.
>> lsprofcalltree is my friend!
>
> Thank you very much for finding that!
>
>>>
>>> Both of these are major problems for real-world use.
>>>
>>> Do you have any thoughts on timing and strategy for solving this 
>>> problem?  A few weeks ago, when the problem with nans and path 
>>> simplification turned up, I tried to figure out what was going on 
>>> and how to fix it, but I did not get very far.  I could try again, 
>>> but as you know I don't get along well with C++.
>> That simplification code is pretty hairy, particularly because it 
>> tries to avoid a copy by doing everything in an iterator/generator 
>> way.  I think even just supporting MOVETOs there would be tricky, but 
>> probably the easiest first thing.
>
> The attached patch seems to work, based on cursory testing.  I can 
> make an array of 1M points, salt it with nans, and plot it, complete 
> with gaps, and all in a reasonably snappy fashion, thanks to your 
> units fix.
Very nice!  It looks like a nice approach --- though I see from your 
second message that things aren't quite perfect yet.  I, too, feel it's 
close, though.

One possible minor improvement might be to change the "should_simplify" 
expression to be true if codes is not None and contains only LINETO and 
MOVETOs (but not curves, obviously).  I don't imagine a lot of people 
are building up their own paths with MOVETOs in them, but your 
improvement would at least make simplifying those possible.

Mike
>
> Eric
>
>>>
>>> I am also wondering whether more than straightforward path 
>>> simplification with nan/moveto might be needed.  Suppose there is a 
>>> nightmarish time series with every third point being bad, so it is 
>>> essentially a sequence of 2-point line segments.  The simplest form 
>>> of path simplification fix might be to reset the calculation 
>>> whenever a moveto is encountered, but this would yield no 
>>> simplification in this case.  I assume Agg would still choke. Is 
>>> there a need for some sort of automatic chunking of the rendering 
>>> operation in addition to path simplification?
>>>
>> Chunking is probably something worth looking into (for lines, at 
>> least), as it might also reduce memory usage vs. the "increase the 
>> cell_block_limit" scenario.
>>
>> I also think for the special case of hi

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

Michael Droettboom wrote:
> Eric Firing wrote:
>   
>> Michael Droettboom wrote:
>> 
>>> Eric Firing wrote:
>>>   
>>>> Mike, John,
>>>>
>>>> Because path simplification does not work with anything but a 
>>>> continuous line, it is turned off if there are any nans in the 
>>>> path.  The result is that if one does this:
>>>>
>>>> import numpy as np
>>>> xx = np.arange(20)
>>>> yy = np.random.rand(20)
>>>> #plot(xx, yy)
>>>> yy[1000] = np.nan
>>>> plot(xx, yy)
>>>>
>>>> the plot fails with an incomplete rendering and general 
>>>> unresponsiveness; apparently some mysterious agg limit is quietly 
>>>> exceeded.
>>>> 
>>> The limit in question is "cell_block_limit" in 
>>> agg_rasterizer_cells_aa.h.  The relationship between the number 
>>> vertices and the number of rasterization cells I suspect depends on 
>>> the nature of the values.
>>> However, if we want to increase the limit, each "cell_block" is 4096 
>>> cells, each with 16 bytes, and currently it maxes out at 1024 cell 
>>> blocks, for a total of 67,108,864 bytes.  So, the question is, how 
>>> much memory should be devoted to rasterization, when the data set is 
>>> large like this?  I think we could safely quadruple this number for a 
>>> lot of modern machines, and this maximum won't affect people plotting 
>>> smaller data sets, since the memory is dynamically allocated anyway.  
>>> It works for me, but I have 4GB RAM here at work.
>>>   
>> It sounds like we have little to lose by increasing the limit as you 
>> suggest here.  In addition, it would be nice if hitting that limit 
>> triggered an informative exception instead of a puzzling and quiet 
>> failure, but maybe that would be hard to arrange.  I have no idea how 
>> to approach it.
>> 
> Agreed.  But also, I'm not sure how to do that. I can see where the 
> limit is tested and no more memory is allocated, but not where it shuts 
> down drawing after that.  If we can find that point, we should be able 
> to throw an exception back to Python somehow.
I figured this out.  When this happens, a RuntimeError("Agg rendering 
complexity exceeded") is thrown.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

John Hunter wrote:
> On Wed, Oct 8, 2008 at 11:37 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>   
>> I figured this out.  When this happens, a RuntimeError("Agg rendering
>> complexity exceeded") is thrown.
>> 
>
> Do you think it is a good idea to put a little helper note in the
> exception along the lines of
>
>   throw "Agg rendering complexity exceeded; you may want to increase
> the cell_block_size in agg_rasterizer_cells_aa.h"
>
> in case someone gets this exception two years from now and none of us
> can remember this brilliant fix :-)
>   
We can suggest that, or suggest that the size of the data is too large 
(which is easier for most users to fix, I would suspect).  What about:

"Agg rendering complexity exceeded.  Consider downsampling or decimating 
your data."

along with a comment (not thrown), saying

/* If this is thrown too often, increase cell_block_limit. */

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

Michael Droettboom wrote:
> John Hunter wrote:
>   
>> In unrelated news, I am not in favor of the recent change to warn on
>> non-GUI backends when "show" is called.  I realize this may sometimes
>> cause head-scratching behavior for some users who call show and no
>> figure pops up, but I think this must be pretty rare.  99% of users
>> have a matplotlibrc which defines a GUI default.  AFAIK, the only
>> exceptions to this are 1) when the user has changed the rc (power
>> user, needs no protection) or 2) no GUI was available at build time
>> and the image backend was the default backend chosen (warning more
>> appropriate at build time).  If I am missing a use case, let me know.
>>   
>> 
> The motivation was when a popular Linux distribution misconfigured the 
> default to the Agg backend:
>
> https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764
>
> This warning was meant as future insurance against this happening -- and 
> hoping that if the packagers don't make a GUI backend the default (in an 
> attempt to reduce dependencies), that they at least would include the 
> warning patch so that users aren't left feeling that matplotlib is "broken".
>
> But we can't prevent all downstream packaging errors, so maybe this 
> patch doesn't belong in trunk. ;)
>   
>> I like the design where the same script can be used to either generate
>> a UI figure or hardcopy depending on an rc settng or a command flag
>> (eg backend driver) and would rather not do the warning.  This has
>> been a very infrequent problem for users over the years (a few times
>> at most?) so I am not sure that the annoyance of the warning is
>> justified.
>>   
>> 
> Perhaps the warning could only be emitted when running inside an 
> interactive console (ipython or standard python) -- if that's possible.  
> Alternatively, "ipython -pylab" could warn on startup if the backend is 
> non-GUI (and that change would probably live in ipython).
I have modified the code to only do this when show() is called directly 
from the python or ipython console.  Calling show() from a script will 
not emit this warning.

If that's still too noisy, I'm happy to revert the whole thing.

Mike

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Michael Droettboom]

John Hunter wrote:
> On Wed, Oct 8, 2008 at 8:40 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>   
>> Thanks for doing this--it has already helped me in my testing of the
>> gappy-path simplification support, which I have now committed.  As you
>> suggested earlier, I included in path.py a check for a compatible codes
>> array.
>>
>> The agg limit still can be a problem.  It looks like chunking could be added
>> easily by making the backend_agg draw_path a python method calling the
>> renderer method; if the path length exceeds some threshold, then subpaths
>> would be generated and passed to the renderer method.
>> 
>
> In unrelated news, I am not in favor of the recent change to warn on
> non-GUI backends when "show" is called.  I realize this may sometimes
> cause head-scratching behavior for some users who call show and no
> figure pops up, but I think this must be pretty rare.  99% of users
> have a matplotlibrc which defines a GUI default.  AFAIK, the only
> exceptions to this are 1) when the user has changed the rc (power
> user, needs no protection) or 2) no GUI was available at build time
> and the image backend was the default backend chosen (warning more
> appropriate at build time).  If I am missing a use case, let me know.
>   
The motivation was when a popular Linux distribution misconfigured the 
default to the Agg backend:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764

This warning was meant as future insurance against this happening -- and 
hoping that if the packagers don't make a GUI backend the default (in an 
attempt to reduce dependencies), that they at least would include the 
warning patch so that users aren't left feeling that matplotlib is "broken".

But we can't prevent all downstream packaging errors, so maybe this 
patch doesn't belong in trunk. ;)
> I like the design where the same script can be used to either generate
> a UI figure or hardcopy depending on an rc settng or a command flag
> (eg backend driver) and would rather not do the warning.  This has
> been a very infrequent problem for users over the years (a few times
> at most?) so I am not sure that the annoyance of the warning is
> justified.
>   
Perhaps the warning could only be emitted when running inside an 
interactive console (ipython or standard python) -- if that's possible.  
Alternatively, "ipython -pylab" could warn on startup if the backend is 
non-GUI (and that change would probably live in ipython).
> If  2) in the choices above is the case you are concerned about, and
> you want this warning feature in this case, we can add an rc param
> which is autoset at build time, something like "show.warn =
> True|False" since the build script is setting the default image
> backend and can set "show.warn = True" when it sets an image backend
> by default, otherwise False.
>   
I intended the warning to warn against misconfiguration, so one 
shouldn't have to explicitly configure anything to get it... ;)

Mike

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] can't commit

[Michael Droettboom]

Yep... just sent a message before seeing this one.  The few possible 
causes I could find through Google didn't seem relevant.

Feel free to pile on to this bug report -->

https://sourceforge.net/tracker/?func=detail&atid=21&aid=2168647&group_id=1

Mike

John Hunter wrote:
> I am getting this error on a couple of machines when I try to commit
>
> [EMAIL PROTECTED]:mpl> svn commit -m 'some more doc mods'
> svn: Commit failed (details follow):
> svn: MKACTIVITY of
> '/svnroot/matplotlib/!svn/act/5726e9f3-f4eb-cc5e-bc97-ffd78106e3fc':
> 403 Forbidden (https://matplotlib.svn.sourceforge.net)
>
> Anyone else seeing this and does anyone have any idea what is wrong?
>
> Thanks,
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] svn commit broken?

[Michael Droettboom]

I'm getting this when trying to commit to SVN this morning:

> svn: Commit failed (details follow):
> svn: MKACTIVITY of 
> '/svnroot/matplotlib/!svn/act/6b28eb9b-4b59-0410-81bc-d80e6be37be8': 
> 403 Forbidden (https://matplotlib.svn.sf.net)
Googling suggests this occurs when the developer doesn't have write 
permissions (not the case here), or using http rather than https (also 
not the case).

Filed a bug here:

https://sourceforge.net/tracker/?func=detail&atid=21&aid=2168647&group_id=1

Anyone else experiencing this?

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] New doc update

[Michael Droettboom]

John Hunter wrote:
> On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> The new stylesheet for the docs looks great, John!
>> 
>
> I just ripped this off hook-line-and-sinker from the sphinx docs, and
> added the few css bits you created earlier.  They do look nice :-)
>
>   
>> One extremely minor nit: perhaps the logo is a too large in this
>> context.  On smaller screens, like a 1024x768 laptop, it encompasses
>> about a third of the usable browser window space.
>>
>> Would it be possible to keep it the current size for the main home page,
>> but use a smaller version for the documentation pages?  Or, to the
>> extreme, just use a small icon-sized logo like in the Python 2.6 docs?
>> 
>
> I'm happy to do use a smaller logo on the doc pages, but off hand do
> not know how to do it.  I am knee deep in trying to convert the
> existing docs, because as you probably gathered the sphinx docs will
> soon entirely replace the existing web pages entirely.  So if you
> could help with this logo change that would be great.  Either route
> (smaller logo or single icon) is fine by me.
>   
Sure.  I'll look into this.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] typo in matplotlibrc.template

[Michael Droettboom]

Thanks.  Fixed in SVN.

Benjamin Drung wrote:
> Hello,
>
> there is a typo in matplotlibrc.template. Appended the fix.
>
> Greeting,
> Benjamin
>   
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] New doc update

[Michael Droettboom]

The new stylesheet for the docs looks great, John!

One extremely minor nit: perhaps the logo is a too large in this 
context.  On smaller screens, like a 1024x768 laptop, it encompasses 
about a third of the usable browser window space.

Would it be possible to keep it the current size for the main home page, 
but use a smaller version for the documentation pages?  Or, to the 
extreme, just use a small icon-sized logo like in the Python 2.6 docs?

http://www.python.org/doc/current/library/

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] New doc update

[Michael Droettboom]

Nope, I'm not seeing this, even when I shrink the window width way down.

This is Firefox 2.0 on RHEL4.

Does putting a   between matplotlib and home help?

Mike

John Hunter wrote:
> On Wed, Oct 15, 2008 at 10:17 AM, Michael Droettboom <[EMAIL PROTECTED]> 
> wrote:
>
>   
>>> I'm happy to do use a smaller logo on the doc pages, but off hand do
>>> not know how to do it.  I am knee deep in trying to convert the
>>> existing docs, because as you probably gathered the sphinx docs will
>>> soon entirely replace the existing web pages entirely.  So if you
>>> could help with this logo change that would be great.  Either route
>>> (smaller logo or single icon) is fine by me.
>>>   
>
> I am having problems in that the "matplotlib home" text is getting
> wrapped with the new icon.  Screenshot attached.  Are you not seeing
> this?
>
> I may work on a thinner default logo, because I like having the
> consistency between pages
>
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] New doc update

[Michael Droettboom]

Weird.  Have to admit I don't understand this HTML stuff very well... ;)

John Hunter wrote:
> On Wed, Oct 15, 2008 at 2:22 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> Nope, I'm not seeing this, even when I shrink the window width way down.
>>
>> This is Firefox 2.0 on RHEL4.
>>
>> Does putting a   between matplotlib and home help?
>> 
>
> I tried this, and it put matplotlib and home together, but on the line
> below the icon.  I tried to make sure there were no spaces between the
> image and the start of the matplotlib word, but wasn't able to kill
> the newline
>
> firefox 2.0.0.14 on solaris x86
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] findfont not matching close weights

[Michael Droettboom]

This is a longstanding known issue -- the font finding algorithm is way 
too precise, and should instead do a nearest-neighbor search similar to 
fontconfig.  It's a non-trivial bit of code that no one has yet found 
time for.

If you're running matplotlib 0.98.x and are on a non-Windows platform, 
you can try the experimental fontconfig support by changing the 
"USE_FONTCONFIG" variable to "True" in font_manager.py.  (You'll need to 
install fontconfig on OS-X -- most recent Linux distributions should 
already have it.)

Cheers,
Mike

Stan West wrote:
> Greetings.  It seems that a "not" operator got dropped in rev. 6143 to
> font_manager.py.  I've attached a patch.
>
> The missing "not" tripped up findfont when trying to match font weights: the
> code
>
> fm = matplotlib.font_manager.FontManager()
> fm.findfont('New Century Schoolbook', fontext='afm')
>
> was yielding '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead of
> the expected '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', because
> fm.afmdict['New Century Schoolbook']['normal']['normal'] had only the
> weights 500 and 700, not the 400 called for by the implicit normal weight in
> the findfont call.
>   
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ----
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] findfont not matching close weights

[Michael Droettboom]

Stan West wrote:
> Thank you, Mike, for your reply.  My understanding of the intent of the code
> is that if the weight is not found in the font dict, setWeights is called to
> supplement the dict with the missing weights, and the weight is sought again
> in the supplemented dict.  That would seem to effect the desired approximate
> matching, albeit by precisely matching to an enlarged font dict.  However,
> Rev. 6143 replaced
>
> if not font.has_key(weight):
> setWeights(font)
>
> with
>
> if weight in font:
> setWeights(font)
>
> dropping the "not" and thereby supplementing the dict when the sought weight
> is already present.  Restoring the "not" would restore the approximate
> matching, no?
>   
You're right  That looks like a typo.  This is now fixed in SVN r6294.
> Thanks also for the fontconfig suggestion; I would be happy to try it,
> except that my platform is Windows.
>   
That's, unfortunately, why we can't just switch to using it.  fontconfig 
solves this problem in a much more robust way, and more importantly is 
maintained by others who know the pitfalls of fonts really well.  It is 
ported to Windows, but it is generally not there, so we would have to 
require or ship it.

Cheers,
Mike
> Stan
>
>   
>> -Original Message-
>> From: Michael Droettboom [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, October 22, 2008 10:11
>> To: Stan West
>> Cc: matplotlib-devel@lists.sourceforge.net
>> Subject: Re: [matplotlib-devel] findfont not matching close weights
>>
>> This is a longstanding known issue -- the font finding 
>> algorithm is way too precise, and should instead do a 
>> nearest-neighbor search similar to fontconfig.  It's a 
>> non-trivial bit of code that no one has yet found time for.
>>
>> If you're running matplotlib 0.98.x and are on a non-Windows 
>> platform, you can try the experimental fontconfig support by 
>> changing the "USE_FONTCONFIG" variable to "True" in 
>> font_manager.py.  (You'll need to install fontconfig on OS-X 
>> -- most recent Linux distributions should already have it.)
>>
>> Cheers,
>> Mike
>>
>> Stan West wrote:
>> 
>>> Greetings.  It seems that a "not" operator got dropped in 
>>>   
>> rev. 6143 to 
>> 
>>> font_manager.py.  I've attached a patch.
>>>
>>> The missing "not" tripped up findfont when trying to match font 
>>> weights: the code
>>>
>>> fm = matplotlib.font_manager.FontManager()
>>> fm.findfont('New Century Schoolbook', fontext='afm')
>>>
>>> was yielding 
>>>   
>> '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead 
>> 
>>> of the expected 
>>>   
>> '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', 
>> 
>>> because fm.afmdict['New Century 
>>>   
>> Schoolbook']['normal']['normal'] had 
>> 
>>> only the weights 500 and 700, not the 400 called for by the 
>>>   
>> implicit 
>> 
>>> normal weight in the findfont call.
>>>   
>>>
>>>   
>> --
>> 
>>> --
>>>
>>>
>>>   
>> --
>> 
>>> --- This SF.Net email is sponsored by the Moblin Your Move 
>>>   
>> Developer's 
>> 
>>> challenge Build the coolest Linux based applications with 
>>>   
>> Moblin SDK & 
>> 
>>> win great prizes Grand prize is a trip for two to an Open 
>>>   
>> Source event 
>> 
>>> anywhere in the world 
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>   
>> --
>> 
>>> --
>>>
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>   
>>>   
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>> 
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text

[Michael Droettboom]

Stan West wrote:
> While labeling axes with both standard and Unicode strings, I noticed some
> alignment problems in EPS output, as in the attached examples.  I traced it
> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
> latter was not accounting for any descenders in the glyphs.  I've attached a
> suggested patch which I believe brings the draw_unicode behavior into line
> with the draw_text behavior for both AFM and TrueType fonts.  The patch also
> removes extraneous indents in multi-line PostScript strings that were
> appearing in the EPS files.
>   
Thanks for the patch.  I'm sure that was just overlooked when Unicode 
support was added to the Ps backend.

This has been committed to SVN r6295.
> I also noticed a related issue in backend_pdf: For both standard and Unicode
> strings, the descender correction is computed, but the text is shifted
> vertically in the canvas coordinate system rather than in the glyph
> coordinate system.  Therefore, y axis labels are bumped up rather than left
> on the canvas.  I'm not able to work on a patch at this time.
I'll have a look at this.  Thanks for pointing it out.

Cheers,
Mike
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text

[Michael Droettboom]

Michael Droettboom wrote:
> Stan West wrote:
>   
>> While labeling axes with both standard and Unicode strings, I noticed some
>> alignment problems in EPS output, as in the attached examples.  I traced it
>> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
>> latter was not accounting for any descenders in the glyphs.  I've attached a
>> suggested patch which I believe brings the draw_unicode behavior into line
>> with the draw_text behavior for both AFM and TrueType fonts.  The patch also
>> removes extraneous indents in multi-line PostScript strings that were
>> appearing in the EPS files.
>>   
>> 
> Thanks for the patch.  I'm sure that was just overlooked when Unicode 
> support was added to the Ps backend.
>
> This has been committed to SVN r6295.
>   
>> I also noticed a related issue in backend_pdf: For both standard and Unicode
>> strings, the descender correction is computed, but the text is shifted
>> vertically in the canvas coordinate system rather than in the glyph
>> coordinate system.  Therefore, y axis labels are bumped up rather than left
>> on the canvas.  I'm not able to work on a patch at this time.
>> 
> I'll have a look at this.  Thanks for pointing it out.
>
>   
Fixed in SVN r6296.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text

[Michael Droettboom]

Stan West wrote:
>> Stan West wrote:
>> 
>>> While labeling axes with both standard and Unicode strings, I noticed some
>>> alignment problems in EPS output, as in the attached examples.  I traced it
>>> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
>>> latter was not accounting for any descenders in the glyphs.  I've attached a
>>> suggested patch which I believe brings the draw_unicode behavior into line
>>> with the draw_text behavior for both AFM and TrueType fonts.  The patch also
>>> removes extraneous indents in multi-line PostScript strings that were
>>> appearing in the EPS files.
>>>   
>>>   
>> Thanks for the patch.  I'm sure that was just overlooked when Unicode 
>> support was added to the Ps backend.
>>
>> This has been committed to SVN r6295.
>> 
>
> You're welcome.  For my edification, are there stylistic or other reasons to 
> leave the spaces in the PostScript at lines 580, 636, and 704?
>   
No.  Just used to ignoring whitespace in diffs, since editors often do 
that kind of thing behind one's back.  Certainly saves a few bytes in 
output to remove them.  I'll do that.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Odd handling of binary png files by pylab.imread

[Michael Droettboom]

I'm looking into this.  It seems that matplotlib is not making the right 
calls to libpng to convert < 8-bit images for us.

Mike

Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
>   
>
> 
>
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Odd handling of binary png files by pylab.imread

[Michael Droettboom]

This is now fixed in SVN r6318.  I also added some of the PNG test suite 
images to out regression tests so we're sure that it works with all of 
the basic PNG types.

Mike

Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
>   
>
> 
>
>
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mpl from svn build failure?

[Michael Droettboom]

This is now fixed in SVN r6341.

Sorry for the inconvenience.

Mike

John Hunter wrote:
> On Mon, Oct 27, 2008 at 8:49 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
>
>   
>> src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*,
>> int, char**)':
>> src/_tkagg.cpp:134: error: no match for 'operator*' in
>> '*aggRenderer->RendererAgg::renderingBuffer'
>> error: command 'gcc' failed with exit status 1
>>
>> John, this is on bic, in case you want to have a look.
>> 
>
> I saw this too, and emailed Michael off list earlier.  He committed a
> significant cleanup earlier of backend agg to reduce the number of
> heap allocations, and somehow tkagg got out of whack, at least on some
> platforms.
>
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Michael Droettboom]

This may not be necessary if we can get a Windows box, but I thought I'd 
mention it.

I wrote a distutils extension a couple of years ago to build Windows 
installers on a Linux box with Mingw32.  This has been working perfectly 
for nightly builds on my home machine since around September 2007 for a 
project with much the same build requirements as matplotlib.  It's 
really easy to install Mingw32 on Debian derivatives (maybe other dists 
as well.)

See here:

http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup

Mike

John Hunter wrote:
> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>   
>> None that I know of.  It would certainly be nice if we had the release
>> package-building completely automated; or automated daily svn builds of the
>> Win and OSX packages. Since I don't work with either Win or OSX, I don't
>> know how hard this would be to set up.
>> 
>
> Nightly builds would be excellent -- Charlie, to what extent do you
> think this is feasible from a scripting perspective?  Ie, ignoring the
> hardware side for a minute, and assuming we had access to a build farm
> with OS X and win32, how hard would it be to setup a build bot for
> nightly builds?
>
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pylab example (gradient_bar.py) only works for png

[Michael Droettboom]

There's a bug filed for this.  I've looked at it a few times, but I'm 
not sure how the image flipping parameters are "supposed" to work.  
Anyone else want to have a look at this?

https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720

Mike

Arnar Flatberg wrote:
> Hi
>
> The gradient_bar example flips the bars using svg, pdf and eps backends.
>
> Add
> fig.savefig("gradient_bar.png")
> fig.savefig("gradient_bar.pdf")
> fig.savefig("gradient_bar.eps")
> fig.savefig("gradient_bar.svg")
>
> to gradient_bar.py to reproduce.
>
> Tested with TkAgg backend (pylab: 1.3.0.dev5867 on python 2.5.2).
>
> Arnar
>
>
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
>
> _______
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Nearest neighbor search for font lookup

[Michael Droettboom]

I've finally gotten around to addressing a long-standing pet peeve of 
mine.  The font lookup is now performed with a nearest neighbor search, 
so if an exact font match can not be found for what the user specifies, 
the best available match is used, rather than dropping down to Vera 
Sans.  This is particularly important with fonts we don't distribute 
(particularly high-end commercial fonts) that have unusual values for 
"bold" etc.

All the examples in the docs and backend_driver seem to pass (with no 
required changes), so I've committed my patch.  But I wouldn't be 
surprised if some external usage may behave differently, particularly if 
it was relying on the old broken behavior.  Please test any scripts you 
may have that use different fonts (those not included with matplotlib 
especially) and report any regressions.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>> This may not be necessary if we can get a Windows box, but I thought 
>> I'd mention it.
>>
>> I wrote a distutils extension a couple of years ago to build Windows 
>> installers on a Linux box with Mingw32.  This has been working 
>> perfectly for nightly builds on my home machine since around 
>> September 2007 for a project with much the same build requirements as 
>> matplotlib.  It's really easy to install Mingw32 on Debian 
>> derivatives (maybe other dists as well.)
>
> Mike,
>
> Thank you!  I had no idea that mingw32 was available as an ubuntu 
> package, for example, and never would have thought to look for it.  
> Now I will have to try it out.  Do you know if there is an scons 
> builder that uses it?  That might be the sticking point for my non-mpl 
> C code, which is now all built with scons.
No idea.  Haven't spent much time with scons myself.
>
> I think that if your distutils extension works for building mpl for 
> Win on a Linux box, then we should use it.  Anything that reduces 
> dependence o having an actual Windows machine around is a win.
>
> On second thought, there is one disadvantage: an automated build on a 
> Win box could also run an automated test.
True.  But there is always wine -- though I fear my head would start to 
spin.  I'll admit that the advantages of cross-compiling can quickly be 
outweighed by the complexity of debugging and testing.
>
> I have some dim impression of having seen a caution regarding 
> compatibility between mingw extensions and present or future official 
> python.org Python builds.  Does this ring any bells?
It does.  I haven't had problems up to Py2.5 -- but I don't know what's 
coming in that respect, and I don't closely follow Python-on-Windows 
development.

Mike
>
> Eric
>
>>
>> See here:
>>
>> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup
>>  
>>
>>
>> Mike
>>
>> John Hunter wrote:
>>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <[EMAIL PROTECTED]> 
>>> wrote:
>>>
>>>  
>>>> None that I know of.  It would certainly be nice if we had the release
>>>> package-building completely automated; or automated daily svn 
>>>> builds of the
>>>> Win and OSX packages. Since I don't work with either Win or OSX, I 
>>>> don't
>>>> know how hard this would be to set up.
>>>> 
>>>
>>> Nightly builds would be excellent -- Charlie, to what extent do you
>>> think this is feasible from a scripting perspective?  Ie, ignoring the
>>> hardware side for a minute, and assuming we had access to a build farm
>>> with OS X and win32, how hard would it be to setup a build bot for
>>> nightly builds?
>>>
>>> JDH
>>>
>>> - 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>   
>>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pylab example (gradient_bar.py) only works for png

[Michael Droettboom]

No problem.  I didn't mean to imply that you should have known you bug 
was a duplicate.  I was mainly pointing it out for other developers to 
keep track of the issue, since I suspect your issue and the one in the 
bug are the same, but that's probably not obvious to most users.

I suspect the fix is as simple as twiddling a single line of code, it's 
just not obvious to me how the image flipping is supposed to work to 
have consistent behavior across backends -- and I hope another developer 
here has a clue...

Thanks for your report,
Mike

Arnar Flatberg wrote:
>
>
> On Tue, Oct 28, 2008 at 4:20 PM, Michael Droettboom <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> There's a bug filed for this.  I've looked at it a few times, but
> I'm not sure how the image flipping parameters are "supposed" to
> work.  Anyone else want to have a look at this?
>
> 
> https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
> 
> <https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720>
>
>
> I was not aware of that, thanks Michael. Just to be clear, (in 
> relation to the filed ticket), the screen image is just fine for my 
> part, its *only* after saving in any vector graphic format I get a 
> "flipped" image as a result. In other words, I have an issue with 
> savefig, while the ticket is concerned with imshow. Perhaps they are 
> obviously related ... then Im sorry for the noise :-)
>
> Thanks,
>
> Arnar
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Event handling example not working

[Michael Droettboom]

Agreed.  I think it is missing only be accident.

Mike

John Hunter wrote:
> On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>
>   
>> Here's probably a better question to ask than just to fix the example.
>> Was it intended that the Rectangle.xy attribute disappear?  I couldn't
>> find it documented in API_CHANGES. It appears that there was just a
>> change at some point in Michael's transforms work.  If it's considered
>> desirable to have it back, I'll volunteer to whip up a patch to make it
>> a property.  If not, let's just make sure we document this in API_CHANGES.
>> 
>
> I have no problem with you adding it back in as a convenience
> property.  Can't see the harm.
>
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SVG clickable images

[Michael Droettboom]

his, I wanted to
>> check whether this is the right approach to take - I'm not experienced
>> with the internals of matplotlib and so if there's a better way of
>> doing it, I'd be grateful for the advice.
>>
>> Once I got the bar charts working, I would be interested in possibly
>> extending this to other chart types.
>>
>> Regards
>>
>> Andrew
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
>
> -----
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SVG clickable images

[Michael Droettboom]

I realised in my earlier message, I didn't really address your initial 
request for feedback on your approach.

I think the goal here should be to make the url support as pervasive as 
possible wrt both plot types and backends.

Many of the high-level plotting functions (such as bar()) take a 
standard set of "Artist" keywords.  In the docs, you'll often see a 
table like the one at the bottom for bar():

   
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar

This support all happens automatically simply by adding a setter and 
getter to the "Artist" class.  So, in Artist, simply add set_url/get_url 
methods and a private attribute to store the url.  You shouldn't have to 
touch any of the high-level plotting functions to have this supported 
everywhere where it makes sense.

Then, to use the url value, you'll want to store it in a GraphicsContext 
object to pass to the backend.  So you'll want to add an attribute and 
getter/setter in GraphicsContextBase as well.

All of the places where the front-end creates a gc and passes it to the 
backend will need to be updated (such as Artist.draw, Text.draw, perhaps 
others, do a grep for the public methods in RendererBase).  Where it 
sets things like facecolor on the GraphicsContext, it should also set a url.

Then, in backends where appropriate you would use the url value if 
present. You could start with SVG, and maybe someone can come along and 
add PDF support later.

An additional complication for completeness is handling Collections.  
Collections store a list of graphics context information (facecolor, 
edgecolor etc.) rather than a single one.  Therefore, you'll want to add 
set_urls/get_urls to Collection as well, and then deal with passing 
those values to the backend.  Collections don't use a GraphicsContext 
class, so you'll need to add a new arg to draw_path_collection in all 
backends.  (Refactoring this so we pass an object to the backends rather 
than a long list of arguments would be welcome to avoid needing to 
update multiple backends for these sorts of new features in the 
future).  You will also need to update RendererBase._iter_collection to 
support iterating over URLs in the same way as everything else there.

draw_image also doesn't use a gc, so you'll need to add an argument there.

Hope that gives you a road map...  Please let me know if I can help further.

Mike

Andrew Stock wrote:
> Hi,
>
> I have a requirement to make clickable bar charts using the SVG output
> (rather than html maps).
>
> An initial look has suggested that the following changes would be required:
>
> backend_bases.py: Add a url property to GraphicsContextBase
> (defaulting to None, so it's all backwards compatible)
> axes.py: Add a url option to the bar function and pass this on to the
> constructor of the Rectangle object
> patches.py: Pass the url option in the constructor for the Patch
> object to the GraphicsContextBase object created in the draw function
> backends/backend_svg.py: Add check to _draw_svg_element for url set in
> gc. If it is, write out SVG code for xlink.
>
> I can make these changes and (if people think it would be useful)
> contribute the changes back.  However, before I do this, I wanted to
> check whether this is the right approach to take - I'm not experienced
> with the internals of matplotlib and so if there's a better way of
> doing it, I'd be grateful for the advice.
>
> Once I got the bar charts working, I would be interested in possibly
> extending this to other chart types.
>
> Regards
>
> Andrew
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SVG clickable images

[Michael Droettboom]

This looks great to me.  I can confirm that this works on Linux as well.

I think from here it's just a matter of applying the same pattern of 
changes to collections and images.  Once that's done, I'm happy to apply 
the patch.  And if you plan to make a lot of changes in the future, it 
generally pretty easy to get commit access.  Just ask.

Mike

Andrew Stock wrote:
> Hi,
>
> I've attached a diff file which implements the basic functionality. It
> currently doesn't handle collections or draw_image, but I wanted to
> get something simple working first, before expanding the scope.  A
> simple test program is as follows:
>
> from pylab import *
>
> f = figure()
> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>
> a.set_url('http://www.google.com')
>
> f.canvas.print_figure(r'c:\test.svg')
>
> I'd be interested in comments / feedback on the attached before I
> start to branch out into more significant changes!
>
> Thanks
>
> Andrew
>
> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> I realised in my earlier message, I didn't really address your initial
>> request for feedback on your approach.
>>
>> I think the goal here should be to make the url support as pervasive as
>> possible wrt both plot types and backends.
>>
>> Many of the high-level plotting functions (such as bar()) take a standard
>> set of "Artist" keywords.  In the docs, you'll often see a table like the
>> one at the bottom for bar():
>>
>>  http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar
>>
>> This support all happens automatically simply by adding a setter and getter
>> to the "Artist" class.  So, in Artist, simply add set_url/get_url methods
>> and a private attribute to store the url.  You shouldn't have to touch any
>> of the high-level plotting functions to have this supported everywhere where
>> it makes sense.
>>
>> Then, to use the url value, you'll want to store it in a GraphicsContext
>> object to pass to the backend.  So you'll want to add an attribute and
>> getter/setter in GraphicsContextBase as well.
>>
>> All of the places where the front-end creates a gc and passes it to the
>> backend will need to be updated (such as Artist.draw, Text.draw, perhaps
>> others, do a grep for the public methods in RendererBase).  Where it sets
>> things like facecolor on the GraphicsContext, it should also set a url.
>>
>> Then, in backends where appropriate you would use the url value if present.
>> You could start with SVG, and maybe someone can come along and add PDF
>> support later.
>>
>> An additional complication for completeness is handling Collections.
>>  Collections store a list of graphics context information (facecolor,
>> edgecolor etc.) rather than a single one.  Therefore, you'll want to add
>> set_urls/get_urls to Collection as well, and then deal with passing those
>> values to the backend.  Collections don't use a GraphicsContext class, so
>> you'll need to add a new arg to draw_path_collection in all backends.
>>  (Refactoring this so we pass an object to the backends rather than a long
>> list of arguments would be welcome to avoid needing to update multiple
>> backends for these sorts of new features in the future).  You will also need
>> to update RendererBase._iter_collection to support iterating over URLs in
>> the same way as everything else there.
>>
>> draw_image also doesn't use a gc, so you'll need to add an argument there.
>>
>> Hope that gives you a road map...  Please let me know if I can help further.
>>
>> Mike
>>
>> Andrew Stock wrote:
>> 
>>> Hi,
>>>
>>> I have a requirement to make clickable bar charts using the SVG output
>>> (rather than html maps).
>>>
>>> An initial look has suggested that the following changes would be
>>> required:
>>>
>>> backend_bases.py: Add a url property to GraphicsContextBase
>>> (defaulting to None, so it's all backwards compatible)
>>> axes.py: Add a url option to the bar function and pass this on to the
>>> constructor of the Rectangle object
>>> patches.py: Pass the url option in the constructor for the Patch
>>> object to the GraphicsContextBase object created in the draw function
>>> backends/backend_svg.py: Add check to _draw_svg_element for url set in
>>> gc. If it is, write out SVG code for xlink.
>>>
>>> I can make the

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6363] trunk/matplotlib/examples/pylab_examples/ text_rotation_relative_to_line.py

[Michael Droettboom]

Thanks, David.  That's a much-needed feature.

However, wouldn't it be simpler, API-wise, to add a new kwarg 
"rotation_data" (or some better name) which would be an angle in data 
space?  (Or alternatively a boolean flag "rotation_in_data_coords").  
The other advantage of that approach is that since the Text object knows 
what the "purpose" of the angle is, it could update the angle when the 
limits or figure size are changed.

It looks like the heavy lifting of the calculation is already there...

Cheers,
Mike

[EMAIL PROTECTED] wrote:
> Revision: 6363
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6363&view=rev
> Author:   dmkaplan
> Date: 2008-11-05 14:43:29 + (Wed, 05 Nov 2008)
>
> Log Message:
> ---
> Adding a small script that demonstrates the utility of transform_angles 
> method added in last
> commit (from dmkaplan).
>
> Added Paths:
> ---
> trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
>
> Added: 
> trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
> ===
> --- 
> trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
> (rev 0)
> +++ 
> trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
> 2008-11-05 14:43:29 UTC (rev 6363)
> @@ -0,0 +1,36 @@
> +#!/usr/bin/env python
> +"""
> +Text objects in matplotlib are normally rotated with respect to the
> +screen coordinate system (i.e., 45 degrees rotation plots text along a
> +line that is inbetween horizontal and vertical no matter how the axes
> +are changed).  However, at times one wants to rotate text with respect
> +to something on the plot.  In this case, the correct angle won't be
> +the angle of that object in the plot coordinate system, but the angle
> +that that object APPEARS in the screen coordinate system.  This angle
> +is found by transforming the angle from the plot to the screen
> +coordinate system, as shown in the example below.
> +"""
> +from pylab import *
> +
> +# Plot diagonal line (45 degrees)
> +h = plot( r_[:10], r_[:10] )
> +
> +# set limits so that it no longer looks on screen to be 45 degrees
> +xlim([-10,20])
> +
> +# Locations to plot text
> +l1 = array((1,1))
> +l2 = array((5,5))
> +
> +# Rotate angle
> +angle = 45
> +trans_angle = gca().transData.transform_angles(array((45,)),
> +   l2.reshape((1,2)))[0]
> +
> +# Plot text
> +th1 = text(l1[0],l1[1],'text not rotated correctly',fontsize=16,
> +   rotation=angle)
> +th2 = text(l2[0],l2[1],'text not rotated correctly',fontsize=16,
> +   rotation=trans_angle)
> +
> +show()
>
>
> This was sent by the SourceForge.net collaborative development platform, the 
> world's largest Open Source development site.
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-checkins mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transform_angles

[Michael Droettboom]

Darn clogged e-mail queue! ;)

I see you've already addressed my question...

Cheers,
Mike

David Kaplan wrote:
> Hi,
>
> I just wanted to send a note saying that I committed an additional
> method to the Transforms class that transforms angles.  The basic idea
> is to transform an angle at a point to a new angle at the corresponding
> point in the transformed coordinate system.  The included method is
> generic and should work well for almost any transform provided that the
> spatial scale isn't too small or too large.  Much faster algorithms that
> would work regardless of spatial scale can be found for particular
> transforms, particularly affine transforms, but I haven't added these
> yet.
>
> I also added an example script that shows how to use this method to plot
> text rotated so that it aligns with a line in a figure
> ( text_rotation_relative_to_line.py ).  
>
> I initially intended to use this method to give text objects the option
> to be rotated with respect to the plot coordinate system (as opposed to
> the screen coordinate system), but I haven't gotten around to finishing
> this yet.
>
> Cheers,
> David
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transform_angles

[Michael Droettboom]

David Kaplan wrote:
> Hi,
>
> Actually your question is a good one.  One of the reasons I never
> finished adding an option to text objects to rotate with respect to the
> plot (is this the correct terminology?), not the screen, is that I
> wasn't sure of the best way to implement this without making it
> hopelessly confusing for the user.  
>
> One way is to add a boolean that tells the text object whether or not
> the angle is with respect to screen coordinates.  In this case,
> text_obj.get_rotation() would return the angle in whichever coordinate
> system is the active one based on the boolean, unless an option to
> get_rotation is specified that would force the angle to the screen
> coordinate system (this option would then be used by show methods to
> assure they get the correct angle for plotting on the screen).
> Similarly, set_rotation would set the angle in the active system.  The
> disadvantage of this approach is that it can be pretty confusing -
> unless you consult the boolean, you don't know what your angle is
> measured relative to.
>
> Another approach would be to add a ._rotationPlot variable, as well
> as .get_rotationPlot and .set_rotationPlot text-object methods.  In this
> case, using set_rotation would set the "active" angle to be the screen
> angle, while using set_rotationPlot would set the "active" angle to be
> the plot angle.  The non-active angle would be set to None and show
> calls would test for whether or not ._rotation is none, in which case
> the screen angle would be calculated from the transform.  In this case,
> get_rotation and get_rotationPlot would return angles in the respective
> system, regardless of which one is "active".
>
> What structure would people prefer?
>   
I think the latter choice presents less confusion, particularly after 
hearing your arguments.  It should probably be rotation_plot, just to be 
consistent with other getters/setters.  There should probably also be a 
check and warning for setting rotation_plot for figure text, where it 
doesn't make sense, and fall back to the identity transform.
> Another reason I never finished this is that I got confused by some of
> the code - there was talk of unitful and unitless rotations and
> coordinates.  
Hopefully someone else has some guidance on unit-related issues.  I 
still don't have my head around that stuff.
> Also, I wasn't sure what to do with objects that inherit
> the text object class - namely, text with a dash.  It didn't seem it was
> worth adding this non-screen rotation functionality to these objects.  
>   
What is the argument against?  It seems like this would be 
straightforward (at least from the outside).  But I'm probably missing 
something.
> If anyone can point me in the right direction on these points, I will
> try to finish a patch for this functionality.
>   
Thanks.

Mike
> Cheers,
> David
>
> On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote:
>   
>> Darn clogged e-mail queue! ;)
>>
>> I see you've already addressed my question...
>>
>> Cheers,
>> Mike
>>
>> David Kaplan wrote:
>> 
>>> Hi,
>>>
>>> I just wanted to send a note saying that I committed an additional
>>> method to the Transforms class that transforms angles.  The basic idea
>>> is to transform an angle at a point to a new angle at the corresponding
>>> point in the transformed coordinate system.  The included method is
>>> generic and should work well for almost any transform provided that the
>>> spatial scale isn't too small or too large.  Much faster algorithms that
>>> would work regardless of spatial scale can be found for particular
>>> transforms, particularly affine transforms, but I haven't added these
>>> yet.
>>>
>>> I also added an example script that shows how to use this method to plot
>>> text rotated so that it aligns with a line in a figure
>>> ( text_rotation_relative_to_line.py ).  
>>>
>>> I initially intended to use this method to give text objects the option
>>> to be rotated with respect to the plot coordinate system (as opposed to
>>> the screen coordinate system), but I haven't gotten around to finishing
>>> this yet.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>   
>>>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transform_angles

[Michael Droettboom]

David Kaplan wrote:
> Hi,
>
> On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote:
>   
>> What is the argument against?  It seems like this would be 
>> straightforward (at least from the outside).  But I'm probably
>> missing 
>> something.
>> 
>
> More work for diminishing interest  Perhaps I am incorrect, but I
> think this object is only used for legends and axes labels, which
> probably wouldn't use this feature.  
>
> If I remember correctly, there was also the problem that the dash had
> its own rotation angle, which would require a whole other set of
> corresponding variables and methods to select the coordinate system for
> the dash  
>
> I think I saw this and just decided to raise not implemented warnings on
> attempts to set non-screen coordinate system rotations.
>
> Is there a strong desire for adding this feature to text with dash?
>   
Thanks.  I see the complications now.  I agree -- let's not worry about 
TextWithDash for now, except for possibly warning or throwing when 
trying to use this new feature with a TextWithDash.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SVG clickable images

[Michael Droettboom]

I went ahead and committed the latest version of your patch.  Thanks.  
This is a cool new feature.

I think it's probably low-risk for having Windows problems, but having 
it in SVN will make it more likely for Windows users to test.

Cheers,
Mike

Andrew Stock wrote:
> Jae-Joon,
>
> Thanks for your comments. You have successfully found areas in my
> patch that were overcomplicated!
>
> I have attached a new patch which doesn't alter the api of draw_image
> and uses the im object as Jae-Joon suggests.
>
> I've tested this on Linux Python 2.5 as before, but not on Windows as
> I don't have the correct development environment set up at the moment.
>
> Regards
>
> Andrew
>
> On Fri, Nov 7, 2008 at 10:36 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>   
>> Andrew,
>>
>> I just had a quick look at your patch.
>> I'm a bit distracted with your changes regarding the "url" support of the 
>> image.
>> Do we need to change the api of the draw_image()? Can we just utilize
>> "im" object as we did with the "gc"? Check the patch below. This
>> simple method seem to work fine for me.
>>
>> I also noted that,  in the __init__() methods of the Patch and the
>> AxesImage class, you explicitly declare "url" as a keyword argument
>> and also initialize self.url. I don't think these are necessary as
>> "url" is already a property of the Artist class.
>>
>> IHTH,
>>
>> -JJ
>>
>>
>> Index: lib/matplotlib/image.py
>> ===
>> --- lib/matplotlib/image.py (revision 6361)
>> +++ lib/matplotlib/image.py (working copy)
>> @@ -234,6 +234,7 @@
>> self.axes.get_yscale() != 'linear'):
>> warnings.warn("Images are not supported on non-linear axes.")
>> im = self.make_image(renderer.get_image_magnification())
>> +im._url = self.get_url()
>> l, b, widthDisplay, heightDisplay = self.axes.bbox.bounds
>> renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
>> *self.get_transformed_clip_path_and_affine())
>> Index: lib/matplotlib/backends/backend_svg.py
>> ===
>> --- lib/matplotlib/backends/backend_svg.py  (revision 6361)
>> +++ lib/matplotlib/backends/backend_svg.py  (working copy)
>> @@ -274,6 +283,9 @@
>>
>> h,w = im.get_size_out()
>>
>> +url = im._url
>> +if url is not None:
>> +self._svgwriter.write('' % url)
>> self._svgwriter.write (
>> '> '%s xlink:href="'%(x/trans[0],
>> (self.height-y)/trans[3]-h, w, h, transstr)
>> @@ -298,6 +310,8 @@
>> self._svgwriter.write(filename)
>>
>> self._svgwriter.write('"/>\n')
>> +if url is not None:
>> +self._svgwriter.write('')
>>
>> def draw_text(self, gc, x, y, s, prop, angle, ismath):
>> if ismath:
>>
>>
>>
>>
>> On Thu, Nov 6, 2008 at 11:40 AM, Andrew Stock
>> <[EMAIL PROTECTED]> wrote:
>> 
>>> Thanks  Michael,
>>>
>>> I've attached a new diff file which I believe also has all the
>>> necessary changes to the collections and images. I've also attached
>>> two simple scripts which test the collections and image functionality.
>>>
>>> I've had to make some modification to extension code in this patch
>>> which is definitely not my area of expertise so it would be worth
>>> someone more experienced casting an eye over this.
>>>
>>> I've tested this on Linux and successfully run the backend_driver.py
>>> file (or at least, it failed with the same errors as before I applied
>>> the patch!).
>>>
>>> Any other comments welcome
>>>
>>> Thanks
>>>
>>> On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <[EMAIL PROTECTED]> 
>>> wrote:
>>>   
>>>> This looks great to me.  I can confirm that this works on Linux as well.
>>>>
>>>> I think from here it's just a matter of applying the same pattern of 
>>>> changes
>>>> to collections and images.  Once that's done, I'm happy to apply the patch.
>>>>  And if you plan to make a lot of changes in the future

Re: [matplotlib-devel] logo example plots are wrong

[Michael Droettboom]

Just a note -- my recent changes to the font cache were drastic enough 
that I changed the file name (a cheap form of versioning...).  It is now 
fontList.cache -- I was hoping that would avoid this, but apparently 
not... :(

Mike

John Hunter wrote:
> On Sat, Nov 8, 2008 at 5:53 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>   
>> Yes, the script also works for me.
>> It seems that the version on the web is picking up a wrong font file.
>> 
>
> I flushed my font caches and rebuilt and the text is looking OK now.
> It may be that some combination of old font caches with Michael's
> recent changes to the font finder caused some grief, so everyone
> working from svn may want to flush the cache.  Perhaps we should
> introduce version tagging on the caches, so these get flushed
> periodically on upgrades.
>
> I pushed the new docs up to the site - thanks for letting me know...
>
> Now I really better get back to the wife and kids :-)
>
>
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] modification of update_path_extents?

[Michael Droettboom]

Eric Firing wrote:
> Mike,
>
> A bug was recently pointed out: axhline, axvline, axhspan, axvspan 
> mess up the ax.dataLim.  I committed a quick fix for axhline and 
> axvline, but I don't think that what I did is a good solution, so 
> before doing anything for axhspan and axvspan I want to arrive at a 
> better strategy.
>
> What is needed is a clean way to specify that only the x or the y part 
> of ax.dataLim be updated when a line or patch (or potentially anything 
> else) is added.  This is specifically for the case, as in *line, where 
> one axis is in data coordinates and the other is in normalized 
> coordinates--we don't want the latter to have any effect on the dataLim.
>
> This could be done in python in any of a variety of ways, but I 
> suspect that to be most consistent with the way the transforms code is 
> now written, relying on update_path_extends from _path.cpp, it might 
> make sense to append two boolean arguments to that cpp function, 
> "update_x" and "update_y", and use kwargs in Bbox.update_from_path and 
> siblings to set these, with default values of True.
It seems we could do this without touching C at all.  Just change 
update_from_path so it only updates certain coordinates in the bounding 
box based on the kwargs you propose.  Sure, the C side will be keeping 
track of y bounds even when it doesn't have to, but I doubt that matters 
much compared to checking a flag in the inner loop.  It will compute the 
bezier curves for both x and y anyway (without digging into Agg).  It's 
hard to really estimate the performance impact, so I'm necessarily 
pushing for either option, but it may save having to update the C.
> What do you think?  If you agree to the _path.cpp change strategy, do 
> you prefer to do that yourself, or would you rather that I try it first?
I probably won't have a chance to look at this today, so go ahead if you 
like.  I'll shoot you a note later in the week if I have time...

Cheers,
Mike
>
> Any suggestions and/or contributions are welcome.
>
> Thanks.
>
> Eric

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] modification of update_path_extents?

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>>
>> Eric Firing wrote:
>>> Mike,
>>>
>>> A bug was recently pointed out: axhline, axvline, axhspan, axvspan 
>>> mess up the ax.dataLim.  I committed a quick fix for axhline and 
>>> axvline, but I don't think that what I did is a good solution, so 
>>> before doing anything for axhspan and axvspan I want to arrive at a 
>>> better strategy.
>>>
>>> What is needed is a clean way to specify that only the x or the y 
>>> part of ax.dataLim be updated when a line or patch (or potentially 
>>> anything else) is added.  This is specifically for the case, as in 
>>> *line, where one axis is in data coordinates and the other is in 
>>> normalized coordinates--we don't want the latter to have any effect 
>>> on the dataLim.
>>>
>>> This could be done in python in any of a variety of ways, but I 
>>> suspect that to be most consistent with the way the transforms code 
>>> is now written, relying on update_path_extends from _path.cpp, it 
>>> might make sense to append two boolean arguments to that cpp 
>>> function, "update_x" and "update_y", and use kwargs in 
>>> Bbox.update_from_path and siblings to set these, with default values 
>>> of True.
>> It seems we could do this without touching C at all.  Just change 
>> update_from_path so it only updates certain coordinates in the 
>> bounding box based on the kwargs you propose.  Sure, the C side will 
>> be keeping track of y bounds even when it doesn't have to, but I 
>> doubt that matters much compared to checking a flag in the inner 
>> loop.  It will compute the bezier curves for both x and y anyway 
>> (without digging into Agg).  It's hard to really estimate the 
>> performance impact, so I'm necessarily pushing for either option, but 
>> it may save having to update the C.
>
> Mike,
>
> I was somehow thinking that update_path_extents was changing things in 
> place--completely wrong.  So yes, it is trivial to make the change at 
> the python level, and that is definitely the place to do it.  I will 
> try to take care of it this evening.
>
> In poking around, however, I came up with a couple of questions. 
> Neither is a blocker for what I need to do, but each might deserve a 
> comment in the code, if nothing else.
>
> 1) in _path.cpp:
>
> void get_path_extents(PathIterator& path, const agg::trans_affine& trans,
>   double* x0, double* y0, double* x1, double* y1,
>   double* xm, double* ym)
> {
> typedef agg::conv_transform transformed_path_t;
> typedef agg::conv_curve curve_t;
> double x, y;
> unsigned code;
>
> transformed_path_t tpath(path, trans);
> curve_t curved_path(tpath);
>
> curved_path.rewind(0);
>
> while ((code = curved_path.vertex(&x, &y)) != agg::path_cmd_stop)
> {
> if ((code & agg::path_cmd_end_poly) == agg::path_cmd_end_poly)
> continue;
> /* if (MPL_notisfinite64(x) || MPL_notisfinite64(y))
> continue;
>We should not need the above, because the path iterator
>should already be filtering out invalid values.
> */
> if (x < *x0) *x0 = x;
> if (y < *y0) *y0 = y;
> if (x > *x1) *x1 = x;
> if (y > *y1) *y1 = y;
> if (x > 0.0 && x < *xm) *xm = x;
> if (y > 0.0 && y < *ym) *ym = y;
> }
> }
>
>
> In the last 2 lines, why are xm and ym being clipped at 0, when x0 and 
> y0 are not?
xm and ym are the minimum positive values, used for log scales. 
Definitely worth a comment.
>
> 2) It looks like update_path_extents throws away orientation by always 
> returning x0 and y0 as the minima.  Bbox.update_from_path is therefore 
> doing the same.  This doesn't hurt in present usage, since orientation 
> is not needed for dataLim, but it seems a bit surprising, and worth a 
> comment at least.  Am I again missing something obvious?
>
I think I'm missing something.  (Choices in my code are always obvious 
to *me*, and any mistakes are invisible... ;)  Are you suggesting that 
if a line has x decreasing then x0 > x1?  What if it boomerangs?  I 
think it's simplest to keep data limits in a consistent order.  View 
limits are another issue, of course.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svg.image_noscale and others

[Michael Droettboom]

Eric Firing wrote:
> Jozef Vesely wrote:
>   
>> Hello matplotlib developers,
>>
>> I have implemented "svg.image_noscale" feature for ps and pdf backends. I 
>> think
>> that resampling/scaling should be avoided, when vector format can scale image
>> itself.
>> 
Unfortunately, the quality of interpolation is often subpar compared to 
what matplotlib (via Agg) provides.  Worse, the quality will be 
different when using Acrobat Reader vs. xpdf, for instance.  I don't 
think zooming in on individual pixels of data in Acroread is something 
we really are trying to support anyway -- for that you should use an 
interactive matplotlib GUI.  The purpose of pdf, imho, is really for 
printing.  In that case, you're likely to get better results and smaller 
file sizes by knowing the maximum resolution of your output device and 
letting matplotlib resample it -- and resample it with a method that is 
appropriate for the data, not the one in the printer or Acrobat that is 
(probably) optimized for photographs of the real world or whatever the 
driver is currently set to.
> It seems to me best if there is an option to scale or not; depending on 
> the situation, one might want to generate a file with images downscaled.
>   
Right.  All the above notwithstanding, I don't have a problem with this 
being a user option, I just can't imagine using it myself.
>   
>> One advantage is that original image can be recovered from final file. 
>> Moreover
>> as it is vector format it should be dpi independent and always provide 
>> maximum
>> possible quality - that's original data.
>> 
The original image can theoretically be recovered from the final file.  
But not the original data, which may be floating point etc.  If you 
anticipate users of your plot to need the original data, just distribute 
the original data alongside the plot.
>> As for svg backend I have commented some transformation changes which 
>> I don't understand and which result in misaligned image and axes. 
>> Without it the misalignment is still there but smaller.
>> 
Thanks for that.  I'm not sure why that code is there.  I see it looks 
much better without it.
>> I have also removed MixedModeRenderer from svg as it conflicts with 
>> "svg.image_noscale"
>> and does not seem to be used.
>> 
I think it would be better to turn off mixed mode rendering only when 
svg.image_noscale is True.
>> 
>
> I think having the option of using the MixedModeRenderer is important in 
> the long run for the vector backends; without it, one can end up with 
> completely unwieldy and potentially unrenderable files.  I'm not sure 
> what its status is at present; I think Mike got it working to a 
> considerable extent, but didn't quite finish, and therefore left it 
> temporarily disabled.
>   
It's fully functional in all the backends where it makes sense.  The 
part that is unfinished is the user interface -- how to turn the 
functionality on and off.  We couldn't find both a general and easy way 
to do it.  But it would be nice to have another go at it.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] partial ring patch

[Michael Droettboom]

Paul Kienzle wrote:
> Hi,
>
> We found we needed to draw a partial ring, but didn't see one in 
> patches.py.
>
> Attached is a generalization of Wedge to accept an inner and an outer 
> radius.
>
> Should I add this to patches?
Looks like a useful feature to me.  Could be used for doing these sort 
of "hierarchical pie chart" graphs:

http://linux.byexamples.com/wp-content/uploads/2007/04/baobab.png

Any reason not to implement this simply as an additional kwarg to Wedge, 
rather than a new class -- since Ring with a r2 == 0 is equivalent to 
Wedge anyway?  Just thinking of having less code to maintain...but maybe 
that's more confusing for end users.
>
> Note that rather saving the unit ring and constructing a transform as 
> in Wedge:
>
> def get_patch_transform(self):
> x = self.convert_xunits(self.center[0])
> y = self.convert_yunits(self.center[1])
> rx = self.convert_xunits(self.r2)
> ry = self.convert_yunits(self.r2)
> self._patch_transform = transforms.Affine2D() \
> .scale(rx, ry).translate(x, y)
> return self._patch_transform
>
> I just transform the coordinates directly:
>
> v *= r2
> v += numpy.array(center)
> self._path = Path(v,c)
> self._patch_transform = transforms.IdentityTransform()
>
> Any reason to prefer one over the other?
No strong reason.  The reason I did it that way was so that if the patch 
were scaled or translated in an animation, the transformation of the 
wedge vertices would happen on-the-fly within backend_agg.  It's not 
based on any benchmarking, but probably more on old habits from game 
programming (where it's common practice to keep shapes and transforms 
separated and let the hardware apply them).  I doubt it matters here.

Mike
>
>   - Paul
>
>
> 
>
>
>
>
>
>
>
> One problem is that I had to explicitly set the axes limits 1because add_patch
>
> wasn't updating the limits to include the bounds of the new patch.
> 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ----
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] partial ring patch

[Michael Droettboom]

Paul Kienzle wrote:
>
> On Nov 14, 2008, at 9:59 AM, Michael Droettboom wrote:
>
>> Paul Kienzle wrote:
>>> Hi,
>>>
>>> We found we needed to draw a partial ring, but didn't see one in 
>>> patches.py.
>>>
>>> Attached is a generalization of Wedge to accept an inner and an 
>>> outer radius.
>>>
>>> Should I add this to patches?
>> Looks like a useful feature to me.  Could be used for doing these 
>> sort of "hierarchical pie chart" graphs:
>>
>> http://linux.byexamples.com/wp-content/uploads/2007/04/baobab.png
>
> That's pretty, though I have no idea what it is supposed to represent.
It's the size of directories in a directory structure.  Each ring is a 
different depth of nesting.  Useful wherever you have a heirarchical 
percentages... 50% of %40 of %30...  Of course, suffers from the same 
usability problems of pie charts.  I'm not seriously suggesting we 
pursue this...  Your Ring class just reminded me of it.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] shared axis zoom bug

[Michael Droettboom]

The change doesn't apply to the trunk.  The shared axes logic is 
completely different now.  Whereas before there was a unidirectional 
link from one axes to another, and a concept of "master" and "slave" 
axes, the new version avoids that complication by using the "Grouper" class.

The bug fix was required on the branch because the zoom rectangle was 
getting "doubly applied", once for each axis which caused (in effect) 
for the zoom to go too far.  The fix was simply to ignore one of the 
axes, in this case the "master" axes.

The trunk has effectively the same fix already in that additional code 
you point out.  Its purpose is to make sure the zoom happens only once 
for each grouping.  It could probably be done better, but it does work.

So the software engineering lesson here, is I should have remembered to 
merge my own change on the branch -- I would have known right away it 
didn't apply.  (Actually, that's probably why I didn't merge it, but of 
course, you still have to let SVN know you don't want to merge the 
change somehow...)

Mike

John Hunter wrote:
> On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>   
>> On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>> 
>>> pan/zoom appears to be broken in the sharex axis demo.  If you do a
>>> zoom to rect on ax2 or ax3 in
>>> examples/pylab_examples/shared_axis_demo.py the event seems to be
>>> swallowed, though a zoom in ax1 is respected.
>>>   
>> The problem appears to be in the backend_bases
>> NavigationToolbar2.release_zoom method.  I have updated svn r6447 with
>>
>># JDH: I don't know why this is here but I expect to be
>># able to zoomo on any axis that is shared.  This was
>># breaking zoom-to-rect on shared_axis_demo if the zoom
>># happened in ax2 or ax3 so i am replacing the continue
>># with a pass until this is sorted out
>>if a._sharex or a._sharey:
>>#continue
>>pass
>>
>> If anyone knows why the continue was/should be there, speak up!
>> 
>
> OK, I think I see where this came in.  I did an svnmerge the other day
> from the branch, and merged in Michael's change:
>
>   r6365 | mdboom | 2008-11-05 09:15:28 -0600 (Wed, 05 Nov 2008) | 1 line
>
>   Fix bug in zoom rectangle with twin axes
>
> Michael, perhaps you can comment on this bugfix on the branch, and
> whether this change or something like it should be in the trunk?  I
> see the trunk has some additional logic that the branch does not have:
>
> # detect twinx,y axes and avoid double zooming
> twinx, twiny = False, False
> if last_a:
> for la in last_a:
> if a.get_shared_x_axes().joined(a,la): twinx=True
> if a.get_shared_y_axes().joined(a,la): twiny=True
>
>
> JDH
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] markersize change

[Michael Droettboom]

This might be related to a change I made in the Agg backend to make the 
markers look better by rounding their coordinates to the nearest pixel.  
It certainly made the stock markers at a standard size look better, but 
I suspect as they get smaller, they are converging down to the same 
value, thus having a truly zero-sized marker.


I'm away from a machine with build tools at the moment, so can't 
confirm.  Does the attached patch work for you?


Mike

Andrew Straw wrote:

John Hunter wrote:
  

On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:


Hi All,

I have been testing the latest svn matplotlib, which failed to produce
any visible data in some long-standing scripts of mine. :(

Investigating further, my use of markersize=0.5 combined with the '.'
symbol and the Agg backend caused a complete disappearance of the
markers. I'm attaching example images from 0.93.3 and the most recent
SVN using the attached script.

I'd be happy to track this down, but I think this might be a no-brainer
for someone on the list.
  

Is this agg only?



It doesn't happen with PS or SVG, so I'll say yes.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  


Index: src/_backend_agg.cpp
===
--- src/_backend_agg.cpp	(revision 6457)
+++ src/_backend_agg.cpp	(working copy)
@@ -494,8 +494,8 @@

   PathIterator marker_path(marker_path_obj);
   // The built-in markers look better if snapping is turned on.
-  const bool marker_snap = true;
-  // bool marker_snap = should_snap(marker_path, marker_trans);
+  // const bool marker_snap = true;
+  bool marker_snap = should_snap(marker_path, marker_trans);
   transformed_path_t marker_path_transformed(marker_path, marker_trans);
   simplify_t marker_path_simplified(marker_path_transformed, marker_snap, false, width, height);
   curve_t marker_path_curve(marker_path_simplified);
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] any git clones of the MPL svn repo out there?

[Michael Droettboom]

I don't know of any, but if you create one let us know.  I'd be 
interested in playing with such a thing.  I'm ready to see what all the 
fuss is about... ;)

Mike

Andrew Straw wrote:
> Since using git for some time on several projects (including projects
> with a central svn repository), it's been hard to go back to the
> universally slow web-based subversion history browsers and the absence
> of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
> into a git repo, but I wonder if anyone has already done this? Are there
> any git clones of the MPL svn repo out there?
>
> Thanks,
> Andrew
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] markersize change

[Michael Droettboom]

Ok.  I'll apply this fix to SVN.  I'll have to go back and find a better 
way to do this later.  Personally, I think the markers at normal to 
largish size (5+ pixels in diameter) look too fuzzy without the pixel 
quantizing.

Mike

Andrew Straw wrote:
> Hi Mike,
>
> That does fix the issue. Another thing I noticed that is fixed with your
> patch: the '.' marks appear like '+' when drawn at a smallish size.
>
> Thanks,
> Andrew
>
> Michael Droettboom wrote:
>   
>> This might be related to a change I made in the Agg backend to make the
>> markers look better by rounding their coordinates to the nearest pixel. 
>> It certainly made the stock markers at a standard size look better, but
>> I suspect as they get smaller, they are converging down to the same
>> value, thus having a truly zero-sized marker.
>>
>> I'm away from a machine with build tools at the moment, so can't
>> confirm.  Does the attached patch work for you?
>>
>> Mike
>>
>> Andrew Straw wrote:
>> 
>>> John Hunter wrote:
>>>  
>>>   
>>>> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>> 
>>>>> Hi All,
>>>>>
>>>>> I have been testing the latest svn matplotlib, which failed to produce
>>>>> any visible data in some long-standing scripts of mine. :(
>>>>>
>>>>> Investigating further, my use of markersize=0.5 combined with the '.'
>>>>> symbol and the Agg backend caused a complete disappearance of the
>>>>> markers. I'm attaching example images from 0.93.3 and the most recent
>>>>> SVN using the attached script.
>>>>>
>>>>> I'd be happy to track this down, but I think this might be a no-brainer
>>>>> for someone on the list.
>>>>>   
>>>>>   
>>>> Is this agg only?
>>>> 
>>>> 
>>> It doesn't happen with PS or SVG, so I'll say yes.
>>>
>>> -
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>   
>>>   
>> 
>>
>> -----
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> 
>>
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Michael Droettboom]

Thanks for the reminder.  It wasn't propagating the "non-affine" 
invalidation correctly.  I think I have a fix in r6465, but please let 
me know if you see anything else funny.

Cheers,
Mike

Eric Firing wrote:
> Mike,
>
> This is a gentle check--I suspect my original message, below, may have 
> slipped under the radar.
>
> Eric
>
> Eric Firing wrote:
>> Mike (or other transforms afficionados),
>>
>> The thread "[Matplotlib-users] Bug saving semilogy plots with a 
>> axvline" started by [EMAIL PROTECTED] pointed to a bug that appears to 
>> be deep in the transforms code.  My head is spinning.  The problem 
>> seems to be related to the propagation of the _invalid attribute in 
>> transforms, in the case of a mixed data/axes transform such as 
>> ashline uses.  The following one-line change in TransformNode, second 
>> line from the bottom, works:
>>
>>  def invalidate(self):
>>  """
>>  Invalidate this :class:`TransformNode` and all of its
>>  ancestors.  Should be called any time the transform changes.
>>  """
>>  # If we are an affine transform being changed, we can set the
>>  # flag to INVALID_AFFINE_ONLY
>>  value = (self.is_affine) and self.INVALID_AFFINE or 
>> self.INVALID
>>
>>  # Shortcut: If self is already invalid, that means its parents
>>  # are as well, so we don't need to do anything.
>>  if self._invalid == value:
>>  return
>>
>>  if not len(self._parents):
>>  self._invalid = value
>>  return
>>
>>  # Invalidate all ancestors of self using pseudo-recursion.
>>  parent = None
>>  stack = [self]
>>  while len(stack):
>>  root = stack.pop()
>>  # Stop at subtrees that have already been invalidated
>>  if root._invalid != value or root.pass_through:
>>  root._invalid = self.INVALID # value  <===
>>  stack.extend(root._parents.keys())
>>
>> Now, I know this is the wrong solution, because it defeats all the 
>> cleverness with the _invalid values; but perhaps it will save you a 
>> few minutes in finding the right solution.
>>
>> To reproduce the problem, do this in ipython -pylab:
>>
>> axhline(5)
>> yscale('log')
>> ylim(0.5,30)
>>
>> Eric
>>
>> - 
>>
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win 
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Michael Droettboom]

Hmm...  works fine for me here, both with the zoom/pan tool and zoom to 
rect.  Can you describe a particular action that isn't working?  I'm at 
a loss otherwise...

Mike

Eric Firing wrote:
> Michael Droettboom wrote:
>> Thanks for the reminder.  It wasn't propagating the "non-affine" 
>> invalidation correctly.  I think I have a fix in r6465, but please 
>> let me know if you see anything else funny.
>>
>> Cheers,
>> Mike
>
> Mike,
>
> It looks like that helps, fixing the window resize behavior, but 
> zooming and panning still do not work in the original example given by 
> João Silva:
>
> import matplotlib.pyplot as pl
> import numpy as np
>
> x = np.linspace(0.0,1.0,100)
>
> pl.semilogy(x,x**2)
> pl.axvline(x=0.5,ls='--',color='k')
> pl.show()
>
> Eric

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Michael Droettboom]

Sorry -- I neglected to commit some changes.  (Playing around with bzr 
and still getting used to it, I guess.)

Mike

Eric Firing wrote:
> Michael Droettboom wrote:
>> Hmm...  works fine for me here, both with the zoom/pan tool and zoom 
>> to rect.  Can you describe a particular action that isn't working?  
>> I'm at a loss otherwise...
>
> Mike,
>
> When I run João's commands in ipython -pylab and click the pan/zoom 
> button, panning or zooming moves the plotted curve, but the axvline 
> stays in the middle of the picture instead of moving with the x=0.5 
> point.  Same with zoom-to-rect: the axvline stays in the middle of the 
> window, not at x=0.5.
>
> Eric
>
>>
>> Mike
>>
>> Eric Firing wrote:
>>> Michael Droettboom wrote:
>>>> Thanks for the reminder.  It wasn't propagating the "non-affine" 
>>>> invalidation correctly.  I think I have a fix in r6465, but please 
>>>> let me know if you see anything else funny.
>>>>
>>>> Cheers,
>>>> Mike
>>>
>>> Mike,
>>>
>>> It looks like that helps, fixing the window resize behavior, but 
>>> zooming and panning still do not work in the original example given 
>>> by João Silva:
>>>
>>> import matplotlib.pyplot as pl
>>> import numpy as np
>>>
>>> x = np.linspace(0.0,1.0,100)
>>>
>>> pl.semilogy(x,x**2)
>>> pl.axvline(x=0.5,ls='--',color='k')
>>> pl.show()
>>>
>>> Eric
>>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>> Sorry -- I neglected to commit some changes.  (Playing around with 
>> bzr and still getting used to it, I guess.)
>
> Very good, thank you!
Phew!  For a minute there I thought I was going crazy...
>
> OT: I'm glad you are taking a look at bzr; personally, I chose hg 
> quite some time ago (when bzr was not mature enough to use), and I 
> have no regrets.  It is very small, quick, and uncluttered--a 
> beautiful piece of work.  (The code base is *much* smaller than bzr--I 
> like that.) The one area in which hg is a bit behind now is svn 
> interoperability,
> http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion,
> which doesn't matter at all for the uses to which I put it.  Possibly 
> it will catch up soon: 
> http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion
> http://blog.red-bean.com/sussman/?p=116
Yeah -- didn't mean to start another thread about distributed version 
control -- I'm just playing with the stuff.  But that was my assessment, 
too.  Couldn't figure out how to use hg with a svn-based project 
(matplotlib) -- bzr was easier but still taking some getting used to.  
git has related features too I might look at.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] experimental MPL git mirror online

[Michael Droettboom]

Has anyone had any success installing git-svn on a managed machine 
without root priviledges?  It seems that the Perl Alien::SVN dependency 
is totally broken in that context.

Mike

Andrew Straw wrote:
> I just put my git mirror of the matplotlib svn repository online. This
> is experimental in nature. Thanks to github for hosting this project.
> Anyhow, I added instructions for how to use this (including to interact
> with the central svn repository) here:
>
> http://github.com/astraw/matplotlib/tree/master/README.git
>
> Note that the initial downloads are about 150 MB in size.
>
> I have not actually used git in collaboration with others save through
> the svn interface, so I don't have experience with some aspects of git,
> particularly collaborating branching/merging/pushing etc. For
> single-user use, however, I've been finding all that stuff very nice.
> One thing particularly useful is the ability to clean up history before
> committing changes to a central subversion repository.
>
> Anyhow, thanks to Ondrej for the critical clue for how to make this work.
>
> -Andrew
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Installing git and git-svn from source

[Michael Droettboom]

Getting git-svn installed without root privileges is truly epic, given 
there are virtually no installation instructions for it, and its 
homepage seems to be down.  This doesn't bode well for git-svn adoption 
in managed environments like mine where users don't have root.  In 
fairness, the hard bit is Subversion and its perl bindings, but those do 
need to be current, and the commonly available advice to install 
Alien::SVN using cpan is totally broken for non-root installs.  I hope 
that the git-svn guys can simplify this down the road...

So, I thought I'd share my solution here to save others the trouble...

###Don't use cpan to install Alien::SVN -- it should have made this 
whole thing really easy, but it has a number of known bugs when 
installing without root.###

Here's what worked for me.  I have a folder ~/usr for my usual 
user-local installs, that's already been set up with the usual 
environment variables in my .bashrc:

   export PATH=~/usr/bin:$PATH
   export LD_LIBRARY_PATH=~/usr/lib:$LD_LIBRARY_PATH
   export PKG_CONFIG_PATH=~/usr/lib/pkgconfig:$PKG_CONFIG_PATH

1) Download and install openssl from www.openssl.org/source

   tar zvxf openssl-0.9.8i.tar.gz
   cd openssl-0.9.8i
   ./configure --prefix=/home/mdroe/usr
   make -j
   make install

2) Download subversion tarball

   cd ..
   tar jxvf subversion-1.5.4.tar.bz2
   cd subversion-1.5.4

3) Download neon inside the subversion source tree, and configure

wget http://www.webdav.org/neon/neon-0.27.2.tar.gz
tar zvxf neon-0.27.2.tar.gz
mv neon-0.27.2 neon
cd neon
./configure --prefix=/home/mdroe/usr --without-gssapi --with-ssl=openssl

4) Get apr and apr-util, and configure

svn co http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x apr
cd apr
./buildconf
cd ..
svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x 
apr-util
cd apr-util
./buildconf
cd ..

5) Build subversion

./autogen.sh
./configure --prefix=/home/mdroe/usr --with-ssl --enable-shared
make -j
make install

6) Build perl bindings

make swig-pl
make swig-pl-lib
make install-swig-pl-lib
cd subversion/bindings/swig/perl/native
perl Makefile.PL PREFIX=/home/mdroe/usr
make install
cd ../../../../../..

7) Download, build and install git

   tar zvxf get-1.6.0.tar.gz
   cd git-1.6.0
   ./configure --prefix=/home/mdroe/usr
   make install


... follow Andrew Straw's git instructions ... (???) ... profit!!!

Mike

   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] symlog problem

[Michael Droettboom]

Just getting to this thread now.  Since you asked for my insight -- I 
can't reproduce the bug on my Linux box, but the patch looks innocent 
enough if it fixes it for others.

Mike

John Hunter wrote:
> On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote:
>   
>> I ran into the same problem independently on an Intel Mac (I didn't read
>> these messages until now) and came up with the first part of Jae-Joon
>> Lee's fix. It does fix the problem, at least for me - I suspect the
>> difference may not actually be in the platform but in the exact version
>> of numpy (I have 1.1.0). I also committed the other part of the fix.
>>
>> This does seem to fix the problem, but I think we should wait for
>> confirmation from John before releasing the code.
>> 
>
> This is looking good on my end -- thanks Jae-Joon and Jouni for the patches.
>
> 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
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] image pixel border bug

[Michael Droettboom]

I don't think it's a rendering bug.  The entire first row of data is 0.0 
and -0.0, which maps to red.  The real solution would be to map 0 and 
-0.0 to different colors, but that's insane ;)

The rendering bug that bothers me, however, is the misalignment of the 
ticks to the colors in the color bar.  I'm sure it's somehow related to 
the pixel-rounding in the Agg backend.  I'll see if I can find an 
obvious fix for this.  If it looks questionable, I'll wait until after 
the release.

Cheers,
Mike

John Hunter wrote:
> In the examples/pylab_examples/custom_cmap.py example, I am seeing a
> pixel red border, eg colored red on the top border of the middle
> subplot, where it looks like it should be blue.  Image attached.  Is
> this an artifact of the breakpoint of the colormap, or a true
> rendering bug?
>
> 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
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] New legend borders -- fuzzy???

[Michael Droettboom]

I think Jae-Joon's new figure refactoring is really great, and is a huge 
improvement over the old code.

I do, however, have one concern.  Since the legend border is no longer a 
simple rectangle, the Agg backend's auto-pixel-alignment routine is no 
longer kicking in, and the border ends up looking fairly fuzzy.  It's 
particularly striking when the axes rectangle is always so clean and 
sharp now.  As nice as the rounded edges are, the fuzziness makes it 
feel like a bit of a regression to me.  Aesthetically, I also feel it's 
a bit out of place to use rounded corners in one case but not elsewhere 
in a document (typical LaTeX templates, for instance, don't use rounded 
corners.)

Should it perhaps be a regular rectangle by default, with rounded 
corners as an option?

This may also be an argument for finally making the auto-pixel-alignment 
code programmatic, rather than automatic.  As it works now, it 
automatically pixel-aligns when there are a) no curves and b) only 
rectilinear axis-aligned line segments.  If the pixel alignment was 
instead controlled from Python as a flag, then the legend code could 
explicitly say it wants the legend patch to be pixel-aligned, even if it 
has rounded corners.  But that's perhaps too deep of a change to make 
for the impending release and should have to wait for next time.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] New legend borders -- fuzzy???

[Michael Droettboom]

John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> This may also be an argument for finally making the auto-pixel-alignment
>> code programmatic, rather than automatic.  As it works now, it
>> automatically pixel-aligns when there are a) no curves and b) only
>> rectilinear axis-aligned line segments.  If the pixel alignment was
>> instead controlled from Python as a flag, then the legend code could
>> explicitly say it wants the legend patch to be pixel-aligned, even if it
>> has rounded corners.  But that's perhaps too deep of a change to make
>> for the impending release and should have to wait for next time.
>> 
>
> This sounds fairly benign (gc param?) so I could go either way: before or 
> after.
>   
The gc param would be the easy part -- I was thinking the difficult 
would be going through all the cases and making sure it's doing the 
right thing, and making sure axes and ticks etc. still look nice.  
Though I suppose having the flag be yes/no/auto (where auto is the 
current behavior) would be the easiest route.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] image pixel border bug

[Michael Droettboom]

This should now be fixed in SVN.  Couldn't see any regressions in the 
documentation examples, but may be worth another set of eyes before the 
release.

Mike

John Hunter wrote:
> On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>   
>> I don't think it's a rendering bug.  The entire first row of data is 0.0 and
>> -0.0, which maps to red.  The real solution would be to map 0 and -0.0 to
>> different colors, but that's insane ;)
>>
>> The rendering bug that bothers me, however, is the misalignment of the ticks
>> to the colors in the color bar.  I'm sure it's somehow related to the
>> pixel-rounding in the Agg backend.  I'll see if I can find an obvious fix
>> for this.  If it looks questionable, I'll wait until after the release.
>> 
>
> Since this would be a bug-fix, I prefer to get it in before the
> release, if possible:-)  So if you have time to look at it, that would
> be great.  Charlie doesn't usually have time during the day to do the
> builds, so it would be tonight at the earliest, which should give us a
> little time to test any changes.
>
> Thanks,
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] New legend borders -- fuzzy???

[Michael Droettboom]

John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>   
>> The gc param would be the easy part -- I was thinking the difficult would be
>> going through all the cases and making sure it's doing the right thing, and
>> making sure axes and ticks etc. still look nice.  Though I suppose having
>> the flag be yes/no/auto (where auto is the current behavior) would be the
>> easiest route.
>> 
>
> I wasn't thinking clearly.  I was thinking you would be applying the
> fix only for the legend implementation, but there is no clean way to
> do this since the backends don't know anything about legends.  Yes,
> doing this for all the artists is definitely too ambitious at this
> stage of the release.
>   
I think this also dovetails nicely with another update I've been meaning 
to make -- to use a GC (or something like it) for images and collections 
as well.  As it stands now, any new property to collections needs to be 
added as a new argument to every backend (as was recently done for 
hyperlink support).  Stuffing everything in an object should make it 
more easily extensible.

But that's not before the release... ;)

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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:
> Since we already have a bug in the 98.4 release, we can anticipate 
> needing to do a bugfix release accumulating all the bugs we fix in the 
> next week (presuming we don't discover any critical bugs which would 
> require us to push out a fix earlier).  To make sure we achieve 
> maximal stability, I have created a 98.4 maintenance branch which 
> should only get bugfixes.  All other development can proceed apace on 
> the trunk.
>
>svn co 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\ 
> 
>v0_98_4_maint mpl98.4 --username=youruser --password=yourpass
>
> Mike, can you advise on the procedure for doing merges from the new 
> branch to the trunk.  In particular, what I am confused about is how 
> to inform svn-merge that I want to merge from 98.4 branch and not 91.4 
> branch.
You can add a new branch for the trunk to "track" using "svnmerge.py 
init", e.g., from a working copy of the trunk:

  > svnmerge.py init 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_4_maint
 

  property 'svnmerge-integrated' set on '.'

After doing a "svn commit" on this, this merge tracking is available to 
everyone, so there's no need for anyone else to do the "svnmerge init".  
I'll go ahead and commit this now.

Now, the trunk is tracking two branches for merges, 0.91.x and 0.98.4.  
This means that when doing a merge, one must manually specify which 
branch to merge from using the "-S" parameter.  You can see which 
branches are available for merge using "svnmerge.py avail":

 > svnmerge.py avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) 
required.
The merge sources available are:
  /branches/v0_91_maint
  /branches/v0_98_4_maint

So to merge from 0.98.4, one would type:

 > svnmerge.py --source v0_98_4_maint merge

(rather than the "svnmerge.py merge" we used to do).

The tracking for 0.91.x can be removed with the "svnmerge.py uninit" 
command, e.g.:

 > svnmerge.py --source v0_91_maint uninit

This will make merging slightly easier, (since the -S parameter is not 
required), and it is generally good practice in the long run to not keep 
extra branches lying around.  I'm happy to make this change, but thought 
I'd run it by you first -- it means we're effectively abandoning the 
0.91.x series, or at least saying any bugfixes to it will have to be 
manually brought over to 0.98.x.


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

[Michael Droettboom]

It looks like there was a slight "oops" making the branch.

https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
<https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint

points to one level above the source tree.  See:

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_98_4_maint/

Was this intentional?

In any case, the svnmerge setup I did this morning is incorrect.  Would 
you like me to fix that, or would you rather remove and recreate the 
branch?  If we don't fix the branch, I would suggest changing the 
instructions for checking out the branch to:

svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
<https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint/matplotlib
 
mpl98.4

Cheers,
Mike

John Hunter wrote:
>
> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> This will make merging slightly easier, (since the -S parameter is
> not required), and it is generally good practice in the long run
> to not keep extra branches lying around.  I'm happy to make this
> change, but thought I'd run it by you first -- it means we're
> effectively abandoning the 0.91.x series, or at least saying any
> bugfixes to it will have to be manually brought over to 0.98.x.
>
>
> Thanks for the notes -- I'l incorporate them into the dev guide.
>
> I definitely do not want to abandon the 91 branch.  I expect this 
> branch to last a while, perhaps a year.  the 98.4 branch is intended 
> to be short lived, order of a week or two, just to fix critical bugs 
> for this release.  Or better yet, we keep it alive until the next 
> point release, then kill it and make a new release branch.  That way 
> if we ever need to fix a critical bug in the latest release, we can go 
> to the branch w/o having all the testing required on the head.  Since 
> the major incompatibility was between 91 and 98, I anticipate that 
> there are some users with a lot of code (eg an axes3d dependency) 
> where moving may never be feasible.
>
> 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

[Michael Droettboom]

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).

In the meantime, I've removed merge tracking on branches/v0_98_4_maint 
to trunk/matplotlib, since it's broken.

Cheers,
Mike

Michael Droettboom wrote:
> It looks like there was a slight "oops" making the branch.
>
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint
>
> points to one level above the source tree.  See:
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_98_4_maint/
>
> Was this intentional?
>
> In any case, the svnmerge setup I did this morning is incorrect.  Would 
> you like me to fix that, or would you rather remove and recreate the 
> branch?  If we don't fix the branch, I would suggest changing the 
> instructions for checking out the branch to:
>
> svn co 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint/matplotlib
>  
> mpl98.4
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED] 
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>>
>> This will make merging slightly easier, (since the -S parameter is
>> not required), and it is generally good practice in the long run
>> to not keep extra branches lying around.  I'm happy to make this
>> change, but thought I'd run it by you first -- it means we're
>> effectively abandoning the 0.91.x series, or at least saying any
>> bugfixes to it will have to be manually brought over to 0.98.x.
>>
>>
>> Thanks for the notes -- I'l incorporate them into the dev guide.
>>
>> I definitely do not want to abandon the 91 branch.  I expect this 
>> branch to last a while, perhaps a year.  the 98.4 branch is intended 
>> to be short lived, order of a week or two, just to fix critical bugs 
>> for this release.  Or better yet, we keep it alive until the next 
>> point release, then kill it and make a new release branch.  That way 
>> if we ever need to fix a critical bug in the latest release, we can go 
>> to the branch w/o having all the testing required on the head.  Since 
>> the major incompatibility was between 91 and 98, I anticipate that 
>> there are some users with a lot of code (eg an axes3d dependency) 
>> where moving may never be feasible.
>>
>> 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
>   


--
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] 
> <mailto:[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

[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] 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] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

There was a discussion on this list around a year ago about this.  The 
concern was that not rendering $ as $ would break (matplotlib) backward 
compatibility with scripts that don't care about math at all but use a 
lot of dollar signs (e.g. financial plots).  This is one of the few 
places where we deliberately broke usetex compatibility in favour of 
matplotlib compatibility.

That said, it's probably a bug that the escaped dollar sign in non-math 
context is not rendered as a dollar sign.

As a workaround "$\$%1.2f$" works with usetex on or off, with the 
proviso that it uses math- rather than text-rendering for the numbers.

Mike

Manuel Metz wrote:
>   I just noted that mathtext and LaTeX rendering behave differently 
> when using a single "$" character in a text string. This happened to 
> me when looking at the dollar_ticks example from the docs because I 
> use LaTeX rendering by default. The problem is here:
>
> formatter = ticker.FormatStrFormatter('$%1.2f')
>
> MathText interprets this as a single "$" character, whereas LaTeX 
> interprets this as starting character of a math expression (and I get 
> an error), i.e. I have to write "\$1.2f" instead, which then, however, 
> is interpreted by MathText as "\$" ... :-(
>
> Shouldn't these two behave equally here?
>
> mm


--
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] using new in axes.hist

[Michael Droettboom]

Well, if it's any consolation -- I just finished setting up the 
maintenance branch for 0.98.5, so there's a place for this fix to go... ;)

Mike

Manuel Metz wrote:
> Manuel Metz wrote:
>   
>> Jae-Joon Lee wrote:
>> 
>>> I just committed the change. Although the change is trivial, I didn't
>>> tested it in the numpy 1.2 or the svn version.
>>>   
>> Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
>> since 0.98.5 is released...
>> 
>
> See here: http://projects.scipy.org/scipy/numpy/ticket/797
>
> "08/05/08 10:47:34 changed by dhuard
>
>   For version 1.2, I set new=None by default, which triggers the new
>   semantics and prints a warning. Setting new to True will trigger the
>   new semantics but won't print a warning. Done in r5611."
>
>
>   
>>> -JJ
>>>
>>>
>>> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter  wrote:
>>>   
 I think the version check is a good idea, so people won't get the annoying
 warning.  Could you add this?

 Sent from my iPhone

 On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee"  wrote:

 
> I'm currently using numpy 1.1.1 and np.histogram behave differently
> depending on the "new" value.
> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
> this different behavior is still there.
> So, as far as we're going to support numpy 1.1 and later, we may
> better not to drop the "new" silently.
> We may check the version number of the numpy in the hist() function,
> and call np.histogram() accordingly.
>
> -JJ
>
>
> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter  wrote:
>   
>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>> deprecation warning with svn numpy.  Anyone have an opinion on whether
>> this kwarg should be included in the upcoming mpl release?
>>
>> 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
>>
>> 
>>> --
>>> 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
>> 
>
> --
> 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] 98.4 maintenance branch

[Michael Droettboom]

Done.

I also cleaned up the svnmerge docs in doc/devel/coding_guide.rst

What we don't currently have is a way to merge fixes from 0.91.x to 
0.98.5.  It's been a long time since 0.91.x has seen any love, so I'm 
not too concerned.  Just be aware of it -- bug fixes on 0.91.x may need 
to be manually brought in to 0.98.5 if applicable.

Mike

John Hunter wrote:
> 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

Re: [matplotlib-devel] git questions

[Michael Droettboom]

Thanks.  I've incorporated your docs into the developer documentation.

My next experiment will be to see if I can track the 0.98.5 maintenance 
branch with git.  SVN tags/* show up as available remote branches, but 
not branches/*, which leaves me a bit stumped?  If you've done this and 
there's a quick answer, let me know, otherwise I'll do a little digging 
to see if it's possible.

Mike

Andrew Straw wrote:
> 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 n

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

[Michael Droettboom]

Darren Dale wrote:
>
>
> On Wed, Dec 10, 2008 at 11:10 PM, John Hunter  <mailto:jdh2...@gmail.com>> wrote:
>
>
>
> 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?
>
> [...]
>
>
> 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).
>
>
> I just removed them from the trunk, but not the 0.91 or 0.98.5 
> branches. I was going to add a note to the API_CHANGES log, was it 
> removed?
API_CHANGES was moved to doc/api/api_changes.rst so it gets 
automatically put up on the website.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Manuel Metz wrote:
> Michael Droettboom wrote:
>   
>> There was a discussion on this list around a year ago about this.  The
>> concern was that not rendering $ as $ would break (matplotlib) backward
>> compatibility with scripts that don't care about math at all but use a
>> lot of dollar signs (e.g. financial plots).  This is one of the few
>> places where we deliberately broke usetex compatibility in favour of
>> matplotlib compatibility.
>>
>> That said, it's probably a bug that the escaped dollar sign in non-math
>> context is not rendered as a dollar sign.
>>
>> As a workaround "$\$%1.2f$" works with usetex on or off, with the
>> proviso that it uses math- rather than text-rendering for the numbers.
>>
>> Mike
>> 
>
> In that case I suggest to note this somewhere in the docs (and User
> Guide) with three exclamation marks (or is it ???).
>   
So there's really two sub-bugs here:

1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim 
to the non-math text renderer, which is a bug).  This, IMHO, is a 
"must-fix".

2) '$8' gives '$8' in mathtext and an error in usetex.  This could be 
solved in two ways:

a) document the difference
b) make '$8' give '$8' in usetex as well

I realise b) is technically making usetex accept a string that is not 
normally valid TeX -- but it's not like a user would ever enter '$8' and 
*want* to get a TeX error back.  And usetex strings aren't perfectly TeX 
anyway.

Personally, I'm leaning toward b), because it requires less mental 
effort for the user turning usetex on/off.  And it doesn't force us to 
backtrack on the idea of supporting "$100.00" easily.

But before I commit -- any feedback?

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] ANN: matplotlib-0.98.5

[Michael Droettboom]

We have just released a new version of matplotlib, available for download at

  
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644

It is a simple bugfix release to fix a number of critical bugs found in 
0.98.4.

These "what's new" release notes, with graphs and links, are available 
in html at

  http://matplotlib.sourceforge.net/users/whats_new.html

Thanks to Charlie Moad for testing and preparing the source release,
including binaries for OS X and Windows for python 2.4 and 2.5 (2.6
and 3.0 will not be available until numpy is available on those
releases).  Thanks to the many developers who contributed to this
release, with contributions from Jae-Joon Lee, Michael Droettboom,
Ryan May, Eric Firing, Manuel Metz, Jouni K. Seppaenen, Jeff Whitaker,
Darren Dale, David Kaplan, Michiel de Hoon and many others who
submitted patches


What's new in 0.98.5
==

It's only been a matter of days since 0.98.4, but there were a number of 
critical bugs that warranted a new release.

2008-12-11 Use subprocess.Popen instead of os.popen in dviread
   (Windows problem reported by Jorgen Stenarson) - JKS

2008-12-10 Added Michael's font_manager fix and Jae-Joon's
   figure/subplot fix.  Bumped version number to 0.98.5 - JDH


-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
> On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom  <mailto:md...@stsci.edu>> wrote:
>
> Manuel Metz wrote:
> > Michael Droettboom wrote:
> >
> >> There was a discussion on this list around a year ago about
> this.  The
> >> concern was that not rendering $ as $ would break (matplotlib)
> backward
> >> compatibility with scripts that don't care about math at all
> but use a
> >> lot of dollar signs (e.g. financial plots).  This is one of the few
> >> places where we deliberately broke usetex compatibility in
> favour of
> >> matplotlib compatibility.
> >>
> >> That said, it's probably a bug that the escaped dollar sign in
> non-math
> >> context is not rendered as a dollar sign.
> >>
> >> As a workaround "$\$%1.2f$" works with usetex on or off, with the
> >> proviso that it uses math- rather than text-rendering for the
> numbers.
> >>
> >> Mike
> >>
> >
> > In that case I suggest to note this somewhere in the docs (and User
> > Guide) with three exclamation marks (or is it ???).
> >
> So there's really two sub-bugs here:
>
> 1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim
> to the non-math text renderer, which is a bug).  This, IMHO, is a
> "must-fix".
>
> 2) '$8' gives '$8' in mathtext and an error in usetex.  This could be
> solved in two ways:
>
> a) document the difference
> b) make '$8' give '$8' in usetex as well
>
> I realise b) is technically making usetex accept a string that is not
> normally valid TeX -- but it's not like a user would ever enter
> '$8' and
> *want* to get a TeX error back.  And usetex strings aren't
> perfectly TeX
> anyway.
>
> Personally, I'm leaning toward b), because it requires less mental
> effort for the user turning usetex on/off.  And it doesn't force us to
> backtrack on the idea of supporting "$100.00" easily.
>
> But before I commit -- any feedback?
>
>  
> I opposed to b). If we go that route, we can look forward to 
> advertising usetex as "a latex backend, with familiar, standard latex 
> markup, except when it isnt."
It's not as bad as that.  '\$8' will still work as in LaTeX as it always 
has and as a LaTeX expert would expect it to.  All I'm proposing is that 
'$8', which is currently a LaTeX syntax error, will behave as it does 
when usetex is turned off.  So it's not breaking anything that's already 
valid.

It's a question of which pain is worse, I guess.

The deeper question is -- should usetex even strive to have any 
compatibility with standard text?  If not, then I can see your point.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
> On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom  <mailto:md...@stsci.edu>> wrote:
>
> Darren Dale wrote:
>
> On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom
> mailto:md...@stsci.edu>
> <mailto:md...@stsci.edu <mailto:md...@stsci.edu>>> wrote:
>
>    Manuel Metz wrote:
>> Michael Droettboom wrote:
>>
>>> There was a discussion on this list around a year ago about
>this.  The
>>> concern was that not rendering $ as $ would break
> (matplotlib)
>backward
>>> compatibility with scripts that don't care about math at all
>but use a
>>> lot of dollar signs (e.g. financial plots).  This is one
> of the few
>>> places where we deliberately broke usetex compatibility in
>favour of
>>> matplotlib compatibility.
>>>
>>> That said, it's probably a bug that the escaped dollar
> sign in
>non-math
>>> context is not rendered as a dollar sign.
>>>
>>> As a workaround "$\$%1.2f$" works with usetex on or off,
> with the
>>> proviso that it uses math- rather than text-rendering
> for the
>numbers.
>>>
>>> Mike
>>>
>>
>> In that case I suggest to note this somewhere in the docs
> (and User
>> Guide) with three exclamation marks (or is it ???).
>>
>So there's really two sub-bugs here:
>
>1) '\$8' gives '\$8' in mathtext (well, actually it gets
> sent verbatim
>to the non-math text renderer, which is a bug).  This,
> IMHO, is a
>"must-fix".
>
>2) '$8' gives '$8' in mathtext and an error in usetex.
>  This could be
>solved in two ways:
>
>a) document the difference
>b) make '$8' give '$8' in usetex as well
>
>I realise b) is technically making usetex accept a string
> that is not
>normally valid TeX -- but it's not like a user would ever enter
>'$8' and
>*want* to get a TeX error back.  And usetex strings aren't
>perfectly TeX
>anyway.
>
>Personally, I'm leaning toward b), because it requires less
> mental
>effort for the user turning usetex on/off.  And it doesn't
> force us to
>backtrack on the idea of supporting "$100.00" easily.
>
>But before I commit -- any feedback?
>
>  I opposed to b). If we go that route, we can look forward to
> advertising usetex as "a latex backend, with familiar,
> standard latex markup, except when it isnt."
>
> It's not as bad as that.  '\$8' will still work as in LaTeX as it
> always has and as a LaTeX expert would expect it to.  All I'm
> proposing is that '$8', which is currently a LaTeX syntax error,
> will behave as it does when usetex is turned off.  So it's not
> breaking anything that's already valid.
>
> It's a question of which pain is worse, I guess.
>
> The deeper question is -- should usetex even strive to have any
> compatibility with standard text?  If not, then I can see your point.
>
>
> http://matplotlib.sourceforge.net/users/mathtext.html advertises \$ as 
> markup for $.
That's always worked and still worked -- that's not the bug at hand. 
> I think it was unwise to accept $ for $ in mathtext in the first 
> place, since mathtext uses tex markup anyway.
I'm not proposing that at all.  I think we're running into a 
misunderstanding about what I mean by "mathtext" and the scope of the 
proposed change.  By mathtext, I mean "the text between a pair of $ $ 
when usetex is off".  mathtext aims to be TeX-compatible (for a 
subset).  Regular text does not (and in fact has no markup whatsoever).  
That last point, I believe, is the root of this problem and why 
reconciling usetex with non-usetex may be a losing battle, as you're 
starting to convince me.  usetex is simply not the same thing as regular 
matplotlib text.

I'll clarify anyway -- but I'm starting to think that unless there is 
someo

Re: [matplotlib-devel] git questions

[Michael Droettboom]

Thanks.  These are really helpful pointers.  For me, this is the one 
missing piece that would help me use git full-time, particularly with 
the way matplotlib and other projects I work on are laid out in SVN.  So 
I'm pretty motivated to figure this out.

I'll certainly share any findings in this regard.

Cheers,
Mike

Andrew Straw wrote:
> Hi Mike,
>
> I have not imported the branches. ( IIRC, this was there were several
> that weren't MPL but other parts of the repo such as py4science,
> toolkits and so on).  It may be possible to add just the 0.98.5
> maintenance branch without the others, but I won't have a chance
> immediately to play around with that.
>
> To add all the branches to your git repo, you might be able to add
> something like "branches = branches/*:refs/remotes/branches/*" to the
> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
> This will grab all the branches over all svn history, which will, I
> think, pull in py4science and toolkits branches... And I guess the
> download time from svn will be extremely long... In that case it's
> probably better to rsync from sourceforge's server to a local disk and
> do the git svn checkout that way making a whole new git repo.
>
> It may be worth attempting to talk to some real git/svn gurus at this
> point about tracking (only one or a couple) svn branches with git
> branches. So far, I've only dealt with the trunk in my git/svn
> interoperation experience.
>
> -Andrew
>
> Michael Droettboom wrote:
>   
>> Thanks.  I've incorporated your docs into the developer documentation.
>>
>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>> branch with git.  SVN tags/* show up as available remote branches, but 
>> not branches/*, which leaves me a bit stumped?  If you've done this and 
>> there's a quick answer, let me know, otherwise I'll do a little digging 
>> to see if it's possible.
>>
>> Mike
>>
>> Andrew Straw wrote:
>> 
>>> 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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
>
> And I forgot that because mathtext used to be an all-or-nothing 
> enterprise, there was no reason to escape the $ in regular text. Once 
> you made it possible to embed mathtext in a regular string, I think it 
> would have been better in the long run to require \$, but the powerful 
> financial interests and their fat-cat lobbyists won the day.
lol ... I'm ready for my payout now... :)
>  
>
> What I would prefer is to raise a deprecation warning when an odd 
> number of dollar signs are encountered, giving people time to learn to 
> escape their $ and modify their code. I wonder how disruptive this 
> would be to people using mpl for finance? If that is unacceptable, I 
> guess the best solution is as you propose, but maybe usetex should 
> issue a warning that it has modified the string rather than strictly 
> interpret it.
That sounds like a good solution going forward.
>
> Do you know if there are any other inconsistencies between the 
> text/mathtext markup and latex?
>
Doh!  That's actually a very illuminating question...  One which, had I 
thought of it earlier, I might have never thought of dealing with $ at 
all... ;)

Basically anything that is meaningful markup in TeX would have to be 
escaped for usetex, but not for regular text.  In that sense, $ is just 
one of many.  Think of "{brackets}", for instance.  You get "{brackets}" 
with regular text, and "brackets" with usetex.  I'm sure the list of 
these things is fairly long.  We don't want to start implicitly escaping 
those for usetex.  All this supports the theory that perhaps the gap 
between regular text and usetex is too wide to reasonably bridge.

While originally this morning thought "let's just fix the 
inconsistencies", I'm now leaning to just adding a note to the docs that 
"regular text and usetex is fundamentally incompatible in a lot of ways" 
and leaving it at that.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] errors building docs

[Michael Droettboom]

Darren Dale wrote:
> I am seeing some errors when I build the docs, including import errors 
> for nonexistent date_support and basic_units modules, and:
I added the ability for explicitly setting sys.path so that modules in 
the same directory as an example would be importable.  It looks likes 
that has somehow broken again. I'll look into it.
>
>
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.BracketB: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.Curve: arg is not a Python 
> function 
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.CurveA: arg is not a Python 
> function
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.CurveAB: arg is not a Python 
> function   
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.CurveB: arg is not a Python 
> function
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.Fancy: arg is not a Python 
> function 
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.Simple: arg is not a Python 
> function
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ArrowStyle.Wedge: arg is not a Python 
> function 
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.LArrow: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.RArrow: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.Round: arg is not a Python 
> function   
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.Round4: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.Roundtooth: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.Sawtooth: arg is not a Python 
> function
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.BoxStyle.Square: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ConnectionStyle.Angle: arg is not a Python 
> function
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ConnectionStyle.Angle3: arg is not a Python 
> function   
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotlib.patches.ConnectionStyle.Arc: arg is not a Python 
> function  
> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: 
> (WARNING/2) error while formatting signature for 
> matplotli

[matplotlib-devel] Next release

[Michael Droettboom]

It's been an unusually bumpy release cycle through no fault of the 
people involved.  We've just been unlucky this time, I guess... ;)

So -- more bad news:

Julien pointed out a very serious bug this morning, that may warrant 
another release...  The gridlines jump around while panning and 
zooming.  I fully take credit for introducing this bug a few weeks ago 
trying to fix a log scaling problem.  It is now fixed in SVN on 0.98.5 
maint and trunk.

Julien also pointed out another bug related to antialiasing which was 
caused by code that I intended to be experimental (it was committed only 
to the trunk) but made it into the release.  I just want to make a 
gentle reminder to the hard-working and exhausted release team to please 
make the next bugfix release from the branch, not the trunk.

Unfortunately, I think because of the seriousness of these bugs, another 
release should be made asap.  I sincerely apologize for the work this 
causes others.  I'm willing to volunteer to do a release to make it up 
to Charlie and John, but I'm worried, having seen how finicky the 
build/release process is, that I may not actually help... ;(

As for the release following that -- maybe we should step back and try 
to find some ways to make it easier.  I'm not trying to second guess us 
here -- I think we're doing a lot of things right, but just want to get 
a discussion going about whether there's any more tweaks that would be 
beneficial.

We're doing some good things already -->

1) The release guide in the developer docs

2) John's recent commits of OS-X release tools

3) Using maintenance branches

We may also want to consider -->

4) Automating (scripting) more of the process where possible (I'm sure 
that's not straightforward... just thinking out loud)

5) Release formal "release candidates" -- IMHO these would be most 
useful if we expect more people to download and try them than are 
already tracking SVN.  But even without that, it may help find packaging 
bugs (such as the configobj stuff) before declaring something a "release".

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
>
> I think it would be worth stating in the docs that # $ % & ~ _ ^ \ { } 
> \( \) \[ \] have special meaning in latex but not in regular mpl text, 
> so buyer beware. It might be nice if mpl regular text rendered the 
> escaped version of all these characters the same way latex does, that 
> would make it easier to go from text to usetex.
For now, I'll just resolve the one straightforward bug (that \$ does not 
work in regular text with usetex off), and document these special 
characters as you suggest -- just so the fix will be in the next 
0.98.6.  I'm going to hold off on these other issues of compatibility 
until they have clearer answers.
>
> Speaking of implicitly doing the right thing, last night I was in the 
> middle of working through a difficult bug when Windows Vista *kicked 
> me out without asking or issuing a warning*, installed updates, and 
> rebooted. I'm still mumbling under my breath about it. Friggin jerks.
I feel your pain.  I've been there.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?

[Michael Droettboom]

One question to ask is whether we need both the .pdf and .html manuals, 
or whether that could be broken up into two packages.  That seems like 
an easy one if that fits Debian policies (which I know nothing about) -- 
and wouldn't degrade the documentation experience at all.

Is there any way to transparently gzip compress the html files (as I 
believe Debian does with manpages)?

Another option would be to not generate the high-res png and pdf 
examples.  (Either or both).  Just removing them after the fact won't 
work, since one would end up with broken links from the docs.  We would 
also have to change the html to not include those links.  It should be 
fairly simple to provide an option to the doc build system to do this, 
and I'm happy to implement that if we all agree that's the direction to 
take.

Beyond that, we'd be looking at selectively including certain examples, 
which I worry would add additional maintenance burden if there's too 
much divergence between the "full" and "small" manuals.  I think that 
road should be a last resort.
 
Mike

Sandro Tosi wrote:
> Hello,
> the problem is this:
>
> $ ls -l python-matplotlib-doc_0.98.5-1_all.deb
> -rw-r--r-- 1 morph morph 91141234 2008-12-16 10:39
> python-matplotlib-doc_0.98.5-1_all.deb
>
> 90M of doc package is a "little bit"... and expanded it's
>
> $ du . -hs
> 119M
>
> In this package we install: doc/build/html/
> doc/build/latex/Matplotlib.pdf examples/*
>
> So I dig into a bit to identify the cause of such a big jump (0.98.3
> has a 16M doc package) and the biggest dir seems to be
> html/_static/plot_directive/mpl_examples/pylab_examples with >50M (a
> full result of "find examples/ html/ -type d -exec du -s {} \;" is
> attached; if you need I can add a full file list). In that particular
> dir (like in many other) i see a png, and hi-res png and a pdf file:
> are those all needed?
>
> At the end, is there a way we packagers can reduce this package size?
> (a fast stat showed it would be the second biggest -doc package in
> Debian.)
>
> Thanks,
>   
> 
>
> --
> 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

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Doc changes

[Michael Droettboom]

I've been working on Debian's (Sandro Tosi's) request to produce a 
smaller doc tree...  If only I had known how much work was involved 
before I started!

SUMMARY: Since so much has changed in the doc build, I need help testing 
it in other environments -- particularly because LaTeX docs have never 
built on my machine.  I've done this on the branch, so the Debian guys 
can run with it, but it's a little risky, due to the depth of cuts I had 
to make.  I've tested successfully with Sphinx 0.5.1 and docutils 0.5.  
Please clean your checkout and then build for yourself and let me know 
if you see anything funny.

DETAILS:

You can now do

  python make.py --small html

which will only generate low-res PNGs for the html build.  "--small" has 
no effect for pdf build.

The payoff here is that the html tree goes from 109MB to 49MB.

There have been some fundamental changes to how files are staged in the 
doc build.  Rather than dumping everything in _static and then having 
Sphinx copy them over for us, our various extensions now either a) put 
the files directly into the build tree under build/html/_images or 
build/html/pyplot_directive, or b) stage things in 
build/pyplot_directive, and then copy to the build tree as needed.  The 
exception is the _static/examples directory (generated by gen_rst.py), 
since they will require some major work to know where the build 
directory is.

The plot_directive always builds all three versions of every plot (png, 
hires.png, pdf) into build/pyplot_directive.  Depending on a user 
setting, only some of these may be copied to the output directory.  The 
reason for this is so that switching between html and pdf builds works, 
and we don't get hundreds of false warnings from sphinx about missing 
files.  It took a while to arrive and that procedure... ;)

gen_gallery now runs in a sphinx callback (env-updated) after all the 
input files have been parsed, (and all the plots have been generated), 
but right before the html or latex is written out.  This eliminates the 
need to run the build multiple times, and the need to have an 
autogenerated file (doc/_templates/gallery.html) in SVN.  The thumbnail 
downsampling is now done as part of this step, rather than as part of 
plot_directive, since it isn't needed for LaTeX builds.

Something similar should be done for the examples, I just haven't gotten 
around to it yet.

Lastly, since files are in many different places, the Sourceforge site 
should probably be cleaned (if it isn't automatically already) to ensure 
we don't go over quota.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Doc changes

[Michael Droettboom]

Ok.  Based on your success report, I'll go ahead and merge this to trunk.

Sandro: please let me know if these changes break anything in your 
package build scripts.

Mike

John Hunter wrote:
> On Wed, Dec 17, 2008 at 10:52 AM, Michael Droettboom  wrote:
>
>   
>> SUMMARY: Since so much has changed in the doc build, I need help testing
>> it in other environments -- particularly because LaTeX docs have never
>> built on my machine.  I've done this on the branch, so the Debian guys
>> can run with it, but it's a little risky, due to the depth of cuts I had
>> to make.  I've tested successfully with Sphinx 0.5.1 and docutils 0.5.
>> Please clean your checkout and then build for yourself and let me know
>> if you see anything funny.
>>
>> DETAILS:
>>
>> You can now do
>>
>>  python make.py --small html
>>
>> which will only generate low-res PNGs for the html build.  "--small" has
>> no effect for pdf build.
>> 
>
> Very nice -- it seems like you've solved some of the unneeded rebuild
> problems we had been having too, because successive calls to make html
> seem to go much faster now.
>
>   
>> gen_gallery now runs in a sphinx callback (env-updated) after all the
>> input files have been parsed, (and all the plots have been generated),
>> but right before the html or latex is written out.  This eliminates the
>> need to run the build multiple times, and the need to have an
>> autogenerated file (doc/_templates/gallery.html) in SVN.  The thumbnail
>> downsampling is now done as part of this step, rather than as part of
>> plot_directive, since it isn't needed for LaTeX builds.
>> 
>
> I have built the pdf on a linux environment and the html on a linux
> and os x environment, so it is looking good.  I've built with and w/o
> the --small
>
>   
>> Lastly, since files are in many different places, the Sourceforge site
>> should probably be cleaned (if it isn't automatically already) to ensure
>> we don't go over quota.
>> 
>
> Will do -- some time ago I emailed the sf support people and asked for
> a quota increase, and they replied that there wasn't really a quota
> anymore, but I will clean it so we minimize our footprint.  And it
> they ever do get anxious about the size we consume, we can always go
> --small :-)
>
> Thanks again, sorry that was such a bear.  Hopefully the plot
> directive emerges stronger from the carnage.
>
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
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] Hatching support

[Michael Droettboom]

I've refactored hatching support to move the hatch design itself to the 
core, added support for them in the Agg and SVG backends, and simplified 
their usage in the PDF and PS backends.  It should now be easier to add 
new hatch styles if anyone ever feels artistic.

In order to use the same general approach in all backends, the PS 
backend now uses the makepattern command rather than a loop to draw each 
hatch line.  That may be a regression in certain situations (eg., old PS 
printers without enough memory).  So those who were using the old PS 
backend with hatches should test the new approach and report any problems.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] polar plotting and theta wrapping

[Michael Droettboom]

Eric Firing wrote:
> Mike, Jan,
>
> Any attempt to normalize the angles to a fixed range of length 2 pi 
> inside of mpl is sure to wreck valid user code; it merely moves the 
> trouble spot to a different angle.
Thanks for catching this.  Clearly that was a bone-headed fix on my 
part... :(
>
> In 6731 I reverted the normalization change from 6106, and also 
> improved the r-tick locations in cases where the actual r-data range 
> is small.
>
> Mike, of course I realized too late that I should have made the change 
> in the maintenance branch and used svnmerge to propagate it to the 
> trunk; should I just make the change manually in the branch?
That should work fine.  Then run "svnmerge merge ; svn commit" back on 
the trunk to mark it as merged.
>
> Polar plotting could still use more work, but I doubt I will be able 
> to do much any time soon.

Yeah -- there's lots of tricky side issues.

Cheers,
Mike

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Multipage pdf files

[Michael Droettboom]

It's slightly hackish, but would it be possible to do an "isinstance" 
check in savefig, and if the first arg is a PdfFile, set "format" to 
"pdf" automatically, and if "format" is set to something else raise an 
exception?  A little hackish because it doesn't necessarily scale to 
other formats easily, but it would prevent the user from shooting 
herself in the foot.

Mike

Jouni K. Seppänen wrote:
> I added support to the pdf backend for multipage pdf files. The current
> API (which I'm not entirely happy with) is that you create a PdfFile
> object, plot your figures, saving each one to the PdfFile object, and
> then close the object. The part I'm unhappy about is that because
> PdfFile is a file-like object - it has a write method - you can
> accidentally save your figure as a png into it and get a broken pdf
> file. You have to specify format='pdf' to savefig to avoid this.
>
> Here's an example:
>
> from matplotlib.backends.backend_pdf import PdfFile
>
> pdf = PdfFile('multipage_pdf.pdf')
>
> figure(...)
> # build your figure
> savefig(pdf, format='pdf')
>
> # repeat for all your figures
>
> pdf.close()
>
>
>   


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] polar plotting and theta wrapping

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>> Eric Firing wrote:
>>> Mike, Jan,
>>>
>>> Any attempt to normalize the angles to a fixed range of length 2 pi 
>>> inside of mpl is sure to wreck valid user code; it merely moves the 
>>> trouble spot to a different angle.
>> Thanks for catching this.  Clearly that was a bone-headed fix on my 
>> part... :(
>>>
>>> In 6731 I reverted the normalization change from 6106, and also 
>>> improved the r-tick locations in cases where the actual r-data range 
>>> is small.
>>>
>>> Mike, of course I realized too late that I should have made the 
>>> change in the maintenance branch and used svnmerge to propagate it 
>>> to the trunk; should I just make the change manually in the branch?
>> That should work fine.  Then run "svnmerge merge ; svn commit" back 
>> on the trunk to mark it as merged.
>
> Mike,
>
> The following is the result of svnmerge merge and svn status; I have 
> not yet run svn commit because the status output suggests to me that 
> things are getting merged that perhaps should not, since I don't know 
> anything about them.  Advice?
>
> Eric
>
> efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S 
> v0_98_5_maintproperty 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> --- Merging r6717 through r6732 into '.':
> Ulib/matplotlib/path.py
>
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> efir...@manini:~/programs/py/mpl/mpl_trunk$ svn status
>  M .
> ?  svnmerge-commit-message.txt
> ?  doc/build
> ?  doc/examples
> ?  doc/_static/inheritance0ca9968ee0.pdf
> ?  doc/_static/inheritance1bda3e63b5.pdf
> ?  doc/_static/inheritance829eaf436e.pdf
> ?  doc/_static/inheritance47732b7b79.pdf
> ?  doc/_static/inheritance0ca9968ee0.png
> ?  doc/_static/inheritancecbc02086c0.pdf
> ?  doc/_static/inheritance1bda3e63b5.png
> ?  doc/_static/inheritance829eaf436e.png
> ?  doc/_static/inheritance47732b7b79.png
> ?  doc/_static/mathmpl
> ?  doc/_static/inheritancecbc02086c0.png
> ?  doc/_static/plot_directive
> ?  doc/_static/examples
>  M doc/sphinxext/gen_gallery.py
>  M doc/sphinxext/gen_rst.py
>  M doc/pyplots/README
> ?  lib/matplotlib/cbook0.py
> ?  lib/matplotlib/colors0.py
> ?  lib/matplotlib/transform.py
> ?  lib/matplotlib/axes0.py
> M  lib/matplotlib/path.py
> ?  examples/tests/ps
> ?  examples/tests/agg
> ?  examples/tests/svg
> ?  examples/tests/pdf
> ?  examples/tests/template
These other modified files all look to be no-ops (they are property-only 
-- no diffs) -- probably the result of someone else manually backporting 
changes to the branch and not merging back to the trunk yet.  All seemed 
harmless, so I went ahead and committed the merge.

Mike

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Jouni K. Seppänen wrote:

Michael Droettboom  writes:

  

when running usetex_fonteffects.py [...]
TypeError: coercing to Unicode: need string or buffer, NoneType found
-> file = open(input, 'rb')



Perhaps your TeX installation doesn't have the font. If you run
"kpsewhich utmr8a.pfb", what do you get? If it does return something,
could you run the example with --verbose-debug?

  

> kpsewhich utmr8a.pfb
/usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb


The output of "python usetex_texteffects.py --verbose-debug" is attached.

Mike

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

$HOME=/home/mdroe
CONFIGDIR=/home/mdroe/.matplotlib
matplotlib data path 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /home/mdroe/.matplotlib/matplotlibrc
matplotlib version 0.98.6svn
verbose.level debug
interactive is False
units is False
platform is linux2
loaded modules: ['_bisect', 'xml.sax.urlparse', 'distutils', 
'matplotlib.errno', 'matplotlib.matplotlib', 'subprocess', 'xml._xmlplus', 
'gc', 'matplotlib.tempfile', 'distutils.sysconfig', 'ctypes._endian', 
'encodings.encodings', 'matplotlib.colors', 'numpy.core.numerictypes', 
'numpy.testing.sys', 'numpy.core.info', 'xml', 'numpy.fft.types', 
'numpy.ma.operator', 'numpy.ma.cPickle', 'struct', 'numpy.random.info', 
'tempfile', 'pprint', 'numpy.linalg', 'matplotlib.threading', 
'numpy.testing.operator', 'imp', 'numpy.testing', 'collections', 
'numpy.core.umath', 'distutils.types', 'numpy.lib.numpy', 
'numpy.core.scalarmath', 'zipimport', 'string', 'matplotlib.subprocess', 
'numpy.testing.os', 'matplotlib.locale', 'numpy.lib.arraysetops', 
'numpy.testing.unittest', 'numpy.lib.math', 'repr', 'matplotlib.__future__', 
'datetime', 'numpy.testing.re', 'numpy.version', 'numpy.lib.re', 
'distutils.re', 'ctypes.os', 'numpy.core.os', 'numpy.lib.type_check', 
'httplib', 'bisect', 'numpy.core._internal', 'signal', 'cmd', 
'numpy.lib.types', 'numpy.lib._datasource', 'random', 'numpy.ma.extras', 
'token', 'numpy.fft.fftpack_lite', 'matplotlib.cbook', 'ctypes.ctypes', 
'xml.sax.xmlreader', 'numpy.__builtin__', 'dis', 'distutils.version', 
'cStringIO', 'numpy.ma.core', 'numpy.numpy', 'matplotlib.StringIO', 'locale', 
'numpy.add_newdocs', 'numpy.lib.getlimits', 'base64', 'xml.sax.saxlib', 
'matplotlib.numpy', 'numpy.testing.types', 'numpy.lib.sys', 'encodings', 
'numpy.ma.itertools', 'StringIO', 'numpy.lib.io', 'numpy.imp', 'bdb', 
'numpy.testing.decorators', 'matplotlib.warnings', 'rfc822', 
'matplotlib.string', 'urllib', 'matplotlib.sys', 're', 
'numpy.lib._compiled_base', 'threading', 'numpy.random.mtrand', 'math', 
'numpy.fft.helper', 'fcntl', 'numpy.ma.warnings', 'inspect', 
'numpy.ma.inspect', 'UserDict', 'numpy.lib.function_base', 'distutils.os', 
'matplotlib', 'numpy.core.types', 'fnmatch', 'numpy.lib.info', 'ctypes', 
'_xmlplus', 'ctypes.struct', 'codecs', 'numpy.core._sort', 'numpy.os', 
'_locale', 'matplotlib.sre_constants', 'matplotlib.os', 'thread', 
'numpy.lib.ufunclike', 'numpy.core.memmap', 'traceback', 
'numpy.testing.warnings', 'xml.sax.sax2exts', 'weakref', 'itertools', 
'numpy.fft.fftpack', 'opcode', 'numpy.testing.imp', 'numpy.linalg.lapack_lite', 
'distutils.sys', 'os', 'marshal', 'numpy.lib.warnings', 'xml.sax.saxexts', 
'__future__', 'matplotlib.copy', 'xml.sax.types', 'numpy.random.numpy', '_sre', 
'unittest', 'numpy.core.sys', 'numpy.random', 'numpy.li

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Jouni: your latest commit resolves the issue for me.  Thanks!

Jae-Joon: Your preview.sty work seems to work great with the PDF backend 
(for me, at least).

Cheers,
Mike

Michael Droettboom wrote:
>
> Jouni K. Seppänen wrote:
>> Michael Droettboom  writes:
>>
>>  
>>> when running usetex_fonteffects.py [...]
>>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>>> -> file = open(input, 'rb')
>>> 
>>
>> Perhaps your TeX installation doesn't have the font. If you run
>> "kpsewhich utmr8a.pfb", what do you get? If it does return something,
>> could you run the example with --verbose-debug?
>>
>>   
> > kpsewhich utmr8a.pfb
> /usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb
>
>
> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>
> Mike
>
> 
>
> --
> 
>
> ___________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Sorry about the wild good chase.  I had fixed up an earlier exception 
which was simply a problem with formatting a verbose message.  That 
gives this, when running usetex_fonteffects.py (with all rcParams at 
defaults):

Traceback (most recent call last):
  File "usetex_fonteffects.py", line 22, in 
pylab.savefig('usetex_fonteffects.pdf')
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 550, in embedType1
' and effects ' + `fontinfo.effects`,
TypeError: cannot concatenate 'str' and 'NoneType' objects
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py(550)embedType1()
-> ' and effects ' + `fontinfo.effects`,*
*
Do an SVN update (r6736) and try again.  Then I get this:

 > python usetex_fonteffects.py
Traceback (most recent call last):
  File "usetex_fonteffects.py", line 22, in 
pylab.savefig('usetex_fonteffects.pdf')
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 553, in embedType1
t1font = type1font.Type1Font(fontinfo.fontfile)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
file = open(input, 'rb')
TypeError: coercing to Unicode: need string or buffer, NoneType found
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py(55)__init__()
-> file = open(input, 'rb')

So somehow, input is None, but I haven't had a chance to look any further.

Cheers,
Mike

Jouni K. Seppänen wrote:
> Michael Droettboom  writes:
>
>   
>> I'm currently getting this traceback with the PDF backend, whether 
>> "text.latex.preview" is True or False -- so it may be unrelated to your 
>> change, but I'm unable to test PDF at the moment.
>> 
>
> Based on the traceback, it looks like I have broken something recently --
> but what is the exact exception? I can't replicate the traceback myself.
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Thanks for the explanation.  The TeX install I have is the stock one 
with RHEL4, which is fairly old at this point.  I've had a number of 
other problems with it as well (such as it not being compatible with 
Sphinx). 

It's nice to know that matplotlib is at least handling this situation 
without crashing.  I think this solution (to warn) is adequate, 
especially given that most newer TeX distributions shouldn't have this 
issue.

Mike

Jouni K. Seppänen wrote:
> Michael Droettboom  writes:
>
>   
>> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>> 
>
> Thanks! The problem seems to be that your TeX configuration (pdftex.map)
> specifies using Helvetica without embedding it into the pdf file. This
> is deprecated in the PDF standard (PDF viewer applications have
> different replacements for the core 14 fonts, and many publishers insist
> that you embed all fonts you use) but I added support for it in 6737,
> with a warning displayed to the user.
>
> Could you see if it works for you now?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Very nice!

I'm currently getting this traceback with the PDF backend, whether 
"text.latex.preview" is True or False -- so it may be unrelated to your 
change, but I'm unable to test PDF at the moment.

Traceback (most recent call last):
  File "usetex_baseline_test.py", line 75, in 
plt.savefig("test.pdf")
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 553, in embedType1
t1font = type1font.Type1Font(fontinfo.fontfile)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
file = open(input, 'rb')

Also, it seems like the text alignment in the PS output is too low by a 
small constant factor.

Assuming those issues can be resolved, is there now any reason to use 
dviread, assuming preview.sty is installed?  If the preview.sty approach 
is superior, I wonder if we could:

a) Determine if preview.sty is installed, and if so, use it, otherwise 
fallback to dviread? (Then we could be a default "auto" setting for the 
rcParam).

b) Or better, include preview.sty with matplotlib and use it instead of 
a system installed copy, so that it's always available.  (This is both a 
licensing and version-compatibility question, really...)

It would be great to make this new behavior with the proper baseline 
more automatic.

Cheers,
Mike

Jae-Joon Lee wrote:
> Hello,
>
> I committed a patch to optionally use preview.sty with usetex=True.
> This is to support a baseline alignment.
>
> A summary of changes:
>
>  * added a get_text_width_height_descent() method in the TexManager
> class, and modified the agg, ps and pdf backends to utilize this
> method.
>
>  * added a new rc parameter, 'text.latex.preview'. If True,
> preview.sty is used to generate dvi files and baseline information of
> each dvi file is stored in a separate file.
> TexManager.get_text_width_height_descent() method uses this
> information.
>
>  * If text.latex.preview==False,
> TexManager.get_text_width_height_descent() method uses dviread module
> (this is what the pdf backend has been using), but the returned
> descent value of the text is sometimes incorrect.
>
>  * added an example ("usetex_baseline_test.py" ). The output is
> attached with this email.
>
> If you have a preview.sty installed, please test this (set
> "text.latex.preview=True" in you rc file) and report any problems.
> Regards,
>
> -JJ
>   
>
> 
>
> 
>
> ------
>   
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Michael Droettboom]

I have successfully used the git mirror to commit changes to the 
maintenance branch.  I've updated the matplotlib developer docs to 
describe how to do it (not that bad really), though it takes a while 
given the v0_98_4 "oops" branch ;)  I have yet to figure out all the 
loop-de-loops required to merge from the maintenance branch to the trunk 
in git and then push that all back to SVN (should be possible, but may 
not play well with svnmerge, anyway).  The good news is that, as always, 
svnmerge still works for that purpose.

Mike

Michael Droettboom wrote:
> Thanks.  These are really helpful pointers.  For me, this is the one 
> missing piece that would help me use git full-time, particularly with 
> the way matplotlib and other projects I work on are laid out in SVN.  So 
> I'm pretty motivated to figure this out.
>
> I'll certainly share any findings in this regard.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
>   
>> Hi Mike,
>>
>> I have not imported the branches. ( IIRC, this was there were several
>> that weren't MPL but other parts of the repo such as py4science,
>> toolkits and so on).  It may be possible to add just the 0.98.5
>> maintenance branch without the others, but I won't have a chance
>> immediately to play around with that.
>>
>> To add all the branches to your git repo, you might be able to add
>> something like "branches = branches/*:refs/remotes/branches/*" to the
>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>> This will grab all the branches over all svn history, which will, I
>> think, pull in py4science and toolkits branches... And I guess the
>> download time from svn will be extremely long... In that case it's
>> probably better to rsync from sourceforge's server to a local disk and
>> do the git svn checkout that way making a whole new git repo.
>>
>> It may be worth attempting to talk to some real git/svn gurus at this
>> point about tracking (only one or a couple) svn branches with git
>> branches. So far, I've only dealt with the trunk in my git/svn
>> interoperation experience.
>>
>> -Andrew
>>
>> Michael Droettboom wrote:
>>   
>> 
>>> Thanks.  I've incorporated your docs into the developer documentation.
>>>
>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>> branch with git.  SVN tags/* show up as available remote branches, but 
>>> not branches/*, which leaves me a bit stumped?  If you've done this and 
>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>> to see if it's possible.
>>>
>>> Mike
>>>
>>> Andrew Straw wrote:
>>> 
>>>   
>>>> 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

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

Since I suspect this change will be a little bit of work, I just wanted 
to put my hand up and say I'm looking into it so we don't duplicate 
effort here.

I think it's a worthwhile experiment, in any case.

Mike

Andrew Hawryluk wrote:
>
> I’m really excited about the new path simplification option for vector 
> output formats. I tried it the first time yesterday and reduced a PDF 
> from 231 kB to 47 kB. Thanks very much for providing this feature!
>
> However, I have noticed that the simplified paths often look more 
> jagged than the original, at least for my data. I can recreate the 
> effect with the following:
>
> [start]
>
> import numpy as np
>
> import matplotlib.pyplot as plt
>
> x = np.arange(-3,3,0.001)
>
> y = np.exp(-x**2) + np.random.normal(scale=0.001,size=x.size)
>
> plt.plot(x,y)
>
> plt.savefig('test.png')
>
> plt.savefig('test.pdf')
>
> [end]
>
> A sample output is attached, and close inspection shows that the PNG 
> is a smooth curve with a small amount of noise while the PDF version 
> has very noticeable changes in direction from one line segment to the 
> next.
>
> <> <>
>
> The simplification algorithm (agg_py_path_iterator.h) does the following:
>
> If line2 is nearly parallel to line1, add the parallel component to 
> the length of line1, leaving it direction unchanged
>
> which results in a new data point, not contained in the original data. 
> Line1 will continue to be lengthened until it has deviated from the 
> data curve enough that the next true data point is considered 
> non-parallel. The cycle then continues. The result is a line that 
> wanders around the data curve, and only the first point is guaranteed 
> to have existed in the original data set.
>
> Instead, could the simplification algorithm do:
>
> If line2 is nearly parallel to line1, combine them by removing the 
> common point, leaving a single line where both end points existed in 
> the original data
>
> Thanks again,
>
> Andrew Hawryluk
>
>
> 
>
> 
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ------------
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svnmerge broken?

[Michael Droettboom]

You need the '-S' parameter to specify a branch.  Otherwise, any arguments 
after the command name are just paths within the working copy, just like most 
other svn commands.

So you need to do:

> svnmerge.py merge -S v0_98_5_maint

I just tested a change to the branch followed by a merge and everything 
seems to be working fine here.

Eric Firing wrote:
> John Hunter wrote:
>   
> svnmerge init 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_5_maint
>   
That would have no effect without a following commit anyway... but 
please don't do that if you're not sure what you're doing.  That command 
really should only ever be needed once.  It's pretty hard to get into a 
state where it would ever need to be done again for a particular branch.
> but it looks like I was still in the wrong directory when I did that, so 
> I don't know if it had any useful effect.
>
> After getting into the right directory, some combination of svn up and 
> svnmerge merge seemed to get everything straightened out, with a little 
> editing to resolve conflicts along the way.
>   
You can do merges from within subdirectories, and it works just like 
most other svn commands when run from a subdirectory.  Generally, 
though, I like to catch all available merges and run from the root of 
the source tree.
> That was last night, in the misty past.  Now it looks like I am back 
> with the original problem I started with last night, and which you also 
> reported:
>
> efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge avail 
> /branches/v0_98_5_maint
> svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
>   
Again, you're specifying a path that doesn't exist within the source 
tree.  There is no need to specify a path (generally) with the "svnmerge 
avail" command.
> So, I'm baffled again.  It is as if Jae-Joon's commit since mine of last 
> night, and my corresponding "svn up" this morning, wiped out the 
> svnmerge tracking info.
>
> I suspect a brief wave of Mike's magic wand tomorrow morning will clear 
> away the fog.
>   
I think this all comes down to missing the '-S'.  I didn't need to get 
out my wand for this one... ;)

Mike

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

> Thanks for looking into this! The new plot is much improved, and the
> simplified calculations are a pleasant surprise. I was also testing the
> previous algorithm with solid_joinstyle set to "round" as it is the
> default in my matplotlibrc.
>
> I am probably not able to build your patch here, unless building
> matplotlib from source on Windows is easier than I anticipate. May I
> send you some data off the list for you to test?
>   
No problem.  I'd also want testing from others -- there aren't a lot of 
examples in matplotlib itself where simplification even kicks in.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

I've checked this change into SVN so others can test it out.

Assuming we don't discover any cases where this is clearly inferior, it 
should make it into the next major release.

Mike

Andrew Hawryluk wrote:
>> -Original Message-
>> From: Michael Droettboom [mailto:md...@stsci.edu]
>> Sent: 16 Jan 2009 1:31 PM
>> To: Andrew Hawryluk
>> Cc: matplotlib-devel@lists.sourceforge.net
>> Subject: Re: [matplotlib-devel] path simplification can decrease the
>> smoothness of data plots
>>
>> Michael Droettboom wrote:
>> 
>
> ...
>
>   
>> I've attached a patch that will only include points from the original
>> data in the simplified path.  I hesitate to commit it to SVN, as these
>> things are very hard to get right -- and just because it appears to
>> work better on this data doesn't mean it doesn't create a regression
>> 
> on
>   
>> something else... ;)  That said, it would be nice to confirm that this
>> solution works, because it has the added benefit of being a little
>> simpler computationally.  Be sure to blitz your build directory when
>> testing the patch -- distutils won't pick it up as a dependency.
>>
>> I've attached two PDFs -- one with the original (current trunk)
>> behavior, and one with the new behavior.  I plotted the unsimplified
>> plot in thick blue behind the simplified plot in green, so you can see
>> how much deviation there is between the original data and the
>> simplified line (you'll want to zoom way in with your PDF viewer to
>> 
> see
>   
>> it.)
>>
>> I've also included a new version of your test script which detects
>> "new"
>> data values in the simplified path, and also seeds the random number
>> generator so that results are comparable.  I also set the
>> solid_joinstyle to "round", as it makes the wiggliness less
>> 
> pronounced.
>   
>> (There was another thread on this list recently about making that the
>> default setting).
>>
>> Cheers,
>> Mike
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>> 
>
> Thanks for looking into this! The new plot is much improved, and the
> simplified calculations are a pleasant surprise. I was also testing the
> previous algorithm with solid_joinstyle set to "round" as it is the
> default in my matplotlibrc.
>
> I am probably not able to build your patch here, unless building
> matplotlib from source on Windows is easier than I anticipate. May I
> send you some data off the list for you to test?
>
> Regards,
> Andrew
>
> NOVA Chemicals Research & Technology Centre
> Calgary, Canada
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel