info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Building the 2021 source release of GnatStudio
265 views
Skip to first unread message
Rod Kay
Jul 28, 2021, 5:25:53 AM7/28/21
to
Greets all,
Has anyone managed this successfully with the Community Edition
source release ?
As I find it, the source and dependent project sources are out of
version sync.
When those problems are sorted out, the python support files
installed to '/usr/share/gnatstudio' are problematic at best, to put it
'nicely'. They differ largely from the python support files installed in
the corresponding 2021 binary install (and, in fact, break running
GnatStudio).
I wonder how this can be (unless I have made several fundamental
build errors).
Ada is touted for its safety, stability and portability. What would
new-comers think when the main Ada IDE, produced by the main Ada vendor,
breaks so frequently (every yearly release, there have been similar
difficulties).
How can these problems be 'accidental' over so many years ?
Regards.
Has anyone managed this successfully with the Community Edition
source release ?
As I find it, the source and dependent project sources are out of
version sync.
When those problems are sorted out, the python support files
installed to '/usr/share/gnatstudio' are problematic at best, to put it
'nicely'. They differ largely from the python support files installed in
the corresponding 2021 binary install (and, in fact, break running
GnatStudio).
I wonder how this can be (unless I have made several fundamental
build errors).
Ada is touted for its safety, stability and portability. What would
new-comers think when the main Ada IDE, produced by the main Ada vendor,
breaks so frequently (every yearly release, there have been similar
difficulties).
How can these problems be 'accidental' over so many years ?
Regards.
Emmanuel Briot
Jul 28, 2021, 6:49:42 AM7/28/21
to
In the same message, you are talking about difficulties with some python files, then mentioning how Ada make everything bad.
Those are two different languages.
I was one of the GPS/GnatStudio developers for quite a number of years (looks like I am still ahead in the total number of commits :-),
and a large part of the installation issues (and a somewhat smaller part of the actual stability issues) were largely in the third party
libraries that GPS depends on, most notably gtk and friends. Those are very hard to install correctly, they come with tons of dependencies
of their own, were not (at the time at least) properly tested on Windows, and so on...
Compiling the Ada part of GnatStudio was not a major issue at the time. I take it things are more complex now (did not try in 4 years) because there are
more dependencies to other Ada libraries. This is a cost to pay for better sharing of code with other projects and the rest of the community (which is
something people have been asking a lot). Things could be a lot simpler if gprbuild was a more competent tool similar to what cargo is for Rust for
instance. Alire is trying to improve things in that area, so hopefully it will simplify the handling of those dependencies...
Collectively, we certainly owe big thanks to the people out there who build these community packages for others to use. I know
Simon does it for MacOS, someone else does it on Debian. Not sure whether there is a similar volunteer on Windows.
Those are two different languages.
I was one of the GPS/GnatStudio developers for quite a number of years (looks like I am still ahead in the total number of commits :-),
and a large part of the installation issues (and a somewhat smaller part of the actual stability issues) were largely in the third party
libraries that GPS depends on, most notably gtk and friends. Those are very hard to install correctly, they come with tons of dependencies
of their own, were not (at the time at least) properly tested on Windows, and so on...
Compiling the Ada part of GnatStudio was not a major issue at the time. I take it things are more complex now (did not try in 4 years) because there are
more dependencies to other Ada libraries. This is a cost to pay for better sharing of code with other projects and the rest of the community (which is
something people have been asking a lot). Things could be a lot simpler if gprbuild was a more competent tool similar to what cargo is for Rust for
instance. Alire is trying to improve things in that area, so hopefully it will simplify the handling of those dependencies...
Collectively, we certainly owe big thanks to the people out there who build these community packages for others to use. I know
Simon does it for MacOS, someone else does it on Debian. Not sure whether there is a similar volunteer on Windows.
Simon Wright
Jul 28, 2021, 10:29:19 AM7/28/21
to
Emmanuel Briot <briot.e...@gmail.com> writes:
> Collectively, we certainly owe big thanks to the people out there who
> build these community packages for others to use. I know
> Simon does it for MacOS, someone else does it on Debian. Not sure
> whether there is a similar volunteer on Windows.
Studio is something I've never provided for macOS: up til now, the CE
> Collectively, we certainly owe big thanks to the people out there who
> build these community packages for others to use. I know
> Simon does it for MacOS, someone else does it on Debian. Not sure
> whether there is a similar volunteer on Windows.
version has been just fine, last one 2019). Pascal (Blady) is working on
the 2021 version, I think.
The last time I tried Studio for macOS I ended up in Python hand-managed
memory management hell.
Randy Brukardt
Jul 28, 2021, 8:49:17 PM7/28/21
to
"Rod Kay" <roda...@gmail.com> wrote in message
news:sdr7qu$cuj$1...@dont-email.me...
...
programmed in Python), I'm not sure what it has to do with the reliability
of Ada programs. If someone built an all-Ada IDE, then that might make more
sense. And in any case, programs like an IDE are almost always installed
from binary packages.
Randy.
news:sdr7qu$cuj$1...@dont-email.me...
...
> Ada is touted for its safety, stability and portability. What would
> new-comers think when the main Ada IDE, produced by the main Ada vendor,
> breaks so frequently (every yearly release, there have been similar
> difficulties).
Since the "main Ada IDE" isn't even an Ada program (primarily being
> new-comers think when the main Ada IDE, produced by the main Ada vendor,
> breaks so frequently (every yearly release, there have been similar
> difficulties).
programmed in Python), I'm not sure what it has to do with the reliability
of Ada programs. If someone built an all-Ada IDE, then that might make more
sense. And in any case, programs like an IDE are almost always installed
from binary packages.
Randy.
Roger Mc
Jul 28, 2021, 9:09:26 PM7/28/21
to
On Wednesday, July 28, 2021 at 7:25:53 PM UTC+10, roda...@gmail.com wrote:
> Greets all,
>
> Has anyone managed this successfully with the Community Edition
> source release ?
>
> As I find it, the source and dependent project sources are out of
> version sync.
>
> When those problems are sorted out, the python support files
> installed to '/usr/share/gnatstudio' are problematic at best, to put it
> 'nicely'. They differ largely from the python support files installed in
> the corresponding 2021 binary install (and, in fact, break running
> GnatStudio).
>
> I wonder how this can be (unless I have made several fundamental
> build errors).
>
Yes! I once tried to build it and found similar problems.
> Greets all,
>
> Has anyone managed this successfully with the Community Edition
> source release ?
>
> As I find it, the source and dependent project sources are out of
> version sync.
>
> When those problems are sorted out, the python support files
> installed to '/usr/share/gnatstudio' are problematic at best, to put it
> 'nicely'. They differ largely from the python support files installed in
> the corresponding 2021 binary install (and, in fact, break running
> GnatStudio).
>
> I wonder how this can be (unless I have made several fundamental
> build errors).
>
My attempt also included converting many Python 2 sources to Python 3.
I note that you refer to "the main Ada IDE" and I tend to agree.
The fact that the causes of the problems are due to "python support files ", including version syncing, causing problems with building "the main Ada IDE" and not Ada can quite possibly give a negative impression for Ada even though Ada is not the culprit.
I am currently trying to use VS Code, but find the 2019 CE GPS version preferable.
Luke A. Guest
Jul 29, 2021, 3:50:28 AM7/29/21
to
On 29/07/2021 01:49, Randy Brukardt wrote:
> Since the "main Ada IDE" isn't even an Ada program (primarily being
> programmed in Python), I'm not sure what it has to do with the reliability
> of Ada programs. If someone built an all-Ada IDE, then that might make more
> sense. And in any case, programs like an IDE are almost always installed
> from binary packages.
Dmitry A. Kazakov
Jul 29, 2021, 4:41:32 AM7/29/21
to
But if you do, as there is no viable scripting alternative (Lua, Julia
are only worse and no Ada script fulfills minimal requirements, last
time I looked). I do use Python loading it dynamically. That eliminates
all build problems, but creates ones with packaging...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Rod Kay
Jul 29, 2021, 6:29:10 AM7/29/21
to
On 28/7/21 8:49 pm, Emmanuel Briot wrote:
> In the same message, you are talking about difficulties with some python files, then mentioning how Ada make everything bad.
> Those are two different languages.
It was never my intention to malign Ada in any way. I apologise if
> In the same message, you are talking about difficulties with some python files, then mentioning how Ada make everything bad.
> Those are two different languages.
that was the received impression. Indeed, the python2/3 side was the
more difficult part.
>
> I was one of the GPS/GnatStudio developers for quite a number of years (looks like I am still ahead in the total number of commits :-),
> and a large part of the installation issues (and a somewhat smaller part of the actual stability issues) were largely in the third party
> libraries that GPS depends on, most notably gtk and friends. Those are very hard to install correctly, they come with tons of dependencies
> of their own, were not (at the time at least) properly tested on Windows, and so on...
used for many years now.
>
> Compiling the Ada part of GnatStudio was not a major issue at the time. I take it things are more complex now (did not try in 4 years) because there are
> more dependencies to other Ada libraries. This is a cost to pay for better sharing of code with other projects and the rest of the community (which is
> something people have been asking a lot). Things could be a lot simpler if gprbuild was a more competent tool similar to what cargo is for Rust for
> instance. Alire is trying to improve things in that area, so hopefully it will simplify the handling of those dependencies...
difficulty there was only with version mismatches with the Ada
dependencies. These were relatively simple to patch by backporting
current git code. Though I wonder how these mismatches could exist in
the source release when any attempt to build reveals them.
>
> Collectively, we certainly owe big thanks to the people out there who build these community packages for others to use. I know
> Simon does it for MacOS, someone else does it on Debian. Not sure whether there is a similar volunteer on Windows.
>
now and have had trouble building GnatStudio on each release. Perhaps I
was speaking out of accumulated frustration over problems which should
be easy to spot and correct (ie the dependencies version mismatches).
Rod Kay
Jul 29, 2021, 6:38:01 AM7/29/21
to
Python at all, given that Ada is superior ?'.
Rod Kay
Jul 29, 2021, 6:47:44 AM7/29/21
to
'/usr/share/gnatstudio' which solved most of the Python2/3
problems. There is still an issue with auto-indent, when using the TAB
key, which I've not been able to fix.
In case it is of use to anyone, here is a link to the Archlinux
gnat-gps package (which builds ok) ...
https://aur.archlinux.org/packages/gnat-gps
Regards.
Stéphane Rivière
Jul 29, 2021, 7:33:54 AM7/29/21
to
> First, never ever use Python!
If scripting capabilities are needed in GnatStudio, why not use HAC ?
https://github.com/zertovitch/hac
We use it at $job on a daily basis, replacing all our Bash and PHP
scripting stuff...
Seven times faster than Bash, tons times powerfull and maintanable and,
even better, HAC source can be GNAT compiled from scratch (without
changing a line). There is also a shebang to ease scripting like with
any other scripting language...
The biggest HAC program here is 3500 lines (!) It's a Cron. A Drupal web
scraper to a Wordpress filer and MySQL DB). It syncs every weeks
thousands of products pages and ten thousands of jpeg and pdf files...
A friendly, humble, well tested and capable companion to a first class
Ada environement.
Dmitry A. Kazakov
Jul 29, 2021, 7:58:31 AM7/29/21
to
On 2021-07-29 13:33, Stéphane Rivière wrote:
>> First, never ever use Python!
>
> If scripting capabilities are needed in GnatStudio, why not use HAC ?
> https://github.com/zertovitch/hac
>
> We use it at $job on a daily basis, replacing all our Bash and PHP
> scripting stuff...
>
> Seven times faster than Bash, tons times powerfull and maintanable and,
> even better, HAC source can be GNAT compiled from scratch (without
> changing a line). There is also a shebang to ease scripting like with
> any other scripting language...
Nothing of the shell sort. I think it is a major confusion on the side
>> First, never ever use Python!
>
> If scripting capabilities are needed in GnatStudio, why not use HAC ?
> https://github.com/zertovitch/hac
>
> We use it at $job on a daily basis, replacing all our Bash and PHP
> scripting stuff...
>
> Seven times faster than Bash, tons times powerfull and maintanable and,
> even better, HAC source can be GNAT compiled from scratch (without
> changing a line). There is also a shebang to ease scripting like with
> any other scripting language...
of developers of Ada scripts.
For scripting an Ada application one needs support of
1. Loadable modules/packages, prebuilt, to call back to the Ada
application subprograms provided by the module/package;
2. Passing Ada in/out parameters down to a script's subprogram upon
invocation;
3. Returning parameters from the script's subprogram;
4. Precompiled script modules, GPS would use a huge number of scripts,
compiling them each time would be expensive;
5. Abortable calls and propagation of exceptions out of the script;
6. Concurrent script run-time with independent instances.
For example, this is what I use Python for, and this is just the same
case as in GPS:
http://www.dmitry-kazakov.de/ada/max_home_automation.htm#5.1
The user script refers to a preloaded module that offers communication
channel back to the application, e.g. GPS script interface.
In my case the script is called periodically and returns a persistent
object, which is passed down by the next call. Such objects must be
managed by the caller (the application).
And I load Python dynamically to break dependency on it.
J-P. Rosen
Jul 29, 2021, 10:37:51 AM7/29/21
to
Le 29/07/2021 à 12:37, Rod Kay a écrit :
> I guess the point I was trying to make was 'Why is GnatStudio using
> Python at all, given that Ada is superior ?'.
Python is useful for tailoring; by dropping a Python file in the
> I guess the point I was trying to make was 'Why is GnatStudio using
> Python at all, given that Ada is superior ?'.
appropriate directory, you can add any feature to GnatStudio (OK, it
needs some XML too).
That's how AdaControl's integration works.
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr
Shark8
Jul 29, 2021, 1:23:48 PM7/29/21
to
On Wednesday, July 28, 2021 at 6:49:17 PM UTC-6, Randy Brukardt wrote:
> "Rod Kay" wrote in message
> news:sdr7qu$cuj$1
(If it was *just* windows, I'd recommend Rod look at Claw: pure Ada, no extraneous dependency, and supporting a small vendor.)
At this point, I think it would be prudent (as-a-community) to assess whether or not external dependencies are worth their keep, whether it be a library like gtkAda or GNATCOLL, or whether it be another language like Python. I'm of the opinion that these dependencies hurt Ada's reputation & goodwill (respectively and especially among newcomers and packagers/maintainers) more than they assist Ada's community.
--------
LINKS to Ada-related GUI libraries:
CLA thread on RAPID: https://groups.google.com/g/comp.lang.ada/c/vzajq2ymI0w/m/sOQIfvNRAQAJ
RAPID Website: http://savannah.nongnu.org/projects/rapid/ / Paper: https://www.researchgate.net/profile/Martin-Carlisle/publication/221444571_RAPID_A_Free_Portable_GUI_Design_Tool/links/55eeeabe08aedecb68fd812f/RAPID-A-Free-Portable-GUI-Design-Tool
CLAW: http://www.rrsoftware.com/html/prodinf/claw/claw.htm / Paper: http://www.rrsoftware.com/html/prodinf/triadapaper/triada.html
JEWL: http://archive.adaic.com/tools/bindings/JEWL/jewl-17.zip
> "Rod Kay" wrote in message
> news:sdr7qu$cuj$1
> ...
> > Ada is touted for its safety, stability and portability. What would
> > new-comers think when the main Ada IDE, produced by the main Ada vendor,
> > breaks so frequently (every yearly release, there have been similar
> > difficulties).
> Since the "main Ada IDE" isn't even an Ada program (primarily being
> programmed in Python), I'm not sure what it has to do with the reliability
> of Ada programs. If someone built an all-Ada IDE, then that might make more
> sense. And in any case, programs like an IDE are almost always installed
> from binary packages.
>
> Randy.
On the issue of IDEs, and in the context of GUI, maybe it would be better to use something like RAPID.
> > Ada is touted for its safety, stability and portability. What would
> > new-comers think when the main Ada IDE, produced by the main Ada vendor,
> > breaks so frequently (every yearly release, there have been similar
> > difficulties).
> Since the "main Ada IDE" isn't even an Ada program (primarily being
> programmed in Python), I'm not sure what it has to do with the reliability
> of Ada programs. If someone built an all-Ada IDE, then that might make more
> sense. And in any case, programs like an IDE are almost always installed
> from binary packages.
>
> Randy.
(If it was *just* windows, I'd recommend Rod look at Claw: pure Ada, no extraneous dependency, and supporting a small vendor.)
At this point, I think it would be prudent (as-a-community) to assess whether or not external dependencies are worth their keep, whether it be a library like gtkAda or GNATCOLL, or whether it be another language like Python. I'm of the opinion that these dependencies hurt Ada's reputation & goodwill (respectively and especially among newcomers and packagers/maintainers) more than they assist Ada's community.
--------
LINKS to Ada-related GUI libraries:
CLA thread on RAPID: https://groups.google.com/g/comp.lang.ada/c/vzajq2ymI0w/m/sOQIfvNRAQAJ
RAPID Website: http://savannah.nongnu.org/projects/rapid/ / Paper: https://www.researchgate.net/profile/Martin-Carlisle/publication/221444571_RAPID_A_Free_Portable_GUI_Design_Tool/links/55eeeabe08aedecb68fd812f/RAPID-A-Free-Portable-GUI-Design-Tool
CLAW: http://www.rrsoftware.com/html/prodinf/claw/claw.htm / Paper: http://www.rrsoftware.com/html/prodinf/triadapaper/triada.html
JEWL: http://archive.adaic.com/tools/bindings/JEWL/jewl-17.zip
Shark8
Jul 29, 2021, 1:43:53 PM7/29/21
to
If you take a look at the implementation I have https://github.com/OneWingedShark/Forth -- you'll observe that there's zero non-Ada portions of the program, all the core-words are given in terms of the VM:
https://github.com/OneWingedShark/Forth/blob/master/src/forth-vm-functions.ads
https://github.com/OneWingedShark/Forth/blob/master/src/forth-vm-functions.adb
https://github.com/OneWingedShark/Forth/blob/master/src/forth-vm-default_words.adb
-- and thus we could achieve a completely portable interpreted system.
Having a fully compliant FORTH 2012 interpreter would be pretty nice in this respect, as FORTH is one of 21 ISO programming languages -- https://en.m.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard -- and only one of three which is traditionally interpreted (ECMAScript, ISLISP, FORTH). ISLISP *might* be a better technical choice than FORTH, but the same technique would work in implementing the portability; ECMAScript (aka JavaScript) would be the obvious choice if it were based on popularity.
TL;DR -- There's zero reason to include Python as a dependency in an IDE.
Randy Brukardt
Jul 29, 2021, 8:22:02 PM7/29/21
to
"Luke A. Guest" <lag...@archeia.com> wrote in message
news:sdtmk1$jl4$1...@gioia.aioe.org...
True enough, but that hardly changes anything. Unless a program is a single
collection of source in a single programming language, pretty much any
builds range from difficult to impossible. You have dependences on
libraries, on unfamiliar build tools, on scripts written for some other
target, etc. This is generally a complex problem to which there is unlikely
to ever be a good general solution.
Tucker described this sort of problem as one where there is a lump under a
carpet. You can move the lump around (hopefully to the edge), but you can't
get rid of it without fully replacing the carpet (which quite likely will
result in a new issue of some sort). There are of course tools that help one
set of users and problems, but they then create even more problems when you
reach the limits of what they can do (especially for the uninitiated).
Randy.
news:sdtmk1$jl4$1...@gioia.aioe.org...
collection of source in a single programming language, pretty much any
builds range from difficult to impossible. You have dependences on
libraries, on unfamiliar build tools, on scripts written for some other
target, etc. This is generally a complex problem to which there is unlikely
to ever be a good general solution.
Tucker described this sort of problem as one where there is a lump under a
carpet. You can move the lump around (hopefully to the edge), but you can't
get rid of it without fully replacing the carpet (which quite likely will
result in a new issue of some sort). There are of course tools that help one
set of users and problems, but they then create even more problems when you
reach the limits of what they can do (especially for the uninitiated).
Randy.
Stéphane Rivière
Jul 30, 2021, 7:29:49 AM7/30/21
to
> For scripting an Ada application one needs support of
I don't see anything that HAC couldn't do, natively or with adaptations,
both on the side of HAC and GNATStudio, considering the enormous amount
of time that has been spent to integrate Python into GNATStudio.
But, imho, this is all history, GNATStudio is scriptable in Python,
GNATStudio is very difficult to build, Adacore is known to love Python
and GNAT CE, as a whole, is a wonderful tool. We have to live with it ;)
Emmanuel Briot
Jul 30, 2021, 7:51:51 AM7/30/21
to
I must admit having a hard time understanding this discussion.
There is of course no way AdaCore will change their tools to use any of the suggestions in this thread.
HAC is 100% unknown outside of the Ada community, and I would guess 100% unknown outside of the small comp.lang.ada subset of it.
At least for now, and things could possibly change in the future.
AdaCore has a large number of customers that have written their own integration scripts in python very easily.
Those scripts are in general not written by people with knowledge of Ada at all, those are the people responsible
for providing the tooling to other teams. So it would make no sense to only have HAC support for instance (and
would not remove any of the build difficulties to boot, since backward compatibility is a thing and python would
have to be kept)
Shark8 suggested that external dependencies are a bad thing altogether, and libraries like GtkAda and GNATCOLL
should never be used. This is totally opposite to what people actually want (see the development of Alire for instance,
or what happens in all programming languages out there). So that also makes no sense.
As the original poster mentioned, building GNATStudio is a very difficult thing. Just like building Firefox, or I presume Visual Studio,
or any large application out there. Things likely could be improved with better documentation, and that's likely where the
community should play a role. AdaCore developers in general have the proper setup because their colleagues helped them (there
is no secret documentation that they do not want to publish to the outside), and of course AdaCore cannot test on all systems
and all machines out there. But building GNATStudio is something only a few people are intended to do. Others will benefit
from their pre-built packages.
There is of course no way AdaCore will change their tools to use any of the suggestions in this thread.
HAC is 100% unknown outside of the Ada community, and I would guess 100% unknown outside of the small comp.lang.ada subset of it.
At least for now, and things could possibly change in the future.
AdaCore has a large number of customers that have written their own integration scripts in python very easily.
Those scripts are in general not written by people with knowledge of Ada at all, those are the people responsible
for providing the tooling to other teams. So it would make no sense to only have HAC support for instance (and
would not remove any of the build difficulties to boot, since backward compatibility is a thing and python would
have to be kept)
Shark8 suggested that external dependencies are a bad thing altogether, and libraries like GtkAda and GNATCOLL
should never be used. This is totally opposite to what people actually want (see the development of Alire for instance,
or what happens in all programming languages out there). So that also makes no sense.
As the original poster mentioned, building GNATStudio is a very difficult thing. Just like building Firefox, or I presume Visual Studio,
or any large application out there. Things likely could be improved with better documentation, and that's likely where the
community should play a role. AdaCore developers in general have the proper setup because their colleagues helped them (there
is no secret documentation that they do not want to publish to the outside), and of course AdaCore cannot test on all systems
and all machines out there. But building GNATStudio is something only a few people are intended to do. Others will benefit
from their pre-built packages.
Shark8
Jul 30, 2021, 12:59:10 PM7/30/21
to
On Friday, July 30, 2021 at 5:51:51 AM UTC-6, briot wrote:
>
> Shark8 suggested that external dependencies are a bad thing altogether, and libraries like GtkAda and GNATCOLL
> should never be used.
This is a rather uncharitable take of my suggestion that all dependencies should be, from time to time, evaluated against their benefits and costs.
>
> Shark8 suggested that external dependencies are a bad thing altogether, and libraries like GtkAda and GNATCOLL
> should never be used.
But I do stand by it: if some dependency costs more to maintain (not excluding things like install/configuration or make/build troubles foisted on the users and maintainers) then it should be eliminated.
I have a rather harsh view of Python itself, especially the tendency to "it works on my computer!" WRT installation woes, that I strongly question if it *IS* "worth its keep".
> This is totally opposite to what people actually want (see the development of Alire for instance, or what happens in all programming languages out there). So that also makes no sense.
I'm sorry, but *HOW* does a package-manager's popularity (much less existence) negate my suggestion that a dependency's usefulness [and pain-points] should be evaluated?
Just because some package's dependency is well-used doesn't make it a good thing to depend upon, does it? I mean, consider the story of NPM and leftpad: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
Simon Wright
Jul 30, 2021, 1:07:59 PM7/30/21
to
Emmanuel Briot <briot.e...@gmail.com> writes:
Good sense.
> But building GNATStudio is something only a few people are intended to
> do. Others will benefit from their pre-built packages.
Those of us on macOS have no CE2021 (at least, from AdaCore :-), and
CE2020 has no GNATStudio. We don't know what the future holds for other
platforms.
Similar position for gnatprove. I don't know how hard it would be to
build from the Linux CE2021 sources.
Good sense.
> But building GNATStudio is something only a few people are intended to
> do. Others will benefit from their pre-built packages.
CE2020 has no GNATStudio. We don't know what the future holds for other
platforms.
Similar position for gnatprove. I don't know how hard it would be to
build from the Linux CE2021 sources.
Stéphane Rivière
Jul 31, 2021, 5:37:04 AM7/31/21
to
Le 30/07/2021 à 13:51, Emmanuel Briot a écrit :
> I must admit having a hard time understanding this discussion.
But it's a pleasure to talk with an Adacore insider :)
> I must admit having a hard time understanding this discussion.
> There is of course no way AdaCore will change their tools to use any of the suggestions in this thread.
> HAC is 100% unknown outside of the Ada community, and I would guess 100% unknown outside of the small comp.lang.ada subset of it.
than the snake :)
> At least for now, and things could possibly change in the future.
> So it would make no sense to only have HAC support for instance (and
> would not remove any of the build difficulties to boot, since backward compatibility is a thing and python would
> have to be kept)
an IDE written in Ada.
I guess GPS/GNATStudio was written also to demonstrate that Ada can
implement any complex graphical application.
So, this is a counterproductive example that gives the image of an
incomplete or weak language having to use Python to implement a
high-level IDE with scripting capabilities.
Emacs uses Lisp, Emacs users script in Lisp (like me at one point).
GNATStudio should have used an Ada subset from the start. The effort was
not made. It is too late. Next case :)
> As the original poster mentioned, building GNATStudio is a very difficult thing. Just like building Firefox, or I presume Visual Studio,
I builded GVD (the GNATStudio ancestor) a breeze, almost 20 years ago.
Then came GPS, with ton of C inside (nearly 30% due to Berkely DB
embedded at this time) and a "unmakeable" make process :>
> is no secret documentation that they do not want to publish to the outside)
GNATStudio build script with instructions, please :) As I don't believe
Adacore engineers keep this complex knowledge in their heads...
Anyway, it seems to me that the latest versions of GNATStudio are better
finished and the whole thing is a really nice tool to use.
All the best for you and Adacore team
Dmitry A. Kazakov
Jul 31, 2021, 6:30:33 AM7/31/21
to
On 2021-07-30 13:29, Stéphane Rivière wrote:
>> For scripting an Ada application one needs support of
>
> I don't see anything that HAC couldn't do, natively or with adaptations,
> both on the side of HAC and GNATStudio, considering the enormous amount
> of time that has been spent to integrate Python into GNATStudio.
It would help to provide a minimal example:
>> For scripting an Ada application one needs support of
>
> I don't see anything that HAC couldn't do, natively or with adaptations,
> both on the side of HAC and GNATStudio, considering the enormous amount
> of time that has been spent to integrate Python into GNATStudio.
--------------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
procedure Scripwriter is
function Square (X : Float) return Float is
begin
return X*X;
end Square;
Argument : constant Float := 2.0;
Result : Float;
begin
Load_HAC_Module (...); -- Load custom module making Square callable
Result := Call_HAC (..., Argument); -- Call script with Argument
Put_Line
( "Square of" & Float'Image (Argument) &
" =" & Float'Image (Result)
);
end Scripwriter ;
--------------------------------------------
The script would be sort of:
--------------------------------------------
with Custom_Module;
procedure Whatever (X : Float) is
begin
return Custom_Module.Square (X);
end Whatever;
--------------------------------------------
The HAC script must take Argument, call Square (accessible via the
module), return the result of Square (Argument).
> But, imho, this is all history, GNATStudio is scriptable in Python,
> GNATStudio is very difficult to build, Adacore is known to love Python
> and GNAT CE, as a whole, is a wonderful tool. We have to live with it ;)
module to interface GPS engine. Their customers would decide witch
script they would use.
What AdaCore *must* do is to remove static linking to Python. The GPS
user should choose the script language per preferences that would look
for the corresponding script run-time e.g. Python or HAC or whatever.
Stéphane Rivière
Jul 31, 2021, 7:58:39 AM7/31/21
to
> The HAC script must take Argument, call Square (accessible via the
> module), return the result of Square (Argument).
API HAC has Argument, Argument_Count and Set_Exit_Status, and the result
> module), return the result of Square (Argument).
can be piped.
However, I do not state HAC is production ready for GNATStudio... But
HAC is well written and easily hackable (I speak for Gautier ;)
> For AdaCore it is not really much work, they only have to provide a
> module to interface GPS engine. Their customers would decide witch
> script they would use.
the need for GNATStudio Python is mandatory anyway...
> What AdaCore *must* do is to remove static linking to Python. The GPS
> user should choose the script language per preferences that would look
> for the corresponding script run-time e.g. Python or HAC or whatever.
this is like reinventing the wheel.
The free software way could be to fork GNATStudio, simplify it and fully
change the build process. Personnaly, I've either nor the time and the
skills to go this way...
The biggest complaint I had about GNATStudio was its instability. I
think that Adacore has made great progress now. It's now a pleasure to
work with.
Dmitry A. Kazakov
Jul 31, 2021, 8:29:07 AM7/31/21
to
On 2021-07-31 13:58, Stéphane Rivière wrote:
>> The HAC script must take Argument, call Square (accessible via the
>> module), return the result of Square (Argument).
>
> API HAC has Argument, Argument_Count and Set_Exit_Status, and the result
> can be piped.
Whatever, you could post a complete example, when ready (:-)).
>> The HAC script must take Argument, call Square (accessible via the
>> module), return the result of Square (Argument).
>
> API HAC has Argument, Argument_Count and Set_Exit_Status, and the result
> can be piped.
E.g. here is a lesser sample in Julia, an Ada subprogram is called from
Julia back when Julia is called from Ada:
----------------------------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.C; use Interfaces.C;
with Julia; use Julia;
procedure Ada_Call is
Bin : constant String := "D:\Julia-1.2.0\bin";
begin
Load (Bin & "\libjulia.dll"); -- Load library
Init_With_Image (Bin); -- Initialize environment
declare
function Increment (X : Double) return Double;
pragma Convention (C, Increment);
function Increment (X : Double) return Double is
begin
return X + 1.0;
end Increment;
begin
Eval_String
( "println(ccall("
& CCall_Address (Increment'Address)
& ",Cdouble,(Cdouble,),10.0))"
);
end;
AtExit_Hook; -- Finalize environment
end Ada_Call;
Note, there is only one process!
-----------------------------------------------------------
> However, I do not state HAC is production ready for GNATStudio... But
> HAC is well written and easily hackable (I speak for Gautier ;)
That is not the point. The point is that AFAIK it cannot be used for
> HAC is well written and easily hackable (I speak for Gautier ;)
scripting unless examples as above provided.
>> What AdaCore *must* do is to remove static linking to Python. The GPS
>> user should choose the script language per preferences that would look
>> for the corresponding script run-time e.g. Python or HAC or whatever.
>
> Freedom choice. I agree. But I guess Adacore ressources are limited and
> this is like reinventing the wheel.
Moreover, whatever resources AdaCore has it does not make any sense to
call internal GPS functions implemented in Ada from Ada code via Python
scripts! So, no work involved.
> The biggest complaint I had about GNATStudio was its instability. I
> think that Adacore has made great progress now. It's now a pleasure to
> work with.
both Windows and Linux, it is just as it is. AdaCore can at best work
around GTK bugs.
Though Python is 100% self-inflicted damage. AdaCore could easily
implement some Ada script, again, not to confuse with shell. They did it
partially with GPR. The GPR compiler could be extended to support a
larger variety of expressions.
Customers wanting Python will use Eclipse instead of GPS anyway, so that
is not an argument either.
Shark8
Aug 2, 2021, 9:05:19 PM8/2/21
to
On Saturday, July 31, 2021 at 6:29:07 AM UTC-6, Dmitry A. Kazakov wrote:
> > The biggest complaint I had about GNATStudio was its instability. I
> > think that Adacore has made great progress now. It's now a pleasure to
> > work with.
> Yes, but each new version of GTK can change that. GTK is unstable on
> both Windows and Linux, it is just as it is. AdaCore can at best work
> around GTK bugs.
And this is exactly why I said that one should evaluate the consequences of your dependencies: depending on something unstable can easily introduce that instability into your program.
> > The biggest complaint I had about GNATStudio was its instability. I
> > think that Adacore has made great progress now. It's now a pleasure to
> > work with.
> Yes, but each new version of GTK can change that. GTK is unstable on
> both Windows and Linux, it is just as it is. AdaCore can at best work
> around GTK bugs.
>
> Though Python is 100% self-inflicted damage.
Agreed.
> Though Python is 100% self-inflicted damage.
While Python can be quick and "easy" for prototyping, there are whole classes of errors that any dynamic-typed language possesses which statically-typed languages do not. The only dynamically-typed programming language that I've come across which [arguably] has both the mechanisms and culture addressing those issues is LISP.
>AdaCore could easily
> implement some Ada script, again, not to confuse with shell. They did it
> partially with GPR. The GPR compiler could be extended to support a
> larger variety of expressions.
GPR is a very saddening example.
> implement some Ada script, again, not to confuse with shell. They did it
> partially with GPR. The GPR compiler could be extended to support a
> larger variety of expressions.
It's too "stringly-typed", it doesn't leverage the obvious structural Ada ancestry, and because of this the GPR-build tool is kneecapped.
(As an example, if GPR files were a tightly restricted GENERIC package [that is, a subset of Ada s.t. all GPR files were valid Ada], with build-options as formal-parameters, you could use the GPR-build tool to automatically generate menus and guide the user through a build.)
>
> Customers wanting Python will use Eclipse instead of GPS anyway, so that
> is not an argument either.
I see the reasoning there, but what basis do you have for such a strong assertion?
> Customers wanting Python will use Eclipse instead of GPS anyway, so that
> is not an argument either.
Dmitry A. Kazakov
Aug 3, 2021, 2:30:28 AM8/3/21
to
Stéphane Rivière
Aug 3, 2021, 3:20:22 AM8/3/21
to
> That is not the point. The point is that AFAIK it cannot be used for
> scripting unless examples as above provided.
I finally got it. You're right :)
> scripting unless examples as above provided.
> Though Python is 100% self-inflicted damage. AdaCore could easily
> implement some Ada script, again, not to confuse with shell. They did
it partially with GPR. The GPR compiler could be extended to support a
> larger variety of expressions.
> Customers wanting Python will use Eclipse instead of GPS anyway, so that
> is not an argument either.
Blady
Aug 27, 2021, 5:58:46 AM8/27/21
to
Though GPS mailing list hasn't been used since March 2017, I propose to
start a thread about sharing experiences in building GNAT Studio:
https://lists.adacore.com/pipermail/gps-devel/2021-August/000237.html
I've sent a first post with some basic questions about used component
versions which are unfortunately not present in INSTALL documentation.
Could please share your experience and component versions on the GPS list?
However, It would be nice to get little support from AdaCore staff.
Thanks, Pascal.
Roger Mc
Aug 27, 2021, 8:08:44 PM8/27/21
to
So Ada enthusiasts who want to build Ada GPS have to use Python.
Are you suggesting that GPS should be built using Eclipse?
Roger Mc
Aug 27, 2021, 8:10:48 PM8/27/21
to
Jeffrey R. Carter
Aug 28, 2021, 2:40:54 AM8/28/21
to
On 8/28/21 2:10 AM, Roger Mc wrote:
>
> Mac Safari complains that this list's website is insecure.
This "list" is a newsgroup. It doesn't have a website.
>
> Mac Safari complains that this list's website is insecure.
There are websites that allow reading and posting to newsgroups, such as Google
Groups, but they are not the only nor the best way to do so. Google Groups, for
example, ignores formatting of code in posts.
It may be preferable to use a news reader rather than such a website. I use
Thunderbird (https://www.thunderbird.net/) with Eternal September
(http://www.eternal-september.org/).
--
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104
Roger Mc
Aug 28, 2021, 3:16:21 AM8/28/21
to
What is https://lists.adacore.com/pipermail/gps-devel/2021-August/000237.html
which is what Safari responds to if its not a "website"?
Sorry if this is off topic.
Simon Wright
Aug 28, 2021, 3:21:55 AM8/28/21
to
Roger Mc <roge...@gmail.com> writes:
> On Saturday, August 28, 2021 at 4:40:54 PM UTC+10, Jeffrey R. Carter wrote:
>> On 8/28/21 2:10 AM, Roger Mc wrote:
>> >
>> > Mac Safari complains that this list's website is insecure.
>> This "list" is a newsgroup. It doesn't have a website.
I suppose that if you had but world enough and time you might have said
> On Saturday, August 28, 2021 at 4:40:54 PM UTC+10, Jeffrey R. Carter wrote:
>> On 8/28/21 2:10 AM, Roger Mc wrote:
>> >
>> > Mac Safari complains that this list's website is insecure.
>> This "list" is a newsgroup. It doesn't have a website.
*that* website!!!!
Jeffrey R. Carter
Aug 28, 2021, 5:14:52 AM8/28/21
to
On 8/28/21 9:16 AM, Roger Mc wrote:
> I'm a bit confused then.
> What is https://lists.adacore.com/pipermail/gps-devel/2021-August/000237.html
> which is what Safari responds to if its not a "website"?
Oh, that list. Sorry, I misunderstood. Since you had not edited a full screen of
> I'm a bit confused then.
> What is https://lists.adacore.com/pipermail/gps-devel/2021-August/000237.html
> which is what Safari responds to if its not a "website"?
quoted text, I didn't bother to read what you were responding to.
0 new messages