Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Status of PGi
1,121 views
Skip to first unread message
JRR
Sep 15, 2019, 9:59:23 AM9/15/19
to
After some extended exchange with the support of the PGI team, I stay
rather frustrated. My estimate is that the compiler has ca. 70 % of the
capabilities of gfortran, ifort and NAG. It took several years before
the compiler compiled our code at all, and now it is full of run time
errors. Starting to deliver reproducers is a heroic task, as the
compiler compiles insanely slow, and the team seems not to be able to
run their tools from our full code. From this I estimate that PGI could
be at the today level of gfortran and ifort (our main compilers) in ca.
2030, because I have to go case by case, wait until things are fixed,
and then go to the next problem. Any advice is highly appreciated.
--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
------------------------------------
invalid is desy .and. com is de
rather frustrated. My estimate is that the compiler has ca. 70 % of the
capabilities of gfortran, ifort and NAG. It took several years before
the compiler compiled our code at all, and now it is full of run time
errors. Starting to deliver reproducers is a heroic task, as the
compiler compiles insanely slow, and the team seems not to be able to
run their tools from our full code. From this I estimate that PGI could
be at the today level of gfortran and ifort (our main compilers) in ca.
2030, because I have to go case by case, wait until things are fixed,
and then go to the next problem. Any advice is highly appreciated.
--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
------------------------------------
invalid is desy .and. com is de
steve kargl
Sep 15, 2019, 11:28:13 AM9/15/19
to
JRR wrote:
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
I stopped trying to use PGI's Fortran compiler years ago. Your
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
current experience with PGI mirrors what I recall. Back then I
had access to DEC Fortran an NAG. Fortunately, Andy Vaught
released the g95 frontend, and Steven Bosscher and Paul Brook
integrated that frontend into GCC.
--
steve
Gary Scott
Sep 15, 2019, 12:21:14 PM9/15/19
to
On 9/15/2019 8:59 AM, JRR wrote:
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
>
>
When Lahey fell behind, I investigated PGI. I could tell immediately
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
>
>
from reading their documentation that it was just not going to be
suitable. I'm always surprised when people choose it. While I always
maintained the MSFPS, DEC, CVF, IVF lineage, I had secondary installs of
Absoft and Lahey. I found neither of those suitable either because I
have extensive OS API entanglement and limited or arcane support for OS
calls or tweaking (contorting) the call convention. I suppose if your
code is 100% Fortran, these fare better, but that's a tiny fraction of
the need.
JRR
Sep 15, 2019, 12:51:57 PM9/15/19
to
On 15.09.19 17:28, steve kargl wrote:
>
> I stopped trying to use PGI's Fortran compiler years ago. Your
> current experience with PGI mirrors what I recall. Back then I
> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
> released the g95 frontend, and Steven Bosscher and Paul Brook
> integrated that frontend into GCC.
>
Of course, with gfortran, ifort and NAG available, one could ask
>
> I stopped trying to use PGI's Fortran compiler years ago. Your
> current experience with PGI mirrors what I recall. Back then I
> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
> released the g95 frontend, and Steven Bosscher and Paul Brook
> integrated that frontend into GCC.
>
the question: why is it important to support or investigate that
compiler? That's true, the point I am worried is the integration
of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
be based on the open source version of PGI. So at some point I have
the vision of people approaching us using the LLVM fortran (based
on PGI) in the future utterly failing to run our code with it.
FJ
Sep 15, 2019, 1:08:02 PM9/15/19
to
Le 15/09/2019 à 18:51, JRR a écrit :
> On 15.09.19 17:28, steve kargl wrote:
>
>>
>> I stopped trying to use PGI's Fortran compiler years ago. Your
>> current experience with PGI mirrors what I recall. Back then I
>> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
>> released the g95 frontend, and Steven Bosscher and Paul Brook
>> integrated that frontend into GCC.
>>
>
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
I tried LLVL Fortran about one year ago and it is as bad as PGI Fortran.
> On 15.09.19 17:28, steve kargl wrote:
>
>>
>> I stopped trying to use PGI's Fortran compiler years ago. Your
>> current experience with PGI mirrors what I recall. Back then I
>> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
>> released the g95 frontend, and Steven Bosscher and Paul Brook
>> integrated that frontend into GCC.
>>
>
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
Impossible to compile my codes which are just F95+ (the + for iso C
binding and the improvement of allocatable)
steve kargl
Sep 15, 2019, 1:17:10 PM9/15/19
to
JRR wrote:
> On 15.09.19 17:28, steve kargl wrote:
>
>>
>> I stopped trying to use PGI's Fortran compiler years ago. Your
>> current experience with PGI mirrors what I recall. Back then I
>> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
>> released the g95 frontend, and Steven Bosscher and Paul Brook
>> integrated that frontend into GCC.
>>
>
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
>
My reading of flang vs f18 is that PGI/Nvidia discovered that
> On 15.09.19 17:28, steve kargl wrote:
>
>>
>> I stopped trying to use PGI's Fortran compiler years ago. Your
>> current experience with PGI mirrors what I recall. Back then I
>> had access to DEC Fortran an NAG. Fortunately, Andy Vaught
>> released the g95 frontend, and Steven Bosscher and Paul Brook
>> integrated that frontend into GCC.
>>
>
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
>
the old PGI compiler frontend could not be integrated into llvm
without a significant effort. Thus, Nvidia/DOE decided that writing
an entirely new frontend (aka f18) was the only option to getting
a working modern Fortran compiler. As the person who submitted
what is now the oldest open bug report against flang+llvm,
https://github.com/flang-compiler/flang/issues/60
I'll suggest that it may be a better use of your time to wait for
f18 to actually replaces flang as bug against flang+llvm may not
be found in f18+llvm.
--
steve
lay...@aol.com
Sep 15, 2019, 2:13:54 PM9/15/19
to
For years I would occasionally try PGI Fortran but always found it inferior to Intel and Gfortran (and even Lahey/Fujitsu) in both robustness and executable speed. I think they put a lot of effort into their CUDA Fortran extension at the expense of the standard part.
Al
Al
JRR
Sep 15, 2019, 3:27:03 PM9/15/19
to
On 15.09.19 19:17, steve kargl wrote:
(snip)
> As the person who submitted
> what is now the oldest open bug report against flang+llvm,
>
> https://github.com/flang-compiler/flang/issues/60
>
> I'll suggest that it may be a better use of your time to wait for
> f18 to actually replaces flang as bug against flang+llvm may not
> be found in f18+llvm.
>
Indeed, I also submitted a bug report in Febr. 2018 which never
triggered any reaction. I tried F18 recently, but a.t.m. it
only parses and does not generate any code, correct?
(snip)
> As the person who submitted
> what is now the oldest open bug report against flang+llvm,
>
> https://github.com/flang-compiler/flang/issues/60
>
> I'll suggest that it may be a better use of your time to wait for
> f18 to actually replaces flang as bug against flang+llvm may not
> be found in f18+llvm.
>
triggered any reaction. I tried F18 recently, but a.t.m. it
only parses and does not generate any code, correct?
robin....@gmail.com
Sep 15, 2019, 8:56:55 PM9/15/19
to
On Sunday, September 15, 2019 at 11:59:23 PM UTC+10, JRR wrote:
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
Use Silverfrost compiler.
> After some extended exchange with the support of the PGI team, I stay
> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> capabilities of gfortran, ifort and NAG. It took several years before
> the compiler compiled our code at all, and now it is full of run time
> errors. Starting to deliver reproducers is a heroic task, as the
> compiler compiles insanely slow, and the team seems not to be able to
> run their tools from our full code. From this I estimate that PGI could
> be at the today level of gfortran and ifort (our main compilers) in ca.
> 2030, because I have to go case by case, wait until things are fixed,
> and then go to the next problem. Any advice is highly appreciated.
JRR
Sep 16, 2019, 6:05:55 AM9/16/19
to
Am 16.09.19 um 02:56 schrieb robin....@gmail.com:
Robin, if you look upthread, my interest does not come from an
under-supply of (good) Fortran compiler, but the fear that this compiler and
its bad, well non-optimal language support might hit me and my
development team when it becomes the basis for an macOS shipped Fortran
frontend together with (the Apple version of) LLVM.
under-supply of (good) Fortran compiler, but the fear that this compiler and
its bad, well non-optimal language support might hit me and my
development team when it becomes the basis for an macOS shipped Fortran
frontend together with (the Apple version of) LLVM.
robin....@gmail.com
Sep 16, 2019, 8:05:28 AM9/16/19
to
On Monday, September 16, 2019 at 8:05:55 PM UTC+10, JRR wrote:
> Am 16.09.19 um 02:56 schrieb r.....@gmail.com:
I replied) you will see that there is no mention of MAC.
Your post consisted only of complaints about PGI,
and you asked for suggestions.
My suggestion was an appropriate and relevant response.
> Am 16.09.19 um 02:56 schrieb r.....@gmail.com:
> > On Sunday, September 15, 2019 at 11:59:23 PM UTC+10, JRR wrote:
> >> After some extended exchange with the support of the PGI team, I stay
> >> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> >> capabilities of gfortran, ifort and NAG. It took several years before
> >> the compiler compiled our code at all, and now it is full of run time
> >> errors. Starting to deliver reproducers is a heroic task, as the
> >> compiler compiles insanely slow, and the team seems not to be able to
> >> run their tools from our full code. From this I estimate that PGI could
> >> be at the today level of gfortran and ifort (our main compilers) in ca.
> >> 2030, because I have to go case by case, wait until things are fixed,
> >> and then go to the next problem. Any advice is highly appreciated.
> >
> > Use Silverfrost compiler.
> Robin, if you look upthread, my interest does not come from an
> under-supply of (good) Fortran compiler, but the fear that this compiler and
> its bad, well non-optimal language support might hit me and my
> development team when it becomes the basis for an macOS shipped Fortran
> frontend together with (the Apple version of) LLVM.
If you look upthread to your original post (viz, the one to which
> >> After some extended exchange with the support of the PGI team, I stay
> >> rather frustrated. My estimate is that the compiler has ca. 70 % of the
> >> capabilities of gfortran, ifort and NAG. It took several years before
> >> the compiler compiled our code at all, and now it is full of run time
> >> errors. Starting to deliver reproducers is a heroic task, as the
> >> compiler compiles insanely slow, and the team seems not to be able to
> >> run their tools from our full code. From this I estimate that PGI could
> >> be at the today level of gfortran and ifort (our main compilers) in ca.
> >> 2030, because I have to go case by case, wait until things are fixed,
> >> and then go to the next problem. Any advice is highly appreciated.
> >
> > Use Silverfrost compiler.
> Robin, if you look upthread, my interest does not come from an
> under-supply of (good) Fortran compiler, but the fear that this compiler and
> its bad, well non-optimal language support might hit me and my
> development team when it becomes the basis for an macOS shipped Fortran
> frontend together with (the Apple version of) LLVM.
I replied) you will see that there is no mention of MAC.
Your post consisted only of complaints about PGI,
and you asked for suggestions.
My suggestion was an appropriate and relevant response.
Terence
Sep 16, 2019, 6:25:11 PM9/16/19
to
On Monday, September 16, 2019 at 8:05:55 PM UTC+10, JRR wrote:
> On Sunday, September 15, 2019 at 11:59:23 PM UTC+10, JRR wrote:
>> After some extended exchange with the support of the PGI team, I stay
>> rather frustrated. My estimate is that the compiler has ca. 70 % of the
>> capabilities of gfortran, ifort and NAG. It took several years before
>> the compiler compiled our code at all, and now it is full of run time
>> errors. Starting to deliver reproducers is a heroic task, as the
>> compiler compiles insanely slow, and the team seems not to be able to
>> run their tools from our full code. From this I estimate that PGI could
>> be at the today level of gfortran and ifort (our main compilers) in ca.
>> 2030, because I have to go case by case, wait until things are fixed,
>> and then go to the next problem. Any advice is highly appreciated.
>
And Robin Vowels sensibly responded:-
> On Sunday, September 15, 2019 at 11:59:23 PM UTC+10, JRR wrote:
>> After some extended exchange with the support of the PGI team, I stay
>> rather frustrated. My estimate is that the compiler has ca. 70 % of the
>> capabilities of gfortran, ifort and NAG. It took several years before
>> the compiler compiled our code at all, and now it is full of run time
>> errors. Starting to deliver reproducers is a heroic task, as the
>> compiler compiles insanely slow, and the team seems not to be able to
>> run their tools from our full code. From this I estimate that PGI could
>> be at the today level of gfortran and ifort (our main compilers) in ca.
>> 2030, because I have to go case by case, wait until things are fixed,
>> and then go to the next problem. Any advice is highly appreciated.
>
> Use Silverfrost compiler.
I read these several related postings about problems with this and that new
versions of Fortran compilers, and then read the wise responses of Robin
Vowels, and I shake my head in disbelief.
What really was wrong with "good old F77" Fortran? And in my case, with 1985
MS V3.31 which I contend till today HAS NO BUGS!. And I still use it. I
maintain I can use it for any problem solving, given external storage
availability.
Mind, you, somewhere in the early 90's, I wrote my own additional extension
library for MS 3.31, for all the bit-wise logic extensions that I needed for
my very successful commercial suite of survey generation, from most any
survey defining languages, from the IBM SAP up through Survey Monkey (for
text processing of European scripted Latin, Greek and Romaji texts, for
automatic OMR questionnaire generation, and e-mailed forms, than subsequent
data read-back, and automatic data processing, and final report writing and
graphics productions in Windows WORD). And all automatic from the first
surveyor's text.
For years, I contemplated decompiling my own copy of the trusty old M.S.
compiler and libraries to the original 16-bit code, so I could process to a
meta-logic and revert to a new compiler and libraries for the newer 32 and
64 bit operating systems. Maybe I still will. None of what I read makes any
good sense. Any Compute-Oriented department of pretty much any University I
am familiar, with could have done the same or better, long ago.
Terence
ga...@u.washington.edu
Sep 16, 2019, 6:51:56 PM9/16/19
to
On Monday, September 16, 2019 at 3:25:11 PM UTC-7, Terence wrote:
>
(snip)
> What really was wrong with "good old F77" Fortran? And in my case, with 1985
> MS V3.31 which I contend till today HAS NO BUGS!. And I still use it. I
> maintain I can use it for any problem solving, given external storage
> availability.
> Mind, you, somewhere in the early 90's, I wrote my own additional extension
> library for MS 3.31, for all the bit-wise logic extensions that I needed for
> my very successful commercial suite of survey generation, from most any
> survey defining languages, from the IBM SAP up through Survey Monkey (for
> text processing of European scripted Latin, Greek and Romaji texts, for
> automatic OMR questionnaire generation, and e-mailed forms, than subsequent
> data read-back, and automatic data processing, and final report writing and
> graphics productions in Windows WORD). And all automatic from the first
> surveyor's text.
Well, some people don't like 16 bit MS-DOS, or emulated versions of it.
> For years, I contemplated decompiling my own copy of the trusty old M.S.
> compiler and libraries to the original 16-bit code, so I could process to a
> meta-logic and revert to a new compiler and libraries for the newer 32 and
> 64 bit operating systems. Maybe I still will. None of what I read makes any
> good sense. Any Compute-Oriented department of pretty much any University I
> am familiar, with could have done the same or better, long ago.
How about the WATCOM compilers? There are both 16 and 32 bit versions,
and I believe that will run on either 16 or 32 bit hosts? Then the
ability to link for a variety of run-time systems, including 32 bit
DOS extenders, WIN32, 16 and 32 bit OS/2, and probably more that
I forgot.
As far as I know, and I believe it can still do it, the only one to
support large model 32 bit code. (I believe OS/2 can support this,
though I am not sure about it now.)
They are nice open source compilers, if you like Fortran 77 compilers.
>
(snip)
> What really was wrong with "good old F77" Fortran? And in my case, with 1985
> MS V3.31 which I contend till today HAS NO BUGS!. And I still use it. I
> maintain I can use it for any problem solving, given external storage
> availability.
> Mind, you, somewhere in the early 90's, I wrote my own additional extension
> library for MS 3.31, for all the bit-wise logic extensions that I needed for
> my very successful commercial suite of survey generation, from most any
> survey defining languages, from the IBM SAP up through Survey Monkey (for
> text processing of European scripted Latin, Greek and Romaji texts, for
> automatic OMR questionnaire generation, and e-mailed forms, than subsequent
> data read-back, and automatic data processing, and final report writing and
> graphics productions in Windows WORD). And all automatic from the first
> surveyor's text.
> For years, I contemplated decompiling my own copy of the trusty old M.S.
> compiler and libraries to the original 16-bit code, so I could process to a
> meta-logic and revert to a new compiler and libraries for the newer 32 and
> 64 bit operating systems. Maybe I still will. None of what I read makes any
> good sense. Any Compute-Oriented department of pretty much any University I
> am familiar, with could have done the same or better, long ago.
and I believe that will run on either 16 or 32 bit hosts? Then the
ability to link for a variety of run-time systems, including 32 bit
DOS extenders, WIN32, 16 and 32 bit OS/2, and probably more that
I forgot.
As far as I know, and I believe it can still do it, the only one to
support large model 32 bit code. (I believe OS/2 can support this,
though I am not sure about it now.)
They are nice open source compilers, if you like Fortran 77 compilers.
steve kargl
Sep 16, 2019, 7:02:31 PM9/16/19
to
Terence wrote:
> I read these several related postings about problems with this and that new
> versions of Fortran compilers, and then read the wise responses of Robin
> Vowels, and I shake my head in disbelief.
>
> What really was wrong with "good old F77" Fortran?
We've been down this road before.
> I read these several related postings about problems with this and that new
> versions of Fortran compilers, and then read the wise responses of Robin
> Vowels, and I shake my head in disbelief.
>
> What really was wrong with "good old F77" Fortran?
1) Proper dynamic memory management.
2) Fixed source form with a 6 character limit for names.
3) Lack of stream IO
4) No intrinsic type for double precision complex
Shall I continue?
--
steve
ga...@u.washington.edu
Sep 16, 2019, 7:37:48 PM9/16/19
to
On Monday, September 16, 2019 at 4:02:31 PM UTC-7, steve kargl wrote:
> Terence wrote:
(snip)
> > What really was wrong with "good old F77" Fortran?
> We've been down this road before.
> 1) Proper dynamic memory management.
> 2) Fixed source form with a 6 character limit for names.
> 3) Lack of stream IO
> 4) No intrinsic type for double precision complex
Sometimes you don't need those.
Otherwise, many Fortran 66 and Fortran 77 compilers
support COMPLEX*16 and some support COMPLEX*32.
Also, sum ppl are good at shrt nams, and dont need
mor than six ltrs.
> Terence wrote:
(snip)
> > What really was wrong with "good old F77" Fortran?
> We've been down this road before.
> 1) Proper dynamic memory management.
> 2) Fixed source form with a 6 character limit for names.
> 3) Lack of stream IO
> 4) No intrinsic type for double precision complex
Otherwise, many Fortran 66 and Fortran 77 compilers
support COMPLEX*16 and some support COMPLEX*32.
Also, sum ppl are good at shrt nams, and dont need
mor than six ltrs.
FortranFan
Sep 16, 2019, 8:18:35 PM9/16/19
to
On Monday, September 16, 2019 at 6:25:11 PM UTC-4, Terence wrote:
> ..
> And in my case, with 1985
> MS V3.31 which I contend till today HAS NO BUGS!
Not true.
. And I still use it. I
> maintain I can use it for any problem solving, given external storage
> availability.
A large number of people "believe" their *revealed book* can be used "for any problem solving" and they don't even require "external storage availability", let alone a Turing device!
>
> Mind, you, somewhere in the early 90's, I wrote my own additional extension
> library for MS 3.31, for all the bit-wise logic extensions that I needed for
> my very successful commercial suite of survey generation, from most any
> survey defining languages, from the IBM SAP up through Survey Monkey (for
> text processing of European scripted Latin, Greek and Romaji texts, for
> automatic OMR questionnaire generation, and e-mailed forms, than subsequent
> data read-back, and automatic data processing, and final report writing and
> graphics productions in Windows WORD). And all automatic from the first
> surveyor's text.
>
Quick, someone tell Microsoft to place MS FORTRAN V3.31 in a GitHub repository (https://github.com/Microsoft), that might finally inspire @Terence to open source the code for this "additional extension library for MS 3.31, for all the bit-wise logic extensions that @Terence needed for .. very successful commercial suite of survey generation" too so it can be used by others to learn how to use FORTRAN 77 using V3.31.
> For years, I contemplated decompiling my own copy of the trusty old M.S.
> compiler and libraries to the original 16-bit code, so I could process to a
> meta-logic and revert to a new compiler and libraries for the newer 32 and
> 64 bit operating systems. Maybe I still will. None of what I read makes any
> good sense. Any Compute-Oriented department of pretty much any University I
> am familiar, with could have done the same or better, long ago.
>
> Terence
Alexander Pope precisely had @Terence in mind when he wrote, "All seems infected that the infected spy, As all looks yellow to the jaundiced eye."
> ..
> What really was wrong with "good old F77" Fortran?
Everything, starting with the fact no one including @Terence (who surely uses a dialect that might have some similarity but which is definitely not "good old F77") wants to use it.
> And in my case, with 1985
> MS V3.31 which I contend till today HAS NO BUGS!
. And I still use it. I
> maintain I can use it for any problem solving, given external storage
> availability.
>
> Mind, you, somewhere in the early 90's, I wrote my own additional extension
> library for MS 3.31, for all the bit-wise logic extensions that I needed for
> my very successful commercial suite of survey generation, from most any
> survey defining languages, from the IBM SAP up through Survey Monkey (for
> text processing of European scripted Latin, Greek and Romaji texts, for
> automatic OMR questionnaire generation, and e-mailed forms, than subsequent
> data read-back, and automatic data processing, and final report writing and
> graphics productions in Windows WORD). And all automatic from the first
> surveyor's text.
>
> For years, I contemplated decompiling my own copy of the trusty old M.S.
> compiler and libraries to the original 16-bit code, so I could process to a
> meta-logic and revert to a new compiler and libraries for the newer 32 and
> 64 bit operating systems. Maybe I still will. None of what I read makes any
> good sense. Any Compute-Oriented department of pretty much any University I
> am familiar, with could have done the same or better, long ago.
>
> Terence
Beliavsky
Sep 16, 2019, 9:21:15 PM9/16/19
to
On Monday, September 16, 2019 at 8:18:35 PM UTC-4, FortranFan wrote:
> On Monday, September 16, 2019 at 6:25:11 PM UTC-4, Terence wrote:
>
> > ..
> > What really was wrong with "good old F77" Fortran?
>
> Everything, starting with the fact no one including @Terence (who surely uses a dialect that might have some similarity but which is definitely not "good old F77") wants to use it.
>
Hey, FortranFan, someday you will be posting here about Fortran (20)50 being all that anyone needs :). Personally I think Fortran reached its apotheosis with Fortran 95.
> On Monday, September 16, 2019 at 6:25:11 PM UTC-4, Terence wrote:
>
> > ..
> > What really was wrong with "good old F77" Fortran?
>
> Everything, starting with the fact no one including @Terence (who surely uses a dialect that might have some similarity but which is definitely not "good old F77") wants to use it.
>
FortranFan
Sep 16, 2019, 11:09:38 PM9/16/19
to
On Monday, September 16, 2019 at 9:21:15 PM UTC-4, Beliavsky wrote:
> ..
https://youtu.be/Q16uINZ1IMQ
> Personally I think Fortran reached its apotheosis with Fortran 95.
ALLOCATABLEs were yet faulty in that revision and no SUBMODULEs, to stick with Fortran 95 would be uncivilized existence, neither progressive nor liberal!
> ..
> Hey, FortranFan, someday you will be posting here about Fortran (20)50 being all that anyone needs :).
:-)) I've updated my living will to also "pull the cord" should that ever happen!
https://youtu.be/Q16uINZ1IMQ
> Personally I think Fortran reached its apotheosis with Fortran 95.
robin....@gmail.com
Sep 17, 2019, 1:52:24 AM9/17/19
to
Ls, sm ppl r gd ut shrt nms, n dnt nd mr thn sx lttrs.
This should be comprehensible to a New Zealander too.
JRR
Sep 17, 2019, 8:20:51 AM9/17/19
to
Am 16.09.19 um 14:05 schrieb robin....@gmail.com:
(snip)
>
>> Robin, if you look upthread, my interest does not come from an
>> under-supply of (good) Fortran compiler, but the fear that this compiler and
>> its bad, well non-optimal language support might hit me and my
>> development team when it becomes the basis for an macOS shipped Fortran
>> frontend together with (the Apple version of) LLVM.
>
> If you look upthread to your original post (viz, the one to which
> I replied) you will see that there is no mention of MAC.
>
> Your post consisted only of complaints about PGI,
> and you asked for suggestions.
> My suggestion was an appropriate and relevant response.
>
Before you made that reponse (maybe without reading relevant parts of
the thread), I already explained:
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
So, your remark was neither relevant nor helpful. You have to look
for those compilers that are available and popular, and that young
people (students) have access and contact to. I for sure will not give
code and compilers that have the dust of the 1980s to young students,
because then they run away and only do Scala and Jupyter Notebooks
(which they will do at the end maybe anyways).
(snip)
>
>> Robin, if you look upthread, my interest does not come from an
>> under-supply of (good) Fortran compiler, but the fear that this compiler and
>> its bad, well non-optimal language support might hit me and my
>> development team when it becomes the basis for an macOS shipped Fortran
>> frontend together with (the Apple version of) LLVM.
>
> If you look upthread to your original post (viz, the one to which
> I replied) you will see that there is no mention of MAC.
>
> Your post consisted only of complaints about PGI,
> and you asked for suggestions.
> My suggestion was an appropriate and relevant response.
>
the thread), I already explained:
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
for those compilers that are available and popular, and that young
people (students) have access and contact to. I for sure will not give
code and compilers that have the dust of the 1980s to young students,
because then they run away and only do Scala and Jupyter Notebooks
(which they will do at the end maybe anyways).
FortranFan
Sep 17, 2019, 8:51:42 AM9/17/19
to
On Monday, September 16, 2019 at 6:05:55 AM UTC-4, JRR wrote:
> .. my .. fear that this compiler and
@Juergen Reuter,
This is just out of curiosity: will it be possible for you to elaborate the compiler support selection process with your software development for a given OS? Meaning, is that determined by some majority of users of your code, or some influential customers, or some other technical/non-technical criteria?
Say for Mac OS: I *presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
> .. my .. fear that this compiler and
> its bad, well non-optimal language support might hit me and my
> development team when it becomes the basis for an macOS shipped Fortran
> frontend together with (the Apple version of) LLVM.
> ..
> development team when it becomes the basis for an macOS shipped Fortran
> frontend together with (the Apple version of) LLVM.
@Juergen Reuter,
This is just out of curiosity: will it be possible for you to elaborate the compiler support selection process with your software development for a given OS? Meaning, is that determined by some majority of users of your code, or some influential customers, or some other technical/non-technical criteria?
Say for Mac OS: I *presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
Ron Shepard
Sep 17, 2019, 10:37:11 AM9/17/19
to
On 9/17/19 7:51 AM, FortranFan wrote:
> Say for Mac OS: I*presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
However, that compiler does not support all of f2003, and it is becoming
less and less useful to me because of that feature lag. On the other
hand, ABSOFT has a very nice interactive debugger. It works so well it
is a pleasure to use. It is a shame that the compiler is in the shape
that it is, it is a great loss to the programming community for Mac
programmers.
As for LLVM, it would certainly be good to have a second free fortran
compiler for MacOS. The importance of the LLVM compiler is elevated due
to the fact that the gnu debugger gdb currently does not work on the
latest versions of MacOS. I have MacOS 10.11 and (I think) 10.12
machines with old versions of gdb that work correctly. But somewhere
since then, 10.13 or 10.14, code signing (security) issues arose, and it
became practically impossible to get everything to work. MacOS 10.15 has
been announced and is due out in the next month (for free, as usual with
MacOS), so it appears that the pace of OS development is exceeding the
capability of the open source development environment to keep up. This
security/compatibility issue is supposedly being addressed within gdb,
but it has been in this state for a couple of years now with no real
progress. The current lldb debugger allows gfortran codes to execute,
but it does not allow low-level access to structure members, allocatable
arrays, and so on, so it has only limited usefulness. So a fully
supported free llvm fortran that works with lldb on MacOS would be nice.
$.02 -Ron Shepard
> Say for Mac OS: I*presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
>
> As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
There is also ABSOFT fortran for MacOS, another commercial compiler.
> As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
However, that compiler does not support all of f2003, and it is becoming
less and less useful to me because of that feature lag. On the other
hand, ABSOFT has a very nice interactive debugger. It works so well it
is a pleasure to use. It is a shame that the compiler is in the shape
that it is, it is a great loss to the programming community for Mac
programmers.
As for LLVM, it would certainly be good to have a second free fortran
compiler for MacOS. The importance of the LLVM compiler is elevated due
to the fact that the gnu debugger gdb currently does not work on the
latest versions of MacOS. I have MacOS 10.11 and (I think) 10.12
machines with old versions of gdb that work correctly. But somewhere
since then, 10.13 or 10.14, code signing (security) issues arose, and it
became practically impossible to get everything to work. MacOS 10.15 has
been announced and is due out in the next month (for free, as usual with
MacOS), so it appears that the pace of OS development is exceeding the
capability of the open source development environment to keep up. This
security/compatibility issue is supposedly being addressed within gdb,
but it has been in this state for a couple of years now with no real
progress. The current lldb debugger allows gfortran codes to execute,
but it does not allow low-level access to structure members, allocatable
arrays, and so on, so it has only limited usefulness. So a fully
supported free llvm fortran that works with lldb on MacOS would be nice.
$.02 -Ron Shepard
Juergen Reuter
Sep 17, 2019, 10:51:55 AM9/17/19
to
On 9/17/19 14:51, FortranFan wrote:
> @Juergen Reuter,
>
> This is just out of curiosity: will it be possible for you to elaborate the compiler support selection process with your software development for a given OS? Meaning, is that determined by some majority of users of your code, or some influential customers, or some other technical/non-technical criteria?
>
> Say for Mac OS: I *presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
>
> As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
>
@Parekh
> @Juergen Reuter,
>
> This is just out of curiosity: will it be possible for you to elaborate the compiler support selection process with your software development for a given OS? Meaning, is that determined by some majority of users of your code, or some influential customers, or some other technical/non-technical criteria?
>
> Say for Mac OS: I *presume* 2 commercial compilers - NAG and Intel - as well as GCC/gfortran provide decent compiler support. Can you not stick with these?
>
> As you indicate, it may be years before LLVM-f18 even becomes viable, if at all ever. Is there anything that would force you to work with that tool-chain before it's proven to be robust and reliable? Thanks,
>
actually we are almost exclusively working on Linux in our team, but
many of our users are working on macOS. For the development, we use
mainly NAG (but are thinking about switching to Intel, mainly because
the submodule support of NAG is delayed by such a long time. I discussed
this with NAG support, and they said that there would be a new version
somewhen in 2019 either called 6.3 or 7.0 depending on how much will be
included). From time to time I am checking Intel as in customer test
versions on macOS. I am still a little more (maybe too?) optimistic that
an LLVM-based Fortran compiler comes out in the not too far future. But
maybe that is not realistic, and it is also not given that it will be
supported within XCode, read Apple-LLVM. But maybe the latter is a good
thing because our users are then forced to use gfortran.
FJ
Sep 17, 2019, 1:23:01 PM9/17/19
to
Ron Shepard
Sep 17, 2019, 8:47:30 PM9/17/19
to
proven difficult to use reliably in a portable way).
Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
the real advantage of f90 and later is the combination of modules and
explicit interfaces. When I first started using f90, that combination
resulted in me being able to write long, complicated programs and having
them run correctly the first time they compiled. Of course, getting them
to compile required some effort, but it was much easier for the compiler
to tell me what was wrong than for me to try to figure it out debugging
later at runtime which arguments were switched, or missing, or
mismatched. Even now, some two decades later, I am still surprised at
how much better f90 is as a language in that respect compared to f77.
Also, it is possible to change real types easily in f90, something that
is much more difficult in f77 (where it requires tools to modify source
code). If you write the code the right way, you can change types
throughout an entire program by changing just a single line of code. I
don't actually need to do that as much now as in the past (thanks to
SELECTED_REAL_KIND), but I wish that had been possible back when I was
running on 16-bit, 24-bit, 32-bit, 36-bit, 60-bit, and 64-bit computers,
sometimes several of them in a single day.
$.02 -Ron Shepard
ga...@u.washington.edu
Sep 17, 2019, 9:39:06 PM9/17/19
to
On Tuesday, September 17, 2019 at 5:47:30 PM UTC-7, Ron Shepard wrote:
(snip)
> That sounds like f2003 (minus parameterized data types, which have
> proven difficult to use reliably in a portable way).
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> the real advantage of f90 and later is the combination of modules and
> explicit interfaces. When I first started using f90, that combination
> resulted in me being able to write long, complicated programs and having
> them run correctly the first time they compiled.
(snip)
Reminds me, in a photographic discussion today, someone asking why
Leica doesn't sell an autofocus rangefinder camera.
In the Fortran 66 and 77 days, we concentrated some on getting argument
types right, and getting COMMON statements the same, along with their
declarations, in all routines.
As for Leica, a manual focus camera reminds you to think about
what part of the subject you are focusing on. Often enough, AF
will focus on the background, or some other object, and not the
one you expected.
Checking arguments and types does take some type, but it also
helps catch other mistakes that one might have made, and that
compilers won't catch even with all the new features.
When any safety feature comes out (seatbelts and anti-lock
brakes are sometimes mentioned) there is always the question
about people relying on the new feature too much. Driving
faster, knowing that anti-lock brakes will help you stop.
Even with all the new features, you still need to think
about what you are doing. Don't let your guard down, just
because the new feature might catch the mistakes.
(snip)
> That sounds like f2003 (minus parameterized data types, which have
> proven difficult to use reliably in a portable way).
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> the real advantage of f90 and later is the combination of modules and
> explicit interfaces. When I first started using f90, that combination
> resulted in me being able to write long, complicated programs and having
> them run correctly the first time they compiled.
Reminds me, in a photographic discussion today, someone asking why
Leica doesn't sell an autofocus rangefinder camera.
In the Fortran 66 and 77 days, we concentrated some on getting argument
types right, and getting COMMON statements the same, along with their
declarations, in all routines.
As for Leica, a manual focus camera reminds you to think about
what part of the subject you are focusing on. Often enough, AF
will focus on the background, or some other object, and not the
one you expected.
Checking arguments and types does take some type, but it also
helps catch other mistakes that one might have made, and that
compilers won't catch even with all the new features.
When any safety feature comes out (seatbelts and anti-lock
brakes are sometimes mentioned) there is always the question
about people relying on the new feature too much. Driving
faster, knowing that anti-lock brakes will help you stop.
Even with all the new features, you still need to think
about what you are doing. Don't let your guard down, just
because the new feature might catch the mistakes.
robin....@gmail.com
Sep 18, 2019, 2:50:07 AM9/18/19
to
On Tuesday, September 17, 2019 at 10:20:51 PM UTC+10, Juergen Reuter wrote:
> Am 16.09.19 um 14:05 schrieb r.....@gmail.com:
> > Of course, with gfortran, ifort and NAG available, one could ask
> > the question: why is it important to support or investigate that
> > compiler? That's true, the point I am worried is the integration
> > of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> > be based on the open source version of PGI. So at some point I have
> > the vision of people approaching us using the LLVM fortran (based
> > on PGI) in the future utterly failing to run our code with it.
> So, your remark was neither relevant nor helpful.
So, your latest remarks are neither relevant nor helpful.
> You have to look
> for those compilers that are available and popular,
So, why are you bothering with PGI at all?
> Am 16.09.19 um 14:05 schrieb r.....@gmail.com:
>
> (snip)
>
> >
> >> Robin, if you look upthread, my interest does not come from an
> >> under-supply of (good) Fortran compiler, but the fear that this compiler and
> >> its bad, well non-optimal language support might hit me and my
> >> development team when it becomes the basis for an macOS shipped Fortran
> >> frontend together with (the Apple version of) LLVM.
> >
> > If you look upthread to your original post (viz, the one to which
> > I replied) you will see that there is no mention of MAC.
> >
> > Your post consisted only of complaints about PGI,
> > and you asked for suggestions.
>
> > My suggestion was an appropriate and relevant response.
> Before you made that reponse (maybe without reading relevant parts of
> the thread), I already explained:
No need to repeat yourself.
> (snip)
>
> >
> >> Robin, if you look upthread, my interest does not come from an
> >> under-supply of (good) Fortran compiler, but the fear that this compiler and
> >> its bad, well non-optimal language support might hit me and my
> >> development team when it becomes the basis for an macOS shipped Fortran
> >> frontend together with (the Apple version of) LLVM.
> >
> > If you look upthread to your original post (viz, the one to which
> > I replied) you will see that there is no mention of MAC.
> >
> > Your post consisted only of complaints about PGI,
> > and you asked for suggestions.
>
> > My suggestion was an appropriate and relevant response.
> Before you made that reponse (maybe without reading relevant parts of
> the thread), I already explained:
> > Of course, with gfortran, ifort and NAG available, one could ask
> > the question: why is it important to support or investigate that
> > compiler? That's true, the point I am worried is the integration
> > of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> > be based on the open source version of PGI. So at some point I have
> > the vision of people approaching us using the LLVM fortran (based
> > on PGI) in the future utterly failing to run our code with it.
> So, your remark was neither relevant nor helpful.
> You have to look
> for those compilers that are available and popular,
robin....@gmail.com
Sep 18, 2019, 2:55:01 AM9/18/19
to
On Wednesday, September 18, 2019 at 10:47:30 AM UTC+10, Ron Shepard wrote:
> On 9/17/19 12:22 PM, FJ wrote:
> > Le 17/09/2019 à 03:21, Beliavsky a écrit :
> >> On Monday, September 16, 2019 at 8:18:35 PM UTC-4, FortranFan wrote:
> >>> On Monday, September 16, 2019 at 6:25:11 PM UTC-4, Terence wrote:
> >>>
> >>> > ..
> >>> > What really was wrong with "good old F77" Fortran?
> >>>
> >>> Everything, starting with the fact no one including @Terence (who
> >>> surely uses a dialect that might have some similarity but which is
> >>> definitely not "good old F77") wants to use it.
> >>>
> >>
> >> Hey, FortranFan, someday you will be posting here about Fortran (20)50
> >> being all that anyone needs :). Personally I think Fortran reached its
> >> apotheosis with Fortran 95.
> >
> > I prefer F95+, the + for iso_c_binding + generalized allocatable variables
>
> That sounds like f2003 (minus parameterized data types, which have
> proven difficult to use reliably in a portable way).
>
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77".
Everyone has his/her reasons for getting past F77.
> On 9/17/19 12:22 PM, FJ wrote:
> > Le 17/09/2019 à 03:21, Beliavsky a écrit :
> >> On Monday, September 16, 2019 at 8:18:35 PM UTC-4, FortranFan wrote:
> >>> On Monday, September 16, 2019 at 6:25:11 PM UTC-4, Terence wrote:
> >>>
> >>> > ..
> >>> > What really was wrong with "good old F77" Fortran?
> >>>
> >>> Everything, starting with the fact no one including @Terence (who
> >>> surely uses a dialect that might have some similarity but which is
> >>> definitely not "good old F77") wants to use it.
> >>>
> >>
> >> Hey, FortranFan, someday you will be posting here about Fortran (20)50
> >> being all that anyone needs :). Personally I think Fortran reached its
> >> apotheosis with Fortran 95.
> >
> > I prefer F95+, the + for iso_c_binding + generalized allocatable variables
>
> That sounds like f2003 (minus parameterized data types, which have
> proven difficult to use reliably in a portable way).
>
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77".
But IMHO the most important ones are IMPLICIT NONE and free source form.
Free source form eliminates many typos that were ignored by F77
on account of blanks being ignored [except in character strings].
IMPLICIT NONE has much the same advantage.
robin....@gmail.com
Sep 18, 2019, 3:04:09 AM9/18/19
to
On Wednesday, September 18, 2019 at 11:39:06 AM UTC+10, ga...@u.washington.edu wrote:
> On Tuesday, September 17, 2019 at 5:47:30 PM UTC-7, Ron Shepard wrote:
>
> (snip)
>
> > That sounds like f2003 (minus parameterized data types, which have
> > proven difficult to use reliably in a portable way).
>
> > Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> > the real advantage of f90 and later is the combination of modules and
> > explicit interfaces. When I first started using f90, that combination
> > resulted in me being able to write long, complicated programs and having
> > them run correctly the first time they compiled.
>
> (snip)
>
> Reminds me, in a photographic discussion today, someone asking why
> Leica doesn't sell an autofocus rangefinder camera.
>
> In the Fortran 66 and 77 days,
And in FORTRAN IV days
> On Tuesday, September 17, 2019 at 5:47:30 PM UTC-7, Ron Shepard wrote:
>
> (snip)
>
> > That sounds like f2003 (minus parameterized data types, which have
> > proven difficult to use reliably in a portable way).
>
> > Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> > the real advantage of f90 and later is the combination of modules and
> > explicit interfaces. When I first started using f90, that combination
> > resulted in me being able to write long, complicated programs and having
> > them run correctly the first time they compiled.
>
> (snip)
>
> Reminds me, in a photographic discussion today, someone asking why
> Leica doesn't sell an autofocus rangefinder camera.
>
> In the Fortran 66 and 77 days,
> we concentrated some on getting argument
> types right, and getting COMMON statements the same, along with their
> declarations, in all routines.
ensuring that variables were spelled correctly (that O and 0,
1 and I, were used appropriately), and that there were no missing
periods or commas, etc. etc., and that variables were of the
appropriate type [most people relying on default types].
> As for Leica, a manual focus camera reminds you to think about
> what part of the subject you are focusing on. Often enough, AF
> will focus on the background, or some other object, and not the
> one you expected.
>
> Checking arguments and types does take some type, but it also
> helps catch other mistakes that one might have made, and that
> compilers won't catch even with all the new features.
>
> When any safety feature comes out (seatbelts and anti-lock
> brakes are sometimes mentioned) there is always the question
> about people relying on the new feature too much. Driving
> faster, knowing that anti-lock brakes will help you stop.
>
> Even with all the new features, you still need to think
> about what you are doing. Don't let your guard down, just
> because the new feature might catch the mistakes.
Although I did not drive faster because the car had seat belts.
steve kargl
Sep 18, 2019, 3:06:35 AM9/18/19
to
Have you actually read the entire thread? PGI (now owned by
Nvidia) under contract to the DOE were task with porting the
PGI Fortran frontend to be integrated with LLVM. Testing PGI
is testing the work in progress of flang+llvm.
--
steve
Nvidia) under contract to the DOE were task with porting the
PGI Fortran frontend to be integrated with LLVM. Testing PGI
is testing the work in progress of flang+llvm.
--
steve
spectrum
Sep 18, 2019, 3:45:12 AM9/18/19
to
On Wednesday, September 18, 2019 at 9:47:30 AM UTC+9, Ron Shepard wrote:
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> the real advantage of f90 and later is the combination of modules and
> explicit interfaces. When I first started using f90, that combination
> resulted in me being able to write long, complicated programs and having
> them run correctly the first time they compiled. (...snip...)
> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77". But
> the real advantage of f90 and later is the combination of modules and
> explicit interfaces. When I first started using f90, that combination
> resulted in me being able to write long, complicated programs and having
This is indeed what I also experienced when starting using f90. When I was a student
(long time ago) using F77 + implicit real*8, I needed to fix bus errors sometimes
(due to argument mismatch, which occurred when changing a function
signature while failing to update all the caller codes throughout).
So I used tools like FTNCHEK and other checkers, and always looking for
additional check tools. After starting to use f90, this became almost unnecessary,
which is essentially thanks to explicit interface (+ module also, avoiding common
blocks).
> As for Leica, a manual focus camera reminds you to think about
what part of the subject you are focusing on.
word for this... something like the focal point is a bit different?)
If manual focus is preferred (say, for better photos), we can turn auto-things
off manually, but the opposite is impossible if there is no functionality provided.
# But I agree that relying too much on "auto things" and becoming too careless
about what one is doing is risky (which I guess the Leica discussion implies).
spectrum
Sep 18, 2019, 4:17:18 AM9/18/19
to
On Monday, September 16, 2019 at 2:17:10 AM UTC+9, steve kargl wrote:
> My reading of flang vs f18 is that PGI/Nvidia discovered that
> the old PGI compiler frontend could not be integrated into llvm
> without a significant effort. Thus, Nvidia/DOE decided that writing
> an entirely new frontend (aka f18) was the only option to getting
> a working modern Fortran compiler. (... snip ...)
I really hope that this is the case (i.e. a new front end for llvm).
I sometimes used PGI for my programs (with a purchased compiler
much ago and more recently the community edition), but
experienced several case of compiler bugs. I filed an issue
for that sometime ago, and hope the newer version works fine.
# I haven't tried the most recent version, which may have fixed
the issue I reported above (just downloaded, so will try later).
https://www.pgroup.com/support/release-tprs-2019.htm
In the product page of PGI, we see the comments from Gaussian
and VASP dev people (about the nice points of GPU and OpenACC etc)
https://www.pgroup.com/about/why-pgi.htm
So I guess the additional features (for GPU etc) may be very appealing.
However, I also feel that the support for the syntax is not very good
(particularly for newer ones), even for rather "primitive" cases (e.g., passing
an array literal to a subroutine results in segfault). Sticking to an old style
coding may be one solution (which I guess the case for Gaussian and VASP above),
but I would like to avoid that approach because other compilers work with no problem.
> My reading of flang vs f18 is that PGI/Nvidia discovered that
> the old PGI compiler frontend could not be integrated into llvm
> without a significant effort. Thus, Nvidia/DOE decided that writing
> an entirely new frontend (aka f18) was the only option to getting
> a working modern Fortran compiler. (... snip ...)
I really hope that this is the case (i.e. a new front end for llvm).
I sometimes used PGI for my programs (with a purchased compiler
much ago and more recently the community edition), but
experienced several case of compiler bugs. I filed an issue
for that sometime ago, and hope the newer version works fine.
# I haven't tried the most recent version, which may have fixed
the issue I reported above (just downloaded, so will try later).
https://www.pgroup.com/support/release-tprs-2019.htm
In the product page of PGI, we see the comments from Gaussian
and VASP dev people (about the nice points of GPU and OpenACC etc)
https://www.pgroup.com/about/why-pgi.htm
So I guess the additional features (for GPU etc) may be very appealing.
However, I also feel that the support for the syntax is not very good
(particularly for newer ones), even for rather "primitive" cases (e.g., passing
an array literal to a subroutine results in segfault). Sticking to an old style
coding may be one solution (which I guess the case for Gaussian and VASP above),
but I would like to avoid that approach because other compilers work with no problem.
ga...@u.washington.edu
Sep 18, 2019, 4:18:03 AM9/18/19
to
On Wednesday, September 18, 2019 at 12:45:12 AM UTC-7, spectrum wrote:
(snip, I wrote)
> > As for Leica, a manual focus camera reminds you to think about
> > what part of the subject you are focusing on.
> I feel this discussion is somewhat misleading (or, I'm not sure
> what's the good word for this... something like the focal
> point is a bit different?)
I suppose.
> If manual focus is preferred (say, for better photos), we can turn
> auto-things off manually, but the opposite is impossible
> if there is no functionality provided.
The split-image rangefinder, which was popular on many cameras
around the time that Leica became popular is interesting.
Using a partial mirror, looking through the viewfinder
(or on some cameras, a separate window) you see two images of
(usually) the center of the view. As you focus, one of the images
moves, until at the desired focus point, the two line up.
SLRs don't have this feature, but a specially designed prism shape
in the center of the viewing screen give a similar function.
Cameras designed for autofocus often don't have this special
viewing prism, making manual focus more difficult.
> # But I agree that relying too much on "auto things" and
> becoming too careless about what one is doing is risky
> (which I guess the Leica discussion implies).
Yes. I was thinking about how it is that we survived all
the years before these features were added. I believe mostly
it is because we tried harder to get things right in the
first place.
I do remember some of my early Fortran programs working
the first time, maybe surprising me. But also I tried to
understand the program as well as I could. Often enough,
when it didn't work, I would know where the problem was
just from what it did. (No debuggers like we have now.)
(snip, I wrote)
> > As for Leica, a manual focus camera reminds you to think about
> > what part of the subject you are focusing on.
> I feel this discussion is somewhat misleading (or, I'm not sure
> what's the good word for this... something like the focal
> point is a bit different?)
> If manual focus is preferred (say, for better photos), we can turn
> auto-things off manually, but the opposite is impossible
> if there is no functionality provided.
around the time that Leica became popular is interesting.
Using a partial mirror, looking through the viewfinder
(or on some cameras, a separate window) you see two images of
(usually) the center of the view. As you focus, one of the images
moves, until at the desired focus point, the two line up.
SLRs don't have this feature, but a specially designed prism shape
in the center of the viewing screen give a similar function.
Cameras designed for autofocus often don't have this special
viewing prism, making manual focus more difficult.
> # But I agree that relying too much on "auto things" and
> becoming too careless about what one is doing is risky
> (which I guess the Leica discussion implies).
the years before these features were added. I believe mostly
it is because we tried harder to get things right in the
first place.
I do remember some of my early Fortran programs working
the first time, maybe surprising me. But also I tried to
understand the program as well as I could. Often enough,
when it didn't work, I would know where the problem was
just from what it did. (No debuggers like we have now.)
Terence
Sep 18, 2019, 6:37:26 PM9/18/19
to
"steve kargl" wrote in message news:qlp4a5$qei$1...@dont-email.me...
But I dealt with at least these four above points in my own linkable
library, as well as adding the standard Logical operation names for the
missing logical operations, plus the standard (then) interface for the names
of the Calcomp services (but to disk, not IBM tape), and stream I/O was
already in my 1985 compiler and i used it for work on external RS232
devices. (I had two F77-capable Fortran compiler, they seemed to be the same
code but one came from MS via IBM and the other from MS via Burroughs B22
standard software). As for fixed format, I still use it. Extremely rarely,
does an instruction of mine exceed a line, unless a format statement. Double
precision I had, but not complex. On the side, I also use a very good Compaq
compiler for 'insist on windows execution' work, with a Windows-compatible
matching library of all of the above.
Terence
Sep 18, 2019, 6:59:35 PM9/18/19
to
Robin noted:-
know this was that uncommon.
For the record: In 1953 I was helping build one of the early computers at
Blackburn Aircraft using vacuum triodes and a teleprinter with a built-in
paper tape reader as the I/O system. We were trying to find why aeroplane
tails tended to fall off on Polar routes but not the alternative southern
route. Perhaps you saw the later movie?
You wonder why I may be "old-fashioned"? But I was flying real working
planes (DH. Rapide, and Tiger Moth) from wartime coastal airfields, in
1946, courtesy British Air League.
> >>> > What really was wrong with "good old F77" Fortran?
>> Using just IMPLICIT NONE or DO-ENDDO gets you past "good old F77".
>Everyone has his/her reasons for getting past F77.
>But IMHO the most important ones are IMPLICIT NONE and free source form.
>Free source form eliminates many typos that were ignored by F77
>on account of blanks being ignored [except in character strings].
>IMPLICIT NONE has much the same advantage.
BUT.. My MS V3.31 F77 compiler HAS "IMPLICIT NONE" and I use it. I didn't
>Everyone has his/her reasons for getting past F77.
>But IMHO the most important ones are IMPLICIT NONE and free source form.
>Free source form eliminates many typos that were ignored by F77
>on account of blanks being ignored [except in character strings].
>IMPLICIT NONE has much the same advantage.
know this was that uncommon.
For the record: In 1953 I was helping build one of the early computers at
Blackburn Aircraft using vacuum triodes and a teleprinter with a built-in
paper tape reader as the I/O system. We were trying to find why aeroplane
tails tended to fall off on Polar routes but not the alternative southern
route. Perhaps you saw the later movie?
You wonder why I may be "old-fashioned"? But I was flying real working
planes (DH. Rapide, and Tiger Moth) from wartime coastal airfields, in
1946, courtesy British Air League.
Sjouke Burry
Sep 18, 2019, 7:17:35 PM9/18/19
to
On 19.09.19 0:37, Terence wrote:
>
>
> "steve kargl" wrote in message news:qlp4a5$qei$1...@dont-email.me...
>
> Terence wrote:
>
>> I read these several related postings about problems with this and that
>> new
>> versions of Fortran compilers, and then read the wise responses of Robin
>> Vowels, and I shake my head in disbelief.
>>
>> What really was wrong with "good old F77" Fortran?
>
> We've been down this road before.
>
> 1) Proper dynamic memory management.
> 2) Fixed source form with a 6 character limit for names.
> 3) Lack of stream IO
> 4) No intrinsic type for double precision complex
>
> Shall I continue?
>
My old f77 compiler supports long double, used it with fractal software.
>
>
> "steve kargl" wrote in message news:qlp4a5$qei$1...@dont-email.me...
>
> Terence wrote:
>
>> I read these several related postings about problems with this and that
>> new
>> versions of Fortran compilers, and then read the wise responses of Robin
>> Vowels, and I shake my head in disbelief.
>>
>> What really was wrong with "good old F77" Fortran?
>
> We've been down this road before.
>
> 1) Proper dynamic memory management.
> 2) Fixed source form with a 6 character limit for names.
> 3) Lack of stream IO
> 4) No intrinsic type for double precision complex
>
> Shall I continue?
>
steve kargl
Sep 18, 2019, 7:30:40 PM9/18/19
to
using an intrinsic type required by the Fortran 77 standard. F77 did
have an intrinsic type for COMPLEX that was complementary to DOUBLE
PRECISION.
--
steve
robin....@gmail.com
Sep 18, 2019, 7:39:11 PM9/18/19
to
On Thursday, September 19, 2019 at 9:30:40 AM UTC+10, steve kargl wrote:
> Sjouke Burry wrote:
>
> > On 19.09.19 0:37, Terence wrote:
> >>
> >>
> >> "steve kargl" wrote in message news:q.....@dont-email.me...
> Sjouke Burry wrote:
>
> > On 19.09.19 0:37, Terence wrote:
> >>
> >>
> >>
> >> Terence wrote:
> >>
> >>> I read these several related postings about problems with this and that
> >>> new
> >>> versions of Fortran compilers, and then read the wise responses of Robin
> >>> Vowels, and I shake my head in disbelief.
> >>>
> >>> What really was wrong with "good old F77" Fortran?
> >>
> >> We've been down this road before.
> >>
> >> 1) Proper dynamic memory management.
> >> 2) Fixed source form with a 6 character limit for names.
> >> 3) Lack of stream IO
> >> 4) No intrinsic type for double precision complex
> >>
> >> Shall I continue?
> >>
> > My old f77 compiler supports long double, used it with fractal software.
>
> If by "long double" you mean DOUBLE PRECISION, then you were
> using an intrinsic type required by the Fortran 77 standard. F77 did
> have an intrinsic type for COMPLEX that was complementary to DOUBLE
> PRECISION.
But not double precision complex.
> >> Terence wrote:
> >>
> >>> I read these several related postings about problems with this and that
> >>> new
> >>> versions of Fortran compilers, and then read the wise responses of Robin
> >>> Vowels, and I shake my head in disbelief.
> >>>
> >>> What really was wrong with "good old F77" Fortran?
> >>
> >> We've been down this road before.
> >>
> >> 1) Proper dynamic memory management.
> >> 2) Fixed source form with a 6 character limit for names.
> >> 3) Lack of stream IO
> >> 4) No intrinsic type for double precision complex
> >>
> >> Shall I continue?
> >>
> > My old f77 compiler supports long double, used it with fractal software.
>
> If by "long double" you mean DOUBLE PRECISION, then you were
> using an intrinsic type required by the Fortran 77 standard. F77 did
> have an intrinsic type for COMPLEX that was complementary to DOUBLE
> PRECISION.
Sjouke Burry
Sep 18, 2019, 8:15:28 PM9/18/19
to
written in C by me a few years ago.
definition from mandel.c:
long double xb,xe,yb,ye,dx,dy,x,y,a,b,c,d,u,delta=.000004l;
So MS C 6.00A has 80 bit doubles.
That means no rounding when transferring to or from memory.
The FPU is 80 bit.
And produces vey nice,deep zoom pictures.
Ron Shepard
Sep 18, 2019, 8:50:49 PM9/18/19
to
On 9/18/19 5:59 PM, Terence wrote:
>> IMPLICIT NONE has much the same advantage.
>
> BUT.. My MS V3.31 F77 compiler HAS "IMPLICIT NONE" and I use it. I
> didn't know this was that uncommon.
I would say that was a common extension, but it was an extension, it was
>> IMPLICIT NONE has much the same advantage.
>
> BUT.. My MS V3.31 F77 compiler HAS "IMPLICIT NONE" and I use it. I
> didn't know this was that uncommon.
not part of the standard language.
$.02 -Ron Shepard
Ron Shepard
Sep 18, 2019, 8:55:53 PM9/18/19
to
On 9/18/19 6:30 PM, steve kargl wrote:
> Sjouke Burry wrote:
> Sjouke Burry wrote:
>> My old f77 compiler supports long double, used it with fractal software.
>
> If by "long double" you mean DOUBLE PRECISION, then you were
> using an intrinsic type required by the Fortran 77 standard. F77 did
> have an intrinsic type for COMPLEX that was complementary to DOUBLE
> PRECISION.
I think you mean "did NOT have an intrinsic..."
>
> If by "long double" you mean DOUBLE PRECISION, then you were
> using an intrinsic type required by the Fortran 77 standard. F77 did
> have an intrinsic type for COMPLEX that was complementary to DOUBLE
> PRECISION.
COMPLEX*16, which was complementary to DOUBLE PRECISION on some machines
was an extension to the standard.
Also, there were two different f77 standards defined in the ANSI
document. I think that DOUBLE PRECISION itself was only in one of them.
$.02 -Ron Shepard
steve kargl
Sep 19, 2019, 12:14:26 PM9/19/19
to
do not make it into text.
--
steve
Ev. Drikos
Nov 5, 2019, 1:11:35 PM11/5/19
to
On 15/09/2019 7:51 PM, JRR wrote:
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
Once users can choose from a number of compilers why one should worry?
> Of course, with gfortran, ifort and NAG available, one could ask
> the question: why is it important to support or investigate that
> compiler? That's true, the point I am worried is the integration
> of flang/f18 into LLVM (and maybe Apple LLVM clang) which seem to
> be based on the open source version of PGI. So at some point I have
> the vision of people approaching us using the LLVM fortran (based
> on PGI) in the future utterly failing to run our code with it.
BTW, I faced a regression with the installation of Whizard (2.8.2) on
macOS (10.13). The test case "os_interface" required installation of the
project first (hope this isn't out of topic in c.l.f.).
Ev. Drikos
----------------------------------------------------------------------------
tarball: whizard-2.8.2.tar.gz:
requires: gfortran-8.2 (ie)
ocalm-4.09 (ie)
GNU sed (is this perhaps a prerequisite on a Mac?)
install: configure
make
make check
...
FAIL: ./os_interface.run
...
sudo make install
make check
...
PASS: os_interface.run
...
Whereas only these 3 tests were marked with XFAIL:
XFAIL: colors_hgg.run
...
XFAIL: hadronize_1.run
...
XFAIL: user_cuts.run
...
============================================================================
Testsuite summary for WHIZARD 2.8.2
============================================================================
# TOTAL: 292
# PASS: 243
# SKIP: 46
# XFAIL: 3
# FAIL: 0
# XPASS: 0
# ERROR: 0
JRR
Nov 6, 2019, 9:52:28 AM11/6/19
to
Hi Evangelos,
cool to see that you are so interested in our software. In our INSTALL
file you see that
Darwin >= 10.11: The security measures of the new
Darwin systems do not allow e.g. environment variables passed
to subprocesses. This does not change anything for the installed
WHIZARD, but the testsuite (make check) will not work probably even
after make install has been executed. make distcheck will not work on
Darwin >= 10.11. There is also the option to disable the System Integrity
Protocol (SIP) of El Capitan by booting in Recovery Mode (use Command R
while booting), open a terminal and type 'csrutil disable'. However, we
do not recommend to do so unless you know exactly what you are doing.
So this is not totally unsurprising. Or do you have SIP disabled?
I haven't run things on Darwin 10.13 for a long time. But I am not sure
what should have changed on our side.
Cheers,
JRR
Am 06.11.19 um 03:11 schrieb Ev. Drikos:
cool to see that you are so interested in our software. In our INSTALL
file you see that
Darwin >= 10.11: The security measures of the new
Darwin systems do not allow e.g. environment variables passed
to subprocesses. This does not change anything for the installed
WHIZARD, but the testsuite (make check) will not work probably even
after make install has been executed. make distcheck will not work on
Darwin >= 10.11. There is also the option to disable the System Integrity
Protocol (SIP) of El Capitan by booting in Recovery Mode (use Command R
while booting), open a terminal and type 'csrutil disable'. However, we
do not recommend to do so unless you know exactly what you are doing.
So this is not totally unsurprising. Or do you have SIP disabled?
I haven't run things on Darwin 10.13 for a long time. But I am not sure
what should have changed on our side.
Cheers,
JRR
Am 06.11.19 um 03:11 schrieb Ev. Drikos:
Ev. Drikos
Nov 6, 2019, 2:37:38 PM11/6/19
to
On 06/11/2019 4:52 PM, JRR wrote:
> Hi Evangelos,
> cool to see that you are so interested in our software...
> Hi Evangelos,
A large project using modern Fortran is good news and when you sought
advice in c.l.f I wanted to have an overall picture of any Mac issues.
> ... This does not change anything for the installed
> WHIZARD, but the testsuite (make check) will not work probably even
> after make install has been executed. make distcheck will not work on
> Darwin >= 10.11. There is also the option to disable the System Integrity
> Protocol (SIP) of El Capitan by booting in Recovery Mode (use Command R
> while booting), open a terminal and type 'csrutil disable'. However, we
> do not recommend to do so unless you know exactly what you are doing.
>
> So this is not totally unsurprising. Or do you have SIP disabled?
Just run `csrutil status` and confirmed that the status is enabled. Note
> after make install has been executed. make distcheck will not work on
> Darwin >= 10.11. There is also the option to disable the System Integrity
> Protocol (SIP) of El Capitan by booting in Recovery Mode (use Command R
> while booting), open a terminal and type 'csrutil disable'. However, we
> do not recommend to do so unless you know exactly what you are doing.
>
> So this is not totally unsurprising. Or do you have SIP disabled?
though that I'd run only `make check`, not `make distcheck` which fails
as you have described but I'm not aware how one is supposed to use it.
> I haven't run things on Darwin 10.13 for a long time. But I am not sure
> what should have changed on our side.
on macOS or use the "install_name_tool" to alter some paths on binaries.
Yet, macOS 10.13 is perhaps outdated now, the current version is 10.15.
Ev. Drikos
Lynn McGuire
Nov 6, 2019, 6:29:19 PM11/6/19
to
Lynn
Terence
Nov 6, 2019, 10:00:38 PM11/6/19
to
"Lynn McGuire" wrote in message news:qpvl0c$fpj$1...@dont-email.me...
>On 9/18/2019 5:59 PM, Terence wrote:
>> For the record: In 1953 I was helping build one of the early computers at
>> Blackburn Aircraft using vacuum triodes and a teleprinter with a built-in
>> paper tape reader as the I/O system. We were trying to find why aeroplane
>> tails tended to fall off on Polar routes but not the alternative southern
>> route. Perhaps you saw the later movie?
>What was the name of the movie ?
>Lynn
Movie was titled "Highway in the sky".
>Lynn
Basic facts OK; story modified to suite commercial interests about
ticketing.
Terence
Michael Siehl
Nov 7, 2019, 11:59:27 AM11/7/19
to
https://www.youtube.com/watch?v=UVxyzpab3wE&list=PLw5RjD3KcbeneCf6WEGfGmM6WfJHD8LjR
My respect anyway.
Terence
Nov 8, 2019, 6:16:18 PM11/8/19
to
"Michael Siehl" wrote in message
news:7a7297a5-a264-44bf...@googlegroups.com...
Am Donnerstag, 7. November 2019 04:00:38 UTC+1 schrieb Terence:
> "Lynn McGuire" wrote in message news:qpvl0c$fpj$1...@dont-email.me...
>
> >On 9/18/2019 5:59 PM, Terence wrote:
> >> For the record: In 1953 I was helping build one of the early computers
> >> at
> >> Blackburn Aircraft using vacuum triodes and a teleprinter with a
> >> built-in
> >> paper tape reader as the I/O system. We were trying to find why
> >> aeroplane
> >> tails tended to fall off on Polar routes but not the alternative
> >> southern
> >> route. Perhaps you saw the later movie?
>
> >What was the name of the movie ?
> >Lynn
>
> Movie was titled "Highway in the sky".
> Basic facts OK; story modified to suite commercial interests about
> ticketing.
>
> Terence
>>Movie was titled "Highway in the sky".
>Isn't it 'No Highway In The Sky' from 1951?
>https://www.youtube.com/watch?v=UVxyzpab3wE&list=PLw5RjD3KcbeneCf6WEGfGmM6WfJHD8LjR
>My respect anyway.
No. That was a thriller.
>Isn't it 'No Highway In The Sky' from 1951?
>https://www.youtube.com/watch?v=UVxyzpab3wE&list=PLw5RjD3KcbeneCf6WEGfGmM6WfJHD8LjR
>My respect anyway.
The one I saw was maybe 10 years later, about 1 or more war-time boffins
trying to find what was wrong with flying in cold areas. And I recognised
the circumstances.
Aluminium planes were new at war end. Almost all war planes were plywood and
stretched canvas.
I got my flying lessons in 1946 in a 1934 DH Tiger Moth, built that way.
The solution Blackburn Aircraft found was to add some more copper to the
standard aluminium alloy starting to be used in aircraft, like the Oxford
fighter bomber developed near WWII end. Resonance was another factor in the
crystallising formed by the vibrations typical of long steady flights.
Did I mention Blackburn jazzed up the speed of the teleprinter to almost
10cps? Wow!
Thomas Koenig
Nov 9, 2019, 6:25:21 AM11/9/19
to
Terence <tbwr...@cantv.net> schrieb:
> Aluminium planes were new at war end. Almost all war planes were plywood and
> stretched canvas.
Huh?
You the Spitfire, the Me 109, the Bristol Blenheim and the He 111 were
"new at war end"?
> Aluminium planes were new at war end. Almost all war planes were plywood and
> stretched canvas.
You the Spitfire, the Me 109, the Bristol Blenheim and the He 111 were
"new at war end"?
Terence
Nov 9, 2019, 3:52:57 PM11/9/19
to
"Thomas Koenig" wrote in message
news:qq67mv$mcs$1...@newsreader4.netcologne.de...
Several or even most WWII UK planes in action were plywood and canvas:
example: the Hurricane fighter; "Faith, Hope and Charity (the three armed DH
Moths which defended Malta) and similar flights in Burma and China.
Some WWII German planes were higher tech than most British e.g. the Me 109,
which outflew the the Spitfire when in the right hands (but didn't turn as
fast), but the Spit was a pre-war plane designed and built to a new
all-metal spec, put out by the ministry of defence. It used aluminium
versions of the traditional plywood formers and the skin was sheet aluminium
riveted to the formers. I have been seated in one, but never flew one.
However I was also introduced to the Oxford bomber in 1946 and was told at
that time (right or wrong) that this was the first UK aluminium-skinned
bomber. But while getting flying training, the only planes I got to fly or
fly in, from a UK south-coast RAF airstrip, were all pre-war planes like the
DH Moth and the Dragon Rapide twin-engined transport.
My later time at Blackburn was 1951-52, and the tail problem was with the
Beverley bomber.
I actually worked a few years later for DH Propellers, but more in the space
area.
Terence
0 new messages