matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Thu, May 15, 2008 at 2:09 PM, Michael Droettboom <md...@st...> wrote:
> 
>> Oh joy! Maybe we should try (as Eric suggested) sscanf instead.
>> 
>
> OK, I just committed a change using scanf with type %lu. tkagg svn
> trunk users should test on any platform they have access to. 
Once we're confident in the fix, I'll backport this to 0.91.x, as it 
exists there also.
> I can
> try OS X tonight.
> 
Thanks.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 15, 2008 at 2:09 PM, Michael Droettboom <md...@st...> wrote:
> Oh joy! Maybe we should try (as Eric suggested) sscanf instead.
OK, I just committed a change using scanf with type %lu. tkagg svn
trunk users should test on any platform they have access to. I can
try OS X tonight.
JDH

Oh joy! Maybe we should try (as Eric suggested) sscanf instead.
Cheers,
Mike
John Hunter wrote:
> On Thu, May 15, 2008 at 8:08 AM, Michael Droettboom <md...@st...> wrote:
> 
>> I recently committed a fix (courtesy of Malte Marquarding) for segfaults
>> in the Tk backend. It seems it was converting a string of digits to a
>> "signed long" and then casting to a pointer. Unfortunately, it really
>> needs to be an "unsigned long" or overflow may occur. Since the C
>> standard library doesn't provide a version of "atol" for "unsigned
>> long", Malte's solution was to use C++ stringstreams. There's a good
>> chance that is portable, but it should probably be tested on Visual
>> Studio for good measure. Would any of you kind Windows folks be willing
>> to compile SVN trunk and open a plot with the TkAgg backend to verify this?
>> 
>
> Unfortunately, this change in segfaulting tkagg on solaris
>
> johnh@flag:~> uname -a
> SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc
> johnh@flag:~> gcc --version
> gcc (GCC) 3.4.1
>
>
> BUILDING MATPLOTLIB
> matplotlib: 0.98pre
> python: 2.4.5 (#4, Apr 12 2008, 09:09:16) [GCC 3.4.1]
> platform: sunos5
>
> REQUIRED DEPENDENCIES
> numpy: 1.2.0.dev5136
> freetype2: found, but unknown version (no pkg-config)
> * WARNING: Could not find 'freetype2' headers in any
> * of '/usr/local/include', '.',
> * '/usr/local/include/freetype2', './freetype2'.
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> * Could not find 'libpng' headers in any of
> * '/usr/local/include', '.'
> Tkinter: Tkinter: 39220, Tk: 8.4, Tcl: 8.4
> wxPython: no
> * wxPython not found
> Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
> pygobject: 2.12.3
> Qt: no
> Qt4: no
> Cairo: 1.4.0
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 15, 2008 at 8:08 AM, Michael Droettboom <md...@st...> wrote:
> I recently committed a fix (courtesy of Malte Marquarding) for segfaults
> in the Tk backend. It seems it was converting a string of digits to a
> "signed long" and then casting to a pointer. Unfortunately, it really
> needs to be an "unsigned long" or overflow may occur. Since the C
> standard library doesn't provide a version of "atol" for "unsigned
> long", Malte's solution was to use C++ stringstreams. There's a good
> chance that is portable, but it should probably be tested on Visual
> Studio for good measure. Would any of you kind Windows folks be willing
> to compile SVN trunk and open a plot with the TkAgg backend to verify this?
Unfortunately, this change in segfaulting tkagg on solaris
johnh@flag:~> uname -a
SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc
johnh@flag:~> gcc --version
gcc (GCC) 3.4.1
BUILDING MATPLOTLIB
 matplotlib: 0.98pre
 python: 2.4.5 (#4, Apr 12 2008, 09:09:16) [GCC 3.4.1]
 platform: sunos5
REQUIRED DEPENDENCIES
 numpy: 1.2.0.dev5136
 freetype2: found, but unknown version (no pkg-config)
 * WARNING: Could not find 'freetype2' headers in any
 * of '/usr/local/include', '.',
 * '/usr/local/include/freetype2', './freetype2'.
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 * Could not find 'libpng' headers in any of
 * '/usr/local/include', '.'
 Tkinter: Tkinter: 39220, Tk: 8.4, Tcl: 8.4
 wxPython: no
 * wxPython not found
 Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
 pygobject: 2.12.3
 Qt: no
 Qt4: no
 Cairo: 1.4.0

On Thu, May 15, 2008 at 8:08 AM, Michael Droettboom <md...@st...> wrote:
> I recently committed a fix (courtesy of Malte Marquarding) for segfaults
> in the Tk backend. It seems it was converting a string of digits to a
> "signed long" and then casting to a pointer. Unfortunately, it really
> needs to be an "unsigned long" or overflow may occur. Since the C
> standard library doesn't provide a version of "atol" for "unsigned
> long", Malte's solution was to use C++ stringstreams. There's a good
> chance that is portable, but it should probably be tested on Visual
> Studio for good measure. Would any of you kind Windows folks be willing
> to compile SVN trunk and open a plot with the TkAgg backend to verify this?
Charlie -- as far as I know you are the only developer who has win32
setup to build from svn. Can you test this when you get a chance?
Thanks,
JDH

I recently committed a fix (courtesy of Malte Marquarding) for segfaults 
in the Tk backend. It seems it was converting a string of digits to a 
"signed long" and then casting to a pointer. Unfortunately, it really 
needs to be an "unsigned long" or overflow may occur. Since the C 
standard library doesn't provide a version of "atol" for "unsigned 
long", Malte's solution was to use C++ stringstreams. There's a good 
chance that is portable, but it should probably be tested on Visual 
Studio for good measure. Would any of you kind Windows folks be willing 
to compile SVN trunk and open a plot with the TkAgg backend to verify this?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

hello,
is there an example in the distribution that shows these new features? 
How about the idea to allow for an option to get cumulative histograms, 
that sounded a very nice idea....
thanks,
Johann
Manuel Metz wrote:
> Eric Firing wrote:
> 
>> John Hunter wrote:
>> 
>>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> wrote:
>>>
>>> 
>>>> are slightly different). There's a slight compatibility issue in that
>>>> as it stands in that the returned tuple now has 4 values (I added a
>>>> list of the lines that are generated if the steps command is used),
>>>> but I can't really imagine how that could break anything but the
>>>> poorest-written code...
>>>> 
>>> I'm not sure I understand this: won't it break all code written like:
>>>
>>> n, bins, patches = ax.hist(x, 50, normed=1)
>>>
>>> which is the code presented in the histogram example and a fairly
>>> common approach. I don't see this as an example of the "poorest
>>> written code". I am inclined to not break this call signature
>>> unless the lines are actually used, ie 'step' in histtype. On a quick
>>> read of the code, you either get lines or patches but not both, so how
>>> about
>>>
>>> n, bins, patches = ax.hist(x, 50, normed=1)
>>>
>>> or
>>>
>>> n, bins, lines = ax.hist(x, 50, normed=1, histtype='lines')
>>> 
>> That was my first reaction also, but the proposed "stepfill" option 
>> yields a bunch of bar patches *and* a line. The solution may be to 
>> accomplish "stepfill" with two separate calls, or to have 4 outputs only 
>> in the "stepfill" case. Or, with sufficient rewriting I think the 
>> "stepfill" case could yield a single patch and a single line, and the 
>> third output in this case could be a single corresponding 2-element 
>> tuple or list. That is, the third output is considered simply a list of 
>> artists. Now I will stop speculating and leave it to Manuel to sort out.
>>
>> Eric
>> 
>
> I have just committed a patch to add the histogram step functionality. I 
> took Erik Tollerud's patch as basis, but basically re-wrote it 
> completely in the end ...
>
> The advantages are: (i) considerably smaller code and (ii) return 
> values are unchanged, ie.
>
> n, bins, patches = ax.hist(x, 50)
> n, bins, patches = ax.hist(x, 50, histtype='step')
>
> In contrast to the original patch, histtype='step' is filled and to 
> produce a non-filled histogram, one has to use facecolor='None'.
>
> Hope I haven't overlooked anything or broken other code ;-)
>
> Manuel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>