sad year

[Jean-Claude Arbaut]

Absoft site: https://www.absoft.com/

Absoft Corporation has stopped selling new products as of September 30th, 2022.

Lahey site: http://www.lahey.com/

Effective December 31, 2022, Lahey Computer Systems, Inc. will no longer license Fortran language systems.

Sad times for Fortran. All my wishes to those who made it thrive all those years.

Jean-Claude Arbaut

[John McCue]

Jean-Claude Arbaut <arba...@gmail.com> wrote:
> Absoft site: https://www.absoft.com/
>
> Absoft Corporation has stopped selling new products
> as of September 30th, 2022.
>
> Lahey site: http://www.lahey.com/
>
> Effective December 31, 2022, Lahey Computer Systems, Inc. will
> no longer license Fortran language systems.

Interesting, I wonder if they will opensource these products ?
One can hope :)

Yes, I doubt they will, but I thought I heard the EU (I think)
may force companies to opensource abandoned software.

<snip>
>
> Jean-Claude Arbaut

John

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

[Lynn McGuire]

With Intel Fortran and GFortran being free, do you think that they
caused all the other Fortran compilers to cease selling ?

Thanks,
Lynn

[Jean-Claude Arbaut]

They survived gfortran for a long time, but Intel going free may have been the last straw.

However I don't think it's what mattered most, as they were both relatively cheap: not being able to upgrade the compilers to the later revisions of the standard was unsustainable. Neither ever implemented Fortran 2003, which was published almost 20 years ago. The classic Lahey compiler was stuck at 32-bit Fortran 95, I don't know much about LGF, but it seems to be based on gfortran.

I know the Absoft compiler better, as I have a license and all upgrades since 2009: they implemented some of Fortran 2003, mainly intrinsics, but not the OO stuff. If I understand correctly, the Fortran 95 frontend was developed in partnership with Cray, maybe Fortran 2003 was just too much to handle alone.

To be honest, in the recent years I was increasingly worried that my beloved Absoft compiler would just disappear. The Lahey site didn't look very lively either.

Sad, but predictable.

Jean-Claude Arbaut

[Ron Shepard]

I used the ABSOFT compiler starting about 2001 on the Mac. It was one of
the first fortran compilers to run on the unix-based MacOSX. I stopped
upgrading about 5 years ago as my codes started to have enough f2003
features that they would no longer compile. One good feature about the
compiler was the interactive debugger. It was probably the best fortran
debugger I've used. I hope that lives on somehow, as open source or a
separate product or something.

$.02 -Ron Shepard

[Gary Scott]

On 12/7/2022 9:16 AM, Ron Shepard wrote:
> On 12/7/22 6:59 AM, Jean-Claude Arbaut wrote:
>> Le mercredi 7 décembre 2022 à 04:07:38 UTC+1, Lynn McGuire a écrit :
>>> On 12/6/2022 5:10 PM, Jean-Claude Arbaut wrote:

snip

>>
>> To be honest, in the recent years I was increasingly worried that my
>> beloved Absoft compiler would just disappear. The Lahey site didn't
>> look very lively either.
>>
>> Sad, but predictable.
>>
>> Jean-Claude Arbaut
>
> I used the ABSOFT compiler starting about 2001 on the Mac. It was one of
> the first fortran compilers to run on the unix-based MacOSX. I stopped
> upgrading about 5 years ago as my codes started to have enough f2003
> features that they would no longer compile. One good feature about the
> compiler was the interactive debugger. It was probably the best fortran
> debugger I've used. I hope that lives on somehow, as open source or a
> separate product or something.
>

I stopped using both Lahey and Absoft because they weren't sufficiently
compatible with MS Fortran Powerstation and various DEC extensions.
Eventually, the standard evolved to where I no longer need any
extensions, but I continued to need cray pointers for some things until
fairly recently. Now the only extension I use is the bb#xxxx number
format extension because I despise the boz z' ' format style and it
supports bases from 2 to 36.

> $.02 -Ron Shepard

[Lynn McGuire]

We have used the old Watcom F77 and C/C++ compilers to date because of
the excellent Windows interactive debugger. One of the most important
things to us is being able to stop at the 457th call to a subroutine, it
accomplishes that with ease. But, the F77 compiler debugging broke with
Windows 10. It is one of the reasons why we are moving to Visual Studio.

Lynn

[gah4]

On Wednesday, December 7, 2022 at 12:43:14 PM UTC-8, Lynn McGuire wrote:

(snip)

> We have used the old Watcom F77 and C/C++ compilers to date because of
> the excellent Windows interactive debugger. One of the most important
> things to us is being able to stop at the 457th call to a subroutine, it
> accomplishes that with ease. But, the F77 compiler debugging broke with
> Windows 10. It is one of the reasons why we are moving to Visual Studio.

The Watcom compilers were my favorite for OS/2 1.x days. Though sometimes
I would use the Watcom linker and MS compilers.

With OS/2 1.x, allocating one segment for each array, or each column of a 2D
array got hardware bounds checking for free. Also, OS/2 gives the exact
address where the program died, which I could easily trace back to where
it was in the program. (That might be a lost art by now.)

With 32 bit OS/2, I would also use the Watcom compilers, but the segment
advantage was gone. It might be that it can be done in OS/2, but no other
IA32 OS use multiple segment selectors.

As for hex constants, I used them back to OS/360 days, where IBM
uses the Znnnnnnn form, no apostrophes, and only allows them
in DATA statements. (They would be ambiguous anywhere else.)

VAX/VMS Fortran also allowed for Z constants. Much fun is the
byte order for VAX floating point values, which is visible in Z
constants.

[FortranFan]

On Wednesday, December 7, 2022 at 3:43:14 PM UTC-5, Lynn McGuire wrote:

> ..

> We have used the old Watcom F77 and C/C++ compilers to date because of
> the excellent Windows interactive debugger. One of the most important
> things to us is being able to stop at the 457th call to a subroutine, it
> accomplishes that with ease. But, the F77 compiler debugging broke with
> Windows 10. It is one of the reasons why we are moving to Visual Studio.

> ..

Microsoft's Visual Studio IDE, in spite of some shortcomings, is currently a far better IDE than all the other IDEs. This is especially the case on Windows OS.

And with the Intel Fortran on Windows OS with its integration with Microsoft Visual Studio, and which is now available *without having to procure a paid license*, provides an excellent debugging environment for most Fortran codes. This is especially the case in spite of certain limitations with this Intel's free product.

Re: "One of the most important things to us is being able to stop at the 457th call to a subroutine," this can be easily accomplished on Windows OS with Microsoft Visual Studio and Intel Fortran oneAPI HPC toolkit with Fortran codes. All one has to do is to learn how to use the *Hit Count Breakpoints* facility in Visual Studio:
https://devblogs.microsoft.com/devops/hit-count-breakpoints/

This "Hit Count Breakpoints" facility works the same with Fortran codes in Visual Studio using Intel Fortran as they do with codes in other languages such as Microsoft C/C++, C#, Visual Basic, etc.

"being able to stop at the 457th call to a subroutine" is readily achievable with Microsoft Visual Studio and Intel Fortran assuming the subroutine does indeed get called that many times.

[fiz...@gmail.com]

Isn't this the same as setting a break point and an ignore count in gdb, the GNU debugger?

[Lynn McGuire]

Probably.

Thanks,
Lynn