Which old version is best to use? don't trust Adacore anymore

Which old version is best to use? don't trust Adacore anymore

[patrick]

Hi Everyone

I like C, Ada and my favorite is COBOL. IF I like COBOL it's obvious I don't drink cool-aid. I just don't care about Ada 2005/2013 features.

As you know Adacore removed the pragma ada-83 and ada_95 recently.

Why remove simple features like this that will help people to run older code, They are laying a trap for future use. I am currently chewing bait, waiting for the hook to puncture.

Over here I found:
https://sourceforge.net/projects/gnuada/files/GNAT_P%20Sources/3.15/

I can download it's corresponding GCC and build it but is this the best version that is still GMGPL ?

Are there any security concerns that you know of with this old code? I am sure I could read online but if you happen to know of something that would be great.

Anyone interested in just forking and maintaining the old code and being done with Adacore's GPL-everything that is free, charge 10K for the rest, game ?

-Patrick

Re: Which old version is best to use? don't trust Adacore anymore

[Shark8]

On Wednesday, August 22, 2018 at 5:49:31 AM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Everyone
> 
> I like C, Ada and my favorite is COBOL. IF I like COBOL it's obvious I don't drink cool-aid. I just don't care about Ada 2005/2013 features.
> 
> As you know Adacore removed the pragma ada-83 and ada_95 recently.
> 
> Why remove simple features like this that will help people to run older code, They are laying a trap for future use. I am currently chewing bait, waiting for the hook to puncture.

On one hand I can see how they would want to be able to reduce the size of their "maintenance-area"; something like that would be understandable as a prelude to a re-engineering/massive-refactoring push.

On the other, AdaCore does seem to be focusing on safety-critical / high-reliability marketing almost to the exclusion of general-computing.

> 
> Over here I found:
> https://sourceforge.net/projects/gnuada/files/GNAT_P%20Sources/3.15/
> 
> I can download it's corresponding GCC and build it but is this the best version that is still GMGPL ?

I think if you want to stick with GPL and GNAT you should look at FSF:
https://www.gnu.org/software/gnat/

There's also GetAdaNow, that has a good collection of links: http://getadanow.com/

But I should also mention, especially since you express apathy toward Ada 2005 and 2012 features, RR Software:
http://www.rrsoftware.com/html/companyinf/prices.htm#95nt

> 
> Are there any security concerns that you know of with this old code? I am sure I could read online but if you happen to know of something that would be great.

Not off the top of my head.

> 
> Anyone interested in just forking and maintaining the old code and being done with Adacore's GPL-everything that is free, charge 10K for the rest, game ?

Honestly, I'd rather re-start work on my own compiler project: Byron, which aims to be a Ada 2012 compiler in Ada 2012.

Re: Which old version is best to use? don't trust Adacore anymore

[Jeffrey R. Carter]

On 08/22/2018 01:49 PM, patrick@spellingbeewinnars.org wrote:
> 
> Over here I found:
> https://sourceforge.net/projects/gnuada/files/GNAT_P%20Sources/3.15/
> 
> I can download it's corresponding GCC and build it but is this the best version that is still GMGPL ?

That is very old. There are much newer GMGPL versions available. What platform 
are you using?

-- 
Jeff Carter
"He had no conception of the instrument. He
was blowing into it."
Take the Money and Run
135

Re: Which old version is best to use? don't trust Adacore anymore

[patrick]

64 bit Linux. Thanks

Re: Which old version is best to use? don't trust Adacore anymore

[Anh Vo]

On Wednesday, August 22, 2018 at 11:22:49 AM UTC-7, pat...@spellingbeewinnars.org wrote:
> 64 bit Linux. Thanks

Select drop down menu x86-64 GNU (64 bits) to download it at https://www.adacore.com/download/more

Anh Vo

Re: Which old version is best to use? don't trust Adacore anymore

[patrick]

Hi Anh

All I can find is Gnat GPL versions going back to 2007. Do you know when the last GMGPL was published?

Thanks

Re: Which old version is best to use? don't trust Adacore anymore

[Dan'l Miller]

On Wednesday, August 22, 2018 at 5:23:41 PM UTC-5, pat...@spellingbeewinnars.org wrote:
> Hi Anh
> 
> All I can find is Gnat GPL versions going back to 2007. Do you know when the last GMGPL was published?
> 
> Thanks

GMGPL goes along strictly with GPLv2, the last of which was GNAT 3.15p released on 07 May 2005 (based on GCC 2.8.1, which was also GPLv2).  The post-GPLv2 equivalent of GMGPL is GPLv3 with Runtime Library Exception, which is all modern releases of FSF GNAT within FSF GCC.

Re: Which old version is best to use? don't trust Adacore anymore

[Mark Lorenzen]

On Wednesday, August 22, 2018 at 1:49:31 PM UTC+2, pat...@spellingbeewinnars.org wrote:
> Hi Everyone
> 
> I like C, Ada and my favorite is COBOL. IF I like COBOL it's obvious I don't drink cool-aid. I just don't care about Ada 2005/2013 features.
> 
> As you know Adacore removed the pragma ada-83 and ada_95 recently.
> 
> Why remove simple features like this that will help people to run older code, They are laying a trap for future use. I am currently chewing bait, waiting for the hook to puncture.
> 

What Ada 95-only features are you using, that are not supported by the newest GNAT GPL version in Ada 2012 mode?

Regards,

Mark L

Re: Which old version is best to use? don't trust Adacore anymore

[patrick]

Hi Mark and thanks for your post Dan'l !

It's not that I am missing a feature, it's just that I am tired of Adacore's games and I want to have independence from them. I feel like they are trying to make free Ada compiler options "demo-ware" for their expensive paid options.

As a few side notes, the older GMGPL code looks kinda scary with many patches applied to GCC in order for it to work. 

The FSF version has a linking exception and would be fine if it wasn't so buggy. 

I am looking at the Ada source code in vim with ctags and it is so well laid out and easy to follow along with. I doubt I am smart enough to do this alone(or have time) but I am wondering about starting a thread about how it works internally. If the thread grew and grew if could become a good tutorial to bring more people in. Maybe we could start maintaining GNAT independently of Adacore, I am sure the GCC people would not be opposed to patches.

As another side note, I am frustrated with Adacore but I don't want to direct any negativity at it's wonderful employees or the other GNAT writers who are no longer with us such as Robert Dewer.

Re: Which old version is best to use? don't trust Adacore anymore

[Lucretia]

On Thursday, 23 August 2018 16:32:02 UTC+1, pat...@spellingbeewinnars.org  wrote:

> As a few side notes, the older GMGPL code looks kinda scary with many patches applied to GCC in order for it to work. 

If you think that's scary, wait until you get into GCC-land.

Re: Which old version is best to use? don't trust Adacore anymore

[Simon Wright]

patrick@spellingbeewinnars.org writes:

> It's not that I am missing a feature, it's just that I am tired of
> Adacore's games and I want to have independence from them. I feel like
> they are trying to make free Ada compiler options "demo-ware" for
> their expensive paid options.

Why are you surprised?

> The FSF version has a linking exception and would be fine if it wasn't
> so buggy.

I don't recognise this. How is it "so buggy"? Do you think that 3.15p
isn't buggy?

> I am looking at the Ada source code in vim with ctags and it is so
> well laid out and easy to follow along with.

It is possible to follow the GNAT source code with GPS/Emacs, provided
you construct a GPR for it (I've only tried this with a development
source/object tree; probably not that hard with an installed
compiler). Understanding it is a different matter.

>                                                       Maybe we could
> start maintaining GNAT independently of Adacore, I am sure the GCC
> people would not be opposed to patches.

GCC welcome patches (though the bar for acceptance is pretty high). Be
aware, though, that the gatekeepers for patches to Ada are almost all
AdaCore employees (how could it be otherwise?) and your patch has to fit
in with their plans. (Sometimes this means that the best is the enemy of
the good.) You stand more chance if it's a problem with the libraries or
with a particular build environment, rather than the compiler internals.

> As another side note, I am frustrated with Adacore but I don't want to
> direct any negativity at it's wonderful employees or the other GNAT
> writers who are no longer with us such as Robert Dewer.

Dewar

Re: Which old version is best to use? don't trust Adacore anymore

[patrick]

Hi Simon

Actually I use pretty simple features and I am not experiencing bugs, I was just going on what has been said on this list.

This version of ctags works with Ada:
https://github.com/rtyler/ctags

So far things are going well.

The FSF is very democratic-oriented. If this is a group effort, patches will probably make it past the gatekeepers if the patches are in the best interest of the community.

If your not surprised about the demo-ware comment, maybe you could chip in, your smarter than I am :)

Re: Which old version is best to use? don't trust Adacore anymore

[Brad Moore]

On Friday, August 24, 2018 at 6:44:10 AM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Simon
> 
> Actually I use pretty simple features and I am not experiencing bugs, I was just going on what has been said on this list.
> 
> This version of ctags works with Ada:
> https://github.com/rtyler/ctags
> 
> So far things are going well.
> 
> The FSF is very democratic-oriented. If this is a group effort, patches will probably make it past the gatekeepers if the patches are in the best interest of the community.
> 
> If your not surprised about the demo-ware comment, maybe you could chip in, your smarter than I am :)

To me, the Adacore decision to not support earlier versions of the Ada standard in the "Community" GPL version seems like a sensible one.

The community edition encourages one to use the current standard version of the language. If one doesn't want to use newer language features, don't use them, your code should still compile.

There is value in at least knowing that the code is forward compatible to the current version of the language standard.

The FSF version supports the current version as well as older versions of the standard.

I have some libraries I maintain, with portability in mind, and maintain different versions of the code, so that the code bases for the older language standards will compile with vendors who do not yet support later versions of the standard, but also allowing me to try out and take advantage of newer language features in the newer code bases. 

For code bases that are written for older versions of the language, I do like to know that that code still compiles with newer versions of the standard. If I want to test forward compatibility, I might use the community edition to compile the code. If I want to make sure say that the Ada 95 version of the code is not using any later versions of the standard, I compile with the FSF compiler with the Ada 95 flag set (Or alternatively, use the FSF compile with the Ada 2012 flag set). At least there is a way to get the best of both worlds,
which I very much appreciate.

I recall Robert Dewar saying something to the effect, the greatest thing about Ada 2012 is that it is built on Ada 2005. The greatest thing about Ada 2005 is that it is built on Ada 95. The greatest thing about Ada 95 is that it is built on Ada 83. 

There are a few cases of backwards incompatibility, but for the most part a program written in Ada 83 will still compile in Ada 2012.

I recently ported a larger system of Ada code from Ada 83 to Ada 2012, from one compiler vendor to another, from one target platform to another (different OS, and different architecture. I was pleasantly surprised how little effort it took to do this. (Changing OS, Vendor, language standard version, target architecture) 

I also recently ported a set of applications written in C++ to just a newer version of the compiler provided by the same vendor, on the same OS (but newer version), same architecture. It was very painful, and consumed a much larger allotment of time and energy (in terms of time and mancount). (Same OS, just newer version, Same target architecture, same compiler vendor, just newer version of compiler)

Your mileage may vary, of course, but my experience has been that Ada code generally has good portablility, when compared to some other environments.

I also find the FSF version of the compiler to be of good quality, and pretty stable. When a new version of the standard comes out, there is a time when the newer introduced language features might be buggy, or not fully implemented, but as time goes on, these bugs tend to get addressed. It's been my experience that older language features work similarly well between the Adacore GPL version, and the FSF version. 

Brad