plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Protecting plP_state calls by level checks

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

Hi Alan
I have just quickly looked at this and I believe I made this change by design.

The reason being that c_plinit calls plP_bop which calls plPsubpInit
which calls c_plschr before plsc->level is set to 1. Therefore a check
for initialisation level means that plP_state does not get called and
the state calls do not get placed in the buffer so it messes up
renders from the buffer.

I can't offhand remember what the need is for other state parameters.
Do I remember correctly that colours can be set before plinit calls to
give a different background colour?

Phil



On 18 May 2015 at 20:46, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> To avoid segfaults when plschr is called before plinit (see
> <https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
> protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
> with a level check.  At the same time (commit id 1424994f) I also
> implemented similar level checks to the plP_state( PLSTATE_SYM ); call
> you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
> you removed the existing level check when you moved that call to the
> spat routine.  (I now realize that additional spat level check is
> redundant since spat is only called from functions which already do
> level checks, but I think it is best to leave it in for code clarity.)
>
> My question for you is did you forget the level check for
> the plP_state calls in plschr and plssym by design or
> in error?
>
> If by design, then we have to figure out some other way to provide
> users with a soft landing (not a segfault) when they call plschr or
> plssym before plinit.
>
> If in error, then you should probably review any other plP_state
> changes you made during your wxwidgets/plbuf changes to make sure the
> plP_state calls are protected by level checks in all 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] c++ wxWidget example compile issue

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

Hi Orion and Alan
I have just fixed the deprecated wxDC::GetLogicalOrigin warning. But I
do not see all the other deprecated warnings you reported Orion on my
Windows wxWidgets 3 system.

Do you still see them? Which version of wxWidgets are you using? I
presume from the messages you are on Linux?

Phil

On 22 May 2015 at 01:44, Alan W. Irwin <ir...@be...> wrote:
> On 2015-05-21 22:58+0100 Phil Rosenberg wrote:
>
>> Hi Orion
>> Thanks for the report. I will look at it asap.
>
>
> Hi Phil:
>
> Note, I have fixed the actual error that Orion noted at the end of his
> message by my recent reform of the entire traditional build system.
> However, that change did not address the deprecated warning messages
> he found.  As a low priority it would be good for you to eliminate
> those deprecated warnings once you have access to the latest wxwidgets
> (which is apparently what is needed to issue all the deprecated
> warnings since I don't see those with wxwidgets-2.8.12.).
>
> 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] Protecting plP_state calls by level checks

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

Sorry everyone

Having started with a clean build directory all those problems have
gone. Jim and Alan please look no further. I had already deleted my
CMakeCache.txt so assumed that there couldn't be any problems
lingering from previous builds but I guess I was wrong.

Phil


On 22 May 2015 at 09:57, Phil Rosenberg <p.d...@gm...> wrote:
>  Hi Jim
>
> The errors are below. These are for all of the plplot library, so
> there are a few warnings about implicit casts from other files in
> there too, but most of it is plbuf.c and plmetafile.c related
>
> Phil
>
> 9>------ Build started: Project: plplot, Configuration: Debug x64 ------
>
> 9> Building Custom Rule D:/usr/local/src/plplot-plplot/src/CMakeLists.txt
>
> 9> CMake does not need to re-run because
> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
> 64sd\src\CMakeFiles\generate.stamp is up-to-date.
>
> 9> mem.c
>
> 9> null.c
>
> 9> ps.c
>
> 9> svg.c
>
> 9> xfig.c
>
> 9> pdfutils.c
>
> 9> plaffine.c
>
> 9> plarc.c
>
> 9> plargs.c
>
> 9> plbox.c
>
> 9> plbuf.c
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(377): warning C4267: '='
> : conversion from 'size_t' to 'unsigned short', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(393): warning C4101:
> 'fci' : unreferenced local variable
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1068): warning C4244:
> 'function' : conversion from 'PLFLT' to 'PLINT', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1325): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1325): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1328): error C2065:
> 'uint16_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1349): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1349): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1352): error C2065:
> 'uint16_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1368): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1368): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1371): error C2065:
> 'uint16_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1424): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1424): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1429): error C2065:
> 'uint16_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1442): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1442): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1445): error C2065:
> 'uint16_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1470): error C2016: C
> requires that a struct or union has at least one member
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1470): error C2061:
> syntax error : identifier 'size_t'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1476): error C2059:
> syntax error : '}'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1495): error C2027: use
> of undefined type '_state'
>
> 9> D:\usr\local\src\plplot-plplot\src\plbuf.c(1469) : see declaration
> of '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1505): error C2037: left
> of 'size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1515): error C2037: left
> of 'valid' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1519): error C2037: left
> of 'size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1531): error C2037: left
> of 'size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1540): error C2037: left
> of 'valid' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1543): error C2036:
> '_state *' : unknown size
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1547): error C2037: left
> of 'plbuf_buffer_size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1548): error C2037: left
> of 'plbuf_top' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1549): error C2037: left
> of 'plbuf_readpos' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1553): error C2037: left
> of 'plbuf_buffer' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): error C2037: left
> of 'plbuf_buffer' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): warning C4022:
> 'memcpy' : pointer mismatch for actual parameter 2
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): error C2198:
> 'memcpy' : too few arguments for call
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1569): error C2037: left
> of 'valid' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1583): error C2037: left
> of 'plbuf_buffer' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1584): error C2037: left
> of 'plbuf_buffer_size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1585): error C2037: left
> of 'plbuf_top' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1586): error C2037: left
> of 'plbuf_readpos' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1615): error C2037: left
> of 'valid' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1621): error C2027: use
> of undefined type '_state'
>
> 9> D:\usr\local\src\plplot-plplot\src\plbuf.c(1469) : see declaration
> of '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1630): error C2037: left
> of 'size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1631): error C2037: left
> of 'valid' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1634): error C2037: left
> of 'plbuf_buffer' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1635): error C2037: left
> of 'plbuf_buffer_size' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1636): error C2037: left
> of 'plbuf_top' specifies undefined struct/union '_state'
>
> 9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1637): error C2037: left
> of 'plbuf_readpos' specifies undefined struct/union '_state'
>
> 9> plcont.c
>
> 9> plcore.c
>
> 9>D:\usr\local\src\plplot-plplot\src\plcore.c(2872): warning C4267:
> '=' : conversion from 'size_t' to 'int', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plcore.c(2873): warning C4267:
> '=' : conversion from 'size_t' to 'int', possible loss of data
>
> 9> plctrl.c
>
> 9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2670): warning C4267:
> 'function' : conversion from 'size_t' to 'int', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2675): warning C4267:
> 'function' : conversion from 'size_t' to 'int', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2717): warning C4267:
> 'function' : conversion from 'size_t' to 'int', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plctrl.c(3041): warning C4013:
> 'vsscanf' undefined; assuming extern returning int
>
> 9> plcvt.c
>
> 9> pldtik.c
>
> 9> plf2ops.c
>
> 9> plfill.c
>
> 9> plgradient.c
>
> 9> plgridd.c
>
> 9>d:\usr\local\src\plplot-plplot\src\../lib/csa/nan.h(53): warning
> C4005: 'isnan' : macro redefinition
>
> 9> D:\usr\local\src\plplot-plplot\include\plplotP.h(265) : see
> previous definition of 'isnan'
>
> 9> Generating Code...
>
> 9> Compiling...
>
> 9> plhist.c
>
> 9> plimage.c
>
> 9> pllegend.c
>
> 9> plline.c
>
> 9> plmem.c
>
> 9> plmetafile.c
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2146:
> syntax error : missing ')' before identifier 'x'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2061:
> syntax error : identifier 'x'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2059:
> syntax error : ';'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2059:
> syntax error : ','
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(137): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(186): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(186): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(189): warning C4244:
> '=' : conversion from 'unsigned short' to 'unsigned char', possible
> loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(226): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(226): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(229): warning C4244:
> '=' : conversion from 'unsigned long' to 'unsigned char', possible
> loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(232): warning C4244:
> '=' : conversion from 'unsigned long' to 'unsigned short', possible
> loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(235): warning C4244:
> '=' : conversion from 'unsigned long' to 'short', possible loss of
> data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(266): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(266): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(269): warning C4244:
> '=' : conversion from 'float' to 'unsigned char', possible loss of
> data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(272): warning C4244:
> '=' : conversion from 'float' to 'unsigned short', possible loss of
> data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(275): warning C4244:
> '=' : conversion from 'float' to 'short', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(278): warning C4244:
> '=' : conversion from 'float' to 'PLINT', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(284): warning C4244:
> '=' : conversion from 'float' to 'unsigned long', possible loss of
> data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2146:
> syntax error : missing ';' before identifier 'b'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2065:
> 'b' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(302): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(303): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(304): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(305): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(306): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(311): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(312): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): error C2065:
> 'b' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): warning C4133:
> 'function' : incompatible types - from 'int *' to 'unsigned char *'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): warning C4013:
> 'set_ubyte_plp_value' undefined; assuming extern returning int
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): error C2065:
> 'b' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): error C2065:
> 'x' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): warning C4133:
> 'function' : incompatible types - from 'int *' to 'unsigned short *'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(322): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(322): error C2065:
> 'x' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(326): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(326): error C2065:
> 'l' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(327): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(327): error C2065:
> 'l' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): error C2065:
> 'f' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): warning C4133:
> 'function' : incompatible types - from 'int *' to 'float *'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): error C2065:
> 'f' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): warning C4244:
> 'function' : conversion from 'int' to 'float', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(337): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(341): error C2065:
> 'pdf_rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(342): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(354): warning C4267:
> 'function' : conversion from 'size_t' to 'int', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2143:
> syntax error : missing ')' before '*'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2081:
> 'uint8_t' : name in formal parameter list illegal
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2143:
> syntax error : missing '{' before '*'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2059:
> syntax error : ')'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(432): error C2054:
> expected '(' to follow 'dest'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(518): warning C4244:
> '=' : conversion from 'PLFLT' to 'short', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(519): warning C4244:
> '=' : conversion from 'PLFLT' to 'short', possible loss of data
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2146:
> syntax error : missing ';' before identifier 'op'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(612): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(615): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(615): warning C4133:
> 'function' : incompatible types - from 'int *' to 'unsigned char *'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(618): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(627): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(628): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(629): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(639): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(640): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(641): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(643): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(644): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(645): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(658): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(678): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(679): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(680): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(681): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(682): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(683): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(685): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(686): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(687): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(688): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(689): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(690): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(691): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(692): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(693): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(694): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(695): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(704): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(720): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(730): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(743): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(747): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(758): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(765): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2065:
> 'uint8_t' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2146:
> syntax error : missing ';' before identifier 'op'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(777): error C2143:
> syntax error : missing ';' before 'type'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(780): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(780): warning C4133:
> 'function' : incompatible types - from 'int *' to 'unsigned char *'
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(783): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(788): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(789): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(790): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(802): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(803): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(804): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(807): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(815): error C2065:
> 'op' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(828): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(829): error C2065:
> 'rc' : undeclared identifier
>
> 9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(829): fatal error
> C1003: error count exceeds 100; stopping compilation
>
> 9> plot3d.c
>
> 9> plpage.c
>
> 9> plsdef.c
>
> 9> plshade.c
>
> 9> plstdio.c
>
> 9> plstripc.c
>
> 9> plsym.c
>
> 9> pltick.c
>
> 9> pltime.c
>
> 9> plvect.c
>
> 9> plvpor.c
>
> 9> plwind.c
>
> On 21 May 2015 at 23:59, Jim Dishaw <ji...@di...> wrote:
>> Please send me the errors. I'm getting a windows build machine going, so I will take a look at that c
>>
>>
>>
>>> On May 21, 2015, at 6:51 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>>
>>> Hi Alan
>>> I just did a git pull and tried to build PLPlot this evening and got a
>>> massive number of build errors.
>>>
>>> Some are related to 64 bit/32 bit conflicts which I have had problems
>>> with in the past and can't remember how I resolved them.
>>>
>>> Another one is below
>>>
>>> 7> Building Custom Rule D:/usr/local/src/plplot-plplot/include/CMakeLists.txt
>>>
>>> 7> CMake does not need to re-run because
>>> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
>>> 64sd\include\CMakeFiles\generate.stamp is up-to-date.
>>>
>>> 7> Generating plhershey-unicode.h
>>>
>>> 7> 'Debug\plhershey-unicode-gen.exe' is not recognized as an internal
>>> or external command,
>>>
>>> 7> operable program or batch file.
>>>
>>> 7>C:\Program Files
>>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5):
>>> error MSB6006: "cmd.exe" exited with code 9009.
>>>
>>> This seems odd because I don't think plhershey-unicode-gen.exe is
>>> built on Windows. Has something changed here?
>>>
>>> Also I got a large number of compile errors from plbuf.c and plmeta.c
>>>
>>> Jim are you still working on this? I can send you a list of errors if you like?
>>>
>>> Once I get building again I will look into the issue you raised.
>>>
>>> Phil
>>>
>>>
>>>
>>>
>>>
>>>> On 18 May 2015 at 20:46, Alan W. Irwin <ir...@be...> wrote:
>>>> Hi Phil:
>>>>
>>>> To avoid segfaults when plschr is called before plinit (see
>>>> <https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
>>>> protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
>>>> with a level check.  At the same time (commit id 1424994f) I also
>>>> implemented similar level checks to the plP_state( PLSTATE_SYM ); call
>>>> you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
>>>> you removed the existing level check when you moved that call to the
>>>> spat routine.  (I now realize that additional spat level check is
>>>> redundant since spat is only called from functions which already do
>>>> level checks, but I think it is best to leave it in for code clarity.)
>>>>
>>>> My question for you is did you forget the level check for
>>>> the plP_state calls in plschr and plssym by design or
>>>> in error?
>>>>
>>>> If by design, then we have to figure out some other way to provide
>>>> users with a soft landing (not a segfault) when they call plschr or
>>>> plssym before plinit.
>>>>
>>>> If in error, then you should probably review any other plP_state
>>>> changes you made during your wxwidgets/plbuf changes to make sure the
>>>> plP_state calls are protected by level checks in all 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
>>>> __________________________
>>>
>>> ------------------------------------------------------------------------------
>>> 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

Re: [Plplot-devel] Protecting plP_state calls by level checks

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

 Hi Jim

The errors are below. These are for all of the plplot library, so
there are a few warnings about implicit casts from other files in
there too, but most of it is plbuf.c and plmetafile.c related

Phil

9>------ Build started: Project: plplot, Configuration: Debug x64 ------

9> Building Custom Rule D:/usr/local/src/plplot-plplot/src/CMakeLists.txt

9> CMake does not need to re-run because
D:\usr\local\src\plplot-plplot\build\Visual Studio 11
64sd\src\CMakeFiles\generate.stamp is up-to-date.

9> mem.c

9> null.c

9> ps.c

9> svg.c

9> xfig.c

9> pdfutils.c

9> plaffine.c

9> plarc.c

9> plargs.c

9> plbox.c

9> plbuf.c

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(377): warning C4267: '='
: conversion from 'size_t' to 'unsigned short', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(393): warning C4101:
'fci' : unreferenced local variable

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1068): warning C4244:
'function' : conversion from 'PLFLT' to 'PLINT', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1325): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1325): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1328): error C2065:
'uint16_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1349): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1349): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1352): error C2065:
'uint16_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1368): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1368): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1371): error C2065:
'uint16_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1424): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1424): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1429): error C2065:
'uint16_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1442): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1442): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1445): error C2065:
'uint16_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1470): error C2016: C
requires that a struct or union has at least one member

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1470): error C2061:
syntax error : identifier 'size_t'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1476): error C2059:
syntax error : '}'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1495): error C2027: use
of undefined type '_state'

9> D:\usr\local\src\plplot-plplot\src\plbuf.c(1469) : see declaration
of '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1505): error C2037: left
of 'size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1515): error C2037: left
of 'valid' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1519): error C2037: left
of 'size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1531): error C2037: left
of 'size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1540): error C2037: left
of 'valid' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1543): error C2036:
'_state *' : unknown size

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1547): error C2037: left
of 'plbuf_buffer_size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1548): error C2037: left
of 'plbuf_top' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1549): error C2037: left
of 'plbuf_readpos' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1553): error C2037: left
of 'plbuf_buffer' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): error C2037: left
of 'plbuf_buffer' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): warning C4022:
'memcpy' : pointer mismatch for actual parameter 2

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1559): error C2198:
'memcpy' : too few arguments for call

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1569): error C2037: left
of 'valid' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1583): error C2037: left
of 'plbuf_buffer' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1584): error C2037: left
of 'plbuf_buffer_size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1585): error C2037: left
of 'plbuf_top' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1586): error C2037: left
of 'plbuf_readpos' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1615): error C2037: left
of 'valid' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1621): error C2027: use
of undefined type '_state'

9> D:\usr\local\src\plplot-plplot\src\plbuf.c(1469) : see declaration
of '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1630): error C2037: left
of 'size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1631): error C2037: left
of 'valid' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1634): error C2037: left
of 'plbuf_buffer' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1635): error C2037: left
of 'plbuf_buffer_size' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1636): error C2037: left
of 'plbuf_top' specifies undefined struct/union '_state'

9>D:\usr\local\src\plplot-plplot\src\plbuf.c(1637): error C2037: left
of 'plbuf_readpos' specifies undefined struct/union '_state'

9> plcont.c

9> plcore.c

9>D:\usr\local\src\plplot-plplot\src\plcore.c(2872): warning C4267:
'=' : conversion from 'size_t' to 'int', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plcore.c(2873): warning C4267:
'=' : conversion from 'size_t' to 'int', possible loss of data

9> plctrl.c

9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2670): warning C4267:
'function' : conversion from 'size_t' to 'int', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2675): warning C4267:
'function' : conversion from 'size_t' to 'int', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plctrl.c(2717): warning C4267:
'function' : conversion from 'size_t' to 'int', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plctrl.c(3041): warning C4013:
'vsscanf' undefined; assuming extern returning int

9> plcvt.c

9> pldtik.c

9> plf2ops.c

9> plfill.c

9> plgradient.c

9> plgridd.c

9>d:\usr\local\src\plplot-plplot\src\../lib/csa/nan.h(53): warning
C4005: 'isnan' : macro redefinition

9> D:\usr\local\src\plplot-plplot\include\plplotP.h(265) : see
previous definition of 'isnan'

9> Generating Code...

9> Compiling...

9> plhist.c

9> plimage.c

9> pllegend.c

9> plline.c

9> plmem.c

9> plmetafile.c

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2146:
syntax error : missing ')' before identifier 'x'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2061:
syntax error : identifier 'x'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2059:
syntax error : ';'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(136): error C2059:
syntax error : ','

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(137): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(186): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(186): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(189): warning C4244:
'=' : conversion from 'unsigned short' to 'unsigned char', possible
loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(226): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(226): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(229): warning C4244:
'=' : conversion from 'unsigned long' to 'unsigned char', possible
loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(232): warning C4244:
'=' : conversion from 'unsigned long' to 'unsigned short', possible
loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(235): warning C4244:
'=' : conversion from 'unsigned long' to 'short', possible loss of
data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(266): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(266): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(269): warning C4244:
'=' : conversion from 'float' to 'unsigned char', possible loss of
data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(272): warning C4244:
'=' : conversion from 'float' to 'unsigned short', possible loss of
data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(275): warning C4244:
'=' : conversion from 'float' to 'short', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(278): warning C4244:
'=' : conversion from 'float' to 'PLINT', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(284): warning C4244:
'=' : conversion from 'float' to 'unsigned long', possible loss of
data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2146:
syntax error : missing ';' before identifier 'b'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(301): error C2065:
'b' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(302): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(303): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(304): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(305): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(306): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(311): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(312): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): error C2065:
'b' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(316): warning C4133:
'function' : incompatible types - from 'int *' to 'unsigned char *'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): warning C4013:
'set_ubyte_plp_value' undefined; assuming extern returning int

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(317): error C2065:
'b' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): error C2065:
'x' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(321): warning C4133:
'function' : incompatible types - from 'int *' to 'unsigned short *'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(322): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(322): error C2065:
'x' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(326): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(326): error C2065:
'l' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(327): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(327): error C2065:
'l' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): error C2065:
'f' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(331): warning C4133:
'function' : incompatible types - from 'int *' to 'float *'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): error C2065:
'f' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(332): warning C4244:
'function' : conversion from 'int' to 'float', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(337): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(341): error C2065:
'pdf_rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(342): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(354): warning C4267:
'function' : conversion from 'size_t' to 'int', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2143:
syntax error : missing ')' before '*'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2081:
'uint8_t' : name in formal parameter list illegal

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2143:
syntax error : missing '{' before '*'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(431): error C2059:
syntax error : ')'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(432): error C2054:
expected '(' to follow 'dest'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(518): warning C4244:
'=' : conversion from 'PLFLT' to 'short', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(519): warning C4244:
'=' : conversion from 'PLFLT' to 'short', possible loss of data

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2146:
syntax error : missing ';' before identifier 'op'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(611): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(612): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(615): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(615): warning C4133:
'function' : incompatible types - from 'int *' to 'unsigned char *'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(618): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(627): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(628): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(629): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(639): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(640): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(641): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(643): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(644): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(645): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(658): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(678): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(679): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(680): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(681): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(682): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(683): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(685): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(686): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(687): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(688): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(689): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(690): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(691): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(692): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(693): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(694): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(695): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(704): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(720): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(730): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(743): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(747): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(758): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(765): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2065:
'uint8_t' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2146:
syntax error : missing ';' before identifier 'op'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(776): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(777): error C2143:
syntax error : missing ';' before 'type'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(780): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(780): warning C4133:
'function' : incompatible types - from 'int *' to 'unsigned char *'

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(783): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(788): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(789): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(790): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(802): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(803): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(804): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(807): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(815): error C2065:
'op' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(828): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(829): error C2065:
'rc' : undeclared identifier

9>D:\usr\local\src\plplot-plplot\src\plmetafile.c(829): fatal error
C1003: error count exceeds 100; stopping compilation

9> plot3d.c

9> plpage.c

9> plsdef.c

9> plshade.c

9> plstdio.c

9> plstripc.c

9> plsym.c

9> pltick.c

9> pltime.c

9> plvect.c

9> plvpor.c

9> plwind.c

On 21 May 2015 at 23:59, Jim Dishaw <ji...@di...> wrote:
> Please send me the errors. I'm getting a windows build machine going, so I will take a look at that c
>
>
>
>> On May 21, 2015, at 6:51 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Hi Alan
>> I just did a git pull and tried to build PLPlot this evening and got a
>> massive number of build errors.
>>
>> Some are related to 64 bit/32 bit conflicts which I have had problems
>> with in the past and can't remember how I resolved them.
>>
>> Another one is below
>>
>> 7> Building Custom Rule D:/usr/local/src/plplot-plplot/include/CMakeLists.txt
>>
>> 7> CMake does not need to re-run because
>> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
>> 64sd\include\CMakeFiles\generate.stamp is up-to-date.
>>
>> 7> Generating plhershey-unicode.h
>>
>> 7> 'Debug\plhershey-unicode-gen.exe' is not recognized as an internal
>> or external command,
>>
>> 7> operable program or batch file.
>>
>> 7>C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5):
>> error MSB6006: "cmd.exe" exited with code 9009.
>>
>> This seems odd because I don't think plhershey-unicode-gen.exe is
>> built on Windows. Has something changed here?
>>
>> Also I got a large number of compile errors from plbuf.c and plmeta.c
>>
>> Jim are you still working on this? I can send you a list of errors if you like?
>>
>> Once I get building again I will look into the issue you raised.
>>
>> Phil
>>
>>
>>
>>
>>
>>> On 18 May 2015 at 20:46, Alan W. Irwin <ir...@be...> wrote:
>>> Hi Phil:
>>>
>>> To avoid segfaults when plschr is called before plinit (see
>>> <https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
>>> protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
>>> with a level check.  At the same time (commit id 1424994f) I also
>>> implemented similar level checks to the plP_state( PLSTATE_SYM ); call
>>> you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
>>> you removed the existing level check when you moved that call to the
>>> spat routine.  (I now realize that additional spat level check is
>>> redundant since spat is only called from functions which already do
>>> level checks, but I think it is best to leave it in for code clarity.)
>>>
>>> My question for you is did you forget the level check for
>>> the plP_state calls in plschr and plssym by design or
>>> in error?
>>>
>>> If by design, then we have to figure out some other way to provide
>>> users with a soft landing (not a segfault) when they call plschr or
>>> plssym before plinit.
>>>
>>> If in error, then you should probably review any other plP_state
>>> changes you made during your wxwidgets/plbuf changes to make sure the
>>> plP_state calls are protected by level checks in all 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
>>> __________________________
>>
>> ------------------------------------------------------------------------------
>> 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

Re: [Plplot-devel] Protecting plP_state calls by level checks

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

Hmm
Thanks Alan. Maybe the 64/32 bit issue is stopping that exe build, causing later problems.

My plplot cmake script probably still has the plmeta driver set to build which might explain why Arjen isn't seeing the compile errors.

I'll keep trying.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎22/‎05/‎2015 03:41
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: Protecting plP_state calls by level checks

On 2015-05-21 23:51+0100 Phil Rosenberg wrote:

> This [error when building this app] seems odd because I don't think plhershey-unicode-gen.exe is
> built on Windows. Has something changed here?

Hi Phil:

That executable is always built for the Linux case, and I
can also answer this question for Cygwin from Arjen's recent report there:

irwin@raven> find . -name "*.out" |grep -vE '(a.out|listing)' | \
xargs grep -l "Built target plhershey-unicode-gen"
./shared/output_tree/make_noninteractive.out
./shared/output_tree/make.out
./shared/output_tree/make_install.out
./nondynamic/output_tree/make_noninteractive.out
./nondynamic/output_tree/make.out
./nondynamic/output_tree/make_install.out
./static/output_tree/make_noninteractive.out
./static/output_tree/make.out
./static/output_tree/make_install.out

So that executable should be built in your MSVC case as well.

By the way, with the Cygwin build currently looking so good, I suspect
the cause of your current many build errors on MSVC might be stale
cached values or a bad build environment in general.  To eliminate the
first possibility are you getting those build errors starting from an
absolutely empty build directory and a fresh clone of the master
branch?  You, of course, also have to put the dll subdirectory of the
build tree on your PATH to get the build to work.

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] A possible design of our new Fortran binding

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> A Linux adaptation of those build instructions got that build to work for me (with
> some spurious warnings because of my old gfortran 4.7.2 version as we have
> discussed before.)
>
> The end result was
>
> irwin@raven> ./x00f
>
> worked and prompted me for device and device file name, and the resulting
> PostScript plot looked good.
>
Great!

> So that is an excellent start, and I especially like the absence of any extra C layer at
> this stage (although we will ultimately need an extremely limited C layer for some of
> the more complex API argument processing); the freedom to choose any real type in
> the examples (so long as that real type is chosen consistently for a single call to a
> PLplot function); and the form of how you have implemented the interface which
> avoids duplicate code to handle the two different PLFLT cases.
>
> However, there are three things we should fix before expanding this further.
>
> 1. Fix plsparseopts
> > -        I have not tested this with command-line arguments yet - that is the trickier
> part of the code.
>
> In fact, it turns out command-line options do not work correctly, e.g.,
>
> irwin@raven> ./x00f -dev psttfc -o test.psc
>
> Bad command line option "test.psc"
> [....]

I noticed it too, when I tried it after sending the message. It always complains about the last option. I will check this.

>
> 2. Fix naming scheme for kind values so the examples (and more importantly user's
> programmes which are depending on plflt) can remain unchanged for backwards
> compatibility.  I have developed some detailed ideas in the way I want to do this, but
> instead of describing those in English I would like to present a commit instead that
> you could evaluate in detail for yourself.
>
Yes, it was pretty much ad hoc what I did to x00f.f90, I wanted to make sure it did not arcanely rely on the current style of binding.

> 3. Integrate these changes into our current build and test scheme.
> Again, I would be happy to take responsibility for this.
>

Again, the main reason for doing it that way was to make sure that no traces of the current style were left. I built the program in a separate directory with a copy of just the C library.

> In sum, I suggest we continue from this good start on the new Fortran binding topic
> with you taking responsibility for topic 1 and me taking responsibility for topics 2 and
> 3 above.
>
> Of course, if I am going to contribute to this development I do need git access to your
> private topic branch work using the usual "git format-patch" and "git am" method that
> is described in README.developers. So for now I suggest your first priority would
> be to present exactly what you have given us here as a tarball in "git format-patch"
> form instead with no further changes (except possibly not including the x00f.f90
> change since I would just revert that, see above).  And that solid git start with just
> your present work and no further except possibly excluding the x00f.f90 change
> would allow us to develop this private topic from there. Of course, I am aware you
> have had some problems with using "git format-patch" in the past, but if those
> continue let me know here or off list, and I think I should be able to give you an exact
> cookbook of what to do to get started.
>
Whenever I need to update the source tree or commit my changes, I follow the cookbook to the letter - that way it works for me. So, maybe indeed an update of the cookbook is required, but we will see.

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] Next steps for comprehensive testing on Cygwin

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> My detailed look showed everything was fine for the limited number of PLplot
> components tested other than the remaining issue with the "CMake no longer
> defines WIN32 on Cygwin!" warning which _should_ be fixed now, see my previous
> "humbled" post today on that subject.
>
I have not kept record of the number of times I thought a small change in a program did not mean I had to test it again :).

> I have now summarized the good results of your Cygwin comprehensive testing at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.
>
Great, especially as you have also listed the missing components. Cygwin may or may not provide all of them, but you already checked that :). This overview greatly reduces my task.

> So the question I want to address now is where should you go from here for
> comprehensive testing on Cygwin, i.e., which of the (B), (D), (E'), (F''), (G), and (H)
> remaining issues noted in that above summary should receive priority?
>
> There is obviously still something wrong with using your X server on Cygwin, but I
> suggest your address that issue last, i.e., keep running the comprehensive test with
> the "--do_test_interactive no" option not only because of that X server issue, but also
> because interactive comprehensive testing is much more difficult. (I have reduced
> that interactive testing misery as much as possible by using the -np [i.e., no pause
> between pages] option for all interactive tests, but -np does not work properly yet for
> Tcl/Tk nor wxwidgets so some babysitting misery is still inevitable if you do not use
> the "--do_test_interactive no" option.)

What I have noticed is that the configuration step looks for an X server with display name "localhost:0.0" but on Cygwin this is ":0.0" (don't ask me why). A workaround could be to set the DISPLAY variable beforehand.

Despite the configuration not finding the X server, it does allow building the X Window driver, which seems a wee bit odd.

>
> So that puts dealing with (B) (dropped interactive tests) last, and I suggest instead
> you deal with most of (D), (E'), (F''), (G), and (H) by simply increasing the scope of
> your comprehensive testing (and adding major functionality to your Cygwin PLplot
> platform) by installing all possible PLplot prequisites before you do your next
> comprehensive test.
>
> So to help you with that installation task I did some research,

Much appreciated.

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

Yes, Cygwin is turning out to be a most enjoyable platform.

>
> N.B. although installing the above packages and running another noninteractive
> comprehensive test should be straightforward, I am well aware that I currently have
> another outstanding request for you concerning creating the "git format-patch"
> version of the current state of your new Fortran binding. Furthermore, I still have a lot
> of simple topics of my own I would like to finish up for the current release cycle.
> Therefore, these two requests from me to you should both be classified as
> "whenever convenient for you".
>
Well, getting to terms with git seems to be the most mentally demanding task. It ought to be a good exercise though.

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] Using Window's raw API for shapes and text

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

On 2015-05-21 22:14-0400 Jim Dishaw wrote:

> Bad news.  I searched for my old Windows driver and I have lost it
to the ether.  I found some remnants, but not enough to compile.  I
can a recreate it without too much difficultly.  The driver version
that I had created was a merge between the X11 and the Windows GDI
drivers because I wanted to have a common UI between the two platforms
(e.g. menubar, crosshairs for picking points, printing).

> Is it worthwhile for me to recreate this driver?  It should not
interfere with the plbuf/plmetafile cleanup; in fact, digging into a
driver might help in clarifying some concepts.

Hi Jim:

That is mostly up to you although I do take your point it could be a
useful exercise for you.  Also, I don't use the xwin menubar or
printer feature at all so cannot properly evaluate their capabilities,
but from comparisons I have done with the -locate feature of
examples/c/x01c.c, running the 3rd (interactive) page of example 20,
and running special octave interactive examples, the xwin crosshairs
capability is the best of all our devices, and it would well be worth
copying what it does to xcairo, qtwidget, wxwidgets, wingcc, and the
new windows device.

Just in case you decide it would be worthwhile to recreate that driver,
I searched through the plplot-devel archive I have collected over
the years and found some references to your Windows driver but
no specific attachments of your source code except possibly part
of your driver that was introduced by you back in 2008 in the following
discussion with Werner:

"
I think it is a good idea.  In fact, I have created an abstract driver
for an interactive device.  I wanted to create a consistent user
interface for both X11 and MS Windows.  In order to achieve that, I
split the driver into two parts:  The real device driver and the
abstract driver.

The real device driver defines the dispatch setup function (and the
dummy function if it is disabled).  The dispatch table is configured to
point to functions in the abstract driver.  The abstract driver calls
the underlying API calls through a function pointer.

I have attached my  abstract driver as a strawman.  It is a work in
progress, so it is a bit crude still.
"

I could send that attachment along to you if you lost the original
that you sent out.

You also might want to search the plplot-devel archives yourself
for any descriptions you gave of your device driver, if you
have not done that already.

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] PLplot build fails on Mac OS X Yosemite 10.10.3

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

Hi Lewis:

I am going to use a new subject line for this question for obvious
reasons.

On 2015-05-21 17:51-0500 J. Lewis Muir wrote:

> P.S. Even though the problem I reported appears to have been fixed,
> my build did not succeed, so I'm guessing I hit a new issue.  The
> build failed as indicated below.  Unfortunately, I don't have time to
> investigate, so this is really just an FYI.  If you have people testing
> on OS X and things work for them, then it may be something related to my
> setup or building in pkgsrc.  Or maybe you don't have people testing on
> OS X, and this is something that you'll eventually run into on OS X at
> some point before you make an official 5.11.1 release.  This is on OS X
> Yosemite 10.10.3.

The fact is we have suffered for a very long time from a lack of
testing on the OS X platform so some build bugs may be currently
present on that platform.  However, if those exist it should be
absolutely straightforward to fix them once we know exactly what they
are.  I do know some of our developers here have access to that
platform so I hope your report inspires them to do some testing on
that platform starting with using the VERBOSE=1 option for the make
command to find out exactly how our CMake-based build system
instructions translate to actual build commands on OS X.

If some developer here with OS X build expertise is interested in
testing on that platform, my additional advice is to look at our
current override file which says (based on Mac OS X knowledge from
nearly a decade ago!)

software@raven> cat cmake/UserOverride.cmake
# User overrides of CMake default compiler and linking rules.
if(APPLE)
   set(CMAKE_SHARED_LINKER_FLAGS "-single_module"
   CACHE STRING "Flags used to link a shared library.")
endif(APPLE)

It is possible, for example, that that -single_module override may be
messing up modern Mac OS X builds with CMake and we should just
completely get rid of cmake/UserOverride.cmake.  But it takes someone
with Mac OS X build expertise to advise us on that question.

Alan

>
> ~~
> Linking C shared module svg.so
> [ 88%] Building C object drivers/CMakeFiles/xwin.dir/xwin.c.o
> [ 88%] Built target xfig
> Scanning dependencies of target pltek
> [ 88%] Built target test-drv-info
> [ 88%] Built target svg
> [ 90%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o
> Scanning dependencies of target test_null_dyndriver
> Scanning dependencies of target test_mem_dyndriver
> [ 93%] Generating test_dyndrivers_dir/null.driver_info
> [ 93%] Generating test_dyndrivers_dir/mem.driver_info
> dyld: Library not loaded: @rpath/libplplot.13.dylib
>  Referenced from: /home/pbulk/build/local/plplot/work/plplot-5.11.1/drivers/./test-drv-info
>  Reason: image not found
> dyld: Library not loaded: @rpath/libplplot.13.dylib
>  Referenced from: /home/pbulk/build/local/plplot/work/plplot-5.11.1/drivers/./test-drv-info
>  Reason: image not found
> sh: line 6: 95551 Trace/BPT trap: 5       ./test-drv-info null > /home/pbulk/build/local/plplot/work/plplot-5.11.1/drivers/test_dyndrivers_dir/null.driver_info
> --- drivers/test_dyndrivers_dir/null.driver_info ---
> *** [drivers/test_dyndrivers_dir/null.driver_info] Error code 133
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> 1 error
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> sh: line 6: 95552 Trace/BPT trap: 5       ./test-drv-info mem > /home/pbulk/build/local/plplot/work/plplot-5.11.1/drivers/test_dyndrivers_dir/mem.driver_info
> --- drivers/CMakeFiles/test_null_dyndriver.dir/all ---
> *** [drivers/CMakeFiles/test_null_dyndriver.dir/all] Error code 2
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> --- drivers/test_dyndrivers_dir/mem.driver_info ---
> *** [drivers/test_dyndrivers_dir/mem.driver_info] Error code 133
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> 1 error
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> --- drivers/CMakeFiles/test_mem_dyndriver.dir/all ---
> *** [drivers/CMakeFiles/test_mem_dyndriver.dir/all] Error code 2
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> Linking C executable pltek
> A failure has been detected in another branch of the parallel make
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> --- utils/CMakeFiles/pltek.dir/all ---
> *** [utils/CMakeFiles/pltek.dir/all] Error code 2
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> A failure has been detected in another branch of the parallel make
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> --- drivers/CMakeFiles/xwin.dir/all ---
> *** [drivers/CMakeFiles/xwin.dir/all] Error code 2
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> 4 errors
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> *** [all] Error code 2
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> 1 error
>
> bmake: stopped in /home/pbulk/build/local/plplot/work/plplot-5.11.1
> ~~
>

__________________________
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] [PATCH] OS X pkg-config.cmake error: string REGEX REPLACE needs 6 arguments

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

Hi Lewis:

On 2015-05-21 17:51-0500 J. Lewis Muir wrote:

> On 5/18/15 5:01 PM, Alan W. Irwin wrote:
>> So could you give the latest version of our git master branch
>> (which will soon form the basis for the forthcoming 5.11.1
>> release) a try to see if that solves the above issue?  If so I
>> will close the corresponding bug report that you just made at
>> <http://sourceforge.net/p/plplot/bugs/163/>.
>
> Hi, Alan.
>
> I just tried, and indeed the problem I reported no longer occurs in the
> git master branch.

Good.  I have therefore changed the status of
<http://sourceforge.net/p/plplot/bugs/163/> to "closed-fixed".

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] Protecting plP_state calls by level checks

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

On 2015-05-21 23:51+0100 Phil Rosenberg wrote:

> This [error when building this app] seems odd because I don't think plhershey-unicode-gen.exe is
> built on Windows. Has something changed here?

Hi Phil:

That executable is always built for the Linux case, and I
can also answer this question for Cygwin from Arjen's recent report there:

irwin@raven> find . -name "*.out" |grep -vE '(a.out|listing)' | \
xargs grep -l "Built target plhershey-unicode-gen"
./shared/output_tree/make_noninteractive.out
./shared/output_tree/make.out
./shared/output_tree/make_install.out
./nondynamic/output_tree/make_noninteractive.out
./nondynamic/output_tree/make.out
./nondynamic/output_tree/make_install.out
./static/output_tree/make_noninteractive.out
./static/output_tree/make.out
./static/output_tree/make_install.out

So that executable should be built in your MSVC case as well.

By the way, with the Cygwin build currently looking so good, I suspect
the cause of your current many build errors on MSVC might be stale
cached values or a bad build environment in general.  To eliminate the
first possibility are you getting those build errors starting from an
absolutely empty build directory and a fresh clone of the master
branch?  You, of course, also have to put the dll subdirectory of the
build tree on your PATH to get the build to work.

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] Using Window's raw API for shapes and text

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

On 2015-05-21 23:39+0100 Phil Rosenberg wrote:

> Regarding text, uniscribe has as noted earlier been superseded by
> directText, but I don't know how far back such compatibility goes. I
> do have some code that I once wrote intending to push into PLplot (but
> again never finished) that took uniscribe as a layout engine and then
> used FreeType for the actual glyph rendering. It should be noted that
> we are a little unfair to FreeType. FreeType is not a layout engine it
> is a rendering engine - it just renders the glyphs it is told to from
> the font files you tell it. The layout engine needs to do things like
> decide text direction. My concept was that if we had the Uniscribe
> layout engine on Windows and Harfbuzz on Linux then Freetype could do
> the rendering on both to give the same style. Anyway if that code is
> any good to you then let me know and I'll send it over.

Hi Phil:

My two objections to the current plfreetype approach are its clunky
selection of fonts (by file name rather than by generic sans, serif,
etc., font type search for the best system font with the desired
generic characteristic to render a single unicode glyph) and its
inability to deal with complex text layout. However, it sounds like
those two objections are answered by the concept you describe above if
working indirectly through an improved plfreetype is the approach Jim
and Aaron decide to take with the wingcc upgrade.  And an improved
plfreetype with the above objections answered would certainly give a
huge boost to the gd device driver (also dependent on plfreetype) back
from its current course toward complete retirement.

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] Using Window's raw API for shapes and text

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

> On May 14, 2015, at 12:11 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-05-13 21:44-0500 Aaron Hexamer wrote:
> 
>> Would it be developed using the GDI?  If so, then maybe wingdi?
> 
> Hi Aaron:
> 
> To respond to your first question even though I am not
> that familiar with Windows, I did look up the article at
> <http://en.wikipedia.org/wiki/Graphics_Device_Interface <http://en.wikipedia.org/wiki/Graphics_Device_Interface>>, and it
> appears that is an old API that has been replaced with the Direct2D
> <http://en.wikipedia.org/wiki/Direct2D <http://en.wikipedia.org/wiki/Direct2D>> API.
> I then followed up with some google
> searching to find
> <https://msdn.microsoft.com/en-us/library/windows/desktop/ff729481(v=vs.85).aspx <https://msdn.microsoft.com/en-us/library/windows/desktop/ff729481(v=vs.85).aspx>>
> which implies you can use gdi for graphics and DirectWrite for text or
> Direct2D for graphics and DirectWrite for text.  Furthermore,
> <http://en.wikipedia.org/wiki/DirectWrite <http://en.wikipedia.org/wiki/DirectWrite>> says one of the features is
> 
> "Comprehensive support for Unicode, with over 20 scripts providing
> layout and rendering of every language supported in Windows."
> 
> So that superficially sounds like exactly what we want to use (in
> combination with either GDI or Direct2D), but remember my Windows
> knowledge is quite limited and this research just took me a few
> minutes of google searching so if our Windows developers have a
> different preference for the Windows API that is used to render
> unicode text, then we should adopt that preference.
> 
> @Aaron: I do think your general idea of the win+API name is better
> than winwidgets. So I would be happy to use wingdi or windirect2d
> depending on the decision about which one is used in conjunction with
> DirectWrite.
> 
> @Jim, Arjen, and Phil:
> 
> As our most active Windows developers please chime in about what
> Windows API you think we should use to render unicode text, and the
> name you would like to see for what is currently called the wingcc
> device driver.
> 

Bad news.  I searched for my old Windows driver and I have lost it to the ether.  I found some remnants, but not enough to compile.  I can a recreate it without too much difficultly.  The driver version that I had created was a merge between the X11 and the Windows GDI drivers because I wanted to have a common UI between the two platforms (e.g. menubar, crosshairs for picking points, printing).

Is it worthwhile for me to recreate this driver?  It should not interfere with the plbuf/plmetafile cleanup; in fact, digging into a driver might help in clarifying some concepts.

Re: [Plplot-devel] Linking model review requested

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

Hi Andrew:

I will respond to your two posts here.

On 2015-05-21 22:54+0100 Andrew Ross wrote:

>
> Alan,
>
> I think your summary is probably correct

Good. That is a big relief to me that I wasn't missing
anything obvious, and thanks for that review.

> [B]ut the solution of just
> explicitly linking stdc++ is so simple, that it makes me think it must be
> possible to work round this. A flag if there is any C++ code would be
> sufficient to identify the need to link with stdc++?

More below on this after I quote your additional post.

On 2015-05-21 23:00+0100 Andrew Ross wrote:

>
> I should probably add that this would for g++, but perhaps not other
> compilers. This is a common enough case that it is perhaps worth
> supporting as a special case nontheless?
>
> Or we could take the decision that cmake builds are the way to go,
and we
> can't support all non-standard cases for the traditional build.

Even if you restrict yourself to supporting only the g++ compiler
for this corner case, the problem is that even if you restrict
yourself still further to just Debian wheezy,
there are 3 separate libstdc++.so symbolic links depending on
g++ compiler version, i.e.,

/usr/lib/gcc/x86_64-linux-gnu/4.4/libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so

As it happens they all link to the same version of the libstdc++.so.6
symlink for Debian wheezy, but in general I don't think you can guarantee that for all Linux
platforms.  And in any case the CMake find_library command works only
for the *.so version of library symlinks and not the *.so.NNNN version of
library symlinks.  So you need a cross-platform way with whatever g++ version
you are using to find the appropriate directory above in which to do
the CMake find_library(stdc++).  And when I attempted to implement
that a few months back it turned into a real mess with semicolon
separation of library locations turning into colon separation for
the latest g++ version on Fedora.  And I have no idea how the
Cygwin version of g++ is going to cope with that "upgrade" since colon separation
is also intrinsically obfuscated by the drive letter question.

Therefore I deleted that whole mess of logic and moved to the
compiling all our C code examples in the traditional build with C++
(which automatically brings in the correct version of libstdc++.so
that is consistent with the compiler version).  But obviously that
general and elegant solution (to link with whatever C++ compiler is
being used) is not available for other language examples such as Ada,
D, f95, java, and ocaml.

In principle, of course, it should be possible to discover the name
and directory location of the special library (or libraries)
associated with the C++ in a fairly general way. For example, on Unix
(including Cygwin) you might be able to make a test compilation of a
C++ executable with no content so it should not link to any regular
libraries, analyze that with readelf or ldd to discover all special
C++ compiler libraries it depends on, and add those libraries to the
pkg-config files for our ada, d, f95, java, and ocaml bindings.  And
there is likely to be similar test cases you can invoke on Windows.
But I have run out of mental energy to pursue something further like
that just to give complete pkg-config results for the corner case. So
I invite you or anybody else here who might be intrigued by that
general idea or any other elegant solution to the problem to give it a
go.

But for now, I really think the right thing to do here is what I have
done with commit a09dc18 which is simply to declare we are not going
to attempt (at least at this time) to discover the name and location
of the special library associated with the user's C++ compiler, put a
warning to that effect in the configured Makefiles of the traditional
build of the Ada, D, f95, java, and ocaml examples, and also avoid
using those configured files for comprehensive testing if the
prerequisites (static build of PLplot, any C++ device driver enabled,
traditional build system for the installed examples) of this corner
case are satisfied.  (Note it is not as bad as it sounds because we
don't have either java or ocaml bindings available in any case for a
static build so we are only truly eliminating compiling and testing
the Ada, D, and f95 examples for this corner case).

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] c++ wxWidget example compile issue

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

On 2015-05-21 22:58+0100 Phil Rosenberg wrote:

> Hi Orion
> Thanks for the report. I will look at it asap.

Hi Phil:

Note, I have fixed the actual error that Orion noted at the end of his
message by my recent reform of the entire traditional build system.
However, that change did not address the deprecated warning messages
he found.  As a low priority it would be good for you to eliminate
those deprecated warnings once you have access to the latest wxwidgets
(which is apparently what is needed to issue all the deprecated
warnings since I don't see those with wxwidgets-2.8.12.).

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] Next steps for comprehensive testing on Cygwin

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

On 2015-05-21 09:18-0000 Arjen Markus wrote:

> The comprehensive test has finished on Cygwin without any
complaints. I have not checked the report extensively but it looks as
if all went well - no deviations reported. The details are in the
attachment.

Hi Arjen:

My detailed look showed everything was fine for the limited number
of PLplot components tested other than the remaining issue with
the "CMake no longer defines WIN32 on Cygwin!" warning which _should_
be fixed now, see my previous "humbled" post today on that subject.

I have now summarized the good results of your Cygwin comprehensive testing
at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.

So the question I want to address now is where should you go from here
for comprehensive testing on Cygwin, i.e., which of the (B), (D),
(E'), (F''), (G), and (H) remaining issues noted in that above summary
should receive priority?

There is obviously still something wrong with using your X server on
Cygwin, but I suggest your address that issue last, i.e., keep running
the comprehensive test with the "--do_test_interactive no" option not
only because of that X server issue, but also because interactive
comprehensive testing is much more difficult. (I have reduced that
interactive testing misery as much as possible by using the -np [i.e.,
no pause between pages] option for all interactive tests, but -np does
not work properly yet for Tcl/Tk nor wxwidgets so some babysitting
misery is still inevitable if you do not use the
"--do_test_interactive no" option.)

So that puts dealing with (B) (dropped interactive tests) last, and I
suggest instead you deal with most of (D), (E'), (F''), (G), and (H)
by simply increasing the scope of your comprehensive testing (and
adding major functionality to your Cygwin PLplot platform) by
installing all possible PLplot prequisites before you do your next
comprehensive test.

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!

N.B. although installing the above packages and running another
noninteractive comprehensive test should be straightforward, I am well
aware that I currently have another outstanding request for you
concerning creating the "git format-patch" version of the current
state of your new Fortran binding. Furthermore, I still have a lot of
simple topics of my own I would like to finish up for the current
release cycle. Therefore, these two requests from me to you should both be
classified as "whenever convenient for you".

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] Protecting plP_state calls by level checks

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

Please send me the errors. I'm getting a windows build machine going, so I will take a look at that c



> On May 21, 2015, at 6:51 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Alan
> I just did a git pull and tried to build PLPlot this evening and got a
> massive number of build errors.
> 
> Some are related to 64 bit/32 bit conflicts which I have had problems
> with in the past and can't remember how I resolved them.
> 
> Another one is below
> 
> 7> Building Custom Rule D:/usr/local/src/plplot-plplot/include/CMakeLists.txt
> 
> 7> CMake does not need to re-run because
> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
> 64sd\include\CMakeFiles\generate.stamp is up-to-date.
> 
> 7> Generating plhershey-unicode.h
> 
> 7> 'Debug\plhershey-unicode-gen.exe' is not recognized as an internal
> or external command,
> 
> 7> operable program or batch file.
> 
> 7>C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5):
> error MSB6006: "cmd.exe" exited with code 9009.
> 
> This seems odd because I don't think plhershey-unicode-gen.exe is
> built on Windows. Has something changed here?
> 
> Also I got a large number of compile errors from plbuf.c and plmeta.c
> 
> Jim are you still working on this? I can send you a list of errors if you like?
> 
> Once I get building again I will look into the issue you raised.
> 
> Phil
> 
> 
> 
> 
> 
>> On 18 May 2015 at 20:46, Alan W. Irwin <ir...@be...> wrote:
>> Hi Phil:
>> 
>> To avoid segfaults when plschr is called before plinit (see
>> <https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
>> protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
>> with a level check.  At the same time (commit id 1424994f) I also
>> implemented similar level checks to the plP_state( PLSTATE_SYM ); call
>> you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
>> you removed the existing level check when you moved that call to the
>> spat routine.  (I now realize that additional spat level check is
>> redundant since spat is only called from functions which already do
>> level checks, but I think it is best to leave it in for code clarity.)
>> 
>> My question for you is did you forget the level check for
>> the plP_state calls in plschr and plssym by design or
>> in error?
>> 
>> If by design, then we have to figure out some other way to provide
>> users with a soft landing (not a segfault) when they call plschr or
>> plssym before plinit.
>> 
>> If in error, then you should probably review any other plP_state
>> changes you made during your wxwidgets/plbuf changes to make sure the
>> plP_state calls are protected by level checks in all 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
>> __________________________
> 
> ------------------------------------------------------------------------------
> 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

Re: [Plplot-devel] Protecting plP_state calls by level checks

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

Hi Alan
I just did a git pull and tried to build PLPlot this evening and got a
massive number of build errors.

Some are related to 64 bit/32 bit conflicts which I have had problems
with in the past and can't remember how I resolved them.

Another one is below

7> Building Custom Rule D:/usr/local/src/plplot-plplot/include/CMakeLists.txt

7> CMake does not need to re-run because
D:\usr\local\src\plplot-plplot\build\Visual Studio 11
64sd\include\CMakeFiles\generate.stamp is up-to-date.

7> Generating plhershey-unicode.h

7> 'Debug\plhershey-unicode-gen.exe' is not recognized as an internal
or external command,

7> operable program or batch file.

7>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5):
error MSB6006: "cmd.exe" exited with code 9009.

This seems odd because I don't think plhershey-unicode-gen.exe is
built on Windows. Has something changed here?

Also I got a large number of compile errors from plbuf.c and plmeta.c

Jim are you still working on this? I can send you a list of errors if you like?

Once I get building again I will look into the issue you raised.

Phil





On 18 May 2015 at 20:46, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> To avoid segfaults when plschr is called before plinit (see
> <https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
> protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
> with a level check.  At the same time (commit id 1424994f) I also
> implemented similar level checks to the plP_state( PLSTATE_SYM ); call
> you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
> you removed the existing level check when you moved that call to the
> spat routine.  (I now realize that additional spat level check is
> redundant since spat is only called from functions which already do
> level checks, but I think it is best to leave it in for code clarity.)
>
> My question for you is did you forget the level check for
> the plP_state calls in plschr and plssym by design or
> in error?
>
> If by design, then we have to figure out some other way to provide
> users with a soft landing (not a segfault) when they call plschr or
> plssym before plinit.
>
> If in error, then you should probably review any other plP_state
> changes you made during your wxwidgets/plbuf changes to make sure the
> plP_state calls are protected by level checks in all 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] Using Window's raw API for shapes and text

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

Hi Jim, Alan et al

Some (rather late) input into all this. GDI is the oldest windows
rendering API in use. Its major disadvantage is that it does not
support antialiasing so the out put is not very good, however it does
support hardware acceleration. GDI+ was the successor. It gives you
antialiasing but does not support hardware acceleration. Direct2D is I
think a split off from DirectX. if I am not mistaken then a
significant portion of that functionality is available within DirectX9
which was probably available on XP, but I am now pushing the limits of
my knowledge. DirectX (and by extension Direct2D) supports hardware
acceleration. I think antialiasing is supported in Direct2D, but not
in older versions of DirectX. I know most of this stuff because on
Windows wxWidgets uses GDI for its wxPaintDC, but GDI+ for its
wxGraphicsContext - which was the difference between the wxDC and
wxGraphicsContext backends of PLPlot. I've never used either directly.
I have used DirectX9 once (actually by mistake, I should really have
used a more modern version). If you want to go down this route you
need to get your head around the COM model - which is basically object
oriented C. If you are interested let me know (this model might be
useful for PLPlot memory management). I then used a bit of Direct2D,
which was neither easier nor harder than DirectX and there are come
crossover functions needed I think so you end up learning both. I
actually started writing a wxDirect2DFrame class that allowed
rendering to a wxWindow  with Direct2D, but once I got it good enough
for that project I never finished it off.

Regarding text, uniscribe has as noted earlier been superseded by
directText, but I don't know how far back such compatibility goes. I
do have some code that I once wrote intending to push into PLplot (but
again never finished) that took uniscribe as a layout engine and then
used FreeType for the actual glyph rendering. It should be noted that
we are a little unfair to FreeType. FreeType is not a layout engine it
is a rendering engine - it just renders the glyphs it is told to from
the font files you tell it. The layout engine needs to do things like
decide text direction. My concept was that if we had the Uniscribe
layout engine on Windows and Harfbuzz on Linux then Freetype could do
the rendering on both to give the same style. Anyway if that code is
any good to you then let me know and I'll send it over.

In terms of what we "should" do. I agree that we probably should still
support XP. However, that is probably like us trying to support Ubuntu
5. Maybe a more modern system would be more beneficial in the long
run. Perhaps we could leave the wingcc for legacy use, but develop
using Direct2D for the new system (call it wind2d or something) rather
than deliberately choosing to use a system that is becoming
depreciated.

Phil

Phil

On 14 May 2015 at 21:35,  <he...@co...> wrote:
> Alan,
>
> That makes sense to me. I can see how the configure/build time checks make
> sense to affect which support to attempt compile-in. E.g. if one were
> building with an older compiler on an XP host, you wouldn't want to try to
> link in Direct2D support. OTOH, what I actually had in mind was runtime
> detection to use the most effective version available on the target
> platform.
>
> Thanks,
>
> Aaron.
>
>
> Sent from XFINITY Connect Mobile App
> -----Original Message-----
>
> From: ir...@be...
> To: he...@co...,ji...@di...
> Cc: Plp...@li...
> Sent: 2015-05-14 15:00:20 GMT
> Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text
>
> On 2015-05-14 15:51-0000 he...@co... wrote:
>
>> Alan,
>>
>> One potential downside of the newer Direct2D/DirectWrite APIs is that they
>> aren't supported on Windows XP. I know I have users of my
>> application still using XP. I can't tell without some more research, but I
>> think Windows 10 even supports GDI/GDI+.
>>
>
> Hi Aaron:
>
> Since Windows XP is an important requirement for you, then it appears
> (again from my rather superficial google searching) that to render
> unicode text with raw Windows API you must use GDI in combination with
> the predecessor to DirectWrite which is Uniscribe
> .
>
> Jim's later post in this thread said he would start with GDI so I
> expect once he replaces the plfreetype approach for rendering unicode
> text with raw Windows API for doing the same task he will be moving to
> GDI/Uniscribe (if his reference to "GDI" did not actually
> already mean GDI/Uniscribe). And I am pretty sure from my reading that
> GDI/Uniscribe is supported for Windows XP and all later Microsoft
> versions.
>
>> If the case for using Direct2D/DirectWrite is compelling enough, maybe
>> they could be supported in addition to GDI and only used if the
>> detected OS is > WinXP?
>
> I think this is a good idea once it is confirmed that the GDI/Uniscribe
> approach works fine. From my reading the advantages of
> Direct2D/DirectWrite are considerable (e.g., vector graphics rather
> than bitmapped). And it should be straightforward to provide
> CMake code to test whether Direct2D/DirectWrite is available, and
> if so, provide the user the option to use Direct2D/DirectWrite
> rather than GDI/Uniscribe.
>
> But with regard to Jim's enhanced version of drivers/wingcc.c it
> it seems to me the implementation order should be
>
> 1. GDI/plfreetype. This approach will give the wrong glyph
> order for the Arabic, Hebrew, and Hindi "peace" words
> in example 24 and may have trouble finding the appropriate
> fonts for all those languages, i.e., certain glyphs will
> be missing.
>
> 2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype
> API with Uniscribe API). Once implemented, the GDI/Uniscribe
> combination should be tested by running example 24 and confirming that
> it produces correct results (i.e., all Peace words present and having
> the correct glyph order (i.e., as demonstrated at
> .
>
> 3. Add the additional possibility (depending on a macro set by the
> CMake logic referred to above) of using the Direct2D/DirectWrite API
> instead of the GDI/Uniscribe API. (Again with a check that example 24
> works properly.)
>
> Note, we want to get rid of all use of plfreetype so if Jim's
> reference to his driver already using GDI actually referred to
> GDI/Uniscribe, then he should ignore 1 and start with the example 24
> test recommended in 2. above.
>
> 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
>

Re: [Plplot-devel] Version 6?

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

Oh and floating point coordinate system was on there too.

Phil

On 21 May 2015 at 23:07, Phil Rosenberg <p.d...@gm...> wrote:
> Indeed for the wxWidgets driver it is bad too. When I first started
> using PLplot I spent a lot of time wondering why my wxWidgets apps
> kept "crashing" It turned out to be mostly due to plplot exit calls
> when e.g. the Hershey font files weren't found.
>
> Also for thread safety we are likely going to have to remove the
> global plsc variable and instead have a plinit function that returns a
> plstream * as a void * to be passed back in with every API call (as is
> done in libcurl for example) so there are now two reasons to need a
> new API.
>
> One other item I had on my list for PLPlot 6 was adding defaults for
> the legend/colourbar with separate functions to change these values as
> needed.
>
> Something I have also brought up in the past that I think needs to be
> addressed is memory management in PLPlot, but I am not sure what the
> best way forward with this is. Suggestions welcome.
>
> Phil
>
> On 13 May 2015 at 22:02, Andrew Ross <and...@us...> wrote:
>> On Tue, May 12, 2015 at 02:51:12PM -0400, Hazen Babcock wrote:
>>>
>>> This e-mail is to provide a summary of what we had discussed, please let
>>> me know if I left anything out. I think we had a consensus that the
>>> following change would be made as part of a possible version 6:
>>>
>>> 1. All API functions return error codes.
>>>
>>>
>>> I think we also agreed on these items, which might not actually require
>>> a major version bump as the actual change to the API is potentially
>>> small / nil:
>>>
>>> 2. Thread safety.
>>>
>>> 3. Improved text handling between core and the drivers.
>>>
>>>
>>> And there was some discussion about whether this was a good idea:
>>>
>>> 4. Core handles some text rendering.
>>>
>>>
>>> Now I think the question is if the effort and disruption involved in (1)
>>> justifies making the change. I would say that I'm neutral about this. I
>>> feel that it is the way a modern library should behave. However I'm not
>>> sure that the fact that PLplot does not currently work this way is
>>> actually causing a lot of problems for people.
>>
>> Hazen,
>>
>> There are some cases where 1) does cause problems - notably for
>> interactive drivers like octave where you do not want errors to result in
>> the program being killed off. The library should report the error and let
>> the program deal with it.
>>
>> It also causes lintian warnings on Debian as it is a Bad Thing (TM) for
>> libraries to do. (For those who don't know, lintian is a package checking
>> program which looks for a whole range of errors / breaches of policy / bad
>> practice when packaging software for Debian).
>>
>> Andrew
>>
>> ------------------------------------------------------------------------------
>> 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

Re: [Plplot-devel] Version 6?

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

Indeed for the wxWidgets driver it is bad too. When I first started
using PLplot I spent a lot of time wondering why my wxWidgets apps
kept "crashing" It turned out to be mostly due to plplot exit calls
when e.g. the Hershey font files weren't found.

Also for thread safety we are likely going to have to remove the
global plsc variable and instead have a plinit function that returns a
plstream * as a void * to be passed back in with every API call (as is
done in libcurl for example) so there are now two reasons to need a
new API.

One other item I had on my list for PLPlot 6 was adding defaults for
the legend/colourbar with separate functions to change these values as
needed.

Something I have also brought up in the past that I think needs to be
addressed is memory management in PLPlot, but I am not sure what the
best way forward with this is. Suggestions welcome.

Phil

On 13 May 2015 at 22:02, Andrew Ross <and...@us...> wrote:
> On Tue, May 12, 2015 at 02:51:12PM -0400, Hazen Babcock wrote:
>>
>> This e-mail is to provide a summary of what we had discussed, please let
>> me know if I left anything out. I think we had a consensus that the
>> following change would be made as part of a possible version 6:
>>
>> 1. All API functions return error codes.
>>
>>
>> I think we also agreed on these items, which might not actually require
>> a major version bump as the actual change to the API is potentially
>> small / nil:
>>
>> 2. Thread safety.
>>
>> 3. Improved text handling between core and the drivers.
>>
>>
>> And there was some discussion about whether this was a good idea:
>>
>> 4. Core handles some text rendering.
>>
>>
>> Now I think the question is if the effort and disruption involved in (1)
>> justifies making the change. I would say that I'm neutral about this. I
>> feel that it is the way a modern library should behave. However I'm not
>> sure that the fact that PLplot does not currently work this way is
>> actually causing a lot of problems for people.
>
> Hazen,
>
> There are some cases where 1) does cause problems - notably for
> interactive drivers like octave where you do not want errors to result in
> the program being killed off. The library should report the error and let
> the program deal with it.
>
> It also causes lintian warnings on Debian as it is a Bad Thing (TM) for
> libraries to do. (For those who don't know, lintian is a package checking
> program which looks for a whole range of errors / breaches of policy / bad
> practice when packaging software for Debian).
>
> Andrew
>
> ------------------------------------------------------------------------------
> 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

Re: [Plplot-devel] Linking model review requested

[Andrew R. <and...@us...>]

I should probably add that this would for g++, but perhaps not other
compilers. This is a common enough case that it is perhaps worth
supporting as a special case nontheless? 

Or we could take the decision that cmake builds are the way to go, and we
can't support all non-standard cases for the traditional build.

Andrew

On Thu, May 21, 2015 at 10:54:19PM +0100, Andrew Ross wrote:
> 
> Alan,
> 
> I think your summary is probably correct, but the solution of just
> explicitly linking stdc++ is so simple, that it makes me think it must be
> possible to work round this. A flag if there is any C++ code would be
> sufficient to identify the need to link with stdc++?
> 
> Andrew
> 
> On Wed, May 20, 2015 at 10:25:06PM -0700, Alan Irwin wrote:
> > Hi Andrew:
> > 
> > Would you please take a quick look at the commit message for a09dc18?
> > In that commit message I outline the linking model I used to draw the
> > conclusion that the ada, d, f95, java, and ocaml traditional examples
> > builds were going to _sometimes_ fail for a certain combination of
> > circumstances (static PLplot build with at least one of the C++ device
> > drivers enabled).
> > 
> > I am asking for that review because I hate to give up all those
> > components of the comprehensive test of the traditional build for the
> > given circumstances if I don't have to.  I am pretty sure your review
> > of the linking model I use will show I am right, but nevertheless that
> > review would be much appreciated since it would help to put my mind at
> > ease about this commit (which disables the relevant parts of the
> > comprehensive test for the given combination of circumstances).
> > 
> > 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

Re: [Plplot-devel] c++ wxWidget example compile issue

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

 Hi Orion
Thanks for the report. I will look at it asap.

Phil

On 24 April 2015 at 23:05, Orion Poplawski <or...@co...> wrote:
> I should not that these are with the installed examples:
>
> /usr/bin/c++ wxPLplotDemo.cpp -o wxPLplotDemo  -D_FILE_OFFSET_BITS=64
> -D_LARGE_FILES -D__WXGTK__ -I/usr/include/plplot
> -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
> -I/usr/include/plplot -lplplotwxwidgets
> wxPLplotDemo.cpp:138:1: warning: ‘virtual wxLog*
> wxAppConsole::CreateLogTarget()’ is deprecated [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wxprec.h:13:0,
>                  from wxPLplotDemo.cpp:22:
> /usr/include/wx-2.8/wx/app.h:184:34: note: declared here
>      wxDEPRECATED( virtual wxLog *CreateLogTarget() );
>                                   ^
> /usr/include/wx-2.8/wx/defs.h:513:29: note: in definition of macro ‘wxDEPRECATED’
>      #define wxDEPRECATED(x) x __attribute__ ((deprecated))
>                              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual wxMessageOutput*
> wxAppConsole::CreateMessageOutput()’ is deprecated [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wxprec.h:13:0,
>                  from wxPLplotDemo.cpp:22:
> /usr/include/wx-2.8/wx/app.h:189:44: note: declared here
>      wxDEPRECATED( virtual wxMessageOutput *CreateMessageOutput() );
>                                             ^
> /usr/include/wx-2.8/wx/defs.h:513:29: note: in definition of macro ‘wxDEPRECATED’
>      #define wxDEPRECATED(x) x __attribute__ ((deprecated))
>                              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> wxPLplotDemo.cpp:138:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
> [-Wdeprecated-declarations]
>  }
>  ^
> In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
>                  from wxPLplotDemo.cpp:29:
> /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
>  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>              ^
> /usr/bin/ld: /tmp/ccH0vhU9.o: undefined reference to symbol
> '_ZN8plstream4lineEiPKdS1_'
> /usr/lib64/libplplotcxx.so.12: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> Makefile:81: recipe for target 'wxPLplotDemo' failed
>
> So it looks like something in either the wxPLplotDemo.cpp file or its includes
> references the '_ZN8plstream4lineEiPKdS1_' symbol and so needs to be linked
> with -lplplotcxx.  If it is wxPLplotDemo.cpp, then it should be added to the
> Makefile like my other example.  If it the includes and so all
> plplot-wxwidgets users need it, it should be added to the pkg-config output:
>
> # pkg-config  --cflags --libs plplot-wxwidgets
> -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -I/usr/include/plplot
> -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
> -I/usr/include/plplot -lplplotwxwidgets
>
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
> 3380 Mitchell Lane                       or...@nw...
> Boulder, CO 80301                   http://www.nwra.com
>
> ------------------------------------------------------------------------------
> 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

Re: [Plplot-devel] Linking model review requested

[Andrew R. <and...@us...>]

Alan,

I think your summary is probably correct, but the solution of just
explicitly linking stdc++ is so simple, that it makes me think it must be
possible to work round this. A flag if there is any C++ code would be
sufficient to identify the need to link with stdc++?

Andrew

On Wed, May 20, 2015 at 10:25:06PM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> Would you please take a quick look at the commit message for a09dc18?
> In that commit message I outline the linking model I used to draw the
> conclusion that the ada, d, f95, java, and ocaml traditional examples
> builds were going to _sometimes_ fail for a certain combination of
> circumstances (static PLplot build with at least one of the C++ device
> drivers enabled).
> 
> I am asking for that review because I hate to give up all those
> components of the comprehensive test of the traditional build for the
> given circumstances if I don't have to.  I am pretty sure your review
> of the linking model I use will show I am right, but nevertheless that
> review would be much appreciated since it would help to put my mind at
> ease about this commit (which disables the relevant parts of the
> comprehensive test for the given combination of circumstances).
> 
> 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
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