AdaCore's survey regarding the future of GNAT Community Edition

[Wesley Pan]

I just discovered this via Ada Planet...

Link to the Google Docs survey: https://docs.google.com/forms/d/e/1FAIpQLSet9x3UNUFmfWt5v-8Jb7dW8BgKiJxyEMJ_TFm0G2UJKx5OmQ/viewform

Reddit discussion: https://www.reddit.com/r/ada/comments/hwgbwa/survey_on_the_future_of_gnat_community/


Survey summary reproduced below...


GNAT Ecosystem Community Survey

Hello Ada supporters,

We are writing this message here to present, discuss and get feedback on a plan that we at AdaCore want to put in place. Over the next couple of years, we want to experiment with an evolution of the GNAT ecosystem and would like your help.

So far, there are three grand families of GNAT releases:

- GNAT Pro: An AdaCore release with professional support and high level quality assurance. Available on many different targets (PowerPC, Leon, vxWorks, etc.).

- GNAT Community: An AdaCore release with a lower level of quality assurance, less targets, and a pure GPL license for the run-time.

- GNAT FSF: community built compiler from the FSF source tree. Available from Linux distributions or Msys2 on Windows, for instance.

Moving forward, we are looking to simplify the situation and remove GNAT Community from the picture.

The plan is to reach a point where AdaCore would not release GNAT Community compilers and instead instruct non-professional users to use GNAT FSF builds. We would still keep making GNAT Studio and SPARK releases, and libraries such as AWS and xmlada will be available in the Alire package manager (http://alire.ada.dev). With this plan we also want to invest some more time to help the maintainers of GNAT packages in Linux, BSD, or Windows (msys2) distributions, for instance, and potentially contribute when necessary. Our intention is to contribute to various communities building GNAT packages so that what can be done today with GNAT Community will be doable tomorrow from these community-led builds.

Why are we working on this plan?

We have noticed that GNAT Community's pure GPL license on the run-time is seen as a barrier to new Ada users. More specifically, understanding the consequences of the GPL licence is complex. The result is that newcomers will often be introduced to Ada/SPARK by a legal licence discussion rather than looking at the value of the technology. This will, understandably, scare people off.

On top of this, we are witnessing a widespread misunderstanding around the openness of the Ada language and the GNAT compiler, some people seem to think that Ada and GNAT are proprietary technologies. We see this phenomenon as detrimental to the growth of the Ada community. Of course this misunderstanding will not fade in a couple days, but we think that removing GNAT Community will make the situation clearer and will allow us to better communicate on the situation of the Ada compiler ecosystem.

Besides general comments and discussion around this plan, we would appreciate your feedback in this survey form. Please help us spread the word. The more feedback we get, the more we will be able to move in the right direction.

[Stephen Leake]

On Friday, July 24, 2020 at 2:42:18 PM UTC-7, Wesley Pan wrote:
> I just discovered this via Ada Planet...
>
> Link to the Google Docs survey: https://docs.google.com/forms/d/e/1FAIpQLSet9x3UNUFmfWt5v-8Jb7dW8BgKiJxyEMJ_TFm0G2UJKx5OmQ/viewform
>
> Reddit discussion: https://www.reddit.com/r/ada/comments/hwgbwa/survey_on_the_future_of_gnat_community/
>
>
> Survey summary reproduced below...
>

Interesting that they did _not_ post about this survey in this newsgroup. I guess we're just _so_ yesterday ...

[Stéphane Rivière]

Many thanks Wesley !!!

Fascinating... (C) Spock

Finally, we're back to the previous situation without the GPL barrier...

Gnat 3.15p was born again ;)

All the arguments given are exactly those I addressed to Adacore at the
highest level at the time (may be about 15 years ago ?)...

Originally, Gnat was funded precisely to be available to everyone,
including commercial use.

I answered their survey, in a constructive way, of course.

Very good news.

--
Be Seeing You
Number Six

[Stéphane Rivière]

Le 25/07/2020 à 04:17, Stephen Leake a écrit :
> Interesting that they did _not_ post about this survey in this newsgroup. I guess we're just _so_ yesterday ...

I deeply agree ! NGs are so (too?) efficient.

[DrPi]

What about Ada for microcontrollers ?

[Fabien Chouteau]

Hello here,

On Saturday, July 25, 2020 at 4:17:32 AM UTC+2, Stephen Leake wrote:
> Interesting that they did _not_ post about this survey in this newsgroup. I guess we're just _so_ yesterday ...

I was going to do it this week ;)

[Fabien Chouteau]

On Monday, July 27, 2020 at 10:07:50 AM UTC+2, DrPi wrote:
> What about Ada for microcontrollers ?

With this plan arm-elf and riscv-elf toolchain will be available for Linux and Windwos at least.

I am doing a lot of microcontroller programming myself so don't worry about that :)

[DrPi]

That's good news :)

Thanks for the information.

[Shark8]

On Monday, July 27, 2020 at 2:07:50 AM UTC-6, DrPi wrote:
> >
> What about Ada for microcontrollers ?

Honestly, Byron's plan would be the easiest way to get microcontrollers:
(1) Design an Ada implementation with a modular backend.
(2) Use SPARK verification for as much of the compiler as possible.
(3) Create a FORTH backend.
(4) Because you can reduce FORTH bootstrapping to about 30 (usually small) words, this provides a way to EASILY bootstrap a new architecture.
(5) If native code generation is needed, you could [more easily] write a new backend, due to #1.
(6) If native compiler-hosting is needed, take the backend of #5, run the compiler through it, done.

Optional would be writing a FORTH implementation in Ada 2012/SPARK, where you could feed the Ada compiler to the FORTH-generating backend, and use that result as an intermediate form for bootstrapping.

[Simon Wright]

Shark8 <onewing...@gmail.com> writes:

> Honestly, Byron's plan would be the easiest way to get microcontrollers:

"easiest"?

[Shark8]

Sure, once you have the infrastructure porting new architecture [via Forth] is a matter of writing the "about thirty" words in machine code. The technique is from seedforth, as illustrated in the FOSDEM video: https://fosdem.org/2020/schedule/event/forth_new_synthesis/

If you did it with a SPARK verified Ada compiler, with the goal of passing the FAA certifications, you also get that level of assurance "for free" allowing you to only have to build a SPARK verified native-generation backend for getting a new FAA capable/certified compiler -- and considering there's literally a sector of the industry there that makes their money off providing virtual-machines of older hardware so that they don't have to re-certify the compiler, there's certainly incentive here.

[foo wong]

Hi Everyone

My name is Patrick, not Foo, I am just trying to keep Google off my trail. I have been posting here for 8+ years.

I just wanted to say that I am very happy to read this thread.

I have wrote several disparaging posts about Adacore and my take on the situation was:

- GNAT Pro: professional support, more targets.

- GNAT Community: Lower level of quality assurance, less targets, and a pure GPL license for the run-time for a demoware experience

- GNAT FSF: least quality assurance designed to push users to the community build or Pro ASAP

I hope I was wrong all along and either way, the future just got a little brighter as Adacore's two offerings will now be suitable for free or non-free software.

I don't believe that there is anything illegal about re-distributing GNAT Pro so if the gap in quality was so large between Pro and FSF, I think one paying customer might take pity on us eventually and release Pro to the world and reset the gap for a while.

With dark days setting in for the avionics industry(for a while at least), maybe Adacore will eventually reconsider and will release Pro as their FSF offering to broaden their user base.

-Patrick

[Simon Wright]

foo wong <cr...@spellingbeewinnars.org> writes:

> I have wrote several disparaging posts about Adacore and my take on
> the situation was:
>
> - GNAT Pro: professional support, more targets.
>
> - GNAT Community: Lower level of quality assurance, less targets, and
> a pure GPL license for the run-time for a demoware experience
>
> - GNAT FSF: least quality assurance designed to push users to the
> community build or Pro ASAP
>
> I hope I was wrong all along and either way, the future just got a
> little brighter as Adacore's two offerings will now be suitable for
> free or non-free software.

IMO you've been wrong all along, at least so far as the quality is
concerned. Assurance, yes; number of targets, yes; support, yes.

> I don't believe that there is anything illegal about re-distributing
> GNAT Pro so if the gap in quality was so large between Pro and FSF, I
> think one paying customer might take pity on us eventually and release
> Pro to the world and reset the gap for a while.

I wouldn't have done this; but we were stuck on an old release for a
long time, so wouldn't have helped.

> With dark days setting in for the avionics industry(for a while at
> least), maybe Adacore will eventually reconsider and will release Pro
> as their FSF offering to broaden their user base.

The only difference between the pro compiler and FSF is a few months.

[foo wong]

> 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?

- Simon Wright August 24th 2018

https://groups.google.com/forum/#!searchin/comp.lang.ada/demo$20ware|sort:date/comp.lang.ada/cdCDljZtBVg/GF8CmMJ6AQAJ

--------and you were wrong too.

I am going to give reddit a try for a while. Between off topic lunatic posts and endemic crankiness here, it might work out better. I hope to start off on a more upbeat note too, I have also been cranky at times-Patrick

[ldries46]

I don't mind the idea on several conditions:

1.  There must be a good other development environment in which FSF
can be integrated. So I don't have to use several other programs to
complete the full cycle. So writing code compiling, building,
running and debugging must be in one program
2. Other languages can also be integrated.
3. The possibilities of .grp files must be supported.
4. Existing GNAT libraries must be reachable.
5. There must come a site in which all of these things can be reached
or downloaded.

In fact all this means that for the "amateur user" it all stays the same
only from another site

[Stephen Leake]

On Friday, July 31, 2020 at 10:32:50 PM UTC-7, ldries46 wrote:
> I don't mind the idea on several conditions:
>
> 1.  There must be a good other development environment in which FSF
> can be integrated. So I don't have to use several other programs to
> complete the full cycle. So writing code compiling, building,
> running and debugging must be in one program

Emacs

> 2. Other languages can also be integrated.

Emacs

> 3. The possibilities of .grp files must be supported.

I assume you meant .gpr

GNU ELPA ada-mode also provides gpr-mode

> 4. Existing GNAT libraries must be reachable.

Depends on the OS distribution. That has always been spotty, which is why I have always preferred the AdaCore distribution. But they promise to make it better, somehow.

> 5. There must come a site in which all of these things can be reached
> or downloaded.

The intent is to use the "normal" way to install things on each supported OS. So on Debian that's apt-get or one of the wrappers around that. On Mingw64 that's pacman. Etc.

> In fact all this means that for the "amateur user" it all stays the same
> only from another site

AdaCore does not intend to provide a distribution. And if they do a good job supporting Debian and Mingw64, I'll be happy.

[Kevin K]

I hadn't seen this before today. The main impediment to me with the free version compared to the community edition is that with the community edition Adacore took a set of packages that build together correctly. I tried to build a set of components from the free version (gcc 8.2 and later), gprbuild, etc. At the time, the other important components didn't all build successfully. Some components were ahead of others. So I wasn't able to build, for example, gps.

[Roger Mc]

On Sunday, August 16, 2020 at 2:38:25 AM UTC+10, Kevin K wrote:
> I hadn't seen this before today. The main impediment to me with the free version compared to the community edition is that with the community edition Adacore took a set of packages that build together correctly. I tried to build a set of components from the free version (gcc 8.2 and later), gprbuild, etc. At the time, the other important components didn't all build successfully. Some components were ahead of others. So I wasn't able to build, for example, gps.

Unfortunately, the Adacore community 2020 edition doesn't include gps so I am currently using the community 2020 tool-chain and gps from community 2019. I did try to build gps from the current Adacore community source but was unsuccessful. The main problem being that Adacore seem to be in the midst of doing the necessary upgrade from Python 2 to Python3. I did attempt to do Python3 modifications myself but eventually got to a stage where I could proceed no further.

[Luke A. Guest]

On 15/08/2020 17:38, Kevin K wrote:
> I hadn't seen this before today. The main impediment to me with the free version compared to the community edition is that with the community edition Adacore took a set of packages that build together correctly. I tried to build a set of components from the free version (gcc 8.2 and later), gprbuild, etc. At the time, the other important components didn't all build successfully. Some components were ahead of others. So I wasn't able to build, for example, gps.
>

You'll have that issue on FSF because AdaCore don't tag for FSF releases
like they should.

Having CE available is a massive mistake, one which they are realising
far too late, imo.

[Simon Wright]

Roger Mc <roge...@gmail.com> writes:

> Unfortunately, the Adacore community 2020 edition doesn't include gps

I _think_ this is on macOS? i.e. Linux, Windows include it? (presumably
under its new name GNATstudio (modulo capitalisation))

[Stephen Leake]

On Sunday, August 16, 2020 at 3:08:20 AM UTC-7, Simon Wright wrote:

> Roger Mc writes:
>
> > Unfortunately, the Adacore community 2020 edition doesn't include gps
> I _think_ this is on macOS? i.e. Linux, Windows include it? (presumably
> under its new name GNATstudio (modulo capitalisation))

Windows has <gnat>/bin/gnatstudio.exe

[Roger Mc]

Yes. My system is macOS.
The source for GPS doesn't appear available from the Adacore community version for any platform?
The source that I tried to build from was obtained from GIT.
I can only find GNATstudio under Ada core pro. Is it available elsewhere?

[Stéphane Rivière]

> You'll have that issue on FSF because AdaCore don't tag for FSF releases
> like they should.
>
> Having CE available is a massive mistake, one which they are realising
> far too late, imo.

Fully agree.

For the records, GVD (Gnu Visual Debugger) was buildable (under Windows¹
or Linux) but I _never_ succeed to build GPS...

¹ For the now deprecated AIDE https://stef.genesix.org/aide/aide.html

[Simon Wright]

Roger Mc <roge...@gmail.com> writes:

> I did try to build gps from the current Adacore community source but
> was unsuccessful. The main problem being that Adacore seem to be in
> the midst of doing the necessary upgrade from Python 2 to Python3. I
> did attempt to do Python3 modifications myself but eventually got to a
> stage where I could proceed no further

I've reached the same stage. I can manage some of the 2-to-3 fixes (not
the one in gobject-introspection, though), but the real problem for me
is that there isn't a consistent complete set of sources, and some
aren't provided on the Adacore community site (e.g. pygobject, langkit,
libadalang, libadalang-tools, ada_language_server). And, so far as I can
see, langkit (20.2) isn't consistent with libadalang (20.2). And, my
Python venv has got screwed.

Netflix & Twitter.

[Andreas ZEURCHER]

If multiple well-skilled people cannot build a GPL-licensed source code with the source code as provided and instructions as provided, wouldn't that be a black-&-white flagrant violation of the GPL? The natural conclusion seems to be: either the source code provided mismatched or the narrative instructions to build were omitting some secret-sauce, either of which was an unintentional or intentional preventative of success. The unintentionality versus intentionality would be able to be determined only after the fact by observing the root-cause of the preventative of successful building once that root cause is discovered/reported. This irreproducibility is both notable and highly interesting.

[Dmitry A. Kazakov]

On 19/08/2020 20:09, Andreas ZEURCHER wrote:

> If multiple well-skilled people cannot build a GPL-licensed source code with the source code as provided and instructions as provided, wouldn't that be a black-&-white flagrant violation of the GPL?

What else you expect when GTK and Python are used? GTK is practically
impossible to bootstrap. Python is full of bugs and incompatibilities.
On top of that for some mysterious reason AdaCore decided to use config
scripts. No wonder it is a nightmare anywhere outside Linux.

If you think that commercial code delivered in sources is any better,
you are wrong. Building from sources working out of the box is a rare
exception. Most vendors simply check out the code from the repository
and send it to you. They have no resources or desire to supply you with
a working toolchain tailored for your targets, nor have they necessary
knowledge anyway.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Simon Wright]

Well - I have every sympathy with people who make a binary release and
then move on in staggered stages, aiming for another binary release in a
year's time. The sort of problem you encounter is that the the version
of gobject-introspection on the CE site won't compile with Python 3.8.5,
because of the removal of the DL_EXPORT macro that was deprecated with
Python 2.3; while libadalang _requires_ Python 3.8.5. The latest glib
uses Yet Another Build Tool (meson/ninja), and the script doesn't export
a header required by gtk-3.14+ ... it's not so much DLL Hell as a
version compatibilty tightrope.

[Luke A. Guest]

On 19/08/2020 19:09, Andreas ZEURCHER wrote:
> If multiple well-skilled people cannot build a GPL-licensed source code with the source code as provided and instructions as provided, wouldn't that be a black-&-white flagrant violation of the GPL? The natural conclusion seems to be: either the source

Every component from AdaCore is an absolute fucker to build.

[Luke A. Guest]

On 19/08/2020 20:11, Dmitry A. Kazakov wrote:

> What else you expect when GTK and Python are used? GTK is practically
> impossible to bootstrap. Python is full of bugs and incompatibilities.
> On top of that for some mysterious reason AdaCore decided to use config
> scripts. No wonder it is a nightmare anywhere outside Linux.

I build on Linux and see my previous comment.

[Simon Wright]

The "front-line" components (gnatcoll*, gprbuild, xmlada & friends)
build pretty reliably for me, even taking the master branch.

[Luke A. Guest]

That's only after you work out which commit to build, after many
attempts at building.

[Roger Mc]

I think I managed to do all the Python 3 conversions but couldn't get linking to work.
I recall that getting the prerequisites built was a challenge and found that if I changed anything in any of them I'd have to go back and start building them from scratch again. Worse, I seem to recall that for at least one of them, probably langkit, I'd have to delete it and reload it from its archive file.
Its comforting to find that many of the opinions expressed in this thread are similar to my own.

[Roger Mc]

Incredibly, Python seems to be the language of choice for "teaching" the now-defunct discipline of software development, even by leading universities as far as I can discover.
Most of the rules of disciplined software development seem to have been discarded long ago. In particular, the maintainability aspect seems to have disappeared.
Regards,
Roger

[Roger Mc]

I think that I also found this. Sometimes, the master worked, occasionally the stable (?) worked but I'd sometimes (often?) have to resort to an earlier build to achieve success!

[Roger Mc]

This indicates my progress:
https://stackoverflow.com/questions/62146798/adacore-gnatstudio-builds-but-wont-run

[st...@cunningsystems.com]

On Wednesday, August 19, 2020 at 10:53:15 PM UTC-7, roge...@gmail.com wrote:
> I think that I also found this. Sometimes, the master worked, occasionally the stable (?) worked but I'd sometimes (often?) have to resort to an earlier build to achieve success!

Note that the libadalang/master and langkit/master repositories are often out ahead of gps/master. You'll have better
luck if you build them from stable branches, then gps/master should build.

Similarly spark2014/master is often ahead of FSF gcc/master. gcc/master is usually in sync with spark2014/fsf branch.

-Steve

[Stéphane Rivière]

> Incredibly, Python seems to be the language of choice for "teaching" the now-defunct discipline of software development, even by leading universities as far as I can discover.

It's not incredible. It's lead to 737max failure, It's Idiocracy.

RM about Idiocracy could be the movie Idiocracy. I urge you to see it.
Its nickname is : the movie which has became a documentary. It's
delightfully vulgar but above all incredibly relevant and funny.

https://en.wikipedia.org/wiki/Idiocracy

In any case, Adacore's choice of python is miserable. It would have been
wiser, if there was a need for a scripting language, to implement a
subset of Ada (like Gautier de Montmollin HAL :) For the doc, they even
abandoned GNU/Texinfo for Python...

Moreover, the GPS code has always been problematic. I remember the first
versions where a very large portion of the code was in C because they
had integrated a full version of old version of berkeley DB...

[Simon Wright]

I must have been lucky.

[Vincent DIEMUNSCH]

Le jeudi 20 août 2020 à 08:43:15 UTC+2, Stéphane Rivière a écrit :
>
> In any case, Adacore's choice of python is miserable. It would have been
> wiser, if there was a need for a scripting language, to implement a
> subset of Ada (like Gautier de Montmollin HAL :) For the doc, they even
> abandoned GNU/Texinfo for Python...
>

I agree.

And they also used Python for libadalang : "libadalang is using the Langkit framework as a basis, and is at the time of writing the main project developped using it. The language specification, while embedded in Python syntax, is mostly its own language, the Langkit DSL, that is used to specify the part of Ada syntax and semantics that are of interest to us."

I wonder if it would have been possible to create a library of objects directly in Ada, somehow equivalent in features to Python's Objects, but with the advantage of strong typing and a compilation to native instructions. It would require a major use of interfaces, one for each Python's built-in type class, but it would have been a foundation for many other applications.

Vincent

[Stephen Leake]

On Monday, August 31, 2020 at 7:54:46 AM UTC-7, Vincent DIEMUNSCH wrote:
> And they also used Python for libadalang : "libadalang is using the Langkit framework as a basis, and is at the time of writing the main project developped using it. The language specification, while embedded in Python syntax, is mostly its own language, the Langkit DSL, that is used to specify the part of Ada syntax and semantics that are of interest to us."
>
> I wonder if it would have been possible to create a library of objects directly in Ada, somehow equivalent in features to Python's Objects, but with the advantage of strong typing and a compilation to native instructions. It would require a major use of interfaces, one for each Python's built-in type class, but it would have been a foundation for many other applications.
>
> Vincent

Langkit uses the advanced features of Python to create a Domain Specific Language (DSL) for defining Abstract Syntax Trees. The DSL also defines much of the user API for accessing the syntax tree after parsing. You could accomplish something similar by using a grammar generator (WisiToken or Langkit :) to create a parser for the desired DSL (as WisiToken does), but then defining the API would be done separately, and the correspondence between the API and the syntax tree maintained manually (ie error-prone). I think Python is a good choice for this application - there are probably other languages with similar features that could have been used, but Ada is not one.

-- Stephe

[Dmitry A. Kazakov]

On 01/09/2020 20:22, Stephen Leake wrote:

> Langkit uses the advanced features of Python to create a Domain Specific Language (DSL) for defining Abstract Syntax Trees.

Which is a big mistake, as well. Each intermediate is yet another point
of error.

> I think Python is a good choice for this application - there are probably other languages with similar features that could have been used, but Ada is not one.

I doubt there could exist applications for languages like Python.
Anyway, GPS is demonstratively not.

I also do not believe in heavily scripted IDEs. I certainly do not want
GPS becoming Emacs. Any usability GPS has, comes from not being Emacs,
or, for that matter, Visual Studio with its horrific VB scripts.