plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] PLPlot 6 and C++

[Jim D. <ji...@di...>]

> On May 28, 2015, at 5:50 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Jim
> Sorry, when I suggested a plmalloc and plfree I meant for these to
> call free and malloc, plus do some extra bookkeeping for us to keep
> track of our garbage collection needs, not as functions to interact
> directly with the OS to bypass free and malloc
> 
> I think the following could be a useful model. If in plstream we have
> variables something like
> void **tempMem;
> PLINT nTempMemArrays;
> void **nextTempMemArray;
> 
> then a function plmalloc, which would malloc the needed memory, assign
> it to nextTempMemArray, increment nextTempMemArray ready for the next
> allocation and if needed increase the size of tempMem.
> plfree would free the memory, search tempMem and set that element to
> NULL, possibly rolling back nextTempMemArray to the point after the
> last non-null pointer.
> Then when we return from an API function we can call a function
> something like plCleanMem which would free all memory from the tempMem
> array.
> In fact there would really be little need to call plfree unless the
> memory used is large and we are worried about resources - before
> returning to the calling program everything would be cleaned up
> anyway.
> 
> Even without a setjmp/longjmp error handling mechanism, this seems
> like a useful way for us to manage memory in plplot and avoid memory
> leaks. I have heard about using memory pools before, but what happens
> when the pool runs out, does the whole pool need reallocating? I think
> the method above does what we need with minimal fuss, but am very open
> to other suggestions - this is all new to me in a C context. Comments
> anyone?
> 
> The only issue I can think of is rentrancy. If we call an API function
> internally then it will free all the memory before returning, some of
> which is likely to still be in use. So something like this would need
> us to separate out the public API from internal functions which do the
> same job - the public API would just call the internal function. Does
> anyone know if this would affect the other language bindings?
> 

I would caution against this approach on rolling our own garbage collection.  It really is a hard problem to do correctly (let alone in a thread safe fashion).  We are far better off calling free() when the memory is not utilized. 

I would advocate using the atexit() function, which appears to be available on many (if not all) the platforms we support.

> With this in place, using setjmp/longjmp seems to give us a trivial
> way to remove all our plexit calls.
> 


> Phil
> 
> On 26 May 2015 at 21:17, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> 
>> 
>>> On May 26, 2015, at 3:53 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>> 
>>> Okay, well it was an option I thought I would put out there as I think
>>> it was worth considering. I will try to answer the questions people
>>> had anyway in case people are interested.
>>> 
>>> Regarding domestic bindings, the C front end would remain. Although
>>> the API would have to change if we wanted to return an error code. but
>>> this is about plplot internal code. What is the maximum number of
>>> levels back which we might need to pass an error code? A dozen or more
>>> probably. The idea is to avoid all that internal book keeping.
>>> Especially if 10 layers down a memory allocation fails. Every layer up
>>> from this needs to have code to deal with checking error codes for
>>> every function it calls and then free resources and propagate that
>>> error code. With the C++ model a throw does all that automatically.
>>> 
>> 
>> I was looking at consolidating all the error/warning messages routines into one or two functions and create a new file in the src directory. One of the motivations was to cleanup some of the mallocs and static char array allocations that are scattered throughout the code. I have some code that I have been using for awhile that I was going to offer. The other advantage is that it makes is easier to implement different translations.
>> 
>>> Regarding efficiency. There would almost certainly be no change. The
>>> compiler would probably optimise away anything superfluous.
>>> 
>>> As far as I know C++ is ubiquitous. The earliest C++ compilers
>>> actually rewrote the C++ to C and passed it to a C compiler!
>>> 
>>> Compilation speed for C++ can be slower if there is a lot of use of
>>> Templates. Templates are functions or classes which can have a version
>>> for any variable type, so instead of writing
>>> int round( int var, int basis);
>>> float round( float var, float basis);
>>> double round( double var, doublebasis);
>>> ...
>>> 
>>> you have
>>> template<class T>
>>> T round( T var, T basis);
>>> 
>>> Then the user can call round with any type and it will work, providing
>>> the code is compilable when you replace T with your type or class. But
>>> there is a compiletime cost associated with the extra work required by
>>> the compiler to do this.
>>> 
>>> Regarding name mangling we can use extern C to give C name mangling to
>>> the API, then the library, both static and dynamic as I understand it,
>>> behaves just like a C library.
>>> 
>>> As far as using a C++ compiler is concerned I am afraid that is
>>> something I have never worried about as I only write C++ programs so I
>>> always link against C runtimes. But as Alan says we already use C++
>>> code in PLPlot so this should already be taken care of.
>>> 
>>> If we are not interested in moving to C++ then we still need a method
>>> to propagate errors up through the multiple layers of code in the
>>> PLPlot library and do so in a way which minimises the risk of memory
>>> or other resource leaks. Because I work in C++ I'm not necessarily the
>>> best person to know best practice for this. But here are some ideas. I
>>> would be very interested to hear comments and more suggestions.
>>> 
>>> 1) We make every internal function in PLPlot return an error code and
>>> check these codes religiously at every call. Even simple functions
>>> would probably have to do this because in the future simple functions
>>> may grow to more complex ones and changing a function that previously
>>> returned a meaningful value to one which returns an error code is
>>> likely to be error prone so best get them all out of the way.
>>> 
>>> 2) We include an error code in the PLStream struct. We then check this
>>> after every function call to check if it has changed. Again this just
>>> requires us to be religious about checking the current error code.
>>> 
>>> 3)I just found out about setjmp and longjmp. These are C macros. As
>>> far as I can tell setjmp saves the state of the program stack and
>>> creates a jump point. Calling longjump jumps back to the jump point
>>> and restores the state. However, any memory malloc'd in the meantime
>>> will leak, unless we have some way to free it later. This might be
>>> conceivable by having an array of pointers in the PLStream to all
>>> memory allocated (maybe create a function plmalloc and plfree to deal
>>> with this?) which we can deal with at the end. Does anyone have any
>>> experience with setjmp and longjmp or  any advice? I also don't know
>>> how it deals with re-entrancy or nesting of setjmp calls. Or how to
>>> deal with our C++ code calling our C code - does our C++ code only
>>> call the public API or does it have access to internal routines?
>>> 
>> 
>> I have used the setjmp/longjmp approach. You definitely want to minimize the mallocs and the "distance" you jump. I prefer to do big mallocs and then partition the chunk of memory as needed rather than calling malloc multiple times. That helps when unwinding to cleanup on an error condition. Wrapping malloc/free with a plmalloc/plfree approach can be useful if the intent is to help cleanup. I do not recommend trying to manage memory because it is hard job to do correctly.
>> 
>>> 4) Any other suggestions?
>>> 
>>> All these methods require us to have some strategy for dealing with
>>> freeing memory although it is often trivial, in some cases this can be
>>> complex and a strong candidate for future bugs and memory leaks.
>>> 
>>> I'm really keen to hear people's thoughts on this. As I said I work in
>>> C++, so I don't know best practice in C for dealing with this, but we
>>> definitely need to make a call and have a definite strategy for this
>>> otherwise it will be a nightmare.
>>> 
>>> Phil
>>> 
>>> 
>>>> On 25 May 2015 at 21:06, Alan W. Irwin <ir...@be...> wrote:
>>>>> On 2015-05-25 17:29-0000 Arjen Markus wrote:
>>>>> 
>>>>> An issue related to the use of C++ that has not been raised yet, but
>>>> which surfaced recently in my comprehensive testing efforts is the
>>>> fact that linking a C++ program requires a C++-enabled linker. Thus
>>>> introducing C++ as the language in which PLplot is to be implemented
>>>> would complicate the use of static builds. That may not be the most
>>>> common option nowadays, but I think we need to take a conscious
>>>> decision: do we want to continue to support static builds or not? One
>>>> pro for static builds is that they make deployment, especially of
>>>> binary-only distributions much easier (and safer).
>>>> 
>>>> Hi Arjen:
>>>> 
>>>> Yes, I think we should keep supporting static builds which work
>>>> virtually perfectly now with our CMake-based build systems for the
>>>> build of PLplot from source and the build of the installed examples.
>>>> 
>>>> I assume what you mean by a C++-enabled linker is that extra libraries
>>>> have to be linked in for that case.  Our CMake build handles this
>>>> situation with ease both for the core build and installed examples
>>>> build.  So static linking is already completely supported in that case.
>>>> 
>>>> Of course, there is currently a limitation on our traditional
>>>> (Makefile + pkg-config) build for e.g., Fortran examples where
>>>> pkg-config does not automatically know the name/location of the
>>>> special C++ library that needs to be linked in for a given C++
>>>> compiler so the user would have to add that link himself to the
>>>> pkg-config results to successfully build the Fortran examples using
>>>> our traditional build system for the installed examples.
>>>> 
>>>> Currently this problem occurs if C++ code is included in libplplot
>>>> from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
>>>> very common case (or should be) to have those device drivers enabled
>>>> so if we adopt C++ for the core library this limitation in our
>>>> traditional build will essentially just stay the same in most cases.
>>>> So I don't see this limitation of our traditional build system for the
>>>> installed examples as a big concern with switching our core library to
>>>> C++ in all cases.
>>>> 
>>>> Don't get me wrong, I would like this limitation to be resolved so
>>>> that our traditional build of the installed examples works as well as
>>>> the CMake build of those.  When discussing this with Andrew I
>>>> mentioned one possibility for implementing a fix for this issue, but
>>>> that is a lot of work which I am going to leave to others if they want
>>>> to make our Makefile+pkg-config approach as high quality as the
>>>> CMake-based one for building our installed examples.
>>>> 
>>>> 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
>>>> __________________________
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>> Performance metrics, stats and reports that give you Actionable Insights
>>>> Deep dive visibility with transaction tracing using APM Insight.
>>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>> _______________________________________________
>>>> Plplot-devel mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Jim D. <ji...@di...>]

> On May 31, 2015, at 10:11 PM, Jim Dishaw <ji...@di...> wrote:
> 
> Yep, I will take a look
> 
> 
> 
>> On May 31, 2015, at 9:32 PM, Alan W. Irwin <ir...@be...> wrote:
>> 
>>> On 2015-05-31 22:06+0100 Phil Rosenberg wrote:
>>> 
>>> Hi Alan
>>> You should now find that the plbuf.c warning is gone. I haven't
>>> touched the plmeta files. I will leave these to Jim as I don't know
>>> that code well.
>> 
>> @ Phil: I confirm you fix, and thanks!
>> 
>> @Jim:
>> 
>> The remaining warnings are
>> 
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘read_header’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ was declared here
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘plreadmetafile’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was declared here
>> 

I think these two patches will fix the warnings (I don’t get any warnings with clang, but it does not have the -Wmaybe-uninitialized option). 

Re: [Plplot-devel] Minor patch to ignore Mac OS X autogenerated files

[Alan W. I. <ir...@be...>]

On 2015-06-01 14:29-0400 Jim Dishaw wrote:

> Mac OS X creates hidden files to store file/directory attribute files.  I added a pattern to .gitignore to ignore those files.

Pushed (with a change to also ignore those files when generating a source
distribution tarball on Mac OS X, see commit id b121708).

Thanks!

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
__________________________

Re: [Plplot-devel] Example 3 text cropping

[Alan W. I. <ir...@be...>]

On 2015-06-01 19:01+0100 Phil Rosenberg wrote:

> Hi Alan

> If you run the example with default size, then resize the window
down to a few tens of pixels then you will see the issue. It occurs
because the text remains the same size. So spills over the edge of the
viewport.

Hi Phil:

I have just tried resizing with -dev xwin, qtwidget, wxwidgets, and
xcairo.

The first two are fine, and resize the graphics and text size
appropriately for the resize, and keep the resulting plot centred on
the resized window.

@Arjen and Phil: Please check on Windows that the qtwidget device
also resizes appropriately on that platform.

@Phil:

The wxwidgets device handles the graphics resizing correctly, and also keeps the
plot centred on the resized window.  However, as you said above the
text is not currently resized. Therefore, I believe that is the issue
you should address, and the 3rd example is fine as is.

@To those here who are familar with the cairo family of device drivers:

The xcairo device on platforms with X does not handle resizes
correctly at all; it just displays the same plot with everything the
same size and position regardless of how it is resized.  I am hoping
someone here will fix those resizing issues.  And I presume a similar
fix needs to be applied for the wincairo device on platforms with
access to raw Windows graphics.

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
__________________________

Re: [Plplot-devel] Example 3 text cropping

[Phil R. <p.d...@gm...>]

Hi Alan
If you run the example with default size, then resize the window down to a few tens of pixels then you will see the issue. It occurs because the text remains the same size. So spills over the edge of the viewport.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎01/‎06/‎2015 18:12
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] Example 3 text cropping

On 2015-06-01 11:07+0100 Phil Rosenberg wrote:

> Hi All
> When I was fighting with aspect ratios with the new wxWidgets driver I
> found that when example 3 was scaled down small the axis labels became
> cropped. This was on my bug list to fix. However I have now realised
> that the reason for the cropping is that the example uses  plptex
> rather than plmtex so writes text within the viewport - hence the
> clipping.
>
> My first instinct was to change this, but the change would need
> propagating to all other languages. In reality I don't think it is a
> big issue, but I just thought I would flag it and if anyone wants to
> volunteer changing this for other languages I would do it for C/C++.
> But if not I will leave it alone.

Can you give a specific example of the issue you are concerned with?  For
example, if I try

examples/c/x03c -dev wxwidgets -geometry 200x150

I an barely make out any details, but it appears to me the text size
is scaled well enough that it does not wander into an area where it
will be clipped.

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
__________________________

Re: [Plplot-devel] PLplot and C++

[Alan W. I. <ir...@be...>]

To Phil and Arjen:

Thanks to both of you for the useful information below which should
help me to sort out the C++ linking issue for the traditional build.

Alan


On 2015-06-01 10:59+0100 Phil Rosenberg wrote:

> I have the same empty variable for my visual studio 64 bit plplot build.
>
> Looking at https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
>
> " If you include one of the C++ Standard Library Header Files in your
> code, a Standard C++ Library will be linked in automatically by Visual
> C++ at compile time."
>
> So as Arjen suggested. Visual Studio is clever enough to detect
> whether or not to link in the C++ runtime library.
>
> Note however, if you have not selected the static runtime option in
> cmake then to deploy your plplot application you must also install the
> (freely available) version of the c/c++ runtime for the visual studio
> version you compiled on. Not that this makes any difference for
> building and running on the same machine.
>
> On 1 June 2015 at 08:09, Arjen Markus <Arj...@de...> wrote:
>> Hi Alan,
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Meanwhile, would both of you guys please let me know the exact results for
>>> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
>>> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
>>> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
>>> the Cygwin and MSVC platforms?
>>>
>> For the Cygwin 64bits build I see the following (CMake 3.1.2):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
>> "stdc++;cygwin;advapi32;shell32;user32;kernel32")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
>> "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
>>
>>
>>
>> For MinGW/MSYS I get this (CMake 3.2.1, no typo):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
>> "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
>> "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")
>>
>>
>>
>> And for MSVC (32 bits, CMake 2.8.12.2):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")
>>
>> I have no idea why these are empty – maybe the linker itself takes care of
>> all of the required libraries?

__________________________
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
__________________________

Re: [Plplot-devel] Code-browsing GUI for PLplot git repository and git feed no longer work

[Alan W. I. <ir...@be...>]

On 2015-05-31 10:58-0700 Alan W. Irwin wrote:

> I have reported this issue to SF (see
> <https://sourceforge.net/p/forge/site-support/10445/>).
>
> My checks (comparing a fresh clone with my present clone) indicate our
> git repository is still OK which was my principal concern.
>
> I am fairly sure this empty (except for the phrase "No (more) commits"
> GUI is the result of some Allura bug rather than malicious damage, but
> we will see what the SF team say about that.
>
> Obviously, the directions for getting git access to our code and the
> ability to browse our code that are normally available via this GUI
> will not be available until the SF team restore this GUI.  But perhaps
> not so obviously the git feed that e-mailed us every time one of us
> changed the code is controlled by this GUI, and I noticed over the
> last day or so that feed had quit working.  Presumably it will
> start working again once this GUI is restored, but meanwhile you
> should pay close attention to "git fetch" and "git log origin/master"
> results to figure out the commits done by others.
>
> If you want to follow the above ticket, click on the
> appropriate button at that URL.  And once it is resolved
> I will say something more here.

This morning my ticket item was still unread, but the problem resolved
itself (presumably due to something done at SF such as a reboot that
was a response to a different issue).  The feed is working again (this
time with all Phil's and my recent changes jammed into the same mail
message), and the GUI is working fine as well.

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
__________________________

Re: [Plplot-devel] Example 3 text cropping

[Alan W. I. <ir...@be...>]

On 2015-06-01 11:07+0100 Phil Rosenberg wrote:

> Hi All
> When I was fighting with aspect ratios with the new wxWidgets driver I
> found that when example 3 was scaled down small the axis labels became
> cropped. This was on my bug list to fix. However I have now realised
> that the reason for the cropping is that the example uses  plptex
> rather than plmtex so writes text within the viewport - hence the
> clipping.
>
> My first instinct was to change this, but the change would need
> propagating to all other languages. In reality I don't think it is a
> big issue, but I just thought I would flag it and if anyone wants to
> volunteer changing this for other languages I would do it for C/C++.
> But if not I will leave it alone.

Can you give a specific example of the issue you are concerned with?  For
example, if I try

examples/c/x03c -dev wxwidgets -geometry 200x150

I an barely make out any details, but it appears to me the text size
is scaled well enough that it does not wander into an area where it
will be clipped.

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
__________________________

[Plplot-devel] Example 3 text cropping

[Phil R. <p.d...@gm...>]

Hi All
When I was fighting with aspect ratios with the new wxWidgets driver I
found that when example 3 was scaled down small the axis labels became
cropped. This was on my bug list to fix. However I have now realised
that the reason for the cropping is that the example uses  plptex
rather than plmtex so writes text within the viewport - hence the
clipping.

My first instinct was to change this, but the change would need
propagating to all other languages. In reality I don't think it is a
big issue, but I just thought I would flag it and if anyone wants to
volunteer changing this for other languages I would do it for C/C++.
But if not I will leave it alone.

Phil

Re: [Plplot-devel] PLplot and C++

[Phil R. <p.d...@gm...>]

 I have the same empty variable for my visual studio 64 bit plplot build.

Looking at https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

" If you include one of the C++ Standard Library Header Files in your
code, a Standard C++ Library will be linked in automatically by Visual
C++ at compile time."

So as Arjen suggested. Visual Studio is clever enough to detect
whether or not to link in the C++ runtime library.

Note however, if you have not selected the static runtime option in
cmake then to deploy your plplot application you must also install the
(freely available) version of the c/c++ runtime for the visual studio
version you compiled on. Not that this makes any difference for
building and running on the same machine.

On 1 June 2015 at 08:09, Arjen Markus <Arj...@de...> wrote:
> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Meanwhile, would both of you guys please let me know the exact results for
>> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
>> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
>> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
>> the Cygwin and MSVC platforms?
>>
> For the Cygwin 64bits build I see the following (CMake 3.1.2):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
> "stdc++;cygwin;advapi32;shell32;user32;kernel32")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
> "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")
>
> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
>
>
>
> For MinGW/MSYS I get this (CMake 3.2.1, no typo):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
> "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
> "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")
>
>
>
> And for MSVC (32 bits, CMake 2.8.12.2):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")
>
> I have no idea why these are empty – maybe the linker itself takes care of
> all of the required libraries?
>
>
>
> 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.

Re: [Plplot-devel] PLplot and C++

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Meanwhile, would both of you guys please let me know the exact results for
> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
> the Cygwin and MSVC platforms?
>
For the Cygwin 64bits build I see the following (CMake 3.1.2):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;cygwin;advapi32;shell32;user32;kernel32")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")

set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")



For MinGW/MSYS I get this (CMake 3.2.1, no typo):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")



And for MSVC (32 bits, CMake 2.8.12.2):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")

I have no idea why these are empty - maybe the linker itself takes care of all of the required libraries?



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.

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Jim D. <ji...@di...>]

Yep, I will take a look



> On May 31, 2015, at 9:32 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-05-31 22:06+0100 Phil Rosenberg wrote:
>> 
>> Hi Alan
>> You should now find that the plbuf.c warning is gone. I haven't
>> touched the plmeta files. I will leave these to Jim as I don't know
>> that code well.
> 
> @ Phil: I confirm you fix, and thanks!
> 
> @Jim:
> 
> The remaining warnings are
> 
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘read_header’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ was declared here
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘plreadmetafile’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was declared here
> 
> Would you please take responsibility for analyzing these and either
> fixing (if possibility exists for using uninitialized value) or
> else squelching by doing a dummy initialization with comment (if false alarm)?
> 
> 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
> __________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. I. <ir...@be...>]

On 2015-05-31 22:06+0100 Phil Rosenberg wrote:

> Hi Alan
> You should now find that the plbuf.c warning is gone. I haven't
> touched the plmeta files. I will leave these to Jim as I don't know
> that code well.

@ Phil: I confirm you fix, and thanks!

@Jim:

The remaining warnings are

/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘read_header’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ was declared here
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘plreadmetafile’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was declared here

Would you please take responsibility for analyzing these and either
fixing (if possibility exists for using uninitialized value) or
else squelching by doing a dummy initialization with comment (if false alarm)?

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
__________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil R. <p.d...@gm...>]

Hi Alan
You should now find that the plbuf.c warning is gone. I haven't
touched the plmeta files. I will leave these to Jim as I don't know
that code well.

Phil

On 31 May 2015 at 20:14, Alan W. Irwin <ir...@be...> wrote:
> On 2015-05-31 18:59+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I've worked this out, the line in question is in a function called
>> with the possibly uninitialized variable.
>> I'm writing the code now to double check everything although the only
>> case where we could get an uninitialized variable would be for a
>> corrupted buffer.
>
>
> Hi Phil:
>
> Our e-mails crossed, but it is great to read above you are analyzing
> the situation and figuring out the source of these warnings. When I
> see your commit with the fix for these warnings, I will follow up by
> trying the same build test again.
>
>
> 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
> __________________________

Re: [Plplot-devel] PLplot and C++

[Alan W. I. <ir...@be...>]

On 2015-05-27 14:50-0700 Alan W. Irwin wrote:

> [.... F]or my latest build [on Linux I found]
>
> software@raven> grep CMAKE_CXX_IMPLICIT_LINK_ CMakeFiles/3.0.2/CMakeCXXCompiler.cmake
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;m;c")
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib")
> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")

To Arjen and Phil:

Today I plan to tackle the job of parsing this information so that our
traditional build system for the static case will have the same C++
compiler library information as our CMake-based build, and I
will ask you both to test the result on Cygwin and MSVC.

Meanwhile, would both of you guys please let me know the exact results
for CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for
both the Cygwin and MSVC platforms?

I would appreciate you sharing that knowledge (especially if you don't
have to do anything special other than to look it up in an old build
directory) since it should help me to figure out in advance if I have
to do anything special to deal with drive letters, etc., for the
various Cygwin and MSVC cases.

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
__________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. I. <ir...@be...>]

On 2015-05-31 18:59+0100 Phil Rosenberg wrote:

> Hi Alan
> I've worked this out, the line in question is in a function called
> with the possibly uninitialized variable.
> I'm writing the code now to double check everything although the only
> case where we could get an uninitialized variable would be for a
> corrupted buffer.

Hi Phil:

Our e-mails crossed, but it is great to read above you are analyzing
the situation and figuring out the source of these warnings. When I
see your commit with the fix for these warnings, I will follow up by
trying the same build test again.

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
__________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. I. <ir...@be...>]

On 2015-05-31 18:33+0100 Phil Rosenberg wrote:

> Hi Alan
> I'm attacking my to do list. Do you still get these warnings? I just
> looked and the line 1309 no longer makes sense in terms of a reference
> to cmd so I guess the code has changed since then. I don't get any
> unallocated variable warnings for plbuf in VC++ so perhaps someone
> else fixed this issue.

With the following compiler options:

CFLAGS=-O3 -fvisibility=hidden -Wuninitialized

and gcc on Linux, the following warnings are
generated from building the plplot target:

/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘read_header’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ was declared here
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘plreadmetafile’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was declared here
[...]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was declared here

You should be able to replicate this on your Linux box and probably
also on your Cygwin platform.

> On 12 March 2015 at 20:14, Alan W. Irwin <ir...@be...> wrote:
>>
>> gcc is generating these warnings when building libplplot.  Would you
>> please take a look to see whether this is either a real uninitialized issue
>> that needs to be fixed or a false alarm?

My guess is these are all due to false alarms from gcc, but if your
analysis says that is the case it is also worth squelching
these warnings by dummy initializing some variables with appropriate comment
like

// To squelch spurious gcc uninitialized warnings
     PLINT i=0; // or whatever is needed

so that real and useful warnings from gcc considering uninitialized
variables will not be obfuscated by known false alarms.

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
__________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil R. <p.d...@gm...>]

Hi Alan
I've worked this out, the line in question is in a function called
with the possibly uninitialized variable.
 I'm writing the code now to double check everything although the only
case where we could get an uninitialized variable would be for a
corrupted buffer.

Phil

On 31 May 2015 at 18:33, Phil Rosenberg <p.d...@gm...> wrote:
>  Hi Alan
> I'm attacking my to do list. Do you still get these warnings? I just
> looked and the line 1309 no longer makes sense in terms of a reference
> to cmd so I guess the code has changed since then. I don't get any
> unallocated variable warnings for plbuf in VC++ so perhaps someone
> else fixed this issue.
>
> Phil
>
> On 12 March 2015 at 20:14, Alan W. Irwin <ir...@be...> wrote:
>> To Phil:
>>
>> gcc is generating these warnings when building libplplot.  Would you
>> please take a look to see whether this is either a real uninitialized issue
>> that needs to be fixed or a false alarm?
>>
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
>> ‘read_header’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:336:8: warning:
>> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:301:9: note: ‘pdf_rc’
>> was declared here
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
>> ‘plreadmetafile’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:373:23: warning:
>> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1112:14: note: ‘plm’
>> was declared here
>> [....]
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was
>> declared here
>>
>> 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
>> __________________________

[Plplot-devel] Code-browsing GUI for PLplot git repository and git feed no longer work

[Alan W. I. <ir...@be...>]

I have reported this issue to SF (see
<https://sourceforge.net/p/forge/site-support/10445/>).

My checks (comparing a fresh clone with my present clone) indicate our
git repository is still OK which was my principal concern.

I am fairly sure this empty (except for the phrase "No (more) commits"
GUI is the result of some Allura bug rather than malicious damage, but
we will see what the SF team say about that.

Obviously, the directions for getting git access to our code and the
ability to browse our code that are normally available via this GUI
will not be available until the SF team restore this GUI.  But perhaps
not so obviously the git feed that e-mailed us every time one of us
changed the code is controlled by this GUI, and I noticed over the
last day or so that feed had quit working.  Presumably it will
start working again once this GUI is restored, but meanwhile you
should pay close attention to "git fetch" and "git log origin/master"
results to figure out the commits done by others.

If you want to follow the above ticket, click on the
appropriate button at that URL.  And once it is resolved
I will say something more here.

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
__________________________

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil R. <p.d...@gm...>]

 Hi Alan
I'm attacking my to do list. Do you still get these warnings? I just
looked and the line 1309 no longer makes sense in terms of a reference
to cmd so I guess the code has changed since then. I don't get any
unallocated variable warnings for plbuf in VC++ so perhaps someone
else fixed this issue.

Phil

On 12 March 2015 at 20:14, Alan W. Irwin <ir...@be...> wrote:
> To Phil:
>
> gcc is generating these warnings when building libplplot.  Would you
> please take a look to see whether this is either a real uninitialized issue
> that needs to be fixed or a false alarm?
>
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
> ‘read_header’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:336:8: warning:
> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:301:9: note: ‘pdf_rc’
> was declared here
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
> ‘plreadmetafile’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:373:23: warning:
> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1112:14: note: ‘plm’
> was declared here
> [....]
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was
> declared here
>
> 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
> __________________________

Re: [Plplot-devel] memory leaks in wxWidgets driver?

[Phil R. <p.d...@gm...>]

 Hello Laurent
I have just fixed the memory leak bug you reported. Thanks for
reporting it. You should be able to download the fixed version from
the git repo via sourceforge.

Phil

On 21 May 2015 at 22:51, Phil Rosenberg <p.d...@gm...> wrote:
> Hello Laurent
> My apologies for not responding sooner. I have unfortunately not been
> able to spend time on PLplot recently, but am now getting back to
> things. I will look into the memory leaks you described as soon as I
> can.
>
> Phil
>
> On 21 April 2015 at 21:42, laurent Berger <Lau...@un...> wrote:
>> Hi,
>>
>> I look fo memory leaks in my program using plplot 5.11. I am using vs
>> 2013 with Visual leak detector.
>> This tools finds two memory leaks in my plplot code in wxPlplotWindow.h
>> at line 187(m_memory_dc) and line 195 (m_gcDc).
>> When I close wxPlplotwindow<> this two pointers are not deleted. May be
>> I don't use good function to close wxPlplotwindow<>. Can you tell me how
>> can I close it?
>>
>> Thanks you for yours answers and for new version of plplot.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wxPLViewer text size

[Phil R. <p.d...@gm...>]

 Hi alan
The missing subpage rendering is now fixed - at least on Windows. This
turned out to be a wxWidgets bug which I have reported
http://trac.wxwidgets.org/ticket/17013 and put some workarounds in
place.

I will look at the optimisations to speed up rendering as soon as I can.

Phil

On 30 May 2015 at 20:29, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> Thanks for that. There is clearly some issue with subpages. For example 1 I
> have just realised I only get the first subpage rendered. I will sort that
> asap and make a commit.
>
> Re the timing, nearly a minute to render is clearly awful. I haven't seen
> anything so bad on Windows. Now I know it is so bad I can add some extra
> optimizations.
>
> Thanks Alan for the testing, I will let you know when the next version is
> ready.
>
> Phil
> ________________________________
> From: Alan W. Irwin
> Sent: ‎30/‎05/‎2015 19:07
> To: Phil Rosenberg
> Cc: plp...@li...
> Subject: Re: [Plplot-devel] wxPLViewer text size
>
> On 2015-05-30 12:11+0100 Phil Rosenberg wrote:
>
>> Hi All
>> I have just pushed some changes allowing wxWidgets driver to generate
>> text sizes for layout purposes. However for use with wxPLViewer (i.e.
>> when wxWidgets driver is used from the command line) this involves
>> multiple checks backwards and forward. this is pretty slow. I have
>> checked example 26 and this works fine, but takes a couple of seconds
>> to render.
>
> Hi Phil:
>
> I am afraid it is bad news for this series of changes.
>
> The speed on Linux has now (commit a407d24) slowed to a crawl, and
> additional rendering issues have been introduced.  Furthermore, time
> measurements vary all over the map.
>
> For example,
>
> software@raven> time examples/c/x01c -dev wxwidgets
> PLplot library version: 5.11.0
>
> real    0m9.242s
> user    0m0.040s
> sys     0m0.064s
> software@raven> time examples/c/x01c -dev wxwidgets
> PLplot library version: 5.11.0
>
> real    0m57.337s
> user    0m0.080s
> sys     0m0.196s
>
> and later the time went back down to ~10 seconds or so.  Furthermore,
> for this example, only the first of the 4 subpages are rendered.  It
> is not a hang, because after the first subpage is rendered (taking
> somewhere between 10 seconds and 60 seconds) hitting the enter key
> exits the example.
>
> My bet is there has been some wxwidgets bug introduced by the recent
> changes and concentrating on example 1 would be a good way to debug
> whatever the problem is.
>
> After doing that, if the time required to render example 1 is still
> more than a fraction of a second, then I would carefully review the
> client-server model you are using for wxPLViewer and why your text
> size changes have made such a drastic reduction in speed.
>
> 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
> __________________________

Re: [Plplot-devel] Next steps for comprehensive testing on Cygwin

[Alan W. I. <ir...@be...>]

On 2015-05-22 12:57-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> So to help you with that installation task I did some research, and here are the
>> missing PLplot components from your current comprehensive testing (in order of the
>> CMake WARNING messages about these issues); the regular expression search
>> term I used at the 64-bit version of <http://cygwin.com/cgi-bin2/package-grep.cgi> to
>> find the package; and the corresponding name of that package.
>>
>> PLplot component          GUI search term  Cygwin 64-bit
>>
>> java bindings             java             Nothing relevant
>> octave bindings           octave           octave-devel-3.8.2-1
>> Tcl/Itcl bindings         itcl             tcl-itcl-3.4.1-1
>> ada bindings              gnatmake         cygwin32-gcc-ada-4.9.2-1
>> lua bindings              lua.h            lua-5.1.5-1
>> d bindings                gdc              Nothing relevant
>> libqhull prerequisite     qhull.h          libqhull-devel-2012.1-2
>> psttf device driver       LASi.h           libLASi-devel-1.1.1-2
>> pyqt4 bindings            sip.h            python-sip-4.16.7-1
>> wxwidgets device driver   wx.h             libwx_gtk2u2.8-devel-2.8.12.1-5
>> pdf device driver         hpdf.h           Nothing relevant
>> ocaml bindings            ocamlc           ocaml-base-4.01.0-2
>> gtk+-x11-2.0 support      gtk+-x11-2.0.pc  libgtk2.0-devel-2.24.28-1
>>
>> Installation of these packages and my fixes for any issues you find with that
>> broadened scope of comprehensive testing should make PLplot nearly as powerful
>> on Cygwin as it currently is on Linux, and I am very much looking forward to
>> achieving that goal!
>>

> I installed the above packages (oh, forgot about wxwidgets), but
some of them were not fully acknowledged by CMake (see the attached
tarball) .

>
>> From the report by CMake:
>
> -        Itcl is not accepted, because CMake could not find the accompanying library - that is available though
>
> -        Ocaml is not accepted, because CMake can not find camlidl, well that is simply not in the installation. I installed all things that contained "caml" in their name/description, but it is missing from Cygwin nonetheless
>
> -        Qhull is not accepted either, same issue as for Itcl
>
> -        Pyqt4 is not accepted because CMake does not find sip - again it all seems to be there
>
> -        Tk is turned off because there was no X Window server, but that has different issues

Hi Arjen:

I was extremely happy to see that your report contained no messages
concerning WIN32 not being defined on Cygwin so that we can finally
put that build-system issue to rest.  And this time there did
not appear to be any warnings concerning X or X access.  Did you
change something with regard to X?

Here is my review of your remaining cmake WARNINGS about missing
components.

1. Octave:

-- WARNING: Required external octave header, hdf5.h, not found. Disabling octave bindings
-- OCTAVE_LIBRARIES = /usr/lib/octave/3.8.2/liboctave.dll.a
-- OCTINTERP_LIBRARIES = /usr/lib/octave/3.8.2/liboctinterp.dll.a
-- OCTAVE_INCLUDE_PATH = /usr/include/octave-3.8.2;/usr/include/octave-3.8.2/octave

My 64-bit search for hdf5.h indicates you should install
libhdf5-devel-1.8.14-1. (I have now [commit id = 7d1dfa8] modified the above WARNING message
to make that clearer.)

On Debian wheezy, the octave-devel package depends on libhdf5-devel,
but I guess that is not the case for Cygwin (which is likely a
packaging bug on that platform) which is why you have to install this
extra package on that platform.  I hope that change will finally allow
you to test our Octave binding and examples on Cygwin.

2. Tcl/Tk/Itcl/Itk

-- Start determining consistent system data for Tcl and friends
-- Found Tclsh: /usr/bin/tclsh (found version "8.5") 
-- Found TCL: /usr/local/lib/libtcl86.a
-- Could NOT find TCLTK (missing:  TK_LIBRARY TK_INCLUDE_PATH) 
-- Could NOT find TK (missing:  TK_LIBRARY TK_INCLUDE_PATH)
-- Looking for Tcl - found
-- TCL_INCLUDE_PATH = /usr/include
-- TCL_LIBRARY = /usr/local/lib/libtcl86.a
-- TCL_STUB_LIBRARY = /usr/local/lib/libtclstub86.a
-- TCL_LIBRARY_PATH = /usr/local/lib
-- Looking for tclsh - found
-- TCL_TCLSH = /usr/bin/tclsh
-- Looking for Tcl version with tclsh - found
-- PLPLOT_TCL_VERSION = 8.5.18
-- WARNING: Tcl library version = 8.6 that is extracted from the
    library name is not consistent with PLPLOT_TCL_VERSION = 8.5.18
[...]

The PLplot build system continues with Tcl/Tk/Itcl/Itk configuration
despite this last version inconsistency warning, and that eventually
lead to other issues.  But it seems to me this is the problem you need
to address since this is a serious inconsistency issue, i.e, you are
attempting to combine Tcl from Cygwin with some other /usr/local
version which is obviously not from an official Cygwin package.

So if you want to continue to use the official Cygwin version of tclsh
that you have installed with tcl-8.5.18-1 it is essential you also
install the consistent set of Cygwin development packages, e.g.,
tcl-devel-8.5.18-1, tcl-tk-devel-8.5.18-1, tcl-itcl-3.4.1-1, and
tcl-itk-3.3-2 (found respectively by using the search strings
"tcl-devel", "tk-devel", itcl.h, and itk.h).  Note that installation
of tcl-tk-devel-8.5.18-1 should also take care of the two "-- Could
NOT find..." messages above.  Also, I note you set TCL_INCLUDE_PATH,
but please try without that workaround which I doubt will be necessary
if you have the correct Cygwin packages installed.

You may have to set CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH
environment variables to force CMake to find consistent
Tcl/Tk/Itcl/Itk versions and to avoid using the /usr/local version you
also seem to have.  Or that might not be necessary.  Also, another
option is if the /usr/local version is some left over version you do
not have any further use for I would just delete it to keep it from
confusing CMake.

Once you install the appropriate development packages, I am pretty
sure this will take care of all remaining Tcl/Tk/Itcl/Itk
inconsistency warnings, but if not, there should be enough information
given out by our build system to allow you to diagnose and fix 
exactly what that remaining Tcl/Tk/Itcl/Itk version inconsistency
issue(s) might be.

3. Ada

-- WARNING: gnat library not found. Disabling ada bindings

Sorry.  I gave you an incorrect cygwin32-gcc-ada-4.9.2-1 package to
install above.  I now realize that is a 32-bit version of the Ada
compiler with libraries in a different location that only a 32-bit gcc
could find.  So you should purge that package and any other 32-bit
compiler packages it sucked in as dependencies from your system and
install instead gcc-ada-4.9.2-3 which should be exactly consistent
with your principal 64-bit gcc package.  And this illustrates the
point (valid on both Linux and Cygwin) that you should always keep an
exact record of what is installed so that it is easy to purge again.
And in any case I hope you are keeping an exact record (or will do so
from now on) since the list of Cygwin packages that should be
installed as PLplot prerequisites is important information that should
be in our wiki.

4. Lua.  Your install of lua-5.1.5-1 lead to no obvious configuration,
build, or run-time errors. So that is already an excellent result, and
I checked further in, e.g., shared/output_tree/make_noninteractive.out
to find the following:

lua
   Missing examples            :
   Differing graphical output  :  04 26
   Missing stdout              :
   Differing stdout            :

which I exactly replicate here for the same Lua version (5.1) that is
available on Cygwin.  So that exact similarity between Cygwin and Linux
is the best you can do at the present time.

However, note that the best PLplot support for Lua is for 5.2 where
the above issues disappear here. So to get that same perfect result
eventually there, I suggest you gently encourage the Lua packager for
Cygwin to upgrade to 5.2.  :-)

5: libqhull

-- WARNING: qhull library not found.  Setting PL_HAVE_QHULL to OFF.

The above failure message is way too terse.  I have now changed that.

A typical set of failure messages on Linux for qhull is now

-- qhull_a.h header could not be found
-- qhull library could not be found
-- Could NOT find QHULL (missing:  QHULL_INCLUDE_DIRS QHULL_LIBRARIES
QHULL_LIBRARY_DIRS) 
-- QHULL_INCLUDE_DIRS = 
-- QHULL_LIBRARIES = 
-- WARNING: at least one of QHULL_INCLUDE_DIRS or QHULL_LIBRARIES is
false so setting PL_HAVE_QHULL to OFF.

And here is a typical set of success messages on Linux for qhull:

-- Found QHULL: /home/software/qhull/install/include 
-- Looking for qh_new_qhull
-- Looking for qh_new_qhull - found
-- QHULL_INCLUDE_DIRS = /home/software/qhull/install/include
-- QHULL_LIBRARIES = /home/software/qhull/install/lib/libqhull.so
-- QHULL_RPATH = /home/software/qhull/install/lib

The other issue here is your search for qhull failed unexpectedly.
If you look in libqhull-devel-2012.1-2,
it contains

/usr/include/libqhull/qhull_a.h

The issue is that our qhull find module was searching for
qhull/qhull_a.h rather than libqhull/qhull_a.h.  So I have now (commit
id = 87a9504 ) fixed that so it looks for both.  This also required
that I change the style of our qhull #includes in that commit from

#include <qhull/qhull_a.h>
==>
#include <qhull_a.h>

I am hoping that these changes will fix the Cygwin qhull troubles
and therefore make PLplot's plgriddata command on Cygwin just as powerful
as it is on Linux.

6. psttf device driver.  All seems well there now.  That device driver
implements the psttfc and psttf devices which should produce really
nice-looking PostScript results for you on Cygwin.

7. pyqt4 bindings

-- WARNING: sip not found so setting ENABLE_pyqt4 to OFF.

I notice that sip.exe is located in the python-sip-4.16.7-1 package at
/usr/lib/python2.7/site-packages/sip.exe rather than in the expected
/usr/bin/sip.exe location.  That seems like a Cygwin packaging error
to me.  Try working around that issue by putting
/usr/lib/python2.7/site-packages/ on your PATH to see if that makes
your pyqt4 issues go away.

8. wxwidgets device driver.  Please do install
libwx_gtk2u2.8-devel-2.8.12.1-5.

9. ocaml bindings

-- OCAMLC = /usr/bin/ocamlc.opt
-- WARNING:camlidl not found. Disabling ocaml bindings

I agree with your analysis above that camlidl is not available on
Cygwin.  Since camlidl is used to help generate the ocaml binding
for PLplot, this is an ocaml binding showstopper on Cygwin that
we can do nothing about (unless you request Cygwin packaging of camlid,
and someone implements that).

10. gtk+-x11-2.0 support.  All appeared to be well in this case.

To summarize all of this, there appears to be nothing you can do for
java, d, pdf, or ocaml. Components that you just got to work this time
or which should be fine on your next try due to changes I made are the
lua binding, libqhull support library, psttf device driver, and
gtk+-x11-2.0 support. However, there is more you can still do for
Octave (install an additional package); Tcl/Tk/Itcl/Itk (get rid of
version inconsistency issues by installing relevant packages); Ada (uninstall the incorrect package I
suggested [and its dependencies that were installed] and install the
correct Ada package instead); pyqt4 (put sip.exe on your PATH); and
wxwidgets (please install libwx_gtk2u2.8-devel-2.8.12.1-5).

Please test again with the above additional packages installed, the
suggested PATH change, and for the latest git version of PLplot (which
includes my recent fix that affects Cygwin).  I am very much looking
forward to those still broader test results on Cygwin.

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
__________________________

Re: [Plplot-devel] wxPLViewer text size

[Phil R. <p.d...@gm...>]

Hi Alan
Thanks for that. There is clearly some issue with subpages. For example 1 I have just realised I only get the first subpage rendered. I will sort that asap and make a commit.

Re the timing, nearly a minute to render is clearly awful. I haven't seen anything so bad on Windows. Now I know it is so bad I can add some extra optimizations.

Thanks Alan for the testing, I will let you know when the next version is ready.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎30/‎05/‎2015 19:07
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] wxPLViewer text size

On 2015-05-30 12:11+0100 Phil Rosenberg wrote:

> Hi All
> I have just pushed some changes allowing wxWidgets driver to generate
> text sizes for layout purposes. However for use with wxPLViewer (i.e.
> when wxWidgets driver is used from the command line) this involves
> multiple checks backwards and forward. this is pretty slow. I have
> checked example 26 and this works fine, but takes a couple of seconds
> to render.

Hi Phil:

I am afraid it is bad news for this series of changes.

The speed on Linux has now (commit a407d24) slowed to a crawl, and
additional rendering issues have been introduced.  Furthermore, time
measurements vary all over the map.

For example,

software@raven> time examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.0

real    0m9.242s
user    0m0.040s
sys     0m0.064s
software@raven> time examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.0

real    0m57.337s
user    0m0.080s
sys     0m0.196s

and later the time went back down to ~10 seconds or so.  Furthermore,
for this example, only the first of the 4 subpages are rendered.  It
is not a hang, because after the first subpage is rendered (taking
somewhere between 10 seconds and 60 seconds) hitting the enter key
exits the example.

My bet is there has been some wxwidgets bug introduced by the recent
changes and concentrating on example 1 would be a good way to debug
whatever the problem is.

After doing that, if the time required to render example 1 is still
more than a fraction of a second, then I would carefully review the
client-server model you are using for wxPLViewer and why your text
size changes have made such a drastic reduction in speed.

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
__________________________

Re: [Plplot-devel] wxPLViewer text size

[Alan W. I. <ir...@be...>]

On 2015-05-30 12:11+0100 Phil Rosenberg wrote:

> Hi All
> I have just pushed some changes allowing wxWidgets driver to generate
> text sizes for layout purposes. However for use with wxPLViewer (i.e.
> when wxWidgets driver is used from the command line) this involves
> multiple checks backwards and forward. this is pretty slow. I have
> checked example 26 and this works fine, but takes a couple of seconds
> to render.

Hi Phil:

I am afraid it is bad news for this series of changes.

The speed on Linux has now (commit a407d24) slowed to a crawl, and
additional rendering issues have been introduced.  Furthermore, time
measurements vary all over the map.

For example,

software@raven> time examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.0

real    0m9.242s
user    0m0.040s
sys     0m0.064s
software@raven> time examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.0

real    0m57.337s
user    0m0.080s
sys     0m0.196s

and later the time went back down to ~10 seconds or so.  Furthermore,
for this example, only the first of the 4 subpages are rendered.  It
is not a hang, because after the first subpage is rendered (taking
somewhere between 10 seconds and 60 seconds) hitting the enter key
exits the example.

My bet is there has been some wxwidgets bug introduced by the recent
changes and concentrating on example 1 would be a good way to debug
whatever the problem is.

After doing that, if the time required to render example 1 is still
more than a fraction of a second, then I would carefully review the
client-server model you are using for wxPLViewer and why your text
size changes have made such a drastic reduction in speed.

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
__________________________