plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] A possible design of our new Fortran binding

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

On 2015-05-25 12:38-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> 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.
>>
> I must be overlooking something, because whatever I do with "git format-patch" it invariably produces no patch at all.
>

> I have made my changes on a separate branch, tried to produce a patch file (nothing happened) committed them to the local repository
> and tried to produce a patch file (nothing continued to happen).

Hi Arjen:

I assume from what you said above that your current situation is a
master branch (presumably the same as the one at SF, but if you are
behind in updating that with the SF variant it doesn't matter) and
private branch (let's call it f95update) that is identical to the
master branch except that the f95update branch has some extra commits.
To verify that situation use the "git log --oneline" command, e.g.,

git log --oneline -4 master
git log --oneline -7 f95update

which respectively show the last 4 commits in master and
last 7 commits in f95update where you specified 7 because
you were pretty sure there were 3 extra commits in the f95update branch.

So let's assume those commands show you that your situation is

master: ... A-B-C
                  \ 
f95update:        D-E-F

where D-E-F are the extra commits you want to package with
format-patch.

Then from "git help format-patch" I would try

git checkout f95update
git format-patch master

where "master" refers to the commit ID C at the tip of the master
branch where you branched f95update from master.

For a more complicated example, suppose you have kept up with
ordinary development from the rest of us and updated the master
branch after you created f95update.

Then the situation has changed to

master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
                  \ 
f95update:        D-E-F

In this case to collect D-E-F in a format patch you simply run

git checkout f95update
git format-patch D^

where D^ is notation for the ancestor of D which is the same as C.  Or
you also have the option of rebasing so you end up effectively with

master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
                                    \ 
f95update:                          G-H-I

where I have used different letters for the 3 extra commits to show
that the rebase has changed those commits (since each commit refers to
a complete file system snapshot) from what they were before.  But in
this case

git checkout f95update
git format-patch G^

would give you the same patch file (except for the commit identity
associated with each of the 3 commits) that you produced before.

I hope these examples help to clarify what goes on with git
format-patch, but the principal message I want you to take away from
this is always to use "git help <commandname>" first whenever you are
having trouble figuring out the syntax of some git command.

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...]
>
> 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.
>
I must be overlooking something, because whatever I do with "git format-patch" it invariably produces no patch at all.

I have made my changes on a separate branch, tried to produce a patch file (nothing happened) committed them to the local repository and tried to produce a patch file (nothing continued to happen).

What am I doing wrong? Using options like "HEAD" does not work either.

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] Improved fix for plInBuildTree on Windows

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]

>
> The issue that was fixed is that IGNORECASE was not #defined on any variety of
> Windows for the static build case.  I don't really understand how the comprehensive
> tests that Arjen has been running on Cygwin did not detect that issue, but fortunately
> Phil's recent tests did detect that issue.

One possibility: all my directories are in lower-case, so the issue never arose.

> @Arjen: This fix should also be tested on Cygwin, but I suggest you wait to do that
> until something else needs testing on Cygwin as well.
> And that will probably occur fairly soon since I hope to have some suggestions for
> you later today about additional packages that should be installed on Cygwin to
> broaden the scope of your Cygwin testing still more.
>
Right, I have not looked into this yet. I look forward to them.

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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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"
> [....]
>
A dumb little error on my part:

The line

        ptr_arg = c_loc( arg(iargs) )

should have been:

        ptr_arg(iargs) = c_loc( arg(iargs) )

With the original (erroneous) line all the elements of the array ptr_arg are set to the address of the last option.

I have fixed that now and am working to incorporate all this in a separate branch. On to the patch after that.

Regards,

Arjen

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

Re: [Plplot-devel] PLplot 6 and git

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

Hi Phil:

This is long, but you have given me lots to respond to.  :-)

On 2015-05-24 09:37+0100 Phil Rosenberg wrote:

> Hi Alan and Dave
>
> Some specific comments first, then some general ones after.
>
>> Fundamentally, the git world is split on the rebase-only
>> versus merge-only question
> As it happens I fall in the merge camp. But for the work we have been
> doing up to now I don't feel there has been much difference either
> way.But this is personal and I know you feel strongly about rebase
> only so I have no intention to push you on this.

Just to explain further why I am being so conservative about this....
The advice I got from Brad King (who has experience advising a large
number of software projects on the svn to git transition) is stick
with our current rebase-only workflow until all developers were up to
speed with git.  I would argue we are not there yet since some of the
PLplot developers who were active in the svn era have not contributed
a single commit yet in the git era.  Some of those might just be
missing in action for other reasons, but I know of at least one case
where intimidation concerning git has played a significant role in
delaying participation for at least a while, but I am hoping he will
overcome his fears and become an active developer for PLplot again.
So this is definitely not a good time to start fooling with the
workflow.

Once we do get to the stage of being up to speed with git as a
development team, Brad went on to argue that moving to a merge-only
workflow that preserved a clean first-parent shape of history was not
for the faint-hearted and would require a merge czar (his current role
in CMake development) to fight through all the complicated merge
issues for the master branch with that merge czar being essentially
the only one in control of the master branch.  So the choices for the
merge-only model seem to be to either have a merge czar or abandon all
workflow rules which would mean that the history DAG was extremely
chaotic.

I don't like either of those choices.

I think none of us, including me, are qualified to be the merge czar,
and in any case I think that is bad politics for such a small
development community to have just one or two gatekeepers for the
master branch.  In my view it is much better for all our active
developers to feel responsible for the quality of PLplot including our
git history, and the rule for enforcing rebase-only workflow (no merge
commits allowed) is in principal a lot easier to understand than the
much more complicated rule required to have a good first-parent shape
for the history.

I think providing a meaningful history is really important for such
development work as git bisection to find regressions.  To expand on
that concern, I just skimmed an interesting paper called "Fighting
regressions with git bisect" by Christian Couder which I highly
recommend to others here.  (You can probably find it with a google
search, but for Debian wheezy it appears as 
<file:///usr/share/doc/git/html/git-bisect-lk2009.html>.) The
principal conclusion I drew from this paper was git bisection results
are more reliable the simpler the history.  And git bisection really
is a killer app that I and others used quite a bit in the last release
cycle to find regressions, and I would personally hate to compromise
that killer app by allowing our history to be chaotic due to an
uncontrolled merge workflow.

>> However, we could allow for deliberate rebasing (e.g., to
>> propagate a must-have fix from master to throwaway_plplot6), but that
>> would have to be scheduled a couple of days in advance
> I feel very strongly against this. If somebody misses the deadline
> because they are off email or their work isn't is a state to commit
> (i.e. it would break the build) then we could easily lose large chunks
> of work that somebody has created. In my opinion we absolutely must
> not rebase a branch we are working on. Ever.

I think that restriction is too strong.  Instead, in response to your
concern, I think we could establish the rule that the guy who is
proposing the rebase could simply wait for a positive OK from
everybody who is actively working on the public topic branch (which
might mean in practice the rebase only occurs right at the end when
the topic has matured, see below).

>
> So perhaps some general points now
>
> In the last development cycle I tried to work simultaneously on my
> Windows machine and two Linux machines to test my personal branches on
> all three. The rebase only workflow made this essentially impossible.
> I continually ended up in situations where I broke my repos because I
> rebased some work that existed in another repo and this caused massive
> issues. This was one person with three checked out versions of the
> code and it was a nightmare. If we have more than one person then I
> can guarantee we will break people's repos with almost every rebase.

I think this is an illustration of the point I made previously in this
thread that pushing between multiple servers is virtually a guarantee
of merge commits which are prohibited under the rebase-only workflow.

However, I think you could have made the above work quite simply as
follows (or at least I would like to see you try this method next
time):

1. Always keep master on each server exactly the same as master on
our official SF server.

2. Always rebase your topic branch on each server on that (common)
master branch.

Those two rules mean every topic branch on each of your servers is
identical except for additional development you have made on that
topic branch on one of your servers.  But then it should be trivial
using the "git format-patch"/"git am" method to update all your
servers' topic branches to be identical with the one where you have
done additional recent development, Note especially I have found the
--interactive option of "git am" and "git log --oneline" to be quite
effective in selecting the commits that will be applied from a series
generated by "git format-patch".

> On question that might have an impact. Do we wish to continue
> supporting PLplot 5 for some time with bug fixes? It might be that
> some users have legacy software that relies on v5 API. So maybe we
> should consider having permanently separate v5 and v6 branches? I'm
> not sure what this does to our development model.

See below for an answer to this question.

>
> I'm not sure this is right, but I would assume that if we apply a bug
> fix to the v5 branch then create a patch of this commit and apply that
> to the v6 branch then if we ever merge (or rebase) the branches then
> git is clever enough to not create a conflict. Is this correct?

I don't think we should limit how we develop on throwaway-plplot6 by
trying to avoid in advance rebase conflict issues.  So using patches
from master to throwaway-plplot6 or rebasing (if you can get complete
agreement to that step for all active developers at the time) should
be fine.  Of course, when we do our final rebase before the merge (see
below), we will just have to deal with conflicts the way that is
described in "git help rebase".

>
> So in my opinion we have limited options (in no particular order)
> 1)We just don't run a parallel v6 branch.
> 2)We run a parallel branch permanently and if we have commits we wish
> to apply to both v5 and v6 we do so with a patch
> 3)We run a parallel branch permanently and if we have commits we wish
> to apply to both v5 and v6 we do a rebase (I think this would be very
> bad!!!)
> 4)We move to a merge workflow
> 5)We hide our v6 branch so we only break out own when we rebase only
> once when v6 is ready (already discounted by Alan)
>
> Out of all those perhaps the idea of having a v5 and v6 branch that we
> actually never merge together, and use patches to commit to both gives
> use the advantage of parallel branches and also rebase workflow?
>

That last is pretty close to one of the two options I proposed so I
think we are quite close to consensus here.  In my proposal the names
of the two public branches would be throwaway-plplot6 for PLplot 6
development and master for PLplot 5 development.  And even if you are
uncomfortable with the rebase method I proposed above to deal with the
developer who is temporarily out of e-mail contact, I think it is
important to rebase at least when throwaway-plplot6 has matured to
make sure all innovations and bug fixes that are on the master branch
that are relevant to PLplot 6 are continued when throwaway-plplot6 is
merged into master.

To make that proposal more specific we should do the following once 
throwaway-plplot6 has matured.

1. Tag the tip of the master branch (with a name like
plplot5-branchpoint for easy future reference).

2. Rebase throwaway-plplot6 with master (making sure that
everyone is aware of this so that nobody is left behind
by this change).

3. merge --ff-only throwaway-plplot6 onto master.

4. Delete throwaway-plplot6.

In other words, we generally treat the public throwaway-plplot6 branch
the same as we ordinary treat a small private topic branch except that
the rebasing of throwaway-plplot6 will probably more limited due to
the developer coordination reasons discussed above.

In sum, I think this is a good compromise git development proposal
that works well for our rebase-only workflow, and which also satisfies
your concerns with ease of collaboration for many developers working
on a private topic branch.

Assuming you agree with this proposal and nobody else can find some
git issue with it, then I would like to flesh out how I visualize the
transition between PLplot 5 and PLplot 6.

The maturation stages that PLplot 6 will go through are something
like the following:

1. Just beginning to work, i.e., parts of it work on one specific
platform. (I assume it would take you only a week or so to achieve
this with a C++ plplot core with decent error propagation and a
corresponding C wrapper.)

2. Partly working, i.e., most components work on most platforms we
have access to.  We would want this to be an all-out effort
concentrating strictly on introducing all backwards-incompatible
changes we want for PLplot 6.  That is, I hope this can be done in a
month or so rather than dragging it out for years with problems in
that case with feature creep that tends to be an issue for unreleased
software.

3. Mostly working, i.e., the comprehensive test script works for
everyone on all platforms we can access as well as it does for PLplot
5.  The amount of time and effort going into this part of the effort
will depend strongly on how much test platform coverage we already
have achieved for PLplot 5, but I am hoping we achieve large coverage
for both PLplot 5 very soon now and PLplot 6 when it is ready so that
users of either will have a smooth ride on most platforms.

4. Completely works for us, e.g., the comprehensive test script without
any special options (i.e., testing everything) works for all of us
on the various platforms we have access to.

Note, I continue to strive for stage 4 with PLplot 5 which makes stage
3 a moving target for PLplot 6.  For example, with my help both in
selecting packages and with any further build system issues we run
into I hope Arjen will be able to achieve perfect comprehensive test
results in the next few weeks for a Cygwin platform where all possible
PLplot prerequisites have been installed.  And once that goal is
achieved and with willingness of our developers to run the tests on
the various platforms accessible to them, it should be fairly
straightforward to achieve similar good results on MinGW-w64/MSYS2 (as
a close analog of the Cygwin success) and Mac OS X (as a fairly close
Unix analog of our Linux success). But, I am pretty sure the
equivalent comprehensive testing success on MSVC is going to be more
difficult to achieve (even for the limited prerequisites that are
available on that platform) so I expect the distinction between stages
3 and 4 for PLplot 6 is going to be a real one for some time to come.

Also note that PLplot 6 is going to be backwards-incompatible with
PLplot 5 so making that transition is going to be painful for our
users without much to gain from their prospective other than a
superior response to errors. So we want to reduce their pain as much
as possible by avoiding a release of PLplot 6 before it is ready.
Furthermore, we have limited manpower so we want to minimize the
length of time we have to support both PLplot 5 and PLplot 6, and the
best way to do that is do not release PLplot 6 until it is ready i.e.,
it has _completely_ achieved stage 3 above.  So what I have in mind is
only when stage 3 has been achieved do we do the above steps to merge
throwaway-plplot6 onto master and release PLplot-5.99.y releases (6.0
release candidates) soon after for our users to evaluate followed by
the 6.0.0 release just as soon as we have no more user complaints
about those release candidates.

Note, I am emphasizing speed of development here and reliability
rather than features.  However, it sounds from what you have said that
propagating all error conditions will be trivial so it will be nice to
have that feature right away as (say) the sole initial selling point
of PLplot 6.0.0 to help pay for the user pain of the transition
from PLplot 5 to 6.

If we follow that model it should be possible in theory to go smoothly
from the last PLplot 5.x release (where x < 99) to the release of
6.0.0 with no overlap in support between PLplot 6 and 5, but we should
definitely tag the last PLplot 5 commit (as I stated in the details
above), and subsequently (if needed) use that tag as the origin of a
semi-permanent public plplot5 branch if we need to do further PLplot
5.x bug-fix releases. Obviously in this case the plplot5 branch would
never be rebased or merged with the master branch since PLplot 5 would
be a dead-end branch of development (only devoted to minimal bug
fixing) by design.

Sorry this has been so long, but there is a lot to think about beyond
just the programming aspects when planning our move from PLplot 5 to
PLplot 6!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot 6 and git

[David M. <da...@as...>]

Hi, Phil,

On May 24, 2015, at 1:37 AM, Phil Rosenberg wrote:

> I'm not sure this is right, but I would assume that if we apply a bug
> fix to the v5 branch then create a patch of this commit and apply that
> to the v6 branch then if we ever merge (or rebase) the branches then
> git is clever enough to not create a conflict. Is this correct?

If the exact same patch is applied, then git is clever enough not to make a conflict on a subsequent merge/rebase.  If the patch needs to be altered slightly to apply it to the v6 branch (e.g. if variable names or indentation have changed slightly on the v6 branch), then I think git will mark it as a conflict on a subsequent merge/rebase, but such cases are usually trivial to resolve.

Dave

Re: [Plplot-devel] PLplot 6 and git

[David M. <da...@as...>]

 	
On May 23, 2015, at 1:14 PM, Alan W. Irwin wrote:

> I think we just have to agree to disagree on this issue.

I agree! :-)

> Fundamentally, the git world is split on the rebase-only
> versus merge-only question, and we just happen to fall in different
> camps.

To be honest, this prompted me to research this point and I was surprised to find how large the rebase-only camp is.

Dave

Re: [Plplot-devel] PLplot 6 and git

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

Hi Alan and Dave

Some specific comments first, then some general ones after.

>Fundamentally, the git world is split on the rebase-only
>versus merge-only question
As it happens I fall in the merge camp. But for the work we have been
doing up to now I don't feel there has been much difference either
way.But this is personal and I know you feel strongly about rebase
only so I have no intention to push you on this.


>However, we could allow for deliberate rebasing (e.g., to
>propagate a must-have fix from master to throwaway_plplot6), but that
>would have to be scheduled a couple of days in advance
I feel very strongly against this. If somebody misses the deadline
because they are off email or their work isn't is a state to commit
(i.e. it would break the build) then we could easily lose large chunks
of work that somebody has created. In my opinion we absolutely must
not rebase a branch we are working on. Ever.

So perhaps some general points now

In the last development cycle I tried to work simultaneously on my
Windows machine and two Linux machines to test my personal branches on
all three. The rebase only workflow made this essentially impossible.
I continually ended up in situations where I broke my repos because I
rebased some work that existed in another repo and this caused massive
issues. This was one person with three checked out versions of the
code and it was a nightmare. If we have more than one person then I
can guarantee we will break people's repos with almost every rebase.

On question that might have an impact. Do we wish to continue
supporting PLPlot 5 for some time with bug fixes? It might be that
some users have legacy software that relies on v5 API. So maybe we
should consider having permanently separate v5 and v6 branches? I'm
not sure what this does to our development model.

I'm not sure this is right, but I would assume that if we apply a bug
fix to the v5 branch then create a patch of this commit and apply that
to the v6 branch then if we ever merge (or rebase) the branches then
git is clever enough to not create a conflict. Is this correct?

So in my opinion we have limited options (in no particular order)
1)We just don't run a parallel v6 branch.
2)We run a parallel branch permanently and if we have commits we wish
to apply to both v5 and v6 we do so with a patch
3)We run a parallel branch permanently and if we have commits we wish
to apply to both v5 and v6 we do a rebase (I think this would be very
bad!!!)
4)We move to a merge workflow
5)We hide our v6 branch so we only break out own when we rebase only
once when v6 is ready (already discounted by Alan)

Out of all those perhaps the idea of having a v5 and v6 branch that we
actually never merge together, and use patches to commit to both gives
use the advantage of parallel branches and also rebase workflow?

Phil

On 23 May 2015 at 21:14, Alan W. Irwin <ir...@be...> wrote:
> Hi Dave:
>
> I already made my points about continuing with the present workflow
> for quite a while longer if not indefinitely in my original post
> starting this topic so I think we just have to agree to disagree on
> this issue.  Fundamentally, the git world is split on the rebase-only
> versus merge-only question, and we just happen to fall in different
> camps.
>
> On 2015-05-23 11:59-0700 David MacMahon wrote:
>
>> A fairly significant advantage (IMHO) to keeping 5.8 and 6
>
> development in one repository is that it makes it much easier to diff
> between versions.
>
> This is another good point against separate servers.  But I am pretty
> sure Phil will agree with a variation of his idea (collaborate on a
> throwaway public topic branch devoted to PLplot 6 development) that I
> just proposed where it is implemented on the SF server with suitable
> warnings.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] PLplot 6 and git

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

Hi Dave:

I already made my points about continuing with the present workflow
for quite a while longer if not indefinitely in my original post
starting this topic so I think we just have to agree to disagree on
this issue.  Fundamentally, the git world is split on the rebase-only
versus merge-only question, and we just happen to fall in different
camps.

On 2015-05-23 11:59-0700 David MacMahon wrote:

> A fairly significant advantage (IMHO) to keeping 5.8 and 6
development in one repository is that it makes it much easier to diff
between versions.

This is another good point against separate servers.  But I am pretty
sure Phil will agree with a variation of his idea (collaborate on a
throwaway public topic branch devoted to PLplot 6 development) that I
just proposed where it is implemented on the SF server with suitable
warnings.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot 6 and git

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

On 2015-05-23 09:23+0100 Phil Rosenberg wrote:

> Hi Alan

> My initial thought was as yours. To have a separate plplot6 branch.
I have a feeling that with so many of us it might be difficult to keep
track of sending patches round. Do you know how that would work with
clashes? I.e if two people send patches round that clash do we have
the potential for every developer would generate their own personal
resolution that would clash with everyone else's?

Caveat: I want to respond here on general grounds for whenever we do
use the "git format-patch"/"git am" method, but that doesn't
necessarily mean I dislike your public branch idea you discussed below
so see there for further discussion of your idea.

First, I don't think there are going to be that many conflicts since
we all tend to stick to our strengths (e.g., I doubt I will doing lots
of changes to the C++ code, and I doubt you will doing lots of changes
to the build system).  But I think others here do pretty much trust me
on build system matters, and you on C++ matters.  So if I resolve a
rare conflict in the build system or you resolve a rare conflict in
the C++ code, I think others will pay attention and accept our
resolutions (as expressed in our constantly updated patch series)
rather than trying to resolve the conflicts for themselves.

> It also sounds quite was for someone to miss a patch.

See Caveat above.

We don't have a lot of experience with this method yet, but obviously
you do have to pay close attention to "git log --oneline" results from
your current private topic branch to see which of a given series
should be applied with "git am --interactive".  And when presenting a
patch series, good communications are a big help, e.g., if you rebased
your private topic branch to get some key fix on master into the
private topic branch that changes at least the commit id's of your 
whole patch series.  Therefore, if you have rebased your patch series
you should say so.  And similarly if your patch series does not
contain all of the private topic branch, you should state something
like "apply this on top of Alan's latest".  etc.

> As you identified, we certainly need parallel development on 5.8 and
6. But if those branches are public they need to not disappear.

> I could make one last alternative suggestion. We could have a
private git site. This could have separate 5.8 and 6 branches. Then
when we are ready to merge we can rebase the branch, push it to our sf
repo and close the site. Then we know that only the devs will have
access and it's our own fault if we have uncommited work based on the
branch that dissapears. If it is useful I have a static ip, a fibre
optic internet connection and an always on Linux box that I use as a
media centre. It might have a 98% uptime rather than 99.9% but it
would be free and I'd be happy to set it up for access for everyone.

That's a nice offer which I very much appreciate.  However, I am
concerned that in general it is difficult to merge results from two
different servers in active use without triggering merge commits
which, of course, are prohibited on the SF server (and would likely be
prohibited on the "Phil" server as well assuming we would be following
the same enforced workflow rules there).  I am thinking of the
scenario of different PLplot 5 development pushes happening at both
the "Phil" server and also the SF one before a merge of one to the
other.  That is a recipe for merge-commit disaster.

You could work around that by enforcing a git vacation at SF so that
only the "Phil" server could be used for further development for a
while.  But then there are concerns about up time, backups, etc.

Another alternative for creating a public topic branch for PLplot 6
development would be to do that at SF, but temporarily prohibit
everyone but core developers from even reading those results (which it
is certainly possible to arrange at SF). But I think that interferes
too much with those who are testing and following PLplot development
but who are not core developers.  And actually, there is the same
objection to not allowing read access results to non-core developers
on the "Phil" server.

So if we are going to collaborate on PLplot 6 development with a public
topic branch, I think that must be done at SF with full public access
with suitable warnings for the public that the branch is
a temporary one that will be rebased from time to time and which
will eventually disappear.  And if someone ignored those warnings, they
would just have to accept the consequences.

Technical git question: is it possible to name a branch something
like throwaway/plplot6 to help ram home the point?  Of course, if
that is not possible the name throwaway_plplot6 would be equally
effective.

I do agree that collaboration on a huge development topic such as
throwaway_plplot6 using this approach would be a lot more convenient than the
"git format-patch"/"git am" method.

However, the big caveat here (if I understand the web warnings about
this) is we would have to be extremely careful of rebasing. For
example, I think if someone did that by accident on their local repo
and pushed the result to the throwaway_plplot6 branch at SF, I think
we would all lose our local committed but unpushed work on that
branch.  However, we could allow for deliberate rebasing (e.g., to
propagate a must-have fix from master to throwaway_plplot6), but that
would have to be scheduled a couple of days in advance so that
everyone had a chance to push their changes first.  However, I freely
admit I might be being overcautious about the consequences to PLplot
developers of rebasing a public topic branch so correct me if that is
the case.

In sum, I think the two good choices for PLplot 6 collaboration are
the following:

(1) Collaborate on a private topic branch using "git
format-patch"/"git am" but with the question still to be answered
about how difficult it would be to scale that method to collaboration
on a very large development topic such as PLplot 6.

(2) Collaborate on a public topic branch hosted at SF with suitable
public warnings and accepting the big caveat about having to be
extremely careful about rebasing. The big advantage of (1) to my mind
is it allows us to gain some important experience with that method
which we will likely be using in any case for collaborations on
smaller topics. But the case for ease-of-use for (2) is pretty
compelling despite the caveats.  So I am actually leaning slightly
toward (2) at the moment for really big topics like PLplot 6
development unless there is some git issue I forgot.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot 6 and git

[David M. <da...@as...>]

Hi, Phil et al.,

On May 23, 2015, at 1:23 AM, Phil Rosenberg wrote:

> I could make one last alternative suggestion. We could have a private git site. This could have separate 5.8 and 6 branches. Then when we are ready to merge we can rebase the branch, push it to our sf repo and close the site.

I'm not an active PLplot developer, just a lurker on the list, so feel free to disregard my comments.  I like your suggestion for having separate 5.8 and 6 branches, but I wonder why people feel the need to keep them in a separate (possibly even "private") repository.  Why not just create the "plplot-6" (and related) branch(es) in the public repository right now (leaving "master" as the de-facto "plplot-5.8" branch)?

If it is motivated by a desire to adhere to the rebase-only workflow, yet it causes you to setup private repositories and/or email multiple (possibly conflicting) patches around, then you're not really taking full advantage of what git does.  Maybe it's time to re-examine the original motivations for the rebase-only workflow to see whether they carry the same weight as before.  I think the migration from svn to git, both technically and mindset-wise, was one of the major reasons for choosing the rebase-only workflow.  Maybe that's not so important anymore?

A fairly significant advantage (IMHO) to keeping 5.8 and 6 development in one repository is that it makes it much easier to diff between versions.

Just some thoughts,
Dave

[Plplot-devel] Improved fix for plInBuildTree on Windows

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

To Arjen and Phil:

I have just now (commit id 3644bc3) reverted Phil's recent C-level
fix for plInBuildTree on Windows and replaced it with a more general
CMake-level fix that makes sure IGNORECASE is always #defined on
all varieties of Windows.  Since all sorts of tests are sensitive
to plInBuildTree delivering the correct result, I throughly tested
my fix on Linux using a default (i.e., all tests were run) comprehensive
test on that platform.

The issue that was fixed is that IGNORECASE was not #defined on any
variety of Windows for the static build case.  I don't really
understand how the comprehensive tests that Arjen has been running on
Cygwin did not detect that issue, but fortunately Phil's recent tests
did detect that issue.

@Phil: Please give this improved fix a try for the MSVC static case where
you had trouble with plInBuildTree before.

@Arjen: This fix should also be tested on Cygwin, but I suggest you
wait to do that until something else needs testing on Cygwin as well.
And that will probably occur fairly soon since I hope to have some
suggestions for you later today about additional packages that should
be installed on Cygwin to broaden the scope of your Cygwin testing
still more.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot 6 and git

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

Hi Alan
My initial thought was as yours. To have a separate plplot6 branch. I have a feeling that with so many of us it might be difficult to keep track of sending patches round. Do you know how that would work with clashes? I.e if two people send patches round that clash do we have the potential for every developer would generate their own personal resolution that would clash with everyone else's? It also sounds quite was for someone to miss a patch.

As you identified, we certainly need parallel development on 5.8 and 6. But if those branches are public they need to not disappear. 

I could make one last alternative suggestion. We could have a private git site. This could have separate 5.8 and 6 branches. Then when we are ready to merge we can rebase the branch, push it to our sf repo and close the site. Then we know that only the devs will have access and it's our own fault if we have uncommited work based on the branch that dissapears. If it is useful I have a static ip, a fibre optic internet connection and an always on Linux box that I use as a media centre. It might have a 98% uptime rather than 99.9% but it would be free and I'd be happy to set it up for access for everyone.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎23/‎05/‎2015 00:27
To: "PLplot development list" <Plp...@li...>
Subject: [Plplot-devel] PLplot 6 and git

Assuming we move forward with plplot6 development in the short term
(either with or without moving to C++ for the core library depending
on what the consensus is here on that topic), then we should also
start thinking about the git workflow implications of such a large and
important development topic.

Our current rebase workflow does allow us to create a public topic
branch called (say) plplot6 which would make it very easy for us to
collaborate on PLplot 6 development on that branch. But our workflow
rules absolutely prohibit merging that public branch back to master
unless plplot6 is rebased, but rebasing of a public branch is never a
good idea since it annoys users who are depending on some of those
public commits which disappear due to rebasing.  Of course, one
possibility is simply never to rebase and never to merge and then when
the plplot6 branch has matured we could rename the master branch to
plplot5 and rename plplot6 to master.  But I am concerned we are all
in such a habit of rebasing private branches we are working on, that
someone would try that for the public plplot6 branch which would not
be a good result for the above reason.

So because of that concern about accidental rebasing, my gut feeling
is it would be better to create plplot6 as a private topic branch
where local private rebases are fine, and simply collaborate on
plplot6 development using the well-known "git format-patch"/"git am"
method that has worked reasonably well in the past for collaborations
between Phil, Jim, and me; which I am encouraging Arjen to use in
his future collaboration with me on the new fortran binding private
topic branch; and which other software projects use a lot for
their own private topic branch development.

Of course, another possibility is to change to an alternative git
workflow i.e., the merge-only first-parent linear history workflow
recommended by Brad King that he suggested we might want to move to
after all our developers are completely comfortable with git using the
current rebase workflow that he recommended we start with.  That
alternative does allow easier public collaboration at the expense of a
lot more complexity in both following and enforcing the workflow. But
I think it is much too soon for such a change in our workflow because
not all our developers are comfortable with git yet.  Furthermore, I
quite like the current rebase-only workflow (as described in
README.developers) so I would like to continue with that indefinitely
and develop major topics such as plplot6 always on rebased private
branches using "git format-patch"/"git am".

Comments?

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] PDL_VERSION error

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

On 2015-05-22 11:05-0600 Orion Poplawski wrote:

> with current plplot git on Fedora rawhide with cmake 3.2.2, I'm getting:
>
> -- PDL_VERSION = 2.007
> CMake Error at cmake/modules/plplot_functions.cmake:181 (math):
>  math cannot parse the expression: "2*1000000 + 007*1000 + 2.007": syntax
>  error, unexpected exp_NUMBER, expecting $end (28)
> Call Stack (most recent call first):
>  cmake/modules/pdl.cmake:63 (transform_version)
>  cmake/modules/plplot.cmake:489 (include)
>  CMakeLists.txt:111 (include)
>
> I don't normally build on a system with PDL installed, so I didn't see this
> before.

Commit 38ea064 should fix this, but please check and let me know whether
or not that is the 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
__________________________

[Plplot-devel] PLplot 6 and git

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

Assuming we move forward with plplot6 development in the short term
(either with or without moving to C++ for the core library depending
on what the consensus is here on that topic), then we should also
start thinking about the git workflow implications of such a large and
important development topic.

Our current rebase workflow does allow us to create a public topic
branch called (say) plplot6 which would make it very easy for us to
collaborate on PLplot 6 development on that branch. But our workflow
rules absolutely prohibit merging that public branch back to master
unless plplot6 is rebased, but rebasing of a public branch is never a
good idea since it annoys users who are depending on some of those
public commits which disappear due to rebasing.  Of course, one
possibility is simply never to rebase and never to merge and then when
the plplot6 branch has matured we could rename the master branch to
plplot5 and rename plplot6 to master.  But I am concerned we are all
in such a habit of rebasing private branches we are working on, that
someone would try that for the public plplot6 branch which would not
be a good result for the above reason.

So because of that concern about accidental rebasing, my gut feeling
is it would be better to create plplot6 as a private topic branch
where local private rebases are fine, and simply collaborate on
plplot6 development using the well-known "git format-patch"/"git am"
method that has worked reasonably well in the past for collaborations
between Phil, Jim, and me; which I am encouraging Arjen to use in
his future collaboration with me on the new fortran binding private
topic branch; and which other software projects use a lot for
their own private topic branch development.

Of course, another possibility is to change to an alternative git
workflow i.e., the merge-only first-parent linear history workflow
recommended by Brad King that he suggested we might want to move to
after all our developers are completely comfortable with git using the
current rebase workflow that he recommended we start with.  That
alternative does allow easier public collaboration at the expense of a
lot more complexity in both following and enforcing the workflow. But
I think it is much too soon for such a change in our workflow because
not all our developers are comfortable with git yet.  Furthermore, I
quite like the current rebase-only workflow (as described in
README.developers) so I would like to continue with that indefinitely
and develop major topics such as plplot6 always on rebased private
branches using "git format-patch"/"git am".

Comments?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

On 2015-05-22 13:00+0100 Phil Rosenberg wrote:

> Hi All
> I mentioned this briefly during the previous release cycle, but we all
> had more pressing things to deal with. Dealing with errors is
> something we really  need to get a hold on for PLPlot 6 and one of the
> big drivers for considering a major API change. However, I am certain
> that the reason why this has been a problem s that propagating those
> errors back up through many layers of function calls is tedious and
> error prone so it has been much simpler to simply call exit().
>
> Here is one possible solution. We switch the core code to C++ with a C frontend.
>
> I am aware some people on this list know C++ better than others,
> however, the actual code changes I am suggesting are relatively small.
> It may seem daunting, but I am not considering rewriting everything in
> an object oriented way, I am simply advocating using two features of
> C++ which will make our lives massively easier. I feel the change
> would be less painful that the switch from svn to git, but with much
> larger gains so please hear me out. So the following is aimed at those
> of us who are a bit wary of C++ that have better C skills. If I'm
> teaching my granny to suck eggs then I apologise.

Hi Phil:

I am one of those active devopers without C++ skills at the present
time, but I could slowly acquire those as needed just as I have done
since 2000 with C, DocBook, Python, CMake, and Fortran 95 for my
PLplot development needs. (Before I started working on PLplot in 2000
the only computer language I needed or used was Fortran 77.) That
said, however, there are plenty of PLplot topics on my plate (e.g.,
build system, testing, documentation) so if I ended up leaving the
development of the C++ core library to others, that might be a good
division of the on-going development labour.

Anyhow, I have no objections to moving to a C++ core library from
personal concerns about me not knowing the language.  And you did go
on to describe the C++ advantages of proper handling of arrays and
propagation of error conditions which sounds like a substantial
benefit.

However, let's be clear here the cost of that benefit is
likely to be considerably higher than you are estimating now.
For example, there is going to be substantial costs in terms of
doxygen and DocBook documentation, and also the domestic bindings and
foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
some concern.  Of course, in theory you could write a perfect C wrapper
library for the C++ core so bindings on that C wrapper work just as
well as they do for PLplot 5.  But that C wrapper would really
have to be perfect and would make the bindings less efficient.  Note,
I don't want to emphasize that last point too much since reliability
is much more important to me than speed.  But at some point, I assume
you will want to address that issue (e.g., for the swig-generated
bindings) by ignoring the C wrapper and binding directly to the C++
core instead which adds to the cost of this change.

Anyhow, I just wanted to sound a note of caution here about the amount
of labour involved, but with a perfect C wrapper I see no fundamental
concerns with such a change.  So if you can get the other active core
developers on-side with changing our core library to C++, then I
certainly will not stand in the way and, in fact, if the consensus is
yes, then I expect to immediately be taking an active part in this
change via required changes that will be needed to the build system
and the documentation.

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

[Orion P. <or...@co...>]

On 05/22/2015 03:58 AM, Phil Rosenberg wrote:
> 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?


with wxGTK3-devel-3.0.2-5.fc23.x86_64 I get the attached.


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

[Plplot-devel] PDL_VERSION error

[Orion P. <or...@co...>]

with current plplot git on Fedora rawhide with cmake 3.2.2, I'm getting:

-- PDL_VERSION = 2.007
CMake Error at cmake/modules/plplot_functions.cmake:181 (math):
  math cannot parse the expression: "2*1000000 + 007*1000 + 2.007": syntax
  error, unexpected exp_NUMBER, expecting $end (28)
Call Stack (most recent call first):
  cmake/modules/pdl.cmake:63 (transform_version)
  cmake/modules/plplot.cmake:489 (include)
  CMakeLists.txt:111 (include)

I don't normally build on a system with PDL installed, so I didn't see this
before.

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

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

[Orion P. <or...@co...>]

On 05/22/2015 03:58 AM, Phil Rosenberg wrote:
> 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?
> 

Actually, this was using wxGTK-devel-2.8.12-18.fc23.x86_64. I guess I'm going
to think about making the transition to wxGTK3.  I don't suppose plplot can
support building against both simultaneously?


/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/bindings/wxwidgets/wxPLplotstream.cpp:141:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]

/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual wxLog* wxAppConsole::CreateLogTarget()' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual wxMessageOutput* wxAppConsole::CreateMessageOutput()' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplviewer.cpp:67:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]

/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/utils/wxplframe.cpp:356:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]

/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets.cpp:513:1: warning:
'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is deprecated
[-Wdeprecated-declarations]


/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1203:32:
warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1323:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/drivers/wxwidgets_dev.cpp:1278:35:
warning: ignoring return value of 'int system(const char*)', declared with
attribute warn_unused_result [-Wunused-result]

/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual wxLog* wxAppConsole::CreateLogTarget()' is deprecated
[-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual wxMessageOutput* wxAppConsole::CreateMessageOutput()' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]
/builddir/build/BUILD/plplot-5.11.0git/examples/c++/wxPLplotDemo.cpp:138:1:
warning: 'virtual void wxWindowBase::SetInitialBestSize(const wxSize&)' is
deprecated [-Wdeprecated-declarations]


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


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

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

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

On 2015-05-22 12:15+0100 Phil Rosenberg wrote:

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

Yes, a lot of possibilities are available as command-line options
(which are all run before plinit).  Here are some from the result of
the -h command-line option (where I have removed a number I don't
think are relevant):

PLplot options:
     -dev name            Output device name
     -o name              Output filename
     -px number           Plots per page in x
     -py number           Plots per page in y
     -geometry geom       Window size/position specified as in X, e.g., 400x300, 400x300-100+200, +100-200, etc.
     -width width         Sets pen width (0 <= width)
     -bg color            Background color (FF0000=opaque red, 0000FF_0.1=blue with alpha of 0.1)
     -ncol0 n             Number of colors to allocate in cmap 0 (upper bound)
     -ncol1 n             Number of colors to allocate in cmap 1 (upper bound)
     -db                  Double buffer X window output
     -np                  No pause between pages
     -dpi dpi             Resolution, in dots per inch (e.g. -dpi 360x360)
     -compression num     Sets compression level in supporting devices
     -cmap0 file name     Initializes color table 0 from a cmap0.pal format file in one of standard PLplot paths.
     -cmap1 file name     Initializes color table 1 from a cmap1.pal format file in one of standard PLplot paths.
     -drvopt option[=value][,option[=value]]* Driver specific options
     -mfo PLplot metafile name Write the plot to the specified PLplot metafile
     -mfi PLplot metafile name Read the specified PLplot metafile

I am sure you had good reasons for needing to insert the extra
plP_state calls, but from one test where I change character size
before running plinit, they definitely segfaulted when level is 0.  So
although it is not the same test, if you remove the level protection,
I am pretty sure you will get a segfault (at least on Linux which is
more sensitive to memory management errors than Windows) using, e.g.,
-bg 0000FF_0.1.

Anyhow, this whole subject area is really beyond my understanding of
the PLplot code so I am going to leave it to you to figure out how to
avoid the segfaults while still satisfying the need not to mess up
renders from the buffer.

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-22 10:06+0100 Phil Rosenberg wrote:

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

Hi Phil:

No problem, and I am just glad you figured it out.

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 Jim
Did you see my subsequent email. A clean build tree fixed all these
errors. Don't know what the cause was.

Phil

On 22 May 2015 at 13:38, Jim Dishaw <ji...@di...> wrote:
> Thanks. What compiler and OS version was this on?
>
>
>
>> On May 22, 2015, at 4:57 AM, 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] Next steps for comprehensive testing on Cygwin

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

Hi Alan,



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

>From the report by CMake:

-        Itcl is not accepted, because CMake could not find the accompanying library - that is available though

-        Ocaml is not accepted, because CMake can not find camlidl, well that is simply not in the installation. I installed all things that contained "caml" in their name/description, but it is missing from Cygwin nonetheless

-        Qhull is not accepted either, same issue as for Itcl

-        Pyqt4 is not accepted because CMake does not find sip - again it all seems to be there

-        Tk is turned off because there was no X Window server, but that has different issues

Anyway, some progress has been made, but there remain a few things to sort out. Indeed, humbling :).

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

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

Thanks. What compiler and OS version was this on? 



> On May 22, 2015, at 4:57 AM, 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

[Plplot-devel] PLPlot 6 and C++

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

Hi All
I mentioned this briefly during the previous release cycle, but we all
had more pressing things to deal with. Dealing with errors is
something we really  need to get a hold on for PLPlot 6 and one of the
big drivers for considering a major API change. However, I am certain
that the reason why this has been a problem s that propagating those
errors back up through many layers of function calls is tedious and
error prone so it has been much simpler to simply call exit().

Here is one possible solution. We switch the core code to C++ with a C frontend.

I am aware some people on this list know C++ better than others,
however, the actual code changes I am suggesting are relatively small.
It may seem daunting, but I am not considering rewriting everything in
an object oriented way, I am simply advocating using two features of
C++ which will make our lives massively easier. I feel the change
would be less painful that the switch from svn to git, but with much
larger gains so please hear me out. So the following is aimed at those
of us who are a bit wary of C++ that have better C skills. If I'm
teaching my granny to suck eggs then I apologise.

The first feature is throw-catch. It would work like this

#define PLERR int
#define PLERR_NONE 0
#define PLERR_OUTOFMEM 1

void someFunc();

PLERR plapiFunc( /*some parameters*/ )
{
   try
   {
      //Any number of function calls declarations etc down to any level
      //But for example lets call someFunc()
      someFunc();
   }
   catch( PLERR err )
   {
      return err;
   }
}

void someFunc()
{
   PLINT *array=malloc( 100000000000000 *sizeof(PLINT);
   if( array == NULL )
      throw( PLERR_OUTOFMEM );
   //do some stuff
   free( array );
}

So the way this works is that if at any time you call throw, the
function returns to its calling function taking the parameter with it.
If the call was made outside of a try block then it returns again and
again until eventually it finds the try block and enters the catch
block. In this case it assigns the error and returns it. Then
execution continues from that point.

This would mean that we could simply replace all exit calls with throw
calls instead and the job would be done!!!

Well actually that's not quite true. There is one other thing to deal
with. Although we now don't exit, if any memory was allocated between
the call in the try block and the throw then it will leak. This is
still an improvement. Memory leaks are surely better than unexpected
exits. At least now the user has the option to do something like write
recovery data to disk and restart or try to trace the problem.

But there is a solution. We create an array class. and do our memory
allocations in that class. Here we are not talking about anything too
fancy, just a simple class without any inheritance or polymorphism. It
would look something like:

class PLINTArr
{
public:
   PLINTArr(PLINT n);
   ~PLINTArr();
   PLINT &operator[]( PLINT idx );
private:
   PLINT m_*mem;
};

PLINTArr::PLINTArr( PLINT n )
{
   m_mem = malloc( n );
   if ( !m_mem )
      throw( PLERR_OUTOFMEM );
}

PLINTArr::~PLINTArr()
{
   free( m_mem );
}

PLINTArr::PLINT &operator[]( PLINT idx )
{
   return m_mem[idx];
}

How does this help? The joy of an object is that when you create one
the constructor is called and when it goes out of scope the destructor
is called. So we can now have

void someFunc()
{
   PLINTArr arr( 100000000000000 );
}

This calls the constructor PLINTArr::PLINTArr with the number of
elements we want in our array. Checking if the allocation was okay has
been done for us so that saved us a job. And when arr goes out of
scope PLINTArr::~PLINTArr is called and everything gets cleaned up, so
we don't even have to worry about that either.

But what is even better, we can do something like this

void someFunc()
{
   PLINTArr arr( 100 );
   char *filename = getFilename();
   if (strlen( filename ) == 0 )
      throw( PLERR_FILENOTFOUND );
}

If throw gets called then someFunc returns, arr goes out of scope, the
destructor is called which cleans up for us and now we have perfect
error reporting and no memory leaks!!!

The effort required to make these changes is tiny compared to trying
to propagate errors back through the code and track down memory leaks
on the way. So it would be something that I would really like to push
if people are open to it.

Any thoughts?

Phil