Hi Daniel
Just letting you know that I've just checked and found a similar memory leak. I was using example 19, but only because I had the code handy. I'm also using wxWidgets on Windows with Visual Studio (2008 in my case).

Alan - You asked recently about things that should be included in the next release. The replot function and the buffering that's done for this function is not quite up to scratch. Maybe a tidy up here should be on the list.

I can have a look into this tomorrow if no one else on the list gets chance.

Phil


From: "plplot-devel-request@lists.sourceforge.net" <plplot-devel-request@lists.sourceforge.net>
To: plplot-devel@lists.sourceforge.net
Sent: Wednesday, 24 October 2012, 18:27
Subject: Plplot-devel Digest, Vol 77, Issue 20

Send Plplot-devel mailing list submissions to
    plplot-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/plplot-devel
or, via email, send a message with subject or body 'help' to
    plplot-devel-request@lists.sourceforge.net

You can reach the person managing the list at
    plplot-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Plplot-devel digest..."


Today's Topics:

  1. Re: MinGW/MSYS PLplot test results on Wine (Arjen Markus)
  2. Re: map resolution (Andrew Ross)
  3. Memory leaks with wxWidgets (Jahn, Daniel)
  4. Re: map resolution (Alan W. Irwin)


----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Oct 2012 09:40:17 +0200
From: Arjen Markus <arjen.markus@deltares.nl>
Subject: Re: [Plplot-devel] MinGW/MSYS PLplot test results on Wine
To: "Alan W. Irwin" <irwin@beluga.phys.uvic.ca>
Cc: PLplot development list <Plplot-devel@lists.sourceforge.net>
Message-ID: <50879B61.8060102@deltares.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Alan,

On 2012-10-21 02:55, Alan W. Irwin wrote:

> A default build (no -DENABLE_* or -DPLD_* options) went into an
> infinite loop in the FindLua.cmake module.
>
> Is that infinite loop a Wine peculiarity or can you confirm that same
> issue there on Windows using your usual CMake command, but with
> -DENABLE_lua=ON?  I am presuming here that you actually don't have Lua
> installed which is also the case for my current Wine platform.  That
> case presumably exercises CMake logic that ends up as an infinite loop
> here.
>
> To avoid the infinite loop I specified -DENABLE_lua=OFF, and the cmake
> command (done with -DBUILD_TEST=ON) finished with no issues (although
> with most components/devices disabled).
>

This does not happen with MSYS on a plain Windows machine.
I had to explicitly set the path to the SWIG executable, because
without SWIG the Lua bindings are not even considered, but CMake
simply finished its job then concluding the Lua library or header files
were not present, so the Lua bindings were turned off.

It really seems to be a Wine issue.

> Here is the summary:
>
...
>
> In sum to help figure out which of the above results are due to Wine
> idiosyncracies, please let me know the -DENABLE_lua=ON results there
> (assuming you actually don't have Lua installed so you will be
> exercising the same CMake logic there as here); the "MSYS Makefiles"
> results there for our f95 interface and examples, the version of MinGW
> on your platform, and the Python results there. Finally, please
> continue with the f77 deprecation including ignoring maintenance, but
> put off its complete removal.
>

As for your Fortran problem, this again appears to be a Wine issue:
I have run the test_noninteractive target without any problems under
MSYS, using gfortran version 4.5.0 (so not indeed 4.5.2).

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.







------------------------------

Message: 2
Date: Wed, 24 Oct 2012 09:36:22 +0100
From: Andrew Ross <andrewross@users.sourceforge.net>
Subject: Re: [Plplot-devel] map resolution
To: phil rosenberg <philip_rosenberg@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <20121024083621.GA5392@gandalf.rivendell>
Content-Type: text/plain; charset=us-ascii

On Tue, Oct 23, 2012 at 06:11:51AM -0700, phil rosenberg wrote:
> Thanks Alan
> I hadn't noticed the missing Antarctica boundary section, I'm not sure why it should be missing, in one but not the other, but if I'm honest I'm not going to lose too much sleep if you intend to depreciate the old files anyway. Was it missing pre patch?
> ?
> Andrew, re?the bug, I can't remember if I encountered the bug using a different test shapefile. I think the old logic was if abs((int)longitude_change)>abs((int)latitude) (where _change is from one point to the next)then initiate wraparound fixing. Some comments indicated the intent was that near the poles points were more likely to span large longitude differences. Near the equator however the system broke down such that relatively small longitude changes were still bigger than the current latitude. By (int)ing the values longitude changes less than 1 were rounded to zero avoiding problems for the current files within 1 degree of the equator?(by design?). In the test shapefile I used, the straight African boundaries must have?had point-to-point differences larger than 1 degree so it all broke down. The current system is as general as I could make it. It might fall over if someone tries to draw a line >180 degrees, point-to-point, but I don't think
>  there is an obvious fix there.

Well if it is not something obvious in the old data sets then probably
not worth worrying about.

> ?
> As for your questions Alan.
> ?
> I don't have a preference about depreciation period.
> ?

This really boils down to whether we want to force a shapelib
dependency. If we do, then I think we could deprecate the old maps now
and maybe remove in the next but one release, so users of releases
have at least some warning. Otherwise we seem to be committed to
supporting the old version indeterminately to avoid the dependency,
which is probably not wise.

> I guess the four maps were used to show the different maps that came with PLplot, can't think of another reason.
> ?

I think so. The main reason for supplying all 4 shapefiles is for
compatibility. At the patch makes no API changes so having the same
map files means users whole only use the standard maps will have to
make no code changes. They will see slightly better quality maps,
but with the same basic information on.

> As for a blowaway example - the biggest advantage of using shapefiles is the access to a huge array of datasets in this format, many of which are much higher res than the old maps. So I think the 'hook' is either an example where the user can specify their own shapefile, or an example where we use a much higher res shapefile that we provide. For the latter case we could deliberately contrast the old coarse maps with a new higher res one - in which case the subject would need to be a coasline otherwise it wouldn't be on the old maps at all. For any Hitchhikers Guide fans out there Norway has a prize winning coast if memory serves correct.

A nice addition would be to supply a "demo" shapefile map in with the
examples. This could be a high resolution map for a small area,
demonstrating how users might like to add their own maps. Norway could
be good. Alternatively one of Phil's examples with a flight track
plotted over the SW of the UK would be good and would show how to use
the maps as a base for more interesting scientific plots.

Andrew



------------------------------

Message: 3
Date: Wed, 24 Oct 2012 11:37:47 +0200
From: "Jahn, Daniel" <Daniel.Jahn@harman.com>
Subject: [Plplot-devel] Memory leaks with wxWidgets
To: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID:
    <EEC932686450C84A9401CF6893602F561273D7C84F@HIKAWSEX04.ad.harman.com>
Content-Type: text/plain; charset="us-ascii"

Hello,

i'am using PLplot with wxWidgets.
I've tried to get some of the examples(wxPLplotdemo and x16) to run in my own wxWidgets Project and everything works great except for some detected memory leak messages from VisualStudioC++.
When I comment out "plotwindow->RenewPlot()" in the plot method of the wxPLplotdemo example, all of the memory leaks are gone. But if I resize the window which contains the plot, there are memory leaks again after closing this window(in both examples).

Here is a part of Debugoutput from VisualStudio after closing the (resized) Window:
Detected memory leaks!
Dumping objects ->
{50457} normal block at 0x01097990, 32 bytes long.
Data: <a  l  t  i  > 61 00 00 00 6C 00 00 00 74 00 00 00 69 00 00 00
{50387} normal block at 0x0109AE58, 32 bytes long.
Data: <d  i  s  t  > 64 00 00 00 69 00 00 00 73 00 00 00 74 00 00 00
{50317} normal block at 0x01098910, 52 bytes long.
Data: <B  o  g  o  > 42 00 00 00 6F 00 00 00 67 00 00 00 6F 00 00 00
{50242} normal block at 0x0109BDB8, 12 bytes long.
Data: <1  .  0  > 31 00 00 00 2E 00 00 00 30 00 00 00
{50172} normal block at 0x0109C998, 12 bytes long.
Data: <0  .  5  > 30 00 00 00 2E 00 00 00 35 00 00 00
{50102} normal block at 0x0109D4F8, 12 bytes long.
Data: <0  .  0  > 30 00 00 00 2E 00 00 00 30 00 00 00
{50032} normal block at 0x01099DF8, 16 bytes long.
Data: <-  0  .  5  > 2D 00 00 00 30 00 00 00 2E 00 00 00 35 00 00 00
{49962} normal block at 0x0109A4D8, 16 bytes long.
Data: <-  1  .  0  > 2D 00 00 00 31 00 00 00 2E 00 00 00 30 00 00 00
{49892} normal block at 0x01097330, 12 bytes long.
Data: <1  .  0  > 31 00 00 00 2E 00 00 00 30 00 00 00
{49822} normal block at 0x0109BAD8, 12 bytes long.
Data: <0  .  5  > 30 00 00 00 2E 00 00 00 35 00 00 00

When resizing the Window, I think there is a Problem with the axis labels!?
Do you know about some issue like that?

Thanks and Best Regards,
Daniel

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 4
Date: Wed, 24 Oct 2012 10:26:48 -0700 (PDT)
From: "Alan W. Irwin" <irwin@beluga.phys.uvic.ca>
Subject: Re: [Plplot-devel] map resolution
To: Andrew Ross <andrewross@users.sourceforge.net>
Cc: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>,    phil rosenberg
    <philip_rosenberg@yahoo.com>
Message-ID: <alpine.DEB.2.02.1210240913330.12141@enira.zlyna.ubzr>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hi Andrew and Phil:

On 2012-10-24 09:36+0100 Andrew Ross wrote:

> On Tue, Oct 23, 2012 at 06:11:51AM -0700, phil rosenberg wrote:

>> I hadn't noticed the missing Antarctica boundary section, I'm not
sure why it should be missing, in one but not the other, but if I'm
honest I'm not going to lose too much sleep if you intend to
depreciate the old files anyway. Was it missing pre patch?

The SourceForge websites (including plplot.sf.net) are now back up so
I was able to answer that question.  See
http://plplot.sourceforge.net/examples-data/demo19/x19.01.png which
does show the correct Antarctica boundary (right lower part near the
edge of the map) for the code for the last release.  So _apparently_
some change you did does compromise how the old maps without shapelibs
are rendered when HAVE_SHAPELIB is not #defined.  On the other hand,
my impression has been the old code has always had difficulty
rendering the old maps in a consistent way.  If you have been
following the Wine thread, I had a case where that old code (before
your changes were incorporated) rendered one of the pages of example
19 completely badly with what looks like bits and pieces of other maps
rendered on half of the map and the rest of it blank.  I just now
double checked the Wine run again for that case.  (This time done with
the new code, but with HAVE_SHAPELIB not #defined at the C level
because I haven't built shapelib for Wine yet.) That previous bad page
is now rendered fine although the Antarctica boundary problem still
occurs on the first page just like it does on Linux with HAVE_SHAPELIB
not #defined. So from this result it looks like the new code is at
least not making huge errors in rendering like happened for the old
code from time to time.  And I think the chances are that we will be
removing support for the old map formats in any case (see below). So I
am not too concerned about the Antartica boundary problem for the old
map format case.

>> ?
>> As for your questions Alan.
>> ?
>> I don't have a preference about depreciation period.
>> ?
>
> This really boils down to whether we want to force a shapelib
> dependency. If we do, then I think we could deprecate the old maps now
> and maybe remove in the next but one release, so users of releases
> have at least some warning. Otherwise we seem to be committed to
> supporting the old version indeterminately to avoid the dependency,
> which is probably not wise.

I believe the shapelib dependency for plmap (alone!) is not a big issue since the vast
majority of PLplot users don't use plmap in any case.  Furthermore,
the minority that do attempt to use that functionality in a serious
way are probably already fairly familiar with mapping software. So the
chances are they already know about shapelib and have it installed on
their system.  Or at least they won't feel that is an onerous
requirement especially if installing shapelib gives them access to a
blowaway example.

As to the blowaway shapefile example, it appears like both of you have
a couple of possibilities in mind.  So please go for it!

If everybody is satisfied that forcing shapelib dependency for plmap
is only a matter of time, then what remains is the decision about
when/how to force that dependency. In this case, I think we should
deprecate now in a realistic way. That is plmap becomes a no-op if
HAVE_SHAPELIB not #defined unless the user specifically opts in (with
a specific CMake option) to using the code that accesses and uses the
old format files.  We can decide later when to remove that option and
pull the plug on the old data formats and the code that supports that
old format depending on user feedback to the opt-in CMake option.  For
example, if we get no reaction at all (which I think is fairly likely)
to this deprecation period which requires opt-in for the old formats,
then I think we can safely pull the plug on those old formats for the
release after this one.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



------------------------------

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

------------------------------

_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


End of Plplot-devel Digest, Vol 77, Issue 20
********************************************