Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it hidden somewhere or just not supported?
On 1/22/2024 4:29 PM, Gary Scott wrote:
Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it
hidden somewhere or just not supported?
I cannot get Intellisense or function lookup to work either using the community version of VS2019.
Lynn
On 1/23/2024 3:31 PM, Lynn McGuire wrote:OK, I've successfully set a bookmark to extracted folder in chrome.
On 1/22/2024 4:29 PM, Gary Scott wrote:I'm presently researching. It appears you have to manually download zip files and manually target to an obscure directory and extract the zip
Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it
hidden somewhere or just not supported?
I cannot get Intellisense or function lookup to work either using the
community version of VS2019.
Lynn
files to that directory...sheesh...used to be so much better/turn key.
On 1/23/2024 3:31 PM, Lynn McGuire wrote:
On 1/22/2024 4:29 PM, Gary Scott wrote:I'm presently researching. It appears you have to manually download zip files and manually target to an obscure directory and extract the zip
Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it
hidden somewhere or just not supported?
I cannot get Intellisense or function lookup to work either using the
community version of VS2019.
Lynn
files to that directory...sheesh...used to be so much better/turn key.
On 1/23/2024 3:48 PM, Gary Scott wrote:
On 1/23/2024 3:31 PM, Lynn McGuire wrote:
On 1/22/2024 4:29 PM, Gary Scott wrote:I'm presently researching. It appears you have to manually download
Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it
hidden somewhere or just not supported?
I cannot get Intellisense or function lookup to work either using the
community version of VS2019.
Lynn
zip files and manually target to an obscure directory and extract the
zip files to that directory...sheesh...used to be so much better/turn
key.
I would really, really, really like to open a file that I am calling in
a subroutine (open file is greyed out on the right mouse menu) and have intellisense tell me something when I hover over the call. Such as:
CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL)
The integration is not complete. I have 3,000 subroutines in one DLL
and 5,000 subroutines in another DLL. Having to look up a called subroutine manually is a pain. But, if the compiler notes that a subroutine has a problem, you can double click on the message and get
the subroutine to open. Weird.
Thanks,
Lynn
On 1/23/2024 5:59 PM, Lynn McGuire wrote:Of course, MS doesn't make it so easy :(
On 1/23/2024 3:48 PM, Gary Scott wrote:I'm pretty sure they don't understand the meaning of "IDE integration"
On 1/23/2024 3:31 PM, Lynn McGuire wrote:
On 1/22/2024 4:29 PM, Gary Scott wrote:I'm presently researching. It appears you have to manually download
Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it
hidden somewhere or just not supported?
I cannot get Intellisense or function lookup to work either using
the community version of VS2019.
Lynn
zip files and manually target to an obscure directory and extract the
zip files to that directory...sheesh...used to be so much better/turn
key.
I would really, really, really like to open a file that I am calling
in a subroutine (open file is greyed out on the right mouse menu) and
have intellisense tell me something when I hover over the call. Such as: >>
CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL) >>
The integration is not complete. I have 3,000 subroutines in one DLL
and 5,000 subroutines in another DLL. Having to look up a called
subroutine manually is a pain. But, if the compiler notes that a
subroutine has a problem, you can double click on the message and get
the subroutine to open. Weird.
Thanks,
Lynn
any more.
CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL)
I'm pretty sure they don't understand the meaning of "IDE integration"
any more.
On Tue, 23 Jan 2024 18:30:12 -0600, Gary Scott wrote:Visual Studio
I'm pretty sure they don't understand the meaning of "IDE integration"
any more.
Is that integration with your IDE development environment?
On Tue, 23 Jan 2024 17:59:59 -0600, Lynn McGuire wrote:
CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL)
Are people still stuck with 6-letter names? I thought we left that behind with FORTRAN 66 ...
On Tue, 23 Jan 2024 17:59:59 -0600, Lynn McGuire wrote:
CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL)
Are people still stuck with 6-letter names? I thought we left that behind with FORTRAN 66 ...
Much Fortran code was written under the F66 rules until the late 1980s
if you supported multiple platforms (we supported ten platforms in the 1980s).
You can update it to longer names at your own peril.
Why is that still the case?
Longer names have been allowed for going back
about a third of a century now.
Why did it take vendors so long to catch up to FORTRAN 77?
On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:
Much Fortran code was written under the F66 rules until the late 1980s
if you supported multiple platforms (we supported ten platforms in the
1980s).
Why did it take vendors so long to catch up to FORTRAN 77?
By the way, I thought the limit on identifier length had been lifted in FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
to 31.
On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
Much Fortran code was written under the F66 rules until the late 1980s
if you supported multiple platforms (we supported ten platforms in the
1980s).
Why did it take vendors so long to catch up to FORTRAN 77?
By the way, I thought the limit on identifier length had been lifted in FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
to 31.
You can update it to longer names at your own peril.
Why is that still the case? Longer names have been allowed for going back about a third of a century now.
In <uovrpj$2okd6$2@dont-email.me> Lawrence D'Oliveiro:
[Snip...]
Why is that still the case?
Longer names have been allowed for going back
about a third of a century now.
Suppose you're in charge of CERN, and responsibile for integrating
2 bazillion lines of particle physics code in libraries resembling
the Tower of Babel.
Chances are very good you have this tattooed on your forehead:
IF IT AIN'T BROKE, DON'T FIX IT.
Harold Stevens <wookie@aspen.localdomain> schrieb:
In <uovrpj$2okd6$2@dont-email.me> Lawrence D'Oliveiro:
[Snip...]
Why is that still the case?
Longer names have been allowed for going back
about a third of a century now.
Suppose you're in charge of CERN, and responsibile for integrating
2 bazillion lines of particle physics code in libraries resembling
the Tower of Babel.
Then you have about the chance of a snowball in a Supernova of
avoiding name conflicts in your subroutines and COMMON blocks
if you stick to six-letter identifiers.
On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:
Much Fortran code was written under the F66 rules until the late 1980s
if you supported multiple platforms (we supported ten platforms in the
1980s).
Why did it take vendors so long to catch up to FORTRAN 77?
By the way, I thought the limit on identifier length had been lifted in FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
to 31.
You can update it to longer names at your own peril.
Why is that still the case? Longer names have been allowed for going back about a third of a century now.
Suppose you're in charge of CERN, and responsibile for integrating 2 bazillion lines of particle physics code in libraries resembling the
Tower of Babel.
And if you don't understand what it does, would you trust it enough to publish a paper with? :-)
Fortran 90 where it went wrong - standard was very late, the
implementations came late (with the exception of NAG, which was very
fast), and g77 (which was part of the gcc suite) was F77.
Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
eventually went into F90 (long procedure/variable names (63 chars), free
form source, full complement of end statements, async IO (although a different form), "Purdue" bit intrinsics (1753), and many others). They
were way ahead of the standard, but there's always risk in adding
extensions. These were however essential to make the systems usable for real-time programming (in addition to program priority control, process initiation/termination, hardware interrupt handling/processing, shared
memory access and control, etc.)
On Fri, 26 Jan 2024 13:15:15 -0600, Gary Scott wrote:
Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
eventually went into F90 (long procedure/variable names (63 chars), free
form source, full complement of end statements, async IO (although a
different form), "Purdue" bit intrinsics (1753), and many others). They
were way ahead of the standard, but there's always risk in adding
extensions. These were however essential to make the systems usable for
real-time programming (in addition to program priority control, process
initiation/termination, hardware interrupt handling/processing, shared
memory access and control, etc.)
Strange, isn’t it. PL/I was supposed to be the language with all of that-- I gather it was even going to be called “FORTRAN VI” at one point.
That never caught on much (outside of IBM). Yet Fortran has ended up reinventing a lot of it.
On 1/26/2024 10:43 PM, Lawrence D'Oliveiro wrote:
[PL/I] never caught on much (outside of IBM). Yet Fortran has ended up
reinventing a lot of it.
Prime computer used PL/1 to rewrite the Primos Operating System in from Fortran (66, I think).
On Fri, 26 Jan 2024 18:42:16 -0000 (UTC), Thomas Koenig wrote:
Fortran 90 where it went wrong - standard was very late, the
implementations came late (with the exception of NAG, which was very
fast), and g77 (which was part of the gcc suite) was F77.
Still, I had a look at the spec, and Fortran 90 was quite a breathtaking advance.
Fortran 90 was a modern programming language including all
the useful features of C (except unsigned numbers), but surpassing it in power by far.
On Sat, 27 Jan 2024 11:04:21 -0000 (UTC), Thomas Koenig wrote:
Fortran 90 was a modern programming language including all
the useful features of C (except unsigned numbers), but surpassing it in
power by far.
It even does recursive functions/subroutines. But you must explicitly declare them RECURSIVE, which C doesn’t.
On the plus side, seems it has a proper MODULE import facility
(reminiscent of Ada), as opposed to relying on the #include hack.
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
You shouldn’t need separate syntax to enable something that should be available as a matter of course.
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
You shouldn’t need separate syntax to enable something that should be
available as a matter of course.
What "should be available as a matter of course" is very much an
opinion ...
Just one example: Stack sizes are severely limited even on modern
systems ...
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:Definitely should NOT be the default.
On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
You shouldn’t need separate syntax to enable something that should be
available as a matter of course.
What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.
Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.
So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
You shouldn’t need separate syntax to enable something that should be
available as a matter of course.
What "should be available as a matter of course" is very much an
opinion, and there are two sides to that argument what should be the
default.
Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to crash mysteriously with recursive subrotines, on modern systems.
So, should a compiler by default follow F2018 (which makes procedures recursive by default) or not? Hmmm...
I submitted a patch to implement the NON_RECURSIVE prefix and made the
change to make procedure recursive by default. It's in bugzilla. Janne
and I had a short discussion, and we are both leary of what might happen
with the stack; particular for an OS that provides a small stack.
On Sun, 28 Jan 2024 16:41:21 -0000 (UTC), Steven G. Kargl wrote:
I submitted a patch to implement the NON_RECURSIVE prefix and made the
change to make procedure recursive by default. It's in bugzilla. Janne
and I had a short discussion, and we are both leary of what might happen
with the stack; particular for an OS that provides a small stack.
Large objects tend to be variable in size anyway; how do you deal with
that?
Do you stop and restart the program with a different global
allocation size?
In modern languages, we do most dynamic allocations, especially large
ones, in the heap.
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
In modern languages, we do most dynamic allocations, especially large
ones, in the heap.
Assume you have a fixed-size buffer for some sort of blocked algorithm. Where do you put it? If you make your subroutine recursive, where it
wasn't before, you suddenly end up using a lot more stack, which then
can crash a user's program.
And changing the default would cause that crash without source code modification... which is bad.
On 1/28/2024 2:54 AM, Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly >>>>> declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
You shouldn’t need separate syntax to enable something that should be
available as a matter of course.
What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.
Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.
So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...
Definitely should NOT be the default.
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.
It's the functionality that counts, not the syntax.
You shouldn’t need separate syntax to enable something that should be
available as a matter of course.
What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.
Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.
So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...
On Mon, 29 Jan 2024 06:54:14 -0000 (UTC), Thomas Koenig wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
In modern languages, we do most dynamic allocations, especially large
ones, in the heap.
Assume you have a fixed-size buffer for some sort of blocked algorithm.
Where do you put it? If you make your subroutine recursive, where it
wasn't before, you suddenly end up using a lot more stack, which then
can crash a user's program.
And changing the default would cause that crash without source code
modification... which is bad.
Precisely my point.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 119:16:24 |
| Calls: | 12,958 |
| Files: | 186,574 |
| Messages: | 3,265,634 |