plplot-general — PLplot user discussion group

[Plplot-general] How do I rotate tick labels for an axis using plplot?

[Jamil E. <unc...@gm...>]

Hi,

I am using [PLplot][1] in C to generate some simple 2-d plots of time
series data and the labels for my x-axis in the resulting plot are
currently horizontal.  Does anyone know how to rotate the tick labels
by 45 deg?  To make it clear what I mean by rotation of tick labels,
[here][2] is an example of rotation of tick labels by 90 degrees in a
plot created using Python/MatPlotlib.

Looking through the PLPlot [documentation][3] I found reference to
[plslabelfunc][4] but I'm not sure how to use this to achieve my goal.

Best would be if someone could show how to modify this simple example
taken from the PLplot [examples][5]:

    #include "plcdemos.h"
    #define NSIZE    101

    int
    main( int argc, const char *argv[] )
    {
      PLFLT x[NSIZE], y[NSIZE];
      PLFLT xmin = 0., xmax = 1., ymin = 0., ymax = 100.;
      int   i;

      // Prepare data to be plotted.
      for ( i = 0; i < NSIZE; i++ )
      {
          x[i] = (PLFLT) ( i ) / (PLFLT) ( NSIZE - 1 );
          y[i] = ymax * x[i] * x[i];
      }

      // Parse and process command line arguments
      plparseopts( &argc, argv, PL_PARSE_FULL );

      // Initialize plplot
      plinit();

      // Create a labelled box to hold the plot.
      plenv( xmin, xmax, ymin, ymax, 0, 0 );
      pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );

      // Plot the data that was prepared above.
      plline( NSIZE, x, y );

      // Close PLplot library
      plend();

      exit( 0 );
    }

Any help would be most appreciated.  I should also mention I posted
this question on stackoverflow at
http://stackoverflow.com/questions/26189242/how-do-i-rotate-tick-labels-for-an-axis-using-plplot.

  [1]: http://plplot.sourceforge.net/index.php
  [2]: http://matplotlib.org/examples/ticks_and_spines/ticklabels_demo_rotation.html
  [3]: http://plplot.sourceforge.net/documentation.php
  [4]: http://plplot.sourceforge.net/docbook-manual/plplot-html-5.10.0/plslabelfunc.html
  [5]: http://plplot.sourceforge.net/examples.php

[Plplot-general] 21th Tcl Conference - Registration & Hotel Reminder

[Andreas K. <and...@ac...>]

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

This is a reminder that Registration for the Conference is open and
can be done at

	http://www.tcl.tk/community/tcl2014/reg.html

Note that the holding period for hotel rooms has passed. To register
for a room, call 1-503-796-3851, speak to Mary Kirchner and mention
the Tcl Conference to receive the reduced rate.

See you in Portland,

Andreas Kupries
Tcl 2014 Program Chair
ActiveState Software Inc.
Vancouver, BC, Canada

Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

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

On 2014-09-22 15:47-0400 Irena Johnson wrote:

> Hello Alan,
>
> Please find below the errors I am getting when I ran the comprehensive
> run-time tests.
>
> Scanning dependencies of target tcl_examples
> Scanning dependencies of target x07c
> Scanning dependencies of target x13c
> Scanning dependencies of target x08c
> [  0%] [  0%] Building C object c/CMakeFiles/x07c.dir/x07c.c.o
> [  8%] Building C object c/CMakeFiles/x13c.dir/x13c.c.o
> Building C object c/CMakeFiles/x08c.dir/x08c.c.o
> [ 39%] Built target tcl_examples
> Scanning dependencies of target x34c
> [ 39%] Building C object c/CMakeFiles/x34c.dir/x34c.c.o
> Linking C executable x13c
> Linking C executable x07c
> /usr/bin/ld: cannot find -lplplot

[...]

Hi Irena:

It looks to me from the above results that the C examples are failing to
link, but I thought you tested that case before?

Anyhow, to test that case without anything else getting in the way,
please give me VERBOSE=1 results for the non-parallel build case for a
fresh build tree.  That is, starting with an empty build tree use

cmake <your usual options including -DBUILD_TEST=ON...> \
<path to PLplot source tree...> \
>& cmake.out

followed by _just_

make VERBOSE=1 x01c >& make.out

Then, assuming the make.out result does show the same link error as
above, please compress those cmake.out and make.out files (and also
the resulting CMakeCache.txt file), and send those three compressed
files to this list as attachments.  Once we have those details, it
will make it much easier for us to figure out exactly what is going
wrong.

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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Hello Alan,

Please find below the errors I am getting when I ran the comprehensive
run-time tests.

Scanning dependencies of target tcl_examples
Scanning dependencies of target x07c
Scanning dependencies of target x13c
Scanning dependencies of target x08c
[  0%] [  0%] Building C object c/CMakeFiles/x07c.dir/x07c.c.o
[  8%] Building C object c/CMakeFiles/x13c.dir/x13c.c.o
Building C object c/CMakeFiles/x08c.dir/x08c.c.o
[ 39%] Built target tcl_examples
Scanning dependencies of target x34c
[ 39%] Building C object c/CMakeFiles/x34c.dir/x34c.c.o
Linking C executable x13c
Linking C executable x07c
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x13c] Error 2
make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x07c] Error 2
make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2
Linking C executable x08c
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x08c] Error 2
make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2
Linking C executable x34c
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x34c] Error 2
make[2]: *** [c/CMakeFiles/x34c.dir/all] Error 2
make[1]: *** [CMakeFiles/test_diff_psc.dir/rule] Error 2
make: *** [test_diff_psc] Error 2


Scanning dependencies of target x33c
Linking C executable x13c
Linking C executable x07c
Linking C executable x08c
[  1%] Building C object c/CMakeFiles/x33c.dir/x33c.c.o
/usr/bin/ld: cannot find -lplplot
/usr/bin/ld: cannot find -lplplot
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x07c] Error 2
make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
make[3]: *** [c/x08c] Error 2
make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2
make[3]: *** [c/x13c] Error 2
make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2
Linking C executable x33c
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x33c] Error 2
make[2]: *** [c/CMakeFiles/x33c.dir/all] Error 2
make[1]: *** [CMakeFiles/test_noninteractive.dir/rule] Error 2
make: *** [test_noninteractive] Error 2


Linking C executable x33c
Linking C executable x13c
Linking C executable x07c
Linking C executable x08c
/usr/bin/ld: cannot find -lplplot
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x33c] Error 2
make[2]: *** [c/CMakeFiles/x33c.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
make[3]: *** [c/x13c] Error 2
make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2
/usr/bin/ld: cannot find -lplplot
/usr/bin/ld: cannot find -lplplot
make[3]: *** [c/x08c] Error 2
make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2
make[3]: *** [c/x07c] Error 2
make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2
make[1]: *** [CMakeFiles/test_interactive.dir/rule] Error 2
make: *** [test_interactive] Error 2


Thanks,
Irena


On Wed, Aug 27, 2014 at 3:41 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-08-27 14:58-0400 Irena Johnson wrote:
>
>  Alan,
>>
>> I will do the run-time testing -- thank you for the detailed info!
>>
>> I do have one more question: it seems that I do not have the static
>> libraries built under plplot (I only have the shared libraries -- can
>> fortran use these libraries?).
>>
>
> Yes, Fortran can use these shared libraries.  In fact the run-time
> testing I suggested (and just completed for git master) does exactly
> that with our standard Fortran 95 examples (for the gfortran/gcc case,
> see further comments about the PG case below).
>
>  Is there a flag I should set at
>> configuration time?
>>
>
> The VERBOSE=1 make option outputs every flag used in compilation for
> CMake-generated Makefiles such as these based on internal knowlege
> CMake has about what is required for the PG compilers you are using.
> So look up the relevant part of compiling the Fortran 95 examples in
> the run-time test *.out files (assuming those run-time tests work),
> and that tells you all the flags you need to use.  Alternative more
> sophisticated ways to get the compile and link flags you need for your
> applications in the PG case can be determined from "make install"
> results which along with everything else installs both a simple
> CMake-based build system for the installed examples as well as a more
> traditional (Makefile + pkg-config) build system for those installed
> examples.
>
> Big caveat.  Whatever method you use to obtain the necessary compile
> and link flags for your applications, you might find an issue for the
> PG compilers since as far as I know you are the first in a long time
> to try those compilers for the PLplot case.  But we will attempt to
> fix such bugs so long as you continue to give us details about
> any issues you find.
>
>
> 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
> __________________________
>



-- 
Irena

Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

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

Hi Davide,



Thanks for that information. It confirms my suspicions about the nature of the error message. Luckily the workaround is simple enough.



Regards,



Arjen

> -----Original Message-----
> From: Davide Cesari [mailto:dc...@ar...]
> Sent: Wednesday, August 27, 2014 4:15 PM
> To: plp...@li...
> Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h
>
> Hi Irena and Arjen, just to add some information: I have Fortran PGI compiler
> available, version 13.10
>
> [dcesari@malina ~]$ pgfortran --version
> pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7 The Portland Group - PGI
> Compilers and Tools Copyright (c) 2013, NVIDIA CORPORATION.  All rights
> reserved.
>
> and it seems that it is capable to compile successfully both Arjen code excerpt as
> well as the complete sfstubsf95.f90 extracted from git together with the
> dependencies, can we compare the versions? I almost stopped using PGI because it
> tends to fail on many correct pieces of code even sticking to strict f90 standard,
> however some bugs are fixed from time to time.
>       Davide
>
>
>
> On 27/08/2014 16:02, Arjen Markus wrote:
> > Hi Irena,
> >
> > Odd, the only thing I can think of is that the compiler does not like
> > this combination of a module procedure and an explicit interface block.
> > Could you try with:
> >
> > interface plsvect
> >
> >          module procedure plsvect1
> >
> > end interface
> >
> > interface plsvect
> >
> >          subroutine plsvect2
> >
> >          end subroutine plsvect2
> >
> > end interface
> >
> > (Change it directly in the file sfstubs95.f90)
> >
> > You can specify multiple interfaces with the same name as long as the
> > individual routines can be distinguished
> >
> > If this does not work either, it is time for me to consult the
> > comp.lang.fortran group.
> >
> > Regards,
> >
> > Arjen
> >
> > *From:*Irena Johnson [mailto:ijo...@pp...]
> > *Sent:* Wednesday, August 27, 2014 3:55 PM
> > *To:* Arjen Markus
> > *Cc:* Alan W. Irwin; plp...@li...
> > *Subject:* Re: [Plplot-general] continuation lines in
> > bindings/tcl/plplot_parameters.h
> >
> > Hi Arjen,
> >
> > I am getting the same error:
> >
> > $ pgf95 -g -Minfo=all -v ../dummy.f90
> >
> > /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x
> > 120
> > 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000
> > -quad -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x
> > 58
> > 0x10000 -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49
> > 0x100 -x 120 0x200 -stdinc
> > /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib
> > /gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linu
> > x/4.1.2/include:/usr/include -def unix -def __unix -def __unix__ -def
> > linux -def __linux -def __linux__ -def __NO_MATH_INLINES -def __x86_64
> > -def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def
> > '__SIZE_TYPE__=unsigned long int'
> > -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__=
> > -def __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__
> > -def __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70
> > 0x40000000 -x 49
> > 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
> > /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
> >
> > *PGF90-S-0070-Incorrect sequence of statements* (../dummy.f90: 7)
> >
> >    0 inform,   0 warnings,   1 severes, 0 fatal for dummy
> >
> >    0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
> >
> > PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
> >
> > pgf95-Fatal-f901 completed with exit code 1
> >
> >  From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,
> >
> > *S 70 "Incorrect sequence of statements $"*
> >
> > The statement order is incorrect. For instance, an IMPLICIT NONE
> > statement must precede a specification statement which in turn must
> > precede an executable statement.
> >
> > Thanks,
> >
> > --Irena
> >
> > On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus
> > <Arj...@de... <mailto:Arj...@de...>> wrote:
> >
> > Hi Irena,
> >
> > That is rather odd, the code is correct as far as I can tell. Could
> > you try to compile this code:
> >
> > module dummy
> >
> >      interface plsvect
> >
> >          module procedure plsvect1
> >
> >          subroutine plsvect2
> >
> >          end subroutine plsvect2
> >
> >      end interface
> >
> > contains
> >
> > subroutine plsvect1( x )
> >
> >     real :: x
> >
> > end subroutine plsvect1
> >
> > end module dummy
> >
> > This should be perfectly acceptable code. If not, the PG compiler is
> > doing something odd. Can you use a flag that will tell us more about
> > what is wrong according to the compiler?
> >
> > Regards,
> >
> > Arjen
> >
> > *From:*Irena Johnson [mailto:ijo...@pp...
> > <mailto:ijo...@pp...>]
> > *Sent:* Wednesday, August 27, 2014 2:43 PM
> > *To:* Alan W. Irwin
> > *Cc:* plp...@li...
> > <mailto:plp...@li...>
> > *Subject:* Re: [Plplot-general] continuation lines in
> > bindings/tcl/plplot_parameters.h
> >
> > Hi Alan, plplot_parameters.h
> >
> > Thank you for your help with this issue: I got the latest version of
> > plplot from git and your modification to plplot_parameters.h has worked!!
> >
> > Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> > sequence of statements"
> >
> > [ 24%] Built target plplotf95c
> >
> > Scanning dependencies of target plplotf95
> >
> > [ 25%] Building Fortran object
> > bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
> >
> > [ 25%] Building Fortran object
> > bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
> >
> > PGF90-S-0070-Incorrect sequence of statements
> >   (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
> >
> >    0 inform,   0 warnings,   1 severes, 0 fatal for plplot
> >
> > make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> > Error 2
> >
> > make[2]: ***
> > [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides]
> > Error 2
> >
> > make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
> >
> > make: *** [all] Error 2
> >
> > Thank you,
> >
> > --Irena
> >
> > On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin
> > <ir...@be... <mailto:ir...@be...>> wrote:
> >
> > On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
> >
> > Getting back to the principal issue, it appears to me that gcc is
> > accepting all those "\n\" continuation lines in
> > bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> > not.  We will look further at this.
> >
> > Hi Irena:
> >
> > I have now changed the style of plplot_parameters.h to replace one
> > huge string literal by a large number of small string literals that
> > the compiler should automatically concatenate together.
> >
> > I prefer this new style on general principles, and gcc compiles this
> > style just as well as the old style. It's possible your Portland Group
> > compiler will still choke on this style as it attempts to concatenate
> > those string literals together. But on the other hand, it might work.
> >
> > To test that possibility, please try the latest version of our source
> > code using
> >
> > git clone git://git.code.sf.net/p/plplot/plplot
> > <http://git.code.sf.net/p/plplot/plplot> plplot.git
> >
> > Then try your normal build (with -DENABLE_tcl=ON or else by removing
> > -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> > default) referring to this version of the source tree rather than
> > 5.10.0 and starting from an empty build tree. If your compiler is able
> > to compile bindings/tcl/tclAPI.c without issues, then the change in
> > style should be judged a success.
> >
> > Furthermore, I hope your set of Portland Group compilers is able to
> > finish the rest of a default build of PLplot without issues, but if
> > there are such issues we will try to deal with them since we prefer to
> > have PLplot builds be successful on all compilers and not just gcc.
> >
> > By the way, I think the above is the first reference to our new
> > official git repository on this list (although there has been a large
> > amount of traffic about this huge change in PLplot development on the
> > plplot-devel list).  The short story is our svn repository at SF is
> > now frozen in read-only mode and as of a few days ago we switched to
> > using git for PLplot development with the above being our official git
> > repo.  I am pretty much a git newbie myself, but my use of it for the
> > last several days shows it is an extremely popular version control
> > system for good reasons.  Therefore, I think there is an excellent
> > chance this change from subversion to git will not only help our
> > current set of developers but also attract new developers to the
> > project.
> >
> >
> >
> > Alan
> > __________________________
> > Alan W. Irwin
> >
> > Astronomical research affiliation with Department of Physics and
> > Astronomy, University of Victoria (astrowww.phys.uvic.ca
> > <http://astrowww.phys.uvic.ca>).
> >
> > Programming affiliations with the FreeEOS equation-of-state
> > implementation for stellar interiors (freeeos.sf.net
> > <http://freeeos.sf.net>); the Time Ephemerides project
> > (timeephem.sf.net <http://timeephem.sf.net>); PLplot scientific
> > plotting software package (plplot.sf.net <http://plplot.sf.net>); the
> > libLASi project (unifont.org/lasi <http://unifont.org/lasi>); the
> > Loads of Linux Links project (loll.sf.net <http://loll.sf.net>); and
> > the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net>).
> > __________________________
> >
> > Linux-powered Science
> > __________________________
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Slashdot TV.
> > Video for Nerds.  Stuff that matters.
> > http://tv.slashdot.org/
> >
> >
> >
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
> >
>
>
> --
> ============================= Davide Cesari
> ============================
> Dott**(0.5) Davide Cesari
> ARPA-Emilia Romagna, Servizio IdroMeteoClima NWP modelling - Modellistica
> numerica previsionale Tel. +39 051525926
> =============================================================
> ===========
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

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-general] continuation lines in bindings/tcl/plplot_parameters.h

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

Hi Alan, Irena,



I will make these changes - they should have no impact, except keep that version of the PG compiler happy, but at the moment I am trying to make sure my laptop stays alive :(. It was not starting up correctly - possibly a hard disk problem.



Regards,



Arjen




> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, August 27, 2014 6:15 PM
> To: Irena Johnson
> Cc: Arjen Markus; plp...@li...
> Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h
>
> To Arjen and Irena:
>
> On 2014-08-27 10:41-0400 Irena Johnson wrote:
>
> > Hi Arjen,
> >
> > Yes, this worked! I was now able to compile and install plplot for
> > pgf-13.6. Thank you very much for your help!
>
> @Arjen: Please go ahead and push your workaround to the master branch of our git
> repository with a code comment that splitting up the module and subroutine this way
> is required to work around a pgf-13.6 bug.  After all, that is a rather minor change,
> and others may want to use this version of the Portland Group compilers as well
> without having to upgrade to Davide's version 13.10.
>
> @Irena: that is excellent news indeed that Arjen's workaround solved the remaining
> build issue for you.  However, from Davide's results (where version 13.10 does not
> need this workaround) it sounds like the Portland Group version 13.6 compilers are a
> little iffy. Therefore I suggest to gain some confidence in results for those that you do
> some comprehensive run-time tests.  (You should run these tests every time you are
> using a new compiler or new compiler version.)
>
> The comprehensive test directions (I go into detail since they are suitable for anyone
> here who wants to test all is well with their PLplot build) are as follows:
>
> Add the cmake command-line option -DBUILD_TEST=ON which instructs cmake to
> configure many build-tree run-time tests.
>
> After cmake completes then run
>
> make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out
>
> which builds and runs each of our 33 standard examples for all languages that are
> enabled plus a number of additional noninteractive tests.
>
> N.B. My high-quality but still 5-yr old PC takes ~8 minutes to run this test and
> produces some 4GB (!) of output plot files.
>
> You should check the resulting test_noninteractive.out file for any run-time errors.  (I
> just did that which confirms that our current git master version is working well.) And
> you can also sample some of those resulting PostScript files using gv, For example,
>
> gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc
>
> views the PostScript results of our 8th standard example written in Fortran 95.
>
> An additional test that you should run is
>
> make -j4 VERBOSE=1 test_interactive >& test_interactive.out
>
> which tests all our interactive devices for our standard examples as well as many
> other interactive tests.  Unlike the test_noninteractive target, this target does not
> have to store plot results so does not chew up disk space.  But you do have to
> interact with a number of those examples (typically by hitting the enter key) to keep
> them moving along.  When you finish with this test, you should also check
> test_interactive.out for any run-time errors.
>
> Good luck with these essential comprehensive run-time tests, and please report back
> here if the resulting *.out files show any issues.
>
> 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
> __________________________

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-general] continuation lines in bindings/tcl/plplot_parameters.h

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

On 2014-08-27 14:58-0400 Irena Johnson wrote:

> Alan,
>
> I will do the run-time testing -- thank you for the detailed info!
>
> I do have one more question: it seems that I do not have the static
> libraries built under plplot (I only have the shared libraries -- can
> fortran use these libraries?).

Yes, Fortran can use these shared libraries.  In fact the run-time
testing I suggested (and just completed for git master) does exactly
that with our standard Fortran 95 examples (for the gfortran/gcc case,
see further comments about the PG case below).

> Is there a flag I should set at
> configuration time?

The VERBOSE=1 make option outputs every flag used in compilation for
CMake-generated Makefiles such as these based on internal knowlege
CMake has about what is required for the PG compilers you are using.
So look up the relevant part of compiling the Fortran 95 examples in
the run-time test *.out files (assuming those run-time tests work),
and that tells you all the flags you need to use.  Alternative more
sophisticated ways to get the compile and link flags you need for your
applications in the PG case can be determined from "make install"
results which along with everything else installs both a simple
CMake-based build system for the installed examples as well as a more
traditional (Makefile + pkg-config) build system for those installed
examples.

Big caveat.  Whatever method you use to obtain the necessary compile
and link flags for your applications, you might find an issue for the
PG compilers since as far as I know you are the first in a long time
to try those compilers for the PLplot case.  But we will attempt to
fix such bugs so long as you continue to give us details about
any issues you find.

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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Alan,

I will do the run-time testing -- thank you for the detailed info!

I do have one more question: it seems that I do not have the static
libraries built under plplot (I only have the shared libraries -- can
fortran use these libraries?). Is there a flag I should set at
configuration time?

Thank you,

-- 
Irena


On Wed, Aug 27, 2014 at 12:15 PM, Alan W. Irwin <ir...@be...>
wrote:

> To Arjen and Irena:
>
>
> On 2014-08-27 10:41-0400 Irena Johnson wrote:
>
>  Hi Arjen,
>>
>> Yes, this worked! I was now able to compile and install plplot for
>> pgf-13.6. Thank you very much for your help!
>>
>
> @Arjen: Please go ahead and push your workaround to the master
> branch of our git repository with a code comment that splitting up the
> module and subroutine this way is required to work around a pgf-13.6
> bug.  After all, that is a rather minor change, and others may want to
> use this version of the Portland Group compilers as well without
> having to upgrade to Davide's version 13.10.
>
> @Irena: that is excellent news indeed that Arjen's workaround solved
> the remaining build issue for you.  However, from Davide's results
> (where version 13.10 does not need this workaround) it sounds like the
> Portland Group version 13.6 compilers are a little iffy. Therefore I
> suggest to gain some confidence in results for those that you do some
> comprehensive run-time tests.  (You should run these tests
> every time you are using a new compiler or new compiler version.)
>
> The comprehensive test directions (I go into detail since they are
> suitable for anyone here who wants to test all is well with their
> PLplot build) are as follows:
>
> Add the cmake command-line option -DBUILD_TEST=ON which instructs
> cmake to configure many build-tree run-time tests.
>
> After cmake completes then run
>
> make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out
>
> which builds and runs each of our 33 standard examples for all
> languages that are enabled plus a number of additional noninteractive
> tests.
>
> N.B. My high-quality but still 5-yr old PC takes ~8 minutes to
> run this test and produces some 4GB (!) of output plot files.
>
> You should check the resulting test_noninteractive.out file for any
> run-time errors.  (I just did that which confirms that our current git
> master version is working well.) And you can also sample some of those
> resulting PostScript files using gv, For example,
>
> gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc
>
> views the PostScript results of our 8th standard example written
> in Fortran 95.
>
> An additional test that you should run is
>
> make -j4 VERBOSE=1 test_interactive >& test_interactive.out
>
> which tests all our interactive devices for our standard examples as
> well as many other interactive tests.  Unlike the test_noninteractive
> target, this target does not have to store plot results so does not
> chew up disk space.  But you do have to interact with a number of
> those examples (typically by hitting the enter key) to keep them
> moving along.  When you finish with this test, you should also check
> test_interactive.out for any run-time errors.
>
> Good luck with these essential comprehensive run-time tests, and
> please report back here if the resulting *.out files show any issues.
>
>
> 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-general] continuation lines in bindings/tcl/plplot_parameters.h

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

To Arjen and Irena:

On 2014-08-27 10:41-0400 Irena Johnson wrote:

> Hi Arjen,
>
> Yes, this worked! I was now able to compile and install plplot for
> pgf-13.6. Thank you very much for your help!

@Arjen: Please go ahead and push your workaround to the master
branch of our git repository with a code comment that splitting up the
module and subroutine this way is required to work around a pgf-13.6
bug.  After all, that is a rather minor change, and others may want to
use this version of the Portland Group compilers as well without
having to upgrade to Davide's version 13.10.

@Irena: that is excellent news indeed that Arjen's workaround solved
the remaining build issue for you.  However, from Davide's results
(where version 13.10 does not need this workaround) it sounds like the
Portland Group version 13.6 compilers are a little iffy. Therefore I
suggest to gain some confidence in results for those that you do some
comprehensive run-time tests.  (You should run these tests
every time you are using a new compiler or new compiler version.)

The comprehensive test directions (I go into detail since they are
suitable for anyone here who wants to test all is well with their
PLplot build) are as follows:

Add the cmake command-line option -DBUILD_TEST=ON which instructs
cmake to configure many build-tree run-time tests.

After cmake completes then run

make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out

which builds and runs each of our 33 standard examples for all
languages that are enabled plus a number of additional noninteractive
tests.

N.B. My high-quality but still 5-yr old PC takes ~8 minutes to
run this test and produces some 4GB (!) of output plot files.

You should check the resulting test_noninteractive.out file for any
run-time errors.  (I just did that which confirms that our current git
master version is working well.) And you can also sample some of those
resulting PostScript files using gv, For example,

gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc

views the PostScript results of our 8th standard example written
in Fortran 95.

An additional test that you should run is

make -j4 VERBOSE=1 test_interactive >& test_interactive.out

which tests all our interactive devices for our standard examples as
well as many other interactive tests.  Unlike the test_noninteractive
target, this target does not have to store plot results so does not
chew up disk space.  But you do have to interact with a number of
those examples (typically by hitting the enter key) to keep them
moving along.  When you finish with this test, you should also check
test_interactive.out for any run-time errors.

Good luck with these essential comprehensive run-time tests, and
please report back here if the resulting *.out files show any issues.

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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Hi Davide,

OK, thanks for the info. It might be good to try the newer version of
pgi-13, but we have a lot of customized software here for our scientists
and sometimes they require a specific version of a compiler.

$ pgfortran --version

pgfortran 13.6-0 64-bit target on x86-64 Linux -tp k8e
Copyright 1989-2000, The Portland Group, Inc.  All Rights Reserved.
Copyright 2000-2013, STMicroelectronics, Inc.  All Rights Reserved.

Thanks,
--Irena


On Wed, Aug 27, 2014 at 10:15 AM, Davide Cesari <dc...@ar...> wrote:

> Hi Irena and Arjen, just to add some information: I have Fortran PGI
> compiler available, version 13.10
>
> [dcesari@malina ~]$ pgfortran --version
> pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7
> The Portland Group - PGI Compilers and Tools
> Copyright (c) 2013, NVIDIA CORPORATION.  All rights reserved.
>
> and it seems that it is capable to compile successfully both Arjen code
> excerpt as well as the complete sfstubsf95.f90 extracted from git
> together with the dependencies, can we compare the versions? I almost
> stopped using PGI because it tends to fail on many correct pieces of
> code even sticking to strict f90 standard, however some bugs are fixed
> from time to time.
>         Davide
>
>
>
> On 27/08/2014 16:02, Arjen Markus wrote:
> > Hi Irena,
> >
> > Odd, the only thing I can think of is that the compiler does not like
> > this combination of a module procedure and an explicit interface block.
> > Could you try with:
> >
> > interface plsvect
> >
> >          module procedure plsvect1
> >
> > end interface
> >
> > interface plsvect
> >
> >          subroutine plsvect2
> >
> >          end subroutine plsvect2
> >
> > end interface
> >
> > (Change it directly in the file sfstubs95.f90)
> >
> > You can specify multiple interfaces with the same name as long as the
> > individual routines can be distinguished
> >
> > If this does not work either, it is time for me to consult the
> > comp.lang.fortran group.
> >
> > Regards,
> >
> > Arjen
> >
> > *From:*Irena Johnson [mailto:ijo...@pp...]
> > *Sent:* Wednesday, August 27, 2014 3:55 PM
> > *To:* Arjen Markus
> > *Cc:* Alan W. Irwin; plp...@li...
> > *Subject:* Re: [Plplot-general] continuation lines in
> > bindings/tcl/plplot_parameters.h
> >
> > Hi Arjen,
> >
> > I am getting the same error:
> >
> > $ pgf95 -g -Minfo=all -v ../dummy.f90
> >
> > /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120
> > 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000
> > -quad -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58
> > 0x10000 -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49
> > 0x100 -x 120 0x200 -stdinc
> >
> /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include
> > -def unix -def __unix -def __unix__ -def linux -def __linux -def
> > __linux__ -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def
> > __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int'
> > -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def
> > __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def
> > __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49
> > 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
> > /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
> >
> > *PGF90-S-0070-Incorrect sequence of statements* (../dummy.f90: 7)
> >
> >    0 inform,   0 warnings,   1 severes, 0 fatal for dummy
> >
> >    0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
> >
> > PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
> >
> > pgf95-Fatal-f901 completed with exit code 1
> >
> >  From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,
> >
> > *S 70 "Incorrect sequence of statements $"*
> >
> > The statement order is incorrect. For instance, an IMPLICIT NONE
> > statement must precede a specification statement which in turn must
> > precede an executable statement.
> >
> > Thanks,
> >
> > --Irena
> >
> > On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de...
> > <mailto:Arj...@de...>> wrote:
> >
> > Hi Irena,
> >
> > That is rather odd, the code is correct as far as I can tell. Could you
> > try to compile this code:
> >
> > module dummy
> >
> >      interface plsvect
> >
> >          module procedure plsvect1
> >
> >          subroutine plsvect2
> >
> >          end subroutine plsvect2
> >
> >      end interface
> >
> > contains
> >
> > subroutine plsvect1( x )
> >
> >     real :: x
> >
> > end subroutine plsvect1
> >
> > end module dummy
> >
> > This should be perfectly acceptable code. If not, the PG compiler is
> > doing something odd. Can you use a flag that will tell us more about
> > what is wrong according to the compiler?
> >
> > Regards,
> >
> > Arjen
> >
> > *From:*Irena Johnson [mailto:ijo...@pp... <mailto:ijo...@pp...
> >]
> > *Sent:* Wednesday, August 27, 2014 2:43 PM
> > *To:* Alan W. Irwin
> > *Cc:* plp...@li...
> > <mailto:plp...@li...>
> > *Subject:* Re: [Plplot-general] continuation lines in
> > bindings/tcl/plplot_parameters.h
> >
> > Hi Alan, plplot_parameters.h
> >
> > Thank you for your help with this issue: I got the latest version of
> > plplot from git and your modification to plplot_parameters.h has worked!!
> >
> > Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> > sequence of statements"
> >
> > [ 24%] Built target plplotf95c
> >
> > Scanning dependencies of target plplotf95
> >
> > [ 25%] Building Fortran object
> > bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
> >
> > [ 25%] Building Fortran object
> > bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
> >
> > PGF90-S-0070-Incorrect sequence of statements
> >   (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
> >
> >    0 inform,   0 warnings,   1 severes, 0 fatal for plplot
> >
> > make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> > Error 2
> >
> > make[2]: ***
> > [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
> >
> > make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
> >
> > make: *** [all] Error 2
> >
> > Thank you,
> >
> > --Irena
> >
> > On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin
> > <ir...@be... <mailto:ir...@be...>> wrote:
> >
> > On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
> >
> > Getting back to the principal issue, it appears to me that gcc is
> > accepting all those "\n\" continuation lines in
> > bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> > not.  We will look further at this.
> >
> > Hi Irena:
> >
> > I have now changed the style of plplot_parameters.h to replace one huge
> > string
> > literal by a large number of small string literals that the compiler
> > should automatically concatenate together.
> >
> > I prefer this new style on general principles, and gcc compiles this
> > style just as well as the old style. It's possible your Portland Group
> > compiler will still choke on this style as it attempts to concatenate
> > those string literals together. But on the other hand, it might work.
> >
> > To test that possibility, please try the latest version of our
> > source code using
> >
> > git clone git://git.code.sf.net/p/plplot/plplot
> > <http://git.code.sf.net/p/plplot/plplot> plplot.git
> >
> > Then try your normal build (with -DENABLE_tcl=ON or else by removing
> > -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> > default) referring to this version of the source tree rather than
> > 5.10.0 and starting from an empty build tree. If your compiler is
> > able to compile bindings/tcl/tclAPI.c without issues, then the change in
> > style
> > should be judged a success.
> >
> > Furthermore, I hope your set of Portland Group compilers is able to
> > finish the rest of a default build of PLplot without issues, but if
> > there are such issues we will try to deal with them since we prefer to
> > have PLplot builds be successful on all compilers and not just gcc.
> >
> > By the way, I think the above is the first reference to our new
> > official git repository on this list (although there has been a large
> > amount of traffic about this huge change in PLplot development on the
> > plplot-devel list).  The short story is our svn repository at SF is
> > now frozen in read-only mode and as of a few days ago we switched to
> > using git for PLplot development with the above being our official git
> > repo.  I am pretty much a git newbie myself, but my use of it for the
> > last several days shows it is an extremely popular version control
> > system for good reasons.  Therefore, I think there is an excellent
> > chance this change from subversion to git will not only help our
> > current set of developers but also attract new developers to the
> > project.
> >
> >
> >
> > Alan
> > __________________________
> > Alan W. Irwin
> >
> > Astronomical research affiliation with Department of Physics and
> Astronomy,
> > University of Victoria (astrowww.phys.uvic.ca
> > <http://astrowww.phys.uvic.ca>).
> >
> > Programming affiliations with the FreeEOS equation-of-state
> > implementation for stellar interiors (freeeos.sf.net
> > <http://freeeos.sf.net>); the Time
> > Ephemerides project (timeephem.sf.net <http://timeephem.sf.net>); PLplot
> > scientific plotting
> > software package (plplot.sf.net <http://plplot.sf.net>); the libLASi
> project
> > (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links
> > project (loll.sf.net <http://loll.sf.net>);
> > and the Linux Brochure Project (lbproject.sf.net <
> http://lbproject.sf.net>).
> > __________________________
> >
> > Linux-powered Science
> > __________________________
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Slashdot TV.
> > Video for Nerds.  Stuff that matters.
> > http://tv.slashdot.org/
> >
> >
> >
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
> >
>
>
> --
> ============================= Davide Cesari ============================
> Dott**(0.5) Davide Cesari
> ARPA-Emilia Romagna, Servizio IdroMeteoClima
> NWP modelling - Modellistica numerica previsionale
> Tel. +39 051525926
> ========================================================================
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>



-- 
Irena

Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Hi Arjen,

Yes, this worked! I was now able to compile and install plplot for
pgf-13.6. Thank you very much for your help!


-- 
Irena


On Wed, Aug 27, 2014 at 10:02 AM, Arjen Markus <Arj...@de...>
wrote:

>  Hi Irena,
>
>
>
> Odd, the only thing I can think of is that the compiler does not like this
> combination of a module procedure and an explicit interface block. Could
> you try with:
>
> interface plsvect
>
>         module procedure plsvect1
>
> end interface
>
> interface plsvect
>
>         subroutine plsvect2
>
>         end subroutine plsvect2
>
> end interface
>
> (Change it directly in the file sfstubs95.f90)
>
>
>
> You can specify multiple interfaces with the same name as long as the
> individual routines can be distinguished
>
> If this does not work either, it is time for me to consult the
> comp.lang.fortran group.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>
> *From:* Irena Johnson [mailto:ijo...@pp...]
> *Sent:* Wednesday, August 27, 2014 3:55 PM
> *To:* Arjen Markus
> *Cc:* Alan W. Irwin; plp...@li...
>
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
>
>
> Hi Arjen,
>
>
>
> I am getting the same error:
>
>
>
> $ pgf95 -g -Minfo=all -v ../dummy.f90
>
>
>
> /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120
> 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000 -quad
> -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000
> -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49 0x100 -x 120
> 0x200 -stdinc
> /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include
> -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__
> -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def
> __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int'
> -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def
> __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def
> __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49
> 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
> /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
>
> *PGF90-S-0070-Incorrect sequence of statements*  (../dummy.f90: 7)
>
>   0 inform,   0 warnings,   1 severes, 0 fatal for dummy
>
>   0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
>
> PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
>
> pgf95-Fatal-f901 completed with exit code 1
>
>
>
>
>
>
>
> From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,
>
>
>
> *S 70 "Incorrect sequence of statements $"*
>
> The statement order is incorrect. For instance, an IMPLICIT NONE statement
> must precede a specification statement which in turn must precede an
> executable statement.
>
>
>
> Thanks,
>
> --Irena
>
>
>
> On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de...>
> wrote:
>
> Hi Irena,
>
>
>
> That is rather odd, the code is correct as far as I can tell. Could you
> try to compile this code:
>
>
>
> module dummy
>
>     interface plsvect
>
>         module procedure plsvect1
>
>         subroutine plsvect2
>
>         end subroutine plsvect2
>
>     end interface
>
> contains
>
> subroutine plsvect1( x )
>
>    real :: x
>
> end subroutine plsvect1
>
> end module dummy
>
>
>
>
>
> This should be perfectly acceptable code. If not, the PG compiler is doing
> something odd. Can you use a flag that will tell us more about what is
> wrong according to the compiler?
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
> *From:* Irena Johnson [mailto:ijo...@pp...]
> *Sent:* Wednesday, August 27, 2014 2:43 PM
> *To:* Alan W. Irwin
> *Cc:* plp...@li...
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
>
>
> Hi Alan, plplot_parameters.h
>
>
>
> Thank you for your help with this issue: I got the latest version of
> plplot from git and your modification to plplot_parameters.h has worked!!
>
>
>
> Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> sequence of statements"
>
>
>
>
>
> [ 24%] Built target plplotf95c
>
> Scanning dependencies of target plplotf95
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
>
> PGF90-S-0070-Incorrect sequence of statements
>  (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
>
>   0 inform,   0 warnings,   1 severes, 0 fatal for plplot
>
> make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> Error 2
>
> make[2]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
>
> make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
>
> make: *** [all] Error 2
>
>
>
> Thank you,
>
> --Irena
>
>
>
> On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@be...>
> wrote:
>
> On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
>
> Getting back to the principal issue, it appears to me that gcc is
> accepting all those "\n\" continuation lines in
> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> not.  We will look further at this.
>
>
>
> Hi Irena:
>
> I have now changed the style of plplot_parameters.h to replace one huge
> string
> literal by a large number of small string literals that the compiler
> should automatically concatenate together.
>
> I prefer this new style on general principles, and gcc compiles this
> style just as well as the old style. It's possible your Portland Group
> compiler will still choke on this style as it attempts to concatenate
> those string literals together. But on the other hand, it might work.
>
> To test that possibility, please try the latest version of our
> source code using
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Then try your normal build (with -DENABLE_tcl=ON or else by removing
> -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> default) referring to this version of the source tree rather than
> 5.10.0 and starting from an empty build tree. If your compiler is
> able to compile bindings/tcl/tclAPI.c without issues, then the change in
> style
> should be judged a success.
>
> Furthermore, I hope your set of Portland Group compilers is able to
> finish the rest of a default build of PLplot without issues, but if
> there are such issues we will try to deal with them since we prefer to
> have PLplot builds be successful on all compilers and not just gcc.
>
> By the way, I think the above is the first reference to our new
> official git repository on this list (although there has been a large
> amount of traffic about this huge change in PLplot development on the
> plplot-devel list).  The short story is our svn repository at SF is
> now frozen in read-only mode and as of a few days ago we switched to
> using git for PLplot development with the above being our official git
> repo.  I am pretty much a git newbie myself, but my use of it for the
> last several days shows it is an extremely popular version control
> system for good reasons.  Therefore, I think there is an excellent
> chance this change from subversion to git will not only help our
> current set of developers but also attract new developers to the
> project.
>
>
>
> 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
> __________________________
>
>
>
> 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.
>
>
>
>
>    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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Davide C. <dc...@ar...>]

Hi Irena and Arjen, just to add some information: I have Fortran PGI 
compiler available, version 13.10

[dcesari@malina ~]$ pgfortran --version
pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7
The Portland Group - PGI Compilers and Tools
Copyright (c) 2013, NVIDIA CORPORATION.  All rights reserved.

and it seems that it is capable to compile successfully both Arjen code 
excerpt as well as the complete sfstubsf95.f90 extracted from git 
together with the dependencies, can we compare the versions? I almost 
stopped using PGI because it tends to fail on many correct pieces of 
code even sticking to strict f90 standard, however some bugs are fixed 
from time to time.
	Davide
	


On 27/08/2014 16:02, Arjen Markus wrote:
> Hi Irena,
>
> Odd, the only thing I can think of is that the compiler does not like
> this combination of a module procedure and an explicit interface block.
> Could you try with:
>
> interface plsvect
>
>          module procedure plsvect1
>
> end interface
>
> interface plsvect
>
>          subroutine plsvect2
>
>          end subroutine plsvect2
>
> end interface
>
> (Change it directly in the file sfstubs95.f90)
>
> You can specify multiple interfaces with the same name as long as the
> individual routines can be distinguished
>
> If this does not work either, it is time for me to consult the
> comp.lang.fortran group.
>
> Regards,
>
> Arjen
>
> *From:*Irena Johnson [mailto:ijo...@pp...]
> *Sent:* Wednesday, August 27, 2014 3:55 PM
> *To:* Arjen Markus
> *Cc:* Alan W. Irwin; plp...@li...
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
> Hi Arjen,
>
> I am getting the same error:
>
> $ pgf95 -g -Minfo=all -v ../dummy.f90
>
> /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120
> 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000
> -quad -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58
> 0x10000 -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49
> 0x100 -x 120 0x200 -stdinc
> /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include
> -def unix -def __unix -def __unix__ -def linux -def __linux -def
> __linux__ -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def
> __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int'
> -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def
> __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def
> __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49
> 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
> /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
>
> *PGF90-S-0070-Incorrect sequence of statements* (../dummy.f90: 7)
>
>    0 inform,   0 warnings,   1 severes, 0 fatal for dummy
>
>    0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
>
> PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
>
> pgf95-Fatal-f901 completed with exit code 1
>
>  From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,
>
> *S 70 "Incorrect sequence of statements $"*
>
> The statement order is incorrect. For instance, an IMPLICIT NONE
> statement must precede a specification statement which in turn must
> precede an executable statement.
>
> Thanks,
>
> --Irena
>
> On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de...
> <mailto:Arj...@de...>> wrote:
>
> Hi Irena,
>
> That is rather odd, the code is correct as far as I can tell. Could you
> try to compile this code:
>
> module dummy
>
>      interface plsvect
>
>          module procedure plsvect1
>
>          subroutine plsvect2
>
>          end subroutine plsvect2
>
>      end interface
>
> contains
>
> subroutine plsvect1( x )
>
>     real :: x
>
> end subroutine plsvect1
>
> end module dummy
>
> This should be perfectly acceptable code. If not, the PG compiler is
> doing something odd. Can you use a flag that will tell us more about
> what is wrong according to the compiler?
>
> Regards,
>
> Arjen
>
> *From:*Irena Johnson [mailto:ijo...@pp... <mailto:ijo...@pp...>]
> *Sent:* Wednesday, August 27, 2014 2:43 PM
> *To:* Alan W. Irwin
> *Cc:* plp...@li...
> <mailto:plp...@li...>
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
> Hi Alan, plplot_parameters.h
>
> Thank you for your help with this issue: I got the latest version of
> plplot from git and your modification to plplot_parameters.h has worked!!
>
> Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> sequence of statements"
>
> [ 24%] Built target plplotf95c
>
> Scanning dependencies of target plplotf95
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
>
> PGF90-S-0070-Incorrect sequence of statements
>   (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
>
>    0 inform,   0 warnings,   1 severes, 0 fatal for plplot
>
> make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> Error 2
>
> make[2]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
>
> make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
>
> make: *** [all] Error 2
>
> Thank you,
>
> --Irena
>
> On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin
> <ir...@be... <mailto:ir...@be...>> wrote:
>
> On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
>
> Getting back to the principal issue, it appears to me that gcc is
> accepting all those "\n\" continuation lines in
> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> not.  We will look further at this.
>
> Hi Irena:
>
> I have now changed the style of plplot_parameters.h to replace one huge
> string
> literal by a large number of small string literals that the compiler
> should automatically concatenate together.
>
> I prefer this new style on general principles, and gcc compiles this
> style just as well as the old style. It's possible your Portland Group
> compiler will still choke on this style as it attempts to concatenate
> those string literals together. But on the other hand, it might work.
>
> To test that possibility, please try the latest version of our
> source code using
>
> git clone git://git.code.sf.net/p/plplot/plplot
> <http://git.code.sf.net/p/plplot/plplot> plplot.git
>
> Then try your normal build (with -DENABLE_tcl=ON or else by removing
> -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> default) referring to this version of the source tree rather than
> 5.10.0 and starting from an empty build tree. If your compiler is
> able to compile bindings/tcl/tclAPI.c without issues, then the change in
> style
> should be judged a success.
>
> Furthermore, I hope your set of Portland Group compilers is able to
> finish the rest of a default build of PLplot without issues, but if
> there are such issues we will try to deal with them since we prefer to
> have PLplot builds be successful on all compilers and not just gcc.
>
> By the way, I think the above is the first reference to our new
> official git repository on this list (although there has been a large
> amount of traffic about this huge change in PLplot development on the
> plplot-devel list).  The short story is our svn repository at SF is
> now frozen in read-only mode and as of a few days ago we switched to
> using git for PLplot development with the above being our official git
> repo.  I am pretty much a git newbie myself, but my use of it for the
> last several days shows it is an extremely popular version control
> system for good reasons.  Therefore, I think there is an excellent
> chance this change from subversion to git will not only help our
> current set of developers but also attract new developers to the
> project.
>
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca
> <http://astrowww.phys.uvic.ca>).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net
> <http://freeeos.sf.net>); the Time
> Ephemerides project (timeephem.sf.net <http://timeephem.sf.net>); PLplot
> scientific plotting
> software package (plplot.sf.net <http://plplot.sf.net>); the libLASi project
> (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links
> project (loll.sf.net <http://loll.sf.net>);
> and the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net>).
> __________________________
>
> Linux-powered Science
> __________________________
>
> 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.
>
>
>
> 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.
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
>
>
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>


-- 
============================= Davide Cesari ============================
Dott**(0.5) Davide Cesari
ARPA-Emilia Romagna, Servizio IdroMeteoClima
NWP modelling - Modellistica numerica previsionale
Tel. +39 051525926
========================================================================

Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

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

Hi Irena,



Odd, the only thing I can think of is that the compiler does not like this combination of a module procedure and an explicit interface block. Could you try with:

interface plsvect

        module procedure plsvect1

end interface

interface plsvect

        subroutine plsvect2

        end subroutine plsvect2

end interface

(Change it directly in the file sfstubs95.f90)



You can specify multiple interfaces with the same name as long as the individual routines can be distinguished
If this does not work either, it is time for me to consult the comp.lang.fortran group.

Regards,

Arjen



From: Irena Johnson [mailto:ijo...@pp...]
Sent: Wednesday, August 27, 2014 3:55 PM
To: Arjen Markus
Cc: Alan W. Irwin; plp...@li...
Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

Hi Arjen,

I am getting the same error:

$ pgf95 -g -Minfo=all -v ../dummy.f90

/usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000 -quad -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49 0x100 -x 120 0x200 -stdinc /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__ -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int' -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
PGF90-S-0070-Incorrect sequence of statements  (../dummy.f90: 7)
  0 inform,   0 warnings,   1 severes, 0 fatal for dummy
  0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
pgf95-Fatal-f901 completed with exit code 1



>From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,

S 70 "Incorrect sequence of statements $"
The statement order is incorrect. For instance, an IMPLICIT NONE statement must precede a specification statement which in turn must precede an executable statement.

Thanks,
--Irena

On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:

Hi Irena,



That is rather odd, the code is correct as far as I can tell. Could you try to compile this code:



module dummy

    interface plsvect

        module procedure plsvect1

        subroutine plsvect2

        end subroutine plsvect2

    end interface

contains

subroutine plsvect1( x )

   real :: x

end subroutine plsvect1

end module dummy




This should be perfectly acceptable code. If not, the PG compiler is doing something odd. Can you use a flag that will tell us more about what is wrong according to the compiler?

Regards,

Arjen


From: Irena Johnson [mailto:ijo...@pp...<mailto:ijo...@pp...>]
Sent: Wednesday, August 27, 2014 2:43 PM
To: Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

Hi Alan, plplot_parameters.h

Thank you for your help with this issue: I got the latest version of plplot from git and your modification to plplot_parameters.h has worked!!

Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect sequence of statements"


[ 24%] Built target plplotf95c
Scanning dependencies of target plplotf95
[ 25%] Building Fortran object bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
[ 25%] Building Fortran object bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
PGF90-S-0070-Incorrect sequence of statements  (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
  0 inform,   0 warnings,   1 severes, 0 fatal for plplot
make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o] Error 2
make[2]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
make: *** [all] Error 2

Thank you,
--Irena

On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> wrote:
On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
Getting back to the principal issue, it appears to me that gcc is
accepting all those "\n\" continuation lines in
bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
not.  We will look further at this.

Hi Irena:

I have now changed the style of plplot_parameters.h to replace one huge string
literal by a large number of small string literals that the compiler
should automatically concatenate together.

I prefer this new style on general principles, and gcc compiles this
style just as well as the old style. It's possible your Portland Group
compiler will still choke on this style as it attempts to concatenate
those string literals together. But on the other hand, it might work.

To test that possibility, please try the latest version of our
source code using

git clone git://git.code.sf.net/p/plplot/plplot<http://git.code.sf.net/p/plplot/plplot> plplot.git

Then try your normal build (with -DENABLE_tcl=ON or else by removing
-DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
default) referring to this version of the source tree rather than
5.10.0 and starting from an empty build tree. If your compiler is
able to compile bindings/tcl/tclAPI.c without issues, then the change in style
should be judged a success.

Furthermore, I hope your set of Portland Group compilers is able to
finish the rest of a default build of PLplot without issues, but if
there are such issues we will try to deal with them since we prefer to
have PLplot builds be successful on all compilers and not just gcc.

By the way, I think the above is the first reference to our new
official git repository on this list (although there has been a large
amount of traffic about this huge change in PLplot development on the
plplot-devel list).  The short story is our svn repository at SF is
now frozen in read-only mode and as of a few days ago we switched to
using git for PLplot development with the above being our official git
repo.  I am pretty much a git newbie myself, but my use of it for the
last several days shows it is an extremely popular version control
system for good reasons.  Therefore, I think there is an excellent
chance this change from subversion to git will not only help our
current set of developers but also attract new developers to the
project.


Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>).

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

Linux-powered Science
__________________________

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.



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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Hi Arjen,

I am getting the same error:

$ pgf95 -g -Minfo=all -v ../dummy.f90

/usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120
0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000 -quad
-x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000
-x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49 0x100 -x 120
0x200 -stdinc
/usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include
-def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__
-def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def
__LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int'
-def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def
__amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def
__SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49
0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
/tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
*PGF90-S-0070-Incorrect sequence of statements*  (../dummy.f90: 7)
  0 inform,   0 warnings,   1 severes, 0 fatal for dummy
  0 inform,   0 warnings,   0 severes, 0 fatal for plsvect1
PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
pgf95-Fatal-f901 completed with exit code 1



>From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,

*S 70 "Incorrect sequence of statements $"*
The statement order is incorrect. For instance, an IMPLICIT NONE statement
must precede a specification statement which in turn must precede an
executable statement.

Thanks,
--Irena


On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de...>
wrote:

>  Hi Irena,
>
>
>
> That is rather odd, the code is correct as far as I can tell. Could you
> try to compile this code:
>
>
>
> module dummy
>
>     interface plsvect
>
>         module procedure plsvect1
>
>         subroutine plsvect2
>
>         end subroutine plsvect2
>
>     end interface
>
> contains
>
> subroutine plsvect1( x )
>
>    real :: x
>
> end subroutine plsvect1
>
> end module dummy
>
>
>
>
>
> This should be perfectly acceptable code. If not, the PG compiler is doing
> something odd. Can you use a flag that will tell us more about what is
> wrong according to the compiler?
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
> *From:* Irena Johnson [mailto:ijo...@pp...]
> *Sent:* Wednesday, August 27, 2014 2:43 PM
> *To:* Alan W. Irwin
> *Cc:* plp...@li...
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
>
>
> Hi Alan, plplot_parameters.h
>
>
>
> Thank you for your help with this issue: I got the latest version of
> plplot from git and your modification to plplot_parameters.h has worked!!
>
>
>
> Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> sequence of statements"
>
>
>
>
>
> [ 24%] Built target plplotf95c
>
> Scanning dependencies of target plplotf95
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
>
> PGF90-S-0070-Incorrect sequence of statements
>  (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
>
>   0 inform,   0 warnings,   1 severes, 0 fatal for plplot
>
> make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> Error 2
>
> make[2]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
>
> make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
>
> make: *** [all] Error 2
>
>
>
> Thank you,
>
> --Irena
>
>
>
> On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@be...>
> wrote:
>
> On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
>
> Getting back to the principal issue, it appears to me that gcc is
> accepting all those "\n\" continuation lines in
> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> not.  We will look further at this.
>
>
>
> Hi Irena:
>
> I have now changed the style of plplot_parameters.h to replace one huge
> string
> literal by a large number of small string literals that the compiler
> should automatically concatenate together.
>
> I prefer this new style on general principles, and gcc compiles this
> style just as well as the old style. It's possible your Portland Group
> compiler will still choke on this style as it attempts to concatenate
> those string literals together. But on the other hand, it might work.
>
> To test that possibility, please try the latest version of our
> source code using
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Then try your normal build (with -DENABLE_tcl=ON or else by removing
> -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> default) referring to this version of the source tree rather than
> 5.10.0 and starting from an empty build tree. If your compiler is
> able to compile bindings/tcl/tclAPI.c without issues, then the change in
> style
> should be judged a success.
>
> Furthermore, I hope your set of Portland Group compilers is able to
> finish the rest of a default build of PLplot without issues, but if
> there are such issues we will try to deal with them since we prefer to
> have PLplot builds be successful on all compilers and not just gcc.
>
> By the way, I think the above is the first reference to our new
> official git repository on this list (although there has been a large
> amount of traffic about this huge change in PLplot development on the
> plplot-devel list).  The short story is our svn repository at SF is
> now frozen in read-only mode and as of a few days ago we switched to
> using git for PLplot development with the above being our official git
> repo.  I am pretty much a git newbie myself, but my use of it for the
> last several days shows it is an extremely popular version control
> system for good reasons.  Therefore, I think there is an excellent
> chance this change from subversion to git will not only help our
> current set of developers but also attract new developers to the
> project.
>
>
>
> 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
> __________________________
>
>
>   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-general] Fortran support issues under Plplot 5.10.0

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

Hi Don,



You are the first in a long time to stumble upon the deprecation of the FORTRAN 77 bindings several years ago. We deprecated it since the Fortran 90 and beyond standards make the interfacing much more robust.



The routines now live in the module PLPLOT. If you USE that module, then most routines are available with the same interface. However, several routines have a changed interface to take advantage of the array features in Fortran 90:



Call plline( n, x, y )



Has become:



Call plline( x, y )



Where the size of the arrays comes from the declaration via x(:), y(:) etc.



>From the README files I deduce version 5.9.10 is the last to contain the FORTRAN 77 bindings.



Regards,



Arjen




> -----Original Message-----
> From: Spong, Donald A. [mailto:sp...@or...]
> Sent: Wednesday, August 27, 2014 3:30 PM
> To: Plp...@li...
> Subject: [Plplot-general] Fortran support issues under Plplot 5.10.0
>
> I recently upgraded from Plplot  5.9.7 to Plplot 5.10.0 on my MacBook Air running
> MacOS 10.9.4. The first problem I encountered is that I don't find a plplotd-f77
> installed under /lib/pkgconfig. I have many legacy Fortran-77 codes I would like to
> keep running and no time to convert them to something else. Is there some way I can
> tell the installer to create plplotd-f77? If not, what is the latest version of Plplot that
> provides f77 support? If I try to use the plplotd-f95 that exists under /lib/pkgconfig,
> then the compiler doesn't find pllab, plline, or plwid. These routines are still
> mentioned in your documentation. Any suggestions as to why they aren't being found?
>
> [spongda~/fortran_code_development/GTC_spdata_check] >ifort -O -o xplot
> spdata_read_plot.o `PKG_CONFIG_PATH=/usr/local/plplot-5.10.0/lib/pkgconfig pkg-
> config --cflags --libs plplotd-f95` Undefined symbols for architecture x86_64:
>   "_pllab_", referenced from:
>       _MAIN__ in spdata_read_plot.o
>   "_plline_", referenced from:
>       _MAIN__ in spdata_read_plot.o
>   "_plwid_", referenced from:
>       _MAIN__ in spdata_read_plot.o
> ld: symbol(s) not found for architecture x86_64
>
> - Thanks, Don
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

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.

[Plplot-general] Fortran support issues under Plplot 5.10.0

[Spong, D. A. <sp...@or...>]

I recently upgraded from Plplot  5.9.7 to Plplot 5.10.0 on my MacBook Air running MacOS 10.9.4. The first problem I encountered is that I don’t find a plplotd-f77 installed under /lib/pkgconfig. I have many legacy Fortran-77 codes I would like to keep running and no time to convert them to something else. Is there some way I can tell the installer to create plplotd-f77? If not, what is the latest version of Plplot that provides f77 support? If I try to use the plplotd-f95 that exists under /lib/pkgconfig, then the compiler doesn’t find pllab, plline, or plwid. These routines are still mentioned in your documentation. Any suggestions as to why they aren’t being found?

[spongda~/fortran_code_development/GTC_spdata_check] >ifort -O -o xplot spdata_read_plot.o `PKG_CONFIG_PATH=/usr/local/plplot-5.10.0/lib/pkgconfig pkg-config --cflags --libs plplotd-f95`
Undefined symbols for architecture x86_64:
  "_pllab_", referenced from:
      _MAIN__ in spdata_read_plot.o
  "_plline_", referenced from:
      _MAIN__ in spdata_read_plot.o
  "_plwid_", referenced from:
      _MAIN__ in spdata_read_plot.o
ld: symbol(s) not found for architecture x86_64

- Thanks, Don

Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

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

Hi Irena,



That is rather odd, the code is correct as far as I can tell. Could you try to compile this code:



module dummy

    interface plsvect

        module procedure plsvect1

        subroutine plsvect2

        end subroutine plsvect2

    end interface

contains

subroutine plsvect1( x )

   real :: x

end subroutine plsvect1

end module dummy




This should be perfectly acceptable code. If not, the PG compiler is doing something odd. Can you use a flag that will tell us more about what is wrong according to the compiler?

Regards,

Arjen


From: Irena Johnson [mailto:ijo...@pp...]
Sent: Wednesday, August 27, 2014 2:43 PM
To: Alan W. Irwin
Cc: plp...@li...
Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h

Hi Alan, plplot_parameters.h

Thank you for your help with this issue: I got the latest version of plplot from git and your modification to plplot_parameters.h has worked!!

Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect sequence of statements"


[ 24%] Built target plplotf95c
Scanning dependencies of target plplotf95
[ 25%] Building Fortran object bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
[ 25%] Building Fortran object bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
PGF90-S-0070-Incorrect sequence of statements  (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
  0 inform,   0 warnings,   1 severes, 0 fatal for plplot
make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o] Error 2
make[2]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
make: *** [all] Error 2

Thank you,
--Irena

On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> wrote:
On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
Getting back to the principal issue, it appears to me that gcc is
accepting all those "\n\" continuation lines in
bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
not.  We will look further at this.

Hi Irena:

I have now changed the style of plplot_parameters.h to replace one huge string
literal by a large number of small string literals that the compiler
should automatically concatenate together.

I prefer this new style on general principles, and gcc compiles this
style just as well as the old style. It's possible your Portland Group
compiler will still choke on this style as it attempts to concatenate
those string literals together. But on the other hand, it might work.

To test that possibility, please try the latest version of our
source code using

git clone git://git.code.sf.net/p/plplot/plplot<http://git.code.sf.net/p/plplot/plplot> plplot.git

Then try your normal build (with -DENABLE_tcl=ON or else by removing
-DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
default) referring to this version of the source tree rather than
5.10.0 and starting from an empty build tree. If your compiler is
able to compile bindings/tcl/tclAPI.c without issues, then the change in style
should be judged a success.

Furthermore, I hope your set of Portland Group compilers is able to
finish the rest of a default build of PLplot without issues, but if
there are such issues we will try to deal with them since we prefer to
have PLplot builds be successful on all compilers and not just gcc.

By the way, I think the above is the first reference to our new
official git repository on this list (although there has been a large
amount of traffic about this huge change in PLplot development on the
plplot-devel list).  The short story is our svn repository at SF is
now frozen in read-only mode and as of a few days ago we switched to
using git for PLplot development with the above being our official git
repo.  I am pretty much a git newbie myself, but my use of it for the
last several days shows it is an extremely popular version control
system for good reasons.  Therefore, I think there is an excellent
chance this change from subversion to git will not only help our
current set of developers but also attract new developers to the
project.


Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>).

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

Linux-powered Science
__________________________

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-general] continuation lines in bindings/tcl/plplot_parameters.h

[Irena J. <ijo...@pp...>]

Hi Alan, plplot_parameters.h

Thank you for your help with this issue: I got the latest version of plplot
from git and your modification to plplot_parameters.h has worked!!

Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect sequence
of statements"


[ 24%] Built target plplotf95c
Scanning dependencies of target plplotf95
[ 25%] Building Fortran object
bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
[ 25%] Building Fortran object
bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
PGF90-S-0070-Incorrect sequence of statements
 (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
  0 inform,   0 warnings,   1 severes, 0 fatal for plplot
make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o] Error
2
make[2]: ***
[bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
make: *** [all] Error 2

Thank you,
--Irena


On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
>
>  Getting back to the principal issue, it appears to me that gcc is
>> accepting all those "\n\" continuation lines in
>> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
>> not.  We will look further at this.
>>
>
> Hi Irena:
>
> I have now changed the style of plplot_parameters.h to replace one huge
> string
> literal by a large number of small string literals that the compiler
> should automatically concatenate together.
>
> I prefer this new style on general principles, and gcc compiles this
> style just as well as the old style. It's possible your Portland Group
> compiler will still choke on this style as it attempts to concatenate
> those string literals together. But on the other hand, it might work.
>
> To test that possibility, please try the latest version of our
> source code using
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Then try your normal build (with -DENABLE_tcl=ON or else by removing
> -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> default) referring to this version of the source tree rather than
> 5.10.0 and starting from an empty build tree. If your compiler is
> able to compile bindings/tcl/tclAPI.c without issues, then the change in
> style
> should be judged a success.
>
> Furthermore, I hope your set of Portland Group compilers is able to
> finish the rest of a default build of PLplot without issues, but if
> there are such issues we will try to deal with them since we prefer to
> have PLplot builds be successful on all compilers and not just gcc.
>
> By the way, I think the above is the first reference to our new
> official git repository on this list (although there has been a large
> amount of traffic about this huge change in PLplot development on the
> plplot-devel list).  The short story is our svn repository at SF is
> now frozen in read-only mode and as of a few days ago we switched to
> using git for PLplot development with the above being our official git
> repo.  I am pretty much a git newbie myself, but my use of it for the
> last several days shows it is an extremely popular version control
> system for good reasons.  Therefore, I think there is an excellent
> chance this change from subversion to git will not only help our
> current set of developers but also attract new developers to the
> project.
>
>
> 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-general] continuation lines in bindings/tcl/plplot_parameters.h

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

On 2014-08-26 13:21-0700 Alan W. Irwin wrote:

> Getting back to the principal issue, it appears to me that gcc is
> accepting all those "\n\" continuation lines in
> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> not.  We will look further at this.

Hi Irena:

I have now changed the style of plplot_parameters.h to replace one huge string
literal by a large number of small string literals that the compiler
should automatically concatenate together.

I prefer this new style on general principles, and gcc compiles this
style just as well as the old style. It's possible your Portland Group
compiler will still choke on this style as it attempts to concatenate
those string literals together. But on the other hand, it might work.

To test that possibility, please try the latest version of our
source code using

git clone git://git.code.sf.net/p/plplot/plplot plplot.git

Then try your normal build (with -DENABLE_tcl=ON or else by removing
-DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
default) referring to this version of the source tree rather than
5.10.0 and starting from an empty build tree. If your compiler is
able to compile bindings/tcl/tclAPI.c without issues, then the change in style
should be judged a success.

Furthermore, I hope your set of Portland Group compilers is able to
finish the rest of a default build of PLplot without issues, but if
there are such issues we will try to deal with them since we prefer to
have PLplot builds be successful on all compilers and not just gcc.

By the way, I think the above is the first reference to our new
official git repository on this list (although there has been a large
amount of traffic about this huge change in PLplot development on the
plplot-devel list).  The short story is our svn repository at SF is
now frozen in read-only mode and as of a few days ago we switched to
using git for PLplot development with the above being our official git
repo.  I am pretty much a git newbie myself, but my use of it for the
last several days shows it is an extremely popular version control
system for good reasons.  Therefore, I think there is an excellent
chance this change from subversion to git will not only help our
current set of developers but also attract new developers to the
project.

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-general] continuation lines in bindings/tcl/plplot_parameters.h

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

On 2014-08-26 14:35-0400 Irena Johnson wrote:

> Hello,
>
> I am trying to compile plplot-5.10.0 for PGF-13.6 and am getting the
> following error:
>
> $ make 2>&1 |tee log.make
> [  0%] Built target deltaT-gen
> [  1%] Built target deltaT.h_built
> [  2%] Built target tai-utc-gen
> [  2%] Built target tai-utc.h_built
> [  2%] Built target qsastime
> [  2%] Built target plhershey-unicode-gen
> [  2%] Built target plhershey-unicode.h_built
> [  3%] Building C object
> src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o
> PGC-F-0223-String too long
> (/pfs/tmp/ijohnson/plplot-5.10.0/bindings/tcl/plplot_parameters.h: 15)
> PGC/x86-64 Linux 13.6-0: compilation aborted
> make[2]: *** [src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o] Error 2
> make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2
> make: *** [all] Error 2
>
>
> Could you please advise? Thank you!

Hi Irena:

I have changed the subject line to something more appropriate.

Note, a quick workaround for any problem like this is to disable the
relevant PLplot component.  So I suggest trying the cmake option
-DENABLE_tcl=OFF to avoid compiling anything to do with Tcl including
bindings/tcl/tclAPI.c. (For quick one-line annotation of each of the
PLplot components look for the string ENABLE in CMakeCache.txt.)

Getting back to the principal issue, it appears to me that gcc is
accepting all those "\n\" continuation lines in
bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
not.  We will look further at this.

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-general] Welcome to the "Plplot-general" mailing list

[Irena J. <ijo...@pp...>]

Hello,

I am trying to compile plplot-5.10.0 for PGF-13.6 and am getting the
following error:

$ make 2>&1 |tee log.make
[  0%] Built target deltaT-gen
[  1%] Built target deltaT.h_built
[  2%] Built target tai-utc-gen
[  2%] Built target tai-utc.h_built
[  2%] Built target qsastime
[  2%] Built target plhershey-unicode-gen
[  2%] Built target plhershey-unicode.h_built
[  3%] Building C object
src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o
PGC-F-0223-String too long
(/pfs/tmp/ijohnson/plplot-5.10.0/bindings/tcl/plplot_parameters.h: 15)
PGC/x86-64 Linux 13.6-0: compilation aborted
make[2]: *** [src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o] Error 2
make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2
make: *** [all] Error 2


Could you please advise? Thank you!

-- 
Irena

[Plplot-general] 2nd Call For Papers, 21th Annual Tcl/Tk Conference 2014

[Andreas K. <and...@ac...>]

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

[ It is 4 weeks to the deadline for Abstracts and proposals ... ]

November 10 - 14, 2014
Embassy Suites Downtown
Portland, Oregon, USA

Important Dates:

Abstracts and proposals due     Sep  8, 2014
Notification to authors         Sep 22, 2014
Author materials due            Oct 20, 2014
Tutorials start                 Nov 10, 2014
Conference starts               Nov 12, 2014

[[ 
        Registration is open.
]]

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2014 will be held in Portland, Oregon, USA from November
10 - 14, 2014. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2014. Authors of accepted abstracts will have until September 2, 2014
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis.
WIP slots can be reserved like any paper proposal. BOF slots will be
managed on-site. All attendees with an interesting work in progress
should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2014/) and will be published on
various Tcl/Tk-related information channels.

        Registration is open.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp                   General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.      Program Chair
Brian Griffin           Mentor Graphics                Site/Facilities Chair
Arjen Markus            Deltares
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago
Donal Fellows           University of Manchester
Gerald Lester           KnG Consulting, LLC
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB at Michigan State University & CAEN Technologies
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2014 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

Re: [Plplot-general] Plplot f95 examples will not compile

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

On 2014-05-28 22:11-0000 rush wrote:

>
> I have been compiling FORTRAN Plplot for sometime using F77 compiler.  But,
> after updating my Ubuntu operating system, the deprecated F77 plplot
> libraries were removed.  At that unfortunate point, I found out that PLPLOT
> has shifted to f95 compiler which encompasses both F77, F90 and F95 codes.
>
> When I attempt to compile the fortran Plplot examples, I get the following
> error:
>
>
>    use plplot
>        1
> "Fatal Error: Can't open module file 'plplot.mod' for reading at (1): No
> such file or directory"
>
> This error relates to the "use plplot".   I cannot determine where this file
> or directory is located.  Please advise.

On Debian (and probably Ubuntu as well) you can search for system file
locations by using the apt-file command.  Here is the result here
(Debian stable) for that command when searching for plplot.mod:

irwin@raven> apt-file search plplot.mod
libplplot-dev: /usr/lib/fortran/modules/plplot/plplot.mod

This means if I want access to this file I have to install the
libplplot-dev package (if that has not been done already), and also
gives the location of the desired file once installed.

The location of the file and even the name of the package on your
Ubuntu system might be different (that depends on the actual Ubuntu
packaging), but the principle is the same for all Debian-related
distributions such as Debian stable or Ubuntu; use apt-file (which you
might have to install and update first if it is not already installed
on your system) to find out where any system file (including
plplot.mod) is located.

HTH.

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-general] Plplot f95 examples will not compile

[rush <ru...@ku...>]

I have been compiling FORTRAN Plplot for sometime using F77 compiler.  But,
after updating my Ubuntu operating system, the deprecated F77 plplot
libraries were removed.  At that unfortunate point, I found out that PLPLOT
has shifted to f95 compiler which encompasses both F77, F90 and F95 codes.

When I attempt to compile the fortran Plplot examples, I get the following
error:


    use plplot
        1    
"Fatal Error: Can't open module file 'plplot.mod' for reading at (1): No
such file or directory"

This error relates to the "use plplot".   I cannot determine where this file
or directory is located.  Please advise.

Much thanks.

rud

  

 

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[David V. <dve...@gm...>]

Thanks, Andrew.  It's OK.  This was a good exercise as it forced me to
figure out how to wrap Fortran95 PlPlot with Fortran95 code, rather than
the Fortran77 PLPlot bindings with Fortran77 code, and do it with
shared-object libraries rather than static libraries, which was a useful
and necessary exercise.  It probably seems trivial, and maybe it is, but
it's made a little less so since it all must be linked against a body of
Fortran77 code that I've no control over, and also since I'm using the
Autotools, which are beneficial but which also warrant a little extra
thought.


On Mon, May 19, 2014 at 12:38 AM, Andrew Ross <
and...@us...> wrote:

>
> For Debian / Ubuntu we only build the shared libraries. The packages are
> somewhat out of date. Sorry - this is a combination of me not having much
> time to work on this, and also the fact that the latest version of plplot
> needs the newest version of cmake to work correctly with octave. I've been
> waiting on this to reach unstable so I can upload the new packages. The
> Debian packaging files are part of the plplot svn repository, but not
> distributed with the source so you can always try those if you fancy
> building your own packages!
>
> Andrew
>
> On Mon, May 19, 2014 at 06:49:21AM +0000, Arjen Markus wrote:
> > Hi David,
> >
> > I do not know how the libraries are distributed in Ubuntu, but if only
> the shared versions are distributed, that will be a very deliberate choice
> of the distributors. Even though the shared libraries get exercised more,
> you should be able to build them yourself.
> >
> > As for the difference between the F77 and F95 bindings:
> >
> > -        First of all, inserting a “use plplot” statement will allow the
> compiler to “see” the interface definitions.
> >
> > -        This is necessary for it to insert the right internal names of
> the routines (otherwise the linker will complain)
> >
> > -        But more importantly, the compiler will be able to check the
> argument lists of the routines. Arguments that have changed between F77 and
> F95 are things like the number of elements in an array. In F95
> introspection is possible and that avoids many mistakes. It does mean some
> incompatibility unfortunately.
> >
> > Regards,
> >
> > Arjen
> >
> > From: David Ventimiglia [mailto:dve...@gm...]
> > Sent: Sunday, May 18, 2014 1:55 PM
> > To: Moez Kilani
> > Cc: plplot_general
> > Subject: Re: [Plplot-general] Compiling against the Fortran77 libraries
> in PLPlot 5.10.0
> >
> > Thanks, Alan and Moez.
> >
> > On Sat, May 17, 2014 at 10:27 PM, Moez Kilani <moe...@gm...
> <mailto:moe...@gm...>> wrote:
> > Hi David,
> >
> > I also liked the fortran77 bindings. For the F95 bindings, I have posted
> an example on my web page :
> >
> > http://perso.univ-lille3.fr/~mkilani/other/other.html
> >
> > hope it helps (notice lines 2, 42-51) !
> >
> > Best
> >
> > 2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...<mailto:
> dve...@gm...>>:
> > Hi,
> >
> > How do I compile Fortran77 programs against PLPlot now that the
> Fortran77 libraries have finally been removed from libplplot-dev (I'm on
> Ubuntu, so this is a Debian style package)?  On my system I also see that
> there now is a libplplot-fortran11 package whose description says:
> >
> > This package contains the Fortran 77 and Fortran 95 bindings for
> > PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
> > version of PLplot, and will be dropped from a future release. New code
> > should use the Fortran 95 bindings.
> >
> > But, within it there are only shared-object libraries and no longer any
> static libraries, which were very convenient.  Further, where are the
> actually Fortran77 libraries?  The .so files here all are labelled with
> f95, and they seem to contain Fortran95 style symbols and don't contain
> Fortran77 symbols.  Have the Fortran77 libraries actually been completely
> purged?
> >
> > Thanks!
> > Best,
> > David
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...<mailto:
> Plp...@li...>
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
> >
> >
> > 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.
>
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
>
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
>
>