plplot-general — PLplot user discussion group

[Plplot-general] Fwd: Fwd: Fwd: x Axis in Date Format has wrong ticks

[Marc R. <mar...@gm...>]

Hi !

Sorry for double posting. I already posted this to the project tracker
support requests. However that's 1 week ago and I noticed that almost no
support request there got a reply. So I'm posting it here again. I hope
that's ok.
The images are at http://mweb.linkpc.net/temp/plplot

I'm logging temperature values and would like to plot them with a graph.
I temperature values are not captured in equal timely distances.

If I use this:

plbox("bcnstd", 0, 0, "bcnstv", 5, 5);

I get graphok.svg

Since I want to have more ticks on the x axis and would prefer them in 6
hour steps instead of 10, I tried this

plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);

which results in graphbugged.svg.

Am I doing something wrong or is this a bug?

Best regards
     Marc


Here is the rest of my code

plsdev("svg");
plsetopt("o", "temp\\a.svg");
plsetopt("geometry", "1024x512");
plinit();

plfont(1);
plschr(0, 0.5);
pltimefmt("%d %H-%M-%S");

plenv(x.GetFront(), x.GetBack(), 0, 50, 0, 40);
plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);
pllab("", "Temperature", "");
plcol0(1);
plline(x.GetN(), x.GetPointer(), y.GetPointer());

plend();

[Plplot-general] Fwd: Fwd: x Axis in Date Format has wrong ticks

[Marc R. <mar...@gm...>]

Hi !

Sorry for double posting. I already posted this to the project tracker
support requests. However that's 1 week ago and I noticed that almost no
support request there got a reply. So I'm posting it here again. I hope
that's ok.
The images are at http://mweb.linkpc.net/temp/plplot

I'm logging temperature values and would like to plot them with a graph.
I temperature values are not captured in equal timely distances.

If I use this:

plbox("bcnstd", 0, 0, "bcnstv", 5, 5);

I get graphok.svg

Since I want to have more ticks on the x axis and would prefer them in 6
hour steps instead of 10, I tried this

plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);

which results in graphbugged.svg.

Am I doing something wrong or is this a bug?

Best regards
    Marc


Here is the rest of my code

plsdev("svg");
plsetopt("o", "temp\\a.svg");
plsetopt("geometry", "1024x512");
plinit();

plfont(1);
plschr(0, 0.5);
pltimefmt("%d %H-%M-%S");

plenv(x.GetFront(), x.GetBack(), 0, 50, 0, 40);
plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);
pllab("", "Temperature", "");
plcol0(1);
plline(x.GetN(), x.GetPointer(), y.GetPointer());

plend();

[Plplot-general] Fwd: x Axis in Date Format has wrong ticks

[Marc R. <mar...@gm...>]

Hi !

Sorry for double posting. I already posted this to the project tracker
support requests. However that's 1 week ago and I noticed that almost no
support request there got a reply. So I'm posting it here again. I hope
that's ok.

I'm logging temperature values and would like to plot them with a graph.
I temperature values are not captured in equal timely distances.

If I use this:

plbox("bcnstd", 0, 0, "bcnstv", 5, 5);

I get graphok.svg

Since I want to have more ticks on the x axis and would prefer them in 6
hour steps instead of 10, I tried this

plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);

which results in graphbugged.svg.

Am I doing something wrong or is this a bug?

Best regards
   Marc


Here is the rest of my code

plsdev("svg");
plsetopt("o", "temp\\a.svg");
plsetopt("geometry", "1024x512");
plinit();

plfont(1);
plschr(0, 0.5);
pltimefmt("%d %H-%M-%S");

plenv(x.GetFront(), x.GetBack(), 0, 50, 0, 40);
plbox("bcnstd", 60 * 60 * 6, 6, "bcnstv", 5, 5);
pllab("", "Temperature", "");
plcol0(1);
plline(x.GetN(), x.GetPointer(), y.GetPointer());

plend();

[Plplot-general] Announcing Gtkmm-PLplot 1.0

[Tom S. <tom...@me...>]

Hi all,


It is my great pleasure to announce the first release of Gtkmm-PLplot, a library providing scientific plotting support for Gtkmm, built entirely around PLplot.

I started this project as I found that there were no plotting libraries around that were supporting Gtkmm-3 and I was badly in need for one.

I discovered that it’s really easy to combine Gtkmm and PLplot using a Gtk::DrawingArea and the extcairo plot device and decided to create an entire library around it.

Currently I am supporting two dimensional plots (including polar), contour plots with/without shades and three-dimensional plots of line data. Where appropriate, I have also added support for zooming by dragging selection boxes.

More features will follow in future releases.

I invite everybody to check out the library and have a look at the documentation (including screenshots) I am hosting at http://github.com/tschoonj/gtkmm-plplot <http://github.com/tschoonj/gtkmm-plplot> and http://tschoonj.github.io/gtkmm-plplot <http://tschoonj.github.io/gtkmm-plplot>.

Best regards,

Tom Schoonjans

Re: [Plplot-general] Color map change, X axis at top and some more

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

Hi Roxo:

Since you are satisfied with the answer you have discovered for
your question 1, I will now move on to your further questions.

On 2015-08-31 20:10-0300 Fernando M. Roxo da Motta wrote:

> ==========================8<--------  Question 2 -----------------
>
>  Another change to the code is some calls to 'plspal0'.   What I
> understand is that if the call happens before 'plinit' the desired
> palette becomes active.  The extent I have tried if I call the routine
> after 'plinit' the result seems to me to be unpredictable.  The
> example x16f.f90 calls it many times, ever followed by a call to
> 'pladv'.  I tried that but does worked.  What should be the call
> sequence to change the color map 0?

See example 16 for a correct way to call plspal0 to set up the colour
palette for the next page.  In this case pladv is used to start the
next page.  But note that a call to plenv implicitly calls pladv so
there is no need for an extra pladv call if your plspal0 call is
followed by a call to plenv rather than pladv.

>
> ==========================8<--------  Question 3 -----------------
>
>  This one is just to confirm if I understood correctly.  Everytime a
> plot is finished (whatever it means) the program holds and wait for an
> interaction, usually the mouse button 3 (rightmost) releases the code
> to go on.   While waiting one can resize and do some other stuffs
> depending on the driver used to plot.   If I use 'plspause(.FALSE.)'
> the program will not hold, with the price of no interaction with the
> graphic.  Is it correct?

Yes.  You can also use the command-line option "-np" to put no-pause
mode into effect.


> ==========================8<--------  Question 4 -----------------
>
>  If I understood correctly, the end of page is reached when the
> program reach a 'pleop', a new 'plenv', or some others calls.  What are
> the calls that trigs the EOP?

I don't think I can give you a complete list, but pladv is one such
call (which is the reason why plenv is also one of them since it
implicitly calls pladv).  It's possible plbop is another, but I
suggest you look at our examples and also experiment to find out. The
reason why starting a new page generally finishes the old page is
simply to make PLplot more convenient/flexible to use.

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] Color map change, X axis at top and some more

[Fernando M. R. da M. <ro...@ro...>]

On Mon, 31 Aug 2015 23:19:25 -0700 (PDT), "Alan W. Irwin"
<ir...@be...> wrote:


> On 2015-08-31 20:10-0300 Fernando M. Roxo da Motta wrote:
> 
> >
> >
> > ========================8<---------  Environment -----------------
> >
> >  I am using a [Xu|U]buntu 14.04 64 bits, Plplot 5.10.0, Gfortran
> > 4.8.4.  The driver I am using is 'PLPLOT_DEV=wxwidgets'.
> >
> >
> > ==========================8<--------  Question 1 -----------------
> >
> >  As it can be seem, the call of 'plenv' exchanging xmin and xmax do
> > the trick of inverting the Y axis, as I expected, except that the X
> > axis+labels keeps being plotted at the bottom of the graph.   That
> > seems to be a proof that the universe has no commitment with my
> > thoughts.  :(    The question:  Is there some really simple
> > approach to change this, or will I need to make a number of calls
> > to plot it "by hand"?   By the way, I am reading the history  of
> > the Plplot-General (I'm at Dec 2010) and so far didn't found an
> > answer to this.
> >
> 
> Hi Roxo:
> 
> Thanks for your interest in PLplot.
> 
> The answer to the above question is plenv is too simple for your
> special seismic data needs, and instead you have to replace it with
> calls to pladv, plvpor, plwind, and plbox.  That sounds like a lot of
> complexity, but it is really not too bad.  See example x01f.f90 for

  Hi Alan,

  Thank you for your attention and kudos to your effort in the list and
the work of all developers.

  Ok, I have played with those routines and I have arrived to an
approach that looks simple enough.

  I called 'plenv' with "axis" parameter equal -2 and them called the
'plbox':

  call plbox("bcmst", 0.0_plflt, 0, "bcnstv", 0.0_plflt, 0)
    (I still have to fully understand the alphabet soup)

  It seems to do what I have expected.   To put the labels where I
wanted I added three calls to 'plmtex' as in the attached code. (Yet
Another Change On x00f.f90)

  I keep thinking that the fact that inverting "ymin" and "ymax" in the
'plenv' call will invert the Y axis.  That is, it is a (desirable IMHO)
feature and not a bug that the developers decide to "fix". ;)

  I think I can live with this.


> how those routines are typically called together and also look for
> those routines in the documentation
> <http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/>.
> 

  I am picky enough to be a manual reader.  ;)

> Let's put off discussion of your further questions until you are
> satisfied with the answer to this question. :-)
> 

  Ok, I think we can proceed to the remaining questions.


  Roxo

-- 
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <ro...@ro...>               | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
      ( Usuário Linux registrado #39505 )               | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Re: [Plplot-general] Color map change, X axis at top and some more

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

On 2015-08-31 20:10-0300 Fernando M. Roxo da Motta wrote:

>
>
>  Hi all,
>
>  I am sending attached the x00f.f90 program with a few changes that, I
> hope, will make clear my questions.   I expect that the list server
> allow attachments.
>
>  It is my first message to this list, so if I violate any rule,
> please, educate me.   I hope no LART will be necessary though.
>
>  I started the use of Plplot a couple of weeks ago.  I had a number of
> programs around without use.  Those used the ancient "Calcomp" call to
> plot (plots, plot, dasher,...) and decide to use some of them as a
> test.
>
> ========================8<---------  Environment -----------------
>
>  I am using a [Xu|U]buntu 14.04 64 bits, Plplot 5.10.0, Gfortran
> 4.8.4.  The driver I am using is 'PLPLOT_DEV=wxwidgets'.
>
> ========================8<---------  Why Y inverted -----------------
>
>  I am a geophysicist and work with seismic data.  What is this?  Does
> not matter.   The point is that the informations I want to plot
> represents something down into the Earth.  For this reason we use ours
> graphics with the X axis (including labels and ticks) on top (surface)
> and the Y axis growing down (depth or wave travel time).
>
>  The attached code is the x00f.f90 program with few changes to try to
> get the feel of the library.
>
> ==========================8<--------  Question 1 -----------------
>
>  As it can be seem, the call of 'plenv' exchanging xmin and xmax do
> the trick of inverting the Y axis, as I expected, except that the X
> axis+labels keeps being plotted at the bottom of the graph.   That
> seems to be a proof that the universe has no commitment with my
> thoughts.  :(    The question:  Is there some really simple approach to
> change this, or will I need to make a number of calls to plot it "by
> hand"?   By the way, I am reading the history  of the Plplot-General
> (I'm at Dec 2010) and so far didn't found an answer to this.
>

Hi Roxo:

Thanks for your interest in PLplot.

The answer to the above question is plenv is too simple for your
special seismic data needs, and instead you have to replace it with
calls to pladv, plvpor, plwind, and plbox.  That sounds like a lot of
complexity, but it is really not too bad.  See example x01f.f90 for
how those routines are typically called together and also look for
those routines in the documentation
<http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/>.

Let's put off discussion of your further questions until you are
satisfied with the answer to this question. :-)

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] Color map change, X axis at top and some more

[Fernando M. R. da M. <ro...@ro...>]

  Hi all,

  I am sending attached the x00f.f90 program with a few changes that, I
hope, will make clear my questions.   I expect that the list server
allow attachments.

  It is my first message to this list, so if I violate any rule,
please, educate me.   I hope no LART will be necessary though.

  I started the use of Plplot a couple of weeks ago.  I had a number of
programs around without use.  Those used the ancient "Calcomp" call to
plot (plots, plot, dasher,...) and decide to use some of them as a
test.

========================8<---------  Environment -----------------

  I am using a [Xu|U]buntu 14.04 64 bits, Plplot 5.10.0, Gfortran
4.8.4.  The driver I am using is 'PLPLOT_DEV=wxwidgets'.

========================8<---------  Why Y inverted -----------------

  I am a geophysicist and work with seismic data.  What is this?  Does
not matter.   The point is that the informations I want to plot
represents something down into the Earth.  For this reason we use ours
graphics with the X axis (including labels and ticks) on top (surface)
and the Y axis growing down (depth or wave travel time).

  The attached code is the x00f.f90 program with few changes to try to
get the feel of the library.

==========================8<--------  Question 1 -----------------

  As it can be seem, the call of 'plenv' exchanging xmin and xmax do
the trick of inverting the Y axis, as I expected, except that the X
axis+labels keeps being plotted at the bottom of the graph.   That
seems to be a proof that the universe has no commitment with my
thoughts.  :(    The question:  Is there some really simple approach to
change this, or will I need to make a number of calls to plot it "by
hand"?   By the way, I am reading the history  of the Plplot-General
(I'm at Dec 2010) and so far didn't found an answer to this.

==========================8<--------  Question 2 -----------------

  Another change to the code is some calls to 'plspal0'.   What I
understand is that if the call happens before 'plinit' the desired
palette becomes active.  The extent I have tried if I call the routine
after 'plinit' the result seems to me to be unpredictable.  The
example x16f.f90 calls it many times, ever followed by a call to
'pladv'.  I tried that but does worked.  What should be the call
sequence to change the color map 0?

==========================8<--------  Question 3 -----------------

  This one is just to confirm if I understood correctly.  Everytime a
plot is finished (whatever it means) the program holds and wait for an
interaction, usually the mouse button 3 (rightmost) releases the code
to go on.   While waiting one can resize and do some other stuffs
depending on the driver used to plot.   If I use 'plspause(.FALSE.)'
the program will not hold, with the price of no interaction with the
graphic.  Is it correct?

==========================8<--------  Question 4 -----------------

  If I understood correctly, the end of page is reached when the
program reach a 'pleop', a new 'plenv', or some others calls.  What are
the calls that trigs the EOP?

  I think there is too many questions for a single message already.
Sorry for that.

  Best regards.



  Roxo

-- 
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <ro...@ro...>               | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
            ( Registered Linux user #39505 )            | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Re: [Plplot-general] PLplot-5.11.1 has been released

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

On 2015-08-12 12:25-0700 Alan W. Irwin wrote:

> I am happy to report that PLplot-5.11.1 has now been released.
[....]
> Because of
> Greg's [comprehensive testing] success I can highly recommend the [MinGW-w64/]MSYS2 platform to all our
> Windows users.

For those wanting to follow up on this recommendation, I suggest they
first look at the recently created wiki page
<https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/>.

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-5.11.1 has been released

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

I am happy to report that PLplot-5.11.1 has now been released. For
more details such as download location, follow the link at
plplot.sf.net to the news item concerning this release.  We encourage
everyone on this mailing list to try this new release since this is
the only version we support.  Once you have downloaded, gpg-verified,
and unpacked the plplot-5.11.1.tar.gz file, you should pay close
attention to the README.release file since that file contains the
all-important notes for this release.

I thank all the developers and testers that helped with this release. 
I would especially like to point out the contribution made by Greg
Jung who has been the first to have essentially complete success with
comprehensive testing on the MSYS2 platform (specifically with the
mingw-w64_x86_64 toolchain, but from his success with that toolchain
it is likely the mingw-w64_i686 toolchain for MSYS2 will also work
well as a PLplot platform).  For more details of Greg's test results see
the comprehensive test reports in the release notes.  Because of
Greg's success I can highly recommend the MSYS2 platform to all our
Windows users.

Enjoy PLplot-5.11.1 on all Unix and Windows platforms, and as always
if you find any problems with this release please report them here (or
the plplot-devel mailing list) first to see if we can get a quick
resolution.

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
__________________________

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Plplot-general mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] 3rd Call For Papers - 22nd Annual Tcl/Tk Conference (Tcl'2015)

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

Hello plplot-general, fyi ...

22nd Annual Tcl/Tk Conference (Tcl'2015)
http://www.tcl.tk/community/tcl2015/

October 19 - 23, 2015
Comfort Suites Manassas
7350 Williamson Blvd, 20109
Manassas, Virginia, USA

[[ Attention! One month to the paper deadline ]]

[[ Attention! Registration is open! Please have a look at
   http://www.tcl.tk/community/tcl2015/register.html
]]

[[ Known Speakers
-- Keynotes

  * Kevin Walzer - Tk on the Mac: Past, Present, Future

-- Tutorials

  * Clif Flynt - Advanced Tcl: TclOO Intro
                 New Tcl/Tk Platforms --- Pi and Android

  * Gerald Lester - Introduction to Tcl 1
                    Introduction to Tcl 2
                    Introduction to Tk 1
                    Programming the Web with Tcl: A Survey of Tools, Tips and Tricks

  * Sean Woods - Advanced TclOO & Megawidgets in TclOO

]]

Important Dates:

Abstracts and proposals due   August 24, 2015
Notification to authors       August 31, 2015
WIP and BOF reservations open July 27, 2015
Hotel Room Release            August 25, 2015
Author materials due          September 28, 2015
Tutorials Start               October 19, 2015
Conference starts             October 21, 2015

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

Submission of Summaries

Tcl/Tk 2015 will be held in Manassas, Virginia, USA from October 19, 2015 to October 23, 2015.

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

Note:
    We are especially interested in papers for OS X this time, to
    complement the keynote.

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 tcl...@go... no later than August 24, 2015. Authors of accepted
abstracts will have until September 28, 2015 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 30 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
starting in July 27, 2015. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in July 27, 2015. Some WIP and BOF time slots will be held open
for on-site reservation. 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/tcl2015/) and will be published on
various Tcl/Tk-related information channels.

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

   * Andreas Kupries  ActiveState Inc
   * Arjen Markus     Deltares
   * Brian Griffin    Mentor Graphics
   * Clif Flynt       Noumena Corp
   * Cynthia Lilagan  National Museum of Health & Medicine, Chicago
   * Donal Fellows    University of Manchester
   * Gerald Lester    KnG Consulting LLC
   * Jeff Hobbs       ActiveState Inc
   * Joe Mistachkin   Mistachkin Systems
   * Kevin Kenny      GE Global Research Center
   * Larry Virden
   * Mike Doyle       National Museum of Health & Medicine, Chicago
   * Ronald Fox       CAEN Technologies
                      NSCL @ Michigan State University
   * Steve Landers    Digital Smarties
   * Steve Redler, IV SR Technology

Contact Information     tcl...@go...

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

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

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

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

On 2015-07-15 13:24-0700 Walt Brainerd wrote:

> First, yes, those are the correct compilers:
>
> bash-3.1$ which gfortran
> /c/mingw/bin/gfortran.exe
> bash-3.1$ gfortran --version
> GNU Fortran (tdm64-1) 5.1.0
>
> I tried MSYS2 to see what would happen.
> Nothing works--not even git. Says my
> version of cygwin.dll is incompatible.
> (Incompatible with what? The compilers,
> cygwin and msys2 are all the latest 64-bit
> version). What is the point of MSYS if
> you also have to have Cygwin?

>
> So I deleted Msys2 and reinstalled msys1.
>
> [It looked interesting for progressing with
> coarray Fortran as it includes /dev/shm.]
>
> Your test didn't get very far, but here it is:
>
> http://www.fortran.com/Test2/*tar.gz

Hi Walt:

Sorry I have been a bit slow to respond today, but I have a number
of things on my plate as release manager with the release of 5.11.1 coming up in
10 days.

I am very happy to see a proper report tarball at the above URL rather than
the peculiar one we had for Test1.

That report is exactly what I should have needed to get further, but
as you stated your test stopped virtually instantly.  The error message
(in shared/output_tree/cmake.out) was

CMake Error: Could not create named generator MSYS Makefiles

I have been told elsewhere that the MSYS2 version of cmake does not
have the MSYS Makefiles generator because you should always use the
"Unix Makefiles" generator on that platform.  So from that it appears
you might have been using the MSYS2 version of cmake, but that
doesn't jibe with your statement above that your removed MSYS2.

I am now left wondering if your TDM environment fails to do a clean
job of imposing MSYS2 on a previous MSYS platform (explaining why you
could not get MSYS2 to work) or vice versa (explaining why from the
above error message some part of MSYS2 appears to still be left).

Anyhow, I suggest you start over with a new clean install of TDM
using a unique installation prefix so that it is always easy thereafter
to remove that version of TDM if it gets clobberred.

According to <http://tdm-gcc.tdragon.net/about> you have two choices
which are MinGW or MinGW-w64.  But I assume that really means your
choices are MinGW/MSYS (a very limited environment which you denote
as MSYS1) or
MinGW-w64/MSYS2 since MSYS is normally used as a companion to MinGW
and MSYS2 is normally used as a companion to MinGW-w64.

Anyhow, when you start over with TDM I suggest you pick MinGW-w64/MSYS2 from
the get go (and the 64-bit rather than 32-bit version if you are
offered the choice by TDM) to see if that clean version works for you.  And in that
case you must use MSYS2 version of cmake and the "Unix Makefiles" generator.

On the other hand, if you decide to make a clean start with TDM using
MinGW/MSYS from the get go, then in that case you have to use the raw
Windows version of cmake (that you can download from Kitware) and the
"MSYS Makefiles" generator.

I hope that helps to clarify your TDM choices.

Also, note it appears to be a constant problem on Windows that
installation to default areas never works properly because of
overlapping results from other similar but not identical installations
(such as MinGW/MSYS and MinGW-w64/MSYS2) and the inability to clean
out the default install area properly.  Thus, I have long advocated
using separate install prefixes as above.  I don't have a lot of
Windows experience so I am not sure my recommendation is common, but I
do note that the one site I have found
(<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>)
that is the source of the recommendation that you must use the MSYS2
version of CMake and the "Unix Makefiles" generator with
MinGW-w64/MSYS2 _also_ recommends a separate install prefix for
MinGW-w64/MSYS2.  So at least I am not alone in recommending a
separate install prefix!

Alan

P.S. I notice you asked further question in a later e-mail, but I
believe I have answered all of them here.  But if not, please
ask them again in light of the extra information I have given
here.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Fortran input unit conflicts

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

Hi Don,



Well, I am certainly glad that you found the cause. Do not worry about the false alarm: you had every reason to suspect PLplot, as it was a new version. If it had been a problem in PLplot, then we would have liked to find it out ASAP - with the number of components and the number of platforms we are dealing with, something odd is always to be expected.



Regards,



Arjen




From: Spong, Donald A. [mailto:sp...@or...]
Sent: Wednesday, July 15, 2015 5:12 PM
To: Arjen Markus
Cc: plp...@li...
Subject: Re: [Plplot-general] Fortran input unit conflicts

Hi Alan and Arjen,

I've now done some further testing on my I/O problem and am happy to report that it does not seem to be Plplot's problem, but rather a bug in Intel's newest ifort compiler. In answer to your earlier questions, I do use a proper open statement in my Fortran code and I had tried the INQUIRE statement, but was finding every unit number was tied up whenever I tried to link with Plplot. I'm running Mac OS10.10.4 and Intel ifort 16.0.0.

What I recalled was that after installing Plplot 5.11.0, I had successfully compiled and run a Fortran/Plplot code that both opened and read a file and made a plot. However, not long after this I had agreed to be a tester for Intel's newest Parallel Studio 2016 Beta program. I just made the test of reverting back to the previous ifort version 15.0.2 and the code I was having trouble with works fine; when I switch to ifort version 16.0.0 it fails in the way I described. So I will contact Intel and see what they have to say. Using Plplot is about the only place where I mix C and Fortran code, so there must be some bug in their new compiler related to this. Other Fortran-only codes I've tested with their new compiler worked okay.

- Thanks, and sorry for the false alarm,
   Don


On Jul 15, 2015, at 3:54 AM, Arjen Markus <arj...@de...<mailto:arj...@de...>> wrote:

Hi Don,

The problem you report is rather curious - Alan's analysis of the situation seems quite right, but that does not mean we understand what is going on. So in addition to Alan's suggestions:

-        Can you capture the problem in a small sample program?
-        Can you tell us what OS and what compiler you are using?
-        If such a sample program is not feasible, can you use the INQUIRE statement to find out what file logical unit 15 is connected to and with what FORMAT? It would seem that if your combination of C and Fortran compilers is usurping the unit numbers, then this information ought to be available to via Fortran.

I have never encountered this situation before, and the reason that one should not mix C and Fortran I/O to the same file is that the two use their own buffering systems, making it unpredictable how notably the output will be written. That is the aspect I understand - the usurping of units is something entirely new. Nothing in the Fortran bindings for PLplot is doing that.

Regards,

Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 15, 2015 12:57 AM
> To: Spong, Donald A.
> Cc: plp...@li...<mailto:plp...@li...>
> Subject: Re: [Plplot-general] Fortran input unit conflicts
>
> Hi Don:
>
> To add to what I said before, everything I have quickly skimmed on this subject
> recommends all i/o be done at the C level or at the Fortran level, but not both (except
> for stdin, stdout, and stderr which typically are OK to use commonly for both C and
> Fortran).
>
> Of course, that mixture of C and Fortran level i/o is exactly what you need in this
> case since our core C library _must_ do i/o, and you want to do that as well at the
> Fortran level for your own needs.
>
> However, my feeling is that recommendation to not mix i/o from C and Fortran levels
> is just a cop-out so those references don't have to deal with that subject.
>
> It is also implied that the Fortran i/o is implemented on top of the standard C way of
> doing i/o.  If that is correct, _and you are not trying to deal with the same file at both
> the C and Fortran level_, then proper opening of a Fortran file should end up as calls
> to C i/o routines, and I don't see how those calls would interfere with C i/o or vice
> versa unless an attempt is made to use the same C i/o resources, e.g., a file
> descriptor.
>
> So if you are not doing so yet, please use a proper open statement at the fortran
> level for your unit 15.  If you do that, my (perhaps naive
> view) is the C i/o level should know about all the existing i/o resources that are in
> use when it attempts to allocate more resources regardless of whether that C i/o
> level is directly used from C or indirectly used from Fortran.  But in case there is
> some sort of bug there, do you get a different result if you call the fortran open
> routine for unit 15 _before_ you make your first PLplot call versus calling that Fortran
> open routine after that first PLplot call?
>
> 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<http://unifont.org/lasi>); the Loads of Linux Links project (loll . sf . net); and the Linux Brochure
> Project (lbproject . sf . net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that you need to
> offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> hxxps://www.gigenetcloud.com/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...<mailto:Plp...@li...>
> hxxps://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.

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] Problem building 5.11 on Windows 8.1

[Walt B. <wal...@gm...>]

I need another bit of information.

I have mingw (the TDM version) with the compilers,
msys\1.0, msys64 (msys2), and cygwin.

Obviously, the mingw is necessary. Which of the others
should be accessible when running the test?

I think when I compiled 5.10 with gcc 4.9, I had none
of them accessible (except the compilers, of course).

I have a separately installed cmake. But it looks like
Unix-ish utilities are needed for the test script ???

Thanks..

On Mon, Jul 13, 2015 at 6:00 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-07-13 15:55-0700 Walt Brainerd wrote:
>
>  Sorry, I saw all the examples in the shared directory and thought
>> maybe they were not necessary. Try this:
>>
>> http://www.fortran.com/Test1/c_d_t.tgz
>>
>
> Hi Walt:
>
> I was able to download that Test1 report tarball.
>
> Here are my comments on the results in various files in that tarball:
>
> I. comprehensive_test_disposeable/comprehensive_test.sh.out
>
> do_clean_as_you_go=no
>
> The script option
>
> --do_clean_as_you_go no
>
> might have been recommended to you by Arjen, but I suggest that is not
> normally a good idea because once the script works it can consume
> ~40GB of disk data. Thus, I recommend you drop the option above which
> means the recommended default do_clean_as_you_go=yes will be used, i.e.,
> plplot files generated by PLplot will be deleted after each of the 21
> different major tests.
>
> II. comprehensive_test_disposeable/shared/output_tree/cmake.out
>
> -- The C compiler identification is GNU 5.1.0
> -- Check for working C compiler: c:/mingw/bin/gcc.exe
> -- Check for working C compiler: c:/mingw/bin/gcc.exe -- works
> [...]
> -- The CXX compiler identification is GNU 5.1.0
> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
> -- Check for working CXX compiler: c:/mingw/bin/g++.exe -- works
> [...]
> -- The Fortran compiler identification is GNU
> -- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe
> -- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe  -- works
>
> Just to double-check, are those the expected locations and
> identifications for your TDM compilers?
>
> This file also shows many components of PLplot are missing (because
> unlike MSYS2, MSYS has very few of the desired PLplot prerequisites).
> So the list of enabled device drivers is limited to just
> mem;null;ps;svg;wingcc;xfig, and the list of bindings is limited to
> just C++ and Fortran 95.  However, there are no obvious fundamental
> issues in these results so there is no evidence in this file to suggest you
> would not get a clean comprehensive test for this minimal set of
> PLplot components.
>
> III.
> comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out
>
> This is a peculiar result since the script generates it with the
> VERBOSE=1 option, but instead we get terse results.  Furthermore, the
> only error messages I can find in there are
>
> make[5]: *** [examples/test_examples_output_dir/x00c.psc] Error 1
> make[4]: *** [examples/CMakeFiles/test_c_psc.dir/all] Error 2
> make[3]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
> make[2]: *** [test_noninteractive] Error 2
>
> which is not very informative to say the least, but I think that
> is the result of somehow VERBOSE=1 not being set by the script
> or being somehow ignored on your platform.  But before commenting
> further IV should be solved.
>
> IV. Peculiarities of your report tarball
>
> It appears to contain the complete comprehensive_test_disposeable tree
> which is not what you should be reporting.  And within that tarball
> comprehensive_test_disposeable/comprehensive_test_env.out is an empty
> file, and comprehensive_test_disposeable/comprehensive_test.tar.gz is
> completely missing.  Those are both extremely peculiar results.
>
> So please follow these exact instructions for your second try.
>
> # Change to the directory where you have a recently updated master
> # branch version of PLplot.
> cd c:/walt/Software/Plplot/plplot-git
>
> # Run the comprehensive test script with everything default (see
> # comment above) except bypassing ctest (for now) and the interactive part
> of the
> # test (for now).
> scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
> --do_ctest no --do_test_interactive no
>
> copy ../comprehensive_test_disposeable/comprehensive_test.tar.gz (the
> report tarball automatically generated by the script) to your website.
>
> I look forward to those Test2 results.
>
> Assuming you follow those directions precisely so that the Test2 tarball is
> actually generated by the script (as opposed to what appears to be the
> case for the Test1 tarball), we may find that the VERBOSE=1 trouble
> for III goes away so that I can say more about the error in that case.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

[Walt B. <wal...@gm...>]

First, yes, those are the correct compilers:

bash-3.1$ which gfortran
/c/mingw/bin/gfortran.exe
bash-3.1$ gfortran --version
GNU Fortran (tdm64-1) 5.1.0

I tried MSYS2 to see what would happen.
Nothing works--not even git. Says my
version of cygwin.dll is incompatible.
(Incompatible with what? The compilers,
cygwin and msys2 are all the latest 64-bit
version). What is the point of MSYS if
you also have to have Cygwin?

So I deleted Msys2 and reinstalled msys1.

[It looked interesting for progressing with
coarray Fortran as it includes /dev/shm.]

Your test didn't get very far, but here it is:

http://www.fortran.com/Test2/*tar.gz


On Mon, Jul 13, 2015 at 6:00 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-07-13 15:55-0700 Walt Brainerd wrote:
>
>  Sorry, I saw all the examples in the shared directory and thought
>> maybe they were not necessary. Try this:
>>
>> http://www.fortran.com/Test1/c_d_t.tgz
>>
>
> Hi Walt:
>
> I was able to download that Test1 report tarball.
>
> Here are my comments on the results in various files in that tarball:
>
> I. comprehensive_test_disposeable/comprehensive_test.sh.out
>
> do_clean_as_you_go=no
>
> The script option
>
> --do_clean_as_you_go no
>
> might have been recommended to you by Arjen, but I suggest that is not
> normally a good idea because once the script works it can consume
> ~40GB of disk data. Thus, I recommend you drop the option above which
> means the recommended default do_clean_as_you_go=yes will be used, i.e.,
> plplot files generated by PLplot will be deleted after each of the 21
> different major tests.
>
> II. comprehensive_test_disposeable/shared/output_tree/cmake.out
>
> -- The C compiler identification is GNU 5.1.0
> -- Check for working C compiler: c:/mingw/bin/gcc.exe
> -- Check for working C compiler: c:/mingw/bin/gcc.exe -- works
> [...]
> -- The CXX compiler identification is GNU 5.1.0
> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
> -- Check for working CXX compiler: c:/mingw/bin/g++.exe -- works
> [...]
> -- The Fortran compiler identification is GNU
> -- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe
> -- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe  -- works
>
> Just to double-check, are those the expected locations and
> identifications for your TDM compilers?
>
> This file also shows many components of PLplot are missing (because
> unlike MSYS2, MSYS has very few of the desired PLplot prerequisites).
> So the list of enabled device drivers is limited to just
> mem;null;ps;svg;wingcc;xfig, and the list of bindings is limited to
> just C++ and Fortran 95.  However, there are no obvious fundamental
> issues in these results so there is no evidence in this file to suggest you
> would not get a clean comprehensive test for this minimal set of
> PLplot components.
>
> III.
> comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out
>
> This is a peculiar result since the script generates it with the
> VERBOSE=1 option, but instead we get terse results.  Furthermore, the
> only error messages I can find in there are
>
> make[5]: *** [examples/test_examples_output_dir/x00c.psc] Error 1
> make[4]: *** [examples/CMakeFiles/test_c_psc.dir/all] Error 2
> make[3]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
> make[2]: *** [test_noninteractive] Error 2
>
> which is not very informative to say the least, but I think that
> is the result of somehow VERBOSE=1 not being set by the script
> or being somehow ignored on your platform.  But before commenting
> further IV should be solved.
>
> IV. Peculiarities of your report tarball
>
> It appears to contain the complete comprehensive_test_disposeable tree
> which is not what you should be reporting.  And within that tarball
> comprehensive_test_disposeable/comprehensive_test_env.out is an empty
> file, and comprehensive_test_disposeable/comprehensive_test.tar.gz is
> completely missing.  Those are both extremely peculiar results.
>
> So please follow these exact instructions for your second try.
>
> # Change to the directory where you have a recently updated master
> # branch version of PLplot.
> cd c:/walt/Software/Plplot/plplot-git
>
> # Run the comprehensive test script with everything default (see
> # comment above) except bypassing ctest (for now) and the interactive part
> of the
> # test (for now).
> scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
> --do_ctest no --do_test_interactive no
>
> copy ../comprehensive_test_disposeable/comprehensive_test.tar.gz (the
> report tarball automatically generated by the script) to your website.
>
> I look forward to those Test2 results.
>
> Assuming you follow those directions precisely so that the Test2 tarball is
> actually generated by the script (as opposed to what appears to be the
> case for the Test1 tarball), we may find that the VERBOSE=1 trouble
> for III goes away so that I can say more about the error in that case.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Fortran input unit conflicts

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

Hi Alan and Arjen,

I’ve now done some further testing on my I/O problem and am happy to report that it does not seem to be Plplot’s problem, but rather a bug in Intel’s newest ifort compiler. In answer to your earlier questions, I do use a proper open statement in my Fortran code and I had tried the INQUIRE statement, but was finding every unit number was tied up whenever I tried to link with Plplot. I’m running Mac OS10.10.4 and Intel ifort 16.0.0.

What I recalled was that after installing Plplot 5.11.0, I had successfully compiled and run a Fortran/Plplot code that both opened and read a file and made a plot. However, not long after this I had agreed to be a tester for Intel’s newest Parallel Studio 2016 Beta program. I just made the test of reverting back to the previous ifort version 15.0.2 and the code I was having trouble with works fine; when I switch to ifort version 16.0.0 it fails in the way I described. So I will contact Intel and see what they have to say. Using Plplot is about the only place where I mix C and Fortran code, so there must be some bug in their new compiler related to this. Other Fortran-only codes I’ve tested with their new compiler worked okay.

- Thanks, and sorry for the false alarm,
   Don


On Jul 15, 2015, at 3:54 AM, Arjen Markus <arj...@de...<mailto:arj...@de...>> wrote:

Hi Don,

The problem you report is rather curious – Alan’s analysis of the situation seems quite right, but that does not mean we understand what is going on. So in addition to Alan’s suggestions:


-        Can you capture the problem in a small sample program?

-        Can you tell us what OS and what compiler you are using?

-        If such a sample program is not feasible, can you use the INQUIRE statement to find out what file logical unit 15 is connected to and with what FORMAT? It would seem that if your combination of C and Fortran compilers is usurping the unit numbers, then this information ought to be available to via Fortran.


I have never encountered this situation before, and the reason that one should not mix C and Fortran I/O to the same file is that the two use their own buffering systems, making it unpredictable how notably the output will be written. That is the aspect I understand – the usurping of units is something entirely new. Nothing in the Fortran bindings for PLplot is doing that.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 15, 2015 12:57 AM
> To: Spong, Donald A.
> Cc: plp...@li...<mailto:plp...@li...>
> Subject: Re: [Plplot-general] Fortran input unit conflicts
>
> Hi Don:
>
> To add to what I said before, everything I have quickly skimmed on this subject
> recommends all i/o be done at the C level or at the Fortran level, but not both (except
> for stdin, stdout, and stderr which typically are OK to use commonly for both C and
> Fortran).
>
> Of course, that mixture of C and Fortran level i/o is exactly what you need in this
> case since our core C library _must_ do i/o, and you want to do that as well at the
> Fortran level for your own needs.
>
> However, my feeling is that recommendation to not mix i/o from C and Fortran levels
> is just a cop-out so those references don't have to deal with that subject.
>
> It is also implied that the Fortran i/o is implemented on top of the standard C way of
> doing i/o.  If that is correct, _and you are not trying to deal with the same file at both
> the C and Fortran level_, then proper opening of a Fortran file should end up as calls
> to C i/o routines, and I don't see how those calls would interfere with C i/o or vice
> versa unless an attempt is made to use the same C i/o resources, e.g., a file
> descriptor.
>
> So if you are not doing so yet, please use a proper open statement at the fortran
> level for your unit 15.  If you do that, my (perhaps naive
> view) is the C i/o level should know about all the existing i/o resources that are in
> use when it attempts to allocate more resources regardless of whether that C i/o
> level is directly used from C or indirectly used from Fortran.  But in case there is
> some sort of bug there, do you get a different result if you call the fortran open
> routine for unit 15 _before_ you make your first PLplot call versus calling that Fortran
> open routine after that first PLplot call?
>
> 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<http://unifont.org/lasi>); the Loads of Linux Links project (loll . sf . net); and the Linux Brochure
> Project (lbproject . sf . net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that you need to
> offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> hxxps://www.gigenetcloud.com/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...<mailto:Plp...@li...>
> hxxps://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] Fortran input unit conflicts

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

Hi Don,



The problem you report is rather curious - Alan's analysis of the situation seems quite right, but that does not mean we understand what is going on. So in addition to Alan's suggestions:



-        Can you capture the problem in a small sample program?

-        Can you tell us what OS and what compiler you are using?

-        If such a sample program is not feasible, can you use the INQUIRE statement to find out what file logical unit 15 is connected to and with what FORMAT? It would seem that if your combination of C and Fortran compilers is usurping the unit numbers, then this information ought to be available to via Fortran.



I have never encountered this situation before, and the reason that one should not mix C and Fortran I/O to the same file is that the two use their own buffering systems, making it unpredictable how notably the output will be written. That is the aspect I understand - the usurping of units is something entirely new. Nothing in the Fortran bindings for PLplot is doing that.



Regards,



Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 15, 2015 12:57 AM
> To: Spong, Donald A.
> Cc: plp...@li...
> Subject: Re: [Plplot-general] Fortran input unit conflicts
>
> Hi Don:
>
> To add to what I said before, everything I have quickly skimmed on this subject
> recommends all i/o be done at the C level or at the Fortran level, but not both (except
> for stdin, stdout, and stderr which typically are OK to use commonly for both C and
> Fortran).
>
> Of course, that mixture of C and Fortran level i/o is exactly what you need in this
> case since our core C library _must_ do i/o, and you want to do that as well at the
> Fortran level for your own needs.
>
> However, my feeling is that recommendation to not mix i/o from C and Fortran levels
> is just a cop-out so those references don't have to deal with that subject.
>
> It is also implied that the Fortran i/o is implemented on top of the standard C way of
> doing i/o.  If that is correct, _and you are not trying to deal with the same file at both
> the C and Fortran level_, then proper opening of a Fortran file should end up as calls
> to C i/o routines, and I don't see how those calls would interfere with C i/o or vice
> versa unless an attempt is made to use the same C i/o resources, e.g., a file
> descriptor.
>
> So if you are not doing so yet, please use a proper open statement at the fortran
> level for your unit 15.  If you do that, my (perhaps naive
> view) is the C i/o level should know about all the existing i/o resources that are in
> use when it attempts to allocate more resources regardless of whether that C i/o
> level is directly used from C or indirectly used from Fortran.  But in case there is
> some sort of bug there, do you get a different result if you call the fortran open
> routine for unit 15 _before_ you make your first PLplot call versus calling that Fortran
> open routine after that first PLplot call?
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that you need to
> offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> 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] Fortran input unit conflicts

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

Hi Don:

To add to what I said before, everything I have quickly skimmed on
this subject recommends all i/o be done at the C level or at the
Fortran level, but not both (except for stdin, stdout, and stderr
which typically are OK to use commonly for both C and Fortran).

Of course, that mixture of C and Fortran level i/o is exactly what you
need in this case since our core C library _must_ do i/o, and you want
to do that as well at the Fortran level for your own needs.

However, my feeling is that recommendation to not mix i/o from C and
Fortran levels is just a cop-out so those references don't have to
deal with that subject.

It is also implied that the Fortran i/o is implemented on top of the
standard C way of doing i/o.  If that is correct, _and you are not
trying to deal with the same file at both the C and Fortran level_,
then proper opening of a Fortran file should end up as calls to C i/o
routines, and I don't see how those calls would interfere with C i/o
or vice versa unless an attempt is made to use the same C i/o
resources, e.g., a file descriptor.

So if you are not doing so yet, please use a proper open statement at
the fortran level for your unit 15.  If you do that, my (perhaps naive
view) is the C i/o level should know about all the existing i/o
resources that are in use when it attempts to allocate more resources
regardless of whether that C i/o level is directly used from C or
indirectly used from Fortran.  But in case there is some sort of bug
there, do you get a different result if you call the fortran open
routine for unit 15 _before_ you make your first PLplot call versus
calling that Fortran open routine after that first PLplot call?

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] Fortran input unit conflicts

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

On 2015-07-14 18:34-0000 Spong, Donald A. wrote:

> I recently upgraded to Plplot 5.11.0. If I use Plplot from within a
Fortran 90 code that tries to open a formatted file and read from it,
I get an error upon execution:

> forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 15, file /Users/dsp/fortran_code_development/taeflseab/MVanZeeland_ECH_2015/modeling_inputs_157737_t470.txt
> Image              PC                Routine            Line        Source
> libplplotf95.12.d  0000000109393DDC  Unknown               Unknown  Unknown
> xmvz-read          0000000109323889  Unknown               Unknown  Unknown
> xmvz-read          0000000109320A4B  Unknown               Unknown  Unknown
> xmvz-read          000000010932051E  Unknown               Unknown  Unknown
>

> If I change the unit number from 15 to something else I still get
the error. If I comment out the Plplot calls and compile without
Plplot, the error goes away. It’s acting as if Plplot has occupied all
available I/O units and declared them to be unformatted. How do I fix
this?

Hi Don:

The answer depends on whether this is a regression we have recently
introduced or a long-standing characteristic of our Fortran binding
(or more likely our core C library which is interfaced by that binding
since I believe all the PLplot I/O is done by our core C library).

So to help us formulate that answer, do you get similar problems for
the previous PLplot release (5.10.0) or not?

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] Fortran input unit conflicts

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

I recently upgraded to Plplot 5.11.0. If I use Plplot from within a Fortran 90 code that tries to open a formatted file and read from it, I get an error upon execution:

forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 15, file /Users/dsp/fortran_code_development/taeflseab/MVanZeeland_ECH_2015/modeling_inputs_157737_t470.txt
Image              PC                Routine            Line        Source             
libplplotf95.12.d  0000000109393DDC  Unknown               Unknown  Unknown
xmvz-read          0000000109323889  Unknown               Unknown  Unknown
xmvz-read          0000000109320A4B  Unknown               Unknown  Unknown
xmvz-read          000000010932051E  Unknown               Unknown  Unknown

If I change the unit number from 15 to something else I still get the error. If I comment out the Plplot calls and compile without Plplot, the error goes away. It’s acting as if Plplot has occupied all available I/O units and declared them to be unformatted. How do I fix this?

- Thanks, Don

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

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

On 2015-07-13 15:55-0700 Walt Brainerd wrote:

> Sorry, I saw all the examples in the shared directory and thought
> maybe they were not necessary. Try this:
>
> http://www.fortran.com/Test1/c_d_t.tgz

Hi Walt:

I was able to download that Test1 report tarball.

Here are my comments on the results in various files in that tarball:

I. comprehensive_test_disposeable/comprehensive_test.sh.out

do_clean_as_you_go=no

The script option

--do_clean_as_you_go no

might have been recommended to you by Arjen, but I suggest that is not
normally a good idea because once the script works it can consume
~40GB of disk data. Thus, I recommend you drop the option above which
means the recommended default do_clean_as_you_go=yes will be used, i.e.,
plplot files generated by PLplot will be deleted after each of the 21
different major tests.

II. comprehensive_test_disposeable/shared/output_tree/cmake.out

-- The C compiler identification is GNU 5.1.0
-- Check for working C compiler: c:/mingw/bin/gcc.exe
-- Check for working C compiler: c:/mingw/bin/gcc.exe -- works
[...]
-- The CXX compiler identification is GNU 5.1.0
-- Check for working CXX compiler: c:/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/mingw/bin/g++.exe -- works
[...]
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe
-- Check for working Fortran compiler: c:/mingw/bin/gfortran.exe  -- works

Just to double-check, are those the expected locations and
identifications for your TDM compilers?

This file also shows many components of PLplot are missing (because
unlike MSYS2, MSYS has very few of the desired PLplot prerequisites).
So the list of enabled device drivers is limited to just
mem;null;ps;svg;wingcc;xfig, and the list of bindings is limited to
just C++ and Fortran 95.  However, there are no obvious fundamental
issues in these results so there is no evidence in this file to suggest you
would not get a clean comprehensive test for this minimal set of
PLplot components.

III. comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out

This is a peculiar result since the script generates it with the
VERBOSE=1 option, but instead we get terse results.  Furthermore, the
only error messages I can find in there are

make[5]: *** [examples/test_examples_output_dir/x00c.psc] Error 1
make[4]: *** [examples/CMakeFiles/test_c_psc.dir/all] Error 2
make[3]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
make[2]: *** [test_noninteractive] Error 2

which is not very informative to say the least, but I think that
is the result of somehow VERBOSE=1 not being set by the script
or being somehow ignored on your platform.  But before commenting
further IV should be solved.

IV. Peculiarities of your report tarball

It appears to contain the complete comprehensive_test_disposeable tree
which is not what you should be reporting.  And within that tarball
comprehensive_test_disposeable/comprehensive_test_env.out is an empty
file, and comprehensive_test_disposeable/comprehensive_test.tar.gz is
completely missing.  Those are both extremely peculiar results.

So please follow these exact instructions for your second try.

# Change to the directory where you have a recently updated master
# branch version of PLplot.
cd c:/walt/Software/Plplot/plplot-git

# Run the comprehensive test script with everything default (see
# comment above) except bypassing ctest (for now) and the interactive part of the
# test (for now).
scripts/comprehensive_test.sh --generator_string "MSYS Makefiles" --do_ctest no --do_test_interactive no

copy ../comprehensive_test_disposeable/comprehensive_test.tar.gz (the
report tarball automatically generated by the script) to your website.

I look forward to those Test2 results.

Assuming you follow those directions precisely so that the Test2 tarball is
actually generated by the script (as opposed to what appears to be the
case for the Test1 tarball), we may find that the VERBOSE=1 trouble
for III goes away so that I can say more about the error in that case.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

[Walt B. <wal...@gm...>]

Sorry, I saw all the examples in the shared directory and thought
maybe they were not necessary. Try this:

http://www.fortran.com/Test1/c_d_t.tgz

And I thought maybe the reason for the problem with the DLL
might be 32 vs 64 bits ??? But I will just leave it to you experts.

The compilers in the MinGW (TDM) I used are 64 bits.

Please let me know if you can't get the tgz file. Thanks.

On Mon, Jul 13, 2015 at 2:30 PM, Alan W. Irwin <ir...@be...>
wrote:

> Walt said:
>
> ===================================
> Here are my attempts to run the test as you requested.
>
> Just to get all the facts:
>
> The TDM version of Mingw is in C:\mingw.
> It includes gcc version 5.1.
>
> Msys is in C:\msys\1.0--the MSYS web site implied this
> was not the latest, but I couldn't find anything else.
>
> I enclose the test output with the directory "shared" removed.
> OW my mail wouldn't let me attach the tgz result.
>
> How do I install libplplot.dll if I can't build plplot?
>
> There may simply be too many things different, especially gcc 4.9 vs
> 5.1,
> but I will keep trying things if it will help you improve Plplot.
> ===================================
>
> Hi Walt:
>
> Just to interject here, I believe Orion Poplaski (who extensively
> tests PLplot on Fedora) has largely had success with gcc-5.x, but I
> also recall there was at least one component of PLplot that had to be
> avoided.  Anyhow, with some care I am pretty sure gcc-5.1 will not be
> a problem for you.
>
> Since Arjen is getting good comprehensive test results for
> MinGW-w64/MSYS2 (and also MinGW/MSYS), I am pretty sure that such
> success for TDM cannot be that far away, and your comprehensive test
> results for that platform should indeed help us to diagnose and fix
> (or workaround) whatever small problems that are keeping you from the
> expected success on that platform.
>
> But to make that happens it is essential that you figure out a way to
> communicate the complete comprehensive_test.tar.gz that is generated
> by the script to us.  For example, that missing shared directory in
> your present report tarball contains absolutely essential information
> that helps us debug the error you encountered and if we cannot do that
> in a timely manner also allows us to give you good advice about how to
> workaround that error (say by disabling some component of PLplot).
>
> So please try a mailer without the restriction of disallowing
> subdirectories in outgoing tarball attachments or if you do not have
> access to such a mailer, please post comprehensive_test.tar.gz to a
> website where we can download it for ourselves.  If you decide to use
> the website alternative, each of your report tarballs should be
> located in a directory on your website with a unique name (such as
> "test1", "test2", etc.) so you, Arjen, and I will all know which
> of your report tarballs we are discussing here.
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

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

Walt said:

===================================
Here are my attempts to run the test as you requested.

Just to get all the facts:

The TDM version of Mingw is in C:\mingw.
It includes gcc version 5.1.

Msys is in C:\msys\1.0--the MSYS web site implied this
was not the latest, but I couldn't find anything else.

I enclose the test output with the directory "shared" removed.
OW my mail wouldn't let me attach the tgz result.

How do I install libplplot.dll if I can't build plplot?

There may simply be too many things different, especially gcc 4.9 vs
5.1,
but I will keep trying things if it will help you improve Plplot.
===================================

Hi Walt:

Just to interject here, I believe Orion Poplaski (who extensively
tests PLplot on Fedora) has largely had success with gcc-5.x, but I
also recall there was at least one component of PLplot that had to be
avoided.  Anyhow, with some care I am pretty sure gcc-5.1 will not be
a problem for you.

Since Arjen is getting good comprehensive test results for
MinGW-w64/MSYS2 (and also MinGW/MSYS), I am pretty sure that such
success for TDM cannot be that far away, and your comprehensive test
results for that platform should indeed help us to diagnose and fix
(or workaround) whatever small problems that are keeping you from the
expected success on that platform.

But to make that happens it is essential that you figure out a way to
communicate the complete comprehensive_test.tar.gz that is generated
by the script to us.  For example, that missing shared directory in
your present report tarball contains absolutely essential information
that helps us debug the error you encountered and if we cannot do that
in a timely manner also allows us to give you good advice about how to
workaround that error (say by disabling some component of PLplot).

So please try a mailer without the restriction of disallowing
subdirectories in outgoing tarball attachments or if you do not have
access to such a mailer, please post comprehensive_test.tar.gz to a
website where we can download it for ourselves.  If you decide to use
the website alternative, each of your report tarballs should be
located in a directory on your website with a unique name (such as
"test1", "test2", etc.) so you, Arjen, and I will all know which
of your report tarballs we are discussing here.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

[Walt B. <wal...@gm...>]

Here are my attempts to run the test as you requested.

Just to get all the facts:

The TDM version of Mingw is in C:\mingw.
It includes gcc version 5.1.

Msys is in C:\msys\1.0--the MSYS web site implied this
was not the latest, but I couldn't find anything else.

I enclose the test output with the directory "shared" removed.
OW my mail wouldn't let me attach the tgz result.

How do I install libplplot.dll if I can't build plplot?

There may simply be too many things different, especially gcc 4.9 vs 5.1,
but I will keep trying things if it will help you improve Plplot.

BTW, I tried a build with MSYS instead of MINGW Makefiles for the first
time before running the test and got pretty much the same results as before.

[image: Inline image 1]



On Mon, Jul 13, 2015 at 11:15 AM, Arjen Markus <Arj...@de...>
wrote:

>  Hi Walt,
>
>
>
> As Alan suggested off-list, it might be a good idea to run the
> comprehensive_test.sh script yourself and send me and Alan the resulting
> tarball. Here is the script I use to get it going:
>
>
> export PATH=/d/cmake/bin:$PATH
>
>
>
> # Generate all script results in ../comprehensive_test_disposeable
>
> ../plplot-git/scripts/comprehensive_test.sh
> --do_test_traditional_install_tree no --do_test_interactive no --do_ctest
> no --generator_string "MSYS Makefiles" --build_command make --ctest_command
> ctest --do_clean_as_you_go no --cmake_added_options "-DENABLE_tcl=OFF"
> --do_shared yes --do_nondynamic yes
>
>
>
> The command line is longer than it actually needs to be (it has gathered a
> lot of cruft over the various iterations), but I have it stored in a small
> shell script for easy use.
>
>
>
> The output is gathered in a concise tarball in the
> comprehensive_test_disposeable directory. It is called
>
> “comprehensive_test.tar.gz”.
>
>
>
> The nice thing about this script, besides being an automatic test of
> various build options (you only need to confirm that you want to run it,
> because it will throw away anything in the test directory), is that it
> collects as much information as could be relevant from the environment.
> That will save us some time ;).
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>
>
> *From:* Arjen Markus
> *Sent:* Monday, July 13, 2015 1:18 PM
> *To:* Arjen Markus; Walt Brainerd
> *Cc:* plplot_general
> *Subject:* RE: [Plplot-general] Problem building 5.11 on Windows 8.1
>
>
>
> Hi Walt,
>
>
>
> The link problem with Fortran under MinGW I reported is solved – it turned
> out that the condition to include the .def file in the link step was
> incomplete. With that fixed it works all fine now. For this I have tested
> the build options covered by the comprehensive test script, using the GCC
> compiler suite that comes with MSYS2.
>
>
>
> Now, since you have problems with theTDM version of the GCC suite, can you
> tell me how the make process fails? What are the error messages? It seems
> strange that it would succeed after several retries – it would almost seem
> that some dependencies are not handled correctly. Or perhaps there is a
> problem with parallel builds? I have done my tests with a single-threaded
> make command.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Arjen Markus [mailto:Arj...@de...
> <Arj...@de...>]
> *Sent:* Monday, July 13, 2015 10:35 AM
> *To:* Walt Brainerd
> *Cc:* plplot_general
> *Subject:* Re: [Plplot-general] Problem building 5.11 on Windows 8.1
>
>
>
> Hi Walt,
>
>
>
> I had to reinstall MinGW 64-bits, as indeed it was hardly useable. I have
> done so by installing MSYS2 as recommended by Alan. Now I see problems with
> the .def file for the Fortran libraries – it has to do with the calling
> convention (stdcall versus cdecl and that sort of fun stuff). Is that the
> sort of failures you have been seeing? Here is a small fragment:
>
> Cannot export _PLPARSEOPTS@4: symbol not defined
>
> Cannot export _PLPLOTP_mp_PLAXES@40: symbol not defined
>
> Cannot export _PLPLOTP_mp_PLBOX3@72: symbol not defined
>
> Cannot export _PLPLOTP_mp_PLBOX@32: symbol not defined
>
> Cannot export _PLPLOTP_mp_PLCOLORBAR_1@96: symbol not defined
>
>
>
> It is not all that difficult to repair, but it has to be done, otherwise
> the shared library option won’t work.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* Walt Brainerd [mailto:wal...@gm...
> <wal...@gm...>]
> *Sent:* Friday, July 10, 2015 9:27 PM
> *To:* Arjen Markus
> *Cc:* plplot_general
> *Subject:* Re: [Plplot-general] Problem building 5.11 on Windows 8.1
>
>
>
> Alan: mingw-64 etc. does not yet include gcc 5.1;
>
> that is why I am using the TDM version.
>
>
>
> Arjen: with the new version, plplot builds (the static
>
> library version), but when I run it, I get all kinds of
>
> errors about missing routines of the form __imp*.
>
> being called from wingcc (for example).
>
>
>
> So I tried the DLL version (which is what I think I
>
> was successful with before). make was strange.
>
> I would get an error, then try it again. It got further
>
> before getting another error. After about 5-6 tries
>
> it went all the way.
>
>
>
> Trying to compile a code then produced an error
>
> trying to load wingcc.dll. Windows says it isn't
>
> suitable to run on Windows; in a bash shell, it
>
> just says there is an error loading wingcc.dll.
>
>
>
> Any other suggestions?
>
>
>
> On Fri, Jul 10, 2015 at 2:14 AM, Arjen Markus <Arj...@de...>
> wrote:
>
> Hi Walt,
>
>
>
> I just completed the set of comprehensive tests and committed the small
> patch I had to make for the access() function. With this latest version it
> ought to work for you too.
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Arjen Markus [mailto:Arj...@de...]
> *Sent:* Friday, July 10, 2015 10:37 AM
> *To:* Walt Brainerd; plplot_general
> *Subject:* Re: [Plplot-general] Problem building 5.11 on Windows 8.1
>
>
>
> Hi Walt,
>
>
>
> I am trying this myself – using the comprehensive tests script under MSYS
> – and I ran into the same issue. It seems that the logic for including the
> header file unistd.h is incomplete or incorrect as far as MinGW is
> concerned. I have changed this in my own repository to:
>
>
>
>
>
> #include "plConfig.h"
>
> #if !PL_HAVE_UNISTD_H
>
>   #define F_OK    1
>
>   #include <stdio.h>
>
> int access( char *filename, int flag )
>
>
>
> and that is doing the trick as far as the build up to now is concerned. If
> successful, I will contribute this.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Walt Brainerd [mailto:wal...@gm...]
> *Sent:* Friday, July 10, 2015 1:25 AM
> *To:* plplot_general
> *Subject:* [Plplot-general] Problem building 5.11 on Windows 8.1
>
>
>
> I have the TDM version of MinGW installed.
>
>
>
> C:\Users\Walt>gfortran --version
>
> GNU Fortran (tdm64-1) 5.1.0
>
> Copyright (C) 2015 Free Software Foundation, Inc.
>
>
>
> I downloaded 5.11.0 using git and built with the following
>
> (all one line, of course):
>
>
>
> cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install
>
> -DBUILD_SHARED_LIBS=OFF -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON
>
> -DENABLE_f95=ON -DDEFAULT_ALL_DEVICES=ON ../plplot.git
>
>
>
> [Something different: I got a lot more devices and drivers.]
>
>
>
> Make produces the following:
>
>
>
> C:\walt\Software\Plplot\BUILD>make
>
> [  0%] Built target csirocsa
>
> [  3%] Built target deltaT-gen
>
> [  4%] Built target deltaT.h_built
>
> [  6%] Built target tai-utc-gen
>
> [  7%] Built target tai-utc.h_built
>
> [ 10%] Built target qsastime
>
> [ 12%] Built target nistcd
>
> [ 12%] Built target cdexpert
>
> [ 13%] Built target cdmulti
>
> [ 15%] Built target cdsimple
>
> [ 16%] Built target cdtest
>
> [ 18%] Built target cdtext
>
> [ 18%] Built target color16
>
> [ 26%] Built target test_nistcd
>
> [ 26%] Built target plhershey-unicode-gen
>
> [ 27%] Built target plhershey-unicode.h_built
>
> [ 29%] Building C object src/CMakeFiles/plplot.dir/plfreetype.c.obj
>
> In file included from
> C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/unistd.h:10:0,
>
>                  from
> C:/walt/Software/Plplot/plplot.git/include/plplotP.h:110,
>
>                  from
> C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:
>
> C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/io.h:310:15: error:
> conflicting types for 'access'
>
>    int __cdecl access(const char *_Filename,int _AccessMode)
> __MINGW_ATTRIB_DEPRECATED_MSVC2005;
>
>                ^
>
> C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:69:5: note: previous
> definition of 'access' was here
>
>  int access( char *filename, int flag )
>
>      ^
>
> In file included from
> C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:0:
>
> C:/walt/Software/Plplot/plplot.git/include/plplotP.h:252:0: warning:
> "isfinite" redefined
>
>  #  define isfinite    finite
>
>  ^
>
> In file included from
> C:/walt/Software/Plplot/plplot.git/include/plplotP.h:105:0,
>
>                  from
> C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:
>
> C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/math.h:520:0: note:
> this is the location of the previous definition
>
>  #define isfinite(x) ((fpclassify(x) & FP_NAN) == 0)
>
>  ^
>
> src\CMakeFiles\plplot.dir\build.make:366: recipe for target
> 'src/CMakeFiles/plplot.dir/plfreetype.c.obj' failed
>
> make[2]: *** [src/CMakeFiles/plplot.dir/plfreetype.c.obj] Error 1
>
> CMakeFiles\Makefile2:798: recipe for target
> 'src/CMakeFiles/plplot.dir/all' failed
>
> make[1]: *** [src/CMakeFiles/plplot.dir/all] Error 2
>
> Makefile:135: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
>
>
> To me, the first one (access) looks like a conflict between gcc and plplot.
>
> The second (isfinite) is a conflict between two things in Plplot???
>
>
>
> Help please?  Thanks.
>
>
>
>
>
> --
>
> Walt Brainerd
>
> 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.
>
>
>
>
>
> --
>
> Walt Brainerd
>
> 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.
>



-- 
Walt Brainerd

Re: [Plplot-general] Problem building 5.11 on Windows 8.1

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

Hi Walt,



As Alan suggested off-list, it might be a good idea to run the comprehensive_test.sh script yourself and send me and Alan the resulting tarball. Here is the script I use to get it going:

export PATH=/d/cmake/bin:$PATH

# Generate all script results in ../comprehensive_test_disposeable
../plplot-git/scripts/comprehensive_test.sh --do_test_traditional_install_tree no --do_test_interactive no --do_ctest no --generator_string "MSYS Makefiles" --build_command make --ctest_command ctest --do_clean_as_you_go no --cmake_added_options "-DENABLE_tcl=OFF" --do_shared yes --do_nondynamic yes

The command line is longer than it actually needs to be (it has gathered a lot of cruft over the various iterations), but I have it stored in a small shell script for easy use.

The output is gathered in a concise tarball in the comprehensive_test_disposeable directory. It is called
"comprehensive_test.tar.gz".

The nice thing about this script, besides being an automatic test of various build options (you only need to confirm that you want to run it, because it will throw away anything in the test directory), is that it collects as much information as could be relevant from the environment. That will save us some time ;).

Regards,

Arjen



From: Arjen Markus
Sent: Monday, July 13, 2015 1:18 PM
To: Arjen Markus; Walt Brainerd
Cc: plplot_general
Subject: RE: [Plplot-general] Problem building 5.11 on Windows 8.1


Hi Walt,



The link problem with Fortran under MinGW I reported is solved - it turned out that the condition to include the .def file in the link step was incomplete. With that fixed it works all fine now. For this I have tested the build options covered by the comprehensive test script, using the GCC compiler suite that comes with MSYS2.



Now, since you have problems with theTDM version of the GCC suite, can you tell me how the make process fails? What are the error messages? It seems strange that it would succeed after several retries - it would almost seem that some dependencies are not handled correctly. Or perhaps there is a problem with parallel builds? I have done my tests with a single-threaded make command.



Regards,



Arjen


From: Arjen Markus [mailto:Arj...@de...]
Sent: Monday, July 13, 2015 10:35 AM
To: Walt Brainerd
Cc: plplot_general
Subject: Re: [Plplot-general] Problem building 5.11 on Windows 8.1


Hi Walt,



I had to reinstall MinGW 64-bits, as indeed it was hardly useable. I have done so by installing MSYS2 as recommended by Alan. Now I see problems with the .def file for the Fortran libraries - it has to do with the calling convention (stdcall versus cdecl and that sort of fun stuff). Is that the sort of failures you have been seeing? Here is a small fragment:

Cannot export _PLPARSEOPTS@4: symbol not defined

Cannot export _PLPLOTP_mp_PLAXES@40: symbol not defined

Cannot export _PLPLOTP_mp_PLBOX3@72: symbol not defined

Cannot export _PLPLOTP_mp_PLBOX@32: symbol not defined

Cannot export _PLPLOTP_mp_PLCOLORBAR_1@96: symbol not defined



It is not all that difficult to repair, but it has to be done, otherwise the shared library option won't work.



Regards,



Arjen

From: Walt Brainerd [mailto:wal...@gm...]
Sent: Friday, July 10, 2015 9:27 PM
To: Arjen Markus
Cc: plplot_general
Subject: Re: [Plplot-general] Problem building 5.11 on Windows 8.1

Alan: mingw-64 etc. does not yet include gcc 5.1;
that is why I am using the TDM version.

Arjen: with the new version, plplot builds (the static
library version), but when I run it, I get all kinds of
errors about missing routines of the form __imp*.
being called from wingcc (for example).

So I tried the DLL version (which is what I think I
was successful with before). make was strange.
I would get an error, then try it again. It got further
before getting another error. After about 5-6 tries
it went all the way.

Trying to compile a code then produced an error
trying to load wingcc.dll. Windows says it isn't
suitable to run on Windows; in a bash shell, it
just says there is an error loading wingcc.dll.

Any other suggestions?

On Fri, Jul 10, 2015 at 2:14 AM, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:

Hi Walt,



I just completed the set of comprehensive tests and committed the small patch I had to make for the access() function. With this latest version it ought to work for you too.

Regards,

Arjen


From: Arjen Markus [mailto:Arj...@de...<mailto:Arj...@de...>]
Sent: Friday, July 10, 2015 10:37 AM
To: Walt Brainerd; plplot_general
Subject: Re: [Plplot-general] Problem building 5.11 on Windows 8.1


Hi Walt,



I am trying this myself - using the comprehensive tests script under MSYS - and I ran into the same issue. It seems that the logic for including the header file unistd.h is incomplete or incorrect as far as MinGW is concerned. I have changed this in my own repository to:



#include "plConfig.h"
#if !PL_HAVE_UNISTD_H
  #define F_OK    1
  #include <stdio.h>
int access( char *filename, int flag )


and that is doing the trick as far as the build up to now is concerned. If successful, I will contribute this.



Regards,



Arjen


From: Walt Brainerd [mailto:wal...@gm...<mailto:wal...@gm...>]
Sent: Friday, July 10, 2015 1:25 AM
To: plplot_general
Subject: [Plplot-general] Problem building 5.11 on Windows 8.1

I have the TDM version of MinGW installed.

C:\Users\Walt>gfortran --version
GNU Fortran (tdm64-1) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.

I downloaded 5.11.0 using git and built with the following
(all one line, of course):

cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install
-DBUILD_SHARED_LIBS=OFF -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON
-DENABLE_f95=ON -DDEFAULT_ALL_DEVICES=ON ../plplot.git

[Something different: I got a lot more devices and drivers.]

Make produces the following:

C:\walt\Software\Plplot\BUILD>make
[  0%] Built target csirocsa
[  3%] Built target deltaT-gen
[  4%] Built target deltaT.h_built
[  6%] Built target tai-utc-gen
[  7%] Built target tai-utc.h_built
[ 10%] Built target qsastime
[ 12%] Built target nistcd
[ 12%] Built target cdexpert
[ 13%] Built target cdmulti
[ 15%] Built target cdsimple
[ 16%] Built target cdtest
[ 18%] Built target cdtext
[ 18%] Built target color16
[ 26%] Built target test_nistcd
[ 26%] Built target plhershey-unicode-gen
[ 27%] Built target plhershey-unicode.h_built
[ 29%] Building C object src/CMakeFiles/plplot.dir/plfreetype.c.obj
In file included from C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/unistd.h:10:0,
                 from C:/walt/Software/Plplot/plplot.git/include/plplotP.h:110,
                 from C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:
C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/io.h:310:15: error: conflicting types for 'access'
   int __cdecl access(const char *_Filename,int _AccessMode) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
               ^
C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:69:5: note: previous definition of 'access' was here
 int access( char *filename, int flag )
     ^
In file included from C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:0:
C:/walt/Software/Plplot/plplot.git/include/plplotP.h:252:0: warning: "isfinite" redefined
 #  define isfinite    finite
 ^
In file included from C:/walt/Software/Plplot/plplot.git/include/plplotP.h:105:0,
                 from C:\walt\Software\Plplot\plplot.git\src\plfreetype.c:90:
C:/Fortran_Tools/gfortran/x86_64-w64-mingw32/include/math.h:520:0: note: this is the location of the previous definition
 #define isfinite(x) ((fpclassify(x) & FP_NAN) == 0)
 ^
src\CMakeFiles\plplot.dir\build.make:366: recipe for target 'src/CMakeFiles/plplot.dir/plfreetype.c.obj' failed
make[2]: *** [src/CMakeFiles/plplot.dir/plfreetype.c.obj] Error 1
CMakeFiles\Makefile2:798: recipe for target 'src/CMakeFiles/plplot.dir/all' failed
make[1]: *** [src/CMakeFiles/plplot.dir/all] Error 2
Makefile:135: recipe for target 'all' failed
make: *** [all] Error 2

To me, the first one (access) looks like a conflict between gcc and plplot.
The second (isfinite) is a conflict between two things in Plplot???

Help please?  Thanks.


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



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