comp.lang.ada
 help / color / mirror / Atom feed
* Building the 2021 source release of GnatStudio
@ 2021-07-28  9:25 Rod Kay
  2021-07-28 10:49 ` Emmanuel Briot
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Rod Kay @ 2021-07-28  9:25 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-28  9:25 Building the 2021 source release of GnatStudio Rod Kay
@ 2021-07-28 10:49 ` Emmanuel Briot
  2021-07-28 14:29   ` Simon Wright
  2021-07-29 10:29   ` Rod Kay
  2021-07-29  0:49 ` Randy Brukardt
  2021-07-29  1:09 ` Roger Mc
  2 siblings, 2 replies; 34+ messages in thread
From: Emmanuel Briot @ 2021-07-28 10:49 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-28 10:49 ` Emmanuel Briot
@ 2021-07-28 14:29   ` Simon Wright
  2021-07-29 10:29   ` Rod Kay
  1 sibling, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-07-28 14:29 UTC (permalink / raw)


Emmanuel Briot <briot.emmanuel@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
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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-28  9:25 Building the 2021 source release of GnatStudio Rod Kay
  2021-07-28 10:49 ` Emmanuel Briot
@ 2021-07-29  0:49 ` Randy Brukardt
  2021-07-29  7:49   ` Luke A. Guest
                     ` (2 more replies)
  2021-07-29  1:09 ` Roger Mc
  2 siblings, 3 replies; 34+ messages in thread
From: Randy Brukardt @ 2021-07-29  0:49 UTC (permalink / raw)


"Rod Kay" <rodakay5@gmail.com> wrote in message 
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 
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.


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-28  9:25 Building the 2021 source release of GnatStudio Rod Kay
  2021-07-28 10:49 ` Emmanuel Briot
  2021-07-29  0:49 ` Randy Brukardt
@ 2021-07-29  1:09 ` Roger Mc
  2021-07-29 10:47   ` Rod Kay
  2 siblings, 1 reply; 34+ messages in thread
From: Roger Mc @ 2021-07-29  1:09 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  0:49 ` Randy Brukardt
@ 2021-07-29  7:49   ` Luke A. Guest
  2021-07-29  8:41     ` Dmitry A. Kazakov
  2021-07-30  0:21     ` Randy Brukardt
  2021-07-29 10:37   ` Rod Kay
  2021-07-29 17:23   ` Shark8
  2 siblings, 2 replies; 34+ messages in thread
From: Luke A. Guest @ 2021-07-29  7:49 UTC (permalink / raw)



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.

Some people still have to build them.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  7:49   ` Luke A. Guest
@ 2021-07-29  8:41     ` Dmitry A. Kazakov
  2021-07-29 11:33       ` Stéphane Rivière
  2021-07-30  0:21     ` Randy Brukardt
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-29  8:41 UTC (permalink / raw)


On 2021-07-29 09:49, Luke A. Guest wrote:
> 
> 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.
> 
> Some people still have to build them.

First, never ever use Python!

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-28 10:49 ` Emmanuel Briot
  2021-07-28 14:29   ` Simon Wright
@ 2021-07-29 10:29   ` Rod Kay
  1 sibling, 0 replies; 34+ messages in thread
From: Rod Kay @ 2021-07-29 10:29 UTC (permalink / raw)


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

    I appreciate your efforts. GnatStudio is a wonderful tool which I've 
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...

    Building the Ada part of GnatStudio was not the main problem. The 
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.
> 

    I've been maintaining Ada packages for Archlinux for several years 
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).

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  0:49 ` Randy Brukardt
  2021-07-29  7:49   ` Luke A. Guest
@ 2021-07-29 10:37   ` Rod Kay
  2021-07-29 14:37     ` J-P. Rosen
  2021-07-29 17:23   ` Shark8
  2 siblings, 1 reply; 34+ messages in thread
From: Rod Kay @ 2021-07-29 10:37 UTC (permalink / raw)


On 29/7/21 10:49 am, Randy Brukardt wrote:
> "Rod Kay" <rodakay5@gmail.com> wrote in message
> 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
> 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.
> 

    I guess the point I was trying to make was 'Why is GnatStudio using 
Python at all, given that Ada is superior ?'.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  1:09 ` Roger Mc
@ 2021-07-29 10:47   ` Rod Kay
  2021-08-27  9:58     ` Blady
  0 siblings, 1 reply; 34+ messages in thread
From: Rod Kay @ 2021-07-29 10:47 UTC (permalink / raw)


On 29/7/21 11:09 am, Roger Mc wrote:
> On Wednesday, July 28, 2021 at 7:25:53 PM UTC+10, roda...@gmail.com wrote:
> 
> Yes! I once tried to build it and found similar problems.
> 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.
> 

    I ended up installing the files from 'GNAT/2021/share/gnatstudio' 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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  8:41     ` Dmitry A. Kazakov
@ 2021-07-29 11:33       ` Stéphane Rivière
  2021-07-29 11:58         ` Dmitry A. Kazakov
  0 siblings, 1 reply; 34+ messages in thread
From: Stéphane Rivière @ 2021-07-29 11:33 UTC (permalink / raw)


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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29 11:33       ` Stéphane Rivière
@ 2021-07-29 11:58         ` Dmitry A. Kazakov
  2021-07-30 11:29           ` Stéphane Rivière
  0 siblings, 1 reply; 34+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-29 11:58 UTC (permalink / raw)


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

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29 10:37   ` Rod Kay
@ 2021-07-29 14:37     ` J-P. Rosen
  2021-07-29 17:43       ` Shark8
  0 siblings, 1 reply; 34+ messages in thread
From: J-P. Rosen @ 2021-07-29 14:37 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  0:49 ` Randy Brukardt
  2021-07-29  7:49   ` Luke A. Guest
  2021-07-29 10:37   ` Rod Kay
@ 2021-07-29 17:23   ` Shark8
  2 siblings, 0 replies; 34+ messages in thread
From: Shark8 @ 2021-07-29 17:23 UTC (permalink / raw)


On Wednesday, July 28, 2021 at 6:49:17 PM UTC-6, Randy Brukardt wrote:
> "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.
(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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29 14:37     ` J-P. Rosen
@ 2021-07-29 17:43       ` Shark8
  0 siblings, 0 replies; 34+ messages in thread
From: Shark8 @ 2021-07-29 17:43 UTC (permalink / raw)


On Thursday, July 29, 2021 at 8:37:51 AM UTC-6, J-P. Rosen wrote:
> 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 
> 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
I mean we could do that even easier with FORTH, and distribute the Ada implementation alongside it.
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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29  7:49   ` Luke A. Guest
  2021-07-29  8:41     ` Dmitry A. Kazakov
@ 2021-07-30  0:21     ` Randy Brukardt
  1 sibling, 0 replies; 34+ messages in thread
From: Randy Brukardt @ 2021-07-30  0:21 UTC (permalink / raw)


"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:sdtmk1$jl4$1@gioia.aioe.org...
>
> 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.
>
> Some people still have to build them.

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.


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29 11:58         ` Dmitry A. Kazakov
@ 2021-07-30 11:29           ` Stéphane Rivière
  2021-07-30 11:51             ` Emmanuel Briot
  2021-07-31 10:30             ` Dmitry A. Kazakov
  0 siblings, 2 replies; 34+ messages in thread
From: Stéphane Rivière @ 2021-07-30 11:29 UTC (permalink / raw)


> 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 ;)


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-30 11:29           ` Stéphane Rivière
@ 2021-07-30 11:51             ` Emmanuel Briot
  2021-07-30 16:59               ` Shark8
                                 ` (2 more replies)
  2021-07-31 10:30             ` Dmitry A. Kazakov
  1 sibling, 3 replies; 34+ messages in thread
From: Emmanuel Briot @ 2021-07-30 11:51 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-30 11:51             ` Emmanuel Briot
@ 2021-07-30 16:59               ` Shark8
  2021-07-30 17:07               ` Simon Wright
  2021-07-31  9:37               ` Stéphane Rivière
  2 siblings, 0 replies; 34+ messages in thread
From: Shark8 @ 2021-07-30 16:59 UTC (permalink / raw)


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.
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/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-30 11:51             ` Emmanuel Briot
  2021-07-30 16:59               ` Shark8
@ 2021-07-30 17:07               ` Simon Wright
  2021-07-31  9:37               ` Stéphane Rivière
  2 siblings, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-07-30 17:07 UTC (permalink / raw)


Emmanuel Briot <briot.emmanuel@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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-30 11:51             ` Emmanuel Briot
  2021-07-30 16:59               ` Shark8
  2021-07-30 17:07               ` Simon Wright
@ 2021-07-31  9:37               ` Stéphane Rivière
  2 siblings, 0 replies; 34+ messages in thread
From: Stéphane Rivière @ 2021-07-31  9:37 UTC (permalink / raw)


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 :)

> There is of course no way AdaCore will change their tools to use any of the suggestions in this thread.

I didn't even think about it :)

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

It uses a clean subset of a certain computer language we know better
than the snake :)

> At least for now, and things could possibly change in the future.

Legacy has to be handle. So I think it's too late and probably irrelevant.

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

The root of the problem is (to my taste) there. Python has no place in
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,

That's, to my taste, definitly not a valuable excuse :)

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)

No secret documentation ? Okay. So I need it for Linux :) A full
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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-30 11:29           ` Stéphane Rivière
  2021-07-30 11:51             ` Emmanuel Briot
@ 2021-07-31 10:30             ` Dmitry A. Kazakov
  2021-07-31 11:58               ` Stéphane Rivière
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-31 10:30 UTC (permalink / raw)


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:
--------------------------------------------
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 ;)

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.

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.

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-31 10:30             ` Dmitry A. Kazakov
@ 2021-07-31 11:58               ` Stéphane Rivière
  2021-07-31 12:29                 ` Dmitry A. Kazakov
  0 siblings, 1 reply; 34+ messages in thread
From: Stéphane Rivière @ 2021-07-31 11:58 UTC (permalink / raw)


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

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.

You're right. That is the best way to handle it. But Emmanuel says that
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.

Freedom choice. I agree. But I guess Adacore ressources are limited and
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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-31 11:58               ` Stéphane Rivière
@ 2021-07-31 12:29                 ` Dmitry A. Kazakov
  2021-08-03  1:05                   ` Shark8
  2021-08-03  7:20                   ` Stéphane Rivière
  0 siblings, 2 replies; 34+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-31 12:29 UTC (permalink / raw)


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 (:-)).

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

It is a minimal requirement to replace static linking with dynamic.

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.

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

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-31 12:29                 ` Dmitry A. Kazakov
@ 2021-08-03  1:05                   ` Shark8
  2021-08-03  6:30                     ` Dmitry A. Kazakov
  2021-08-03  7:20                   ` Stéphane Rivière
  1 sibling, 1 reply; 34+ messages in thread
From: Shark8 @ 2021-08-03  1:05 UTC (permalink / raw)


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.
> 
> Though Python is 100% self-inflicted damage.
Agreed.
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.
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?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-03  1:05                   ` Shark8
@ 2021-08-03  6:30                     ` Dmitry A. Kazakov
  0 siblings, 0 replies; 34+ messages in thread
From: Dmitry A. Kazakov @ 2021-08-03  6:30 UTC (permalink / raw)


On 2021-08-03 03:05, Shark8 wrote:
> On Saturday, July 31, 2021 at 6:29:07 AM UTC-6, Dmitry A. Kazakov wrote:

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

There is logic in each madness.

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-31 12:29                 ` Dmitry A. Kazakov
  2021-08-03  1:05                   ` Shark8
@ 2021-08-03  7:20                   ` Stéphane Rivière
  2021-08-28  0:08                     ` Roger Mc
  1 sibling, 1 reply; 34+ messages in thread
From: Stéphane Rivière @ 2021-08-03  7:20 UTC (permalink / raw)


> 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 :)

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

GPR is a great tool. I hope Adacore will go even further in its features.

> Customers wanting Python will use Eclipse instead of GPS anyway, so that
> is not an argument either.

I /fully/ agree.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-07-29 10:47   ` Rod Kay
@ 2021-08-27  9:58     ` Blady
  2021-08-28  0:10       ` Roger Mc
  0 siblings, 1 reply; 34+ messages in thread
From: Blady @ 2021-08-27  9:58 UTC (permalink / raw)


Le 29/07/2021 à 12:47, Rod Kay a écrit :
> On 29/7/21 11:09 am, Roger Mc wrote:
>> On Wednesday, July 28, 2021 at 7:25:53 PM UTC+10, roda...@gmail.com 
>> wrote:
>>
>> Yes! I once tried to build it and found similar problems.
>> 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.
>>
> 
>     I ended up installing the files from 'GNAT/2021/share/gnatstudio' 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


Hello,

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-03  7:20                   ` Stéphane Rivière
@ 2021-08-28  0:08                     ` Roger Mc
  0 siblings, 0 replies; 34+ messages in thread
From: Roger Mc @ 2021-08-28  0:08 UTC (permalink / raw)


On Tuesday, August 3, 2021 at 5:20:22 PM UTC+10, Stéphane Rivière wrote:
> > 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 :)
> > 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.
> GPR is a great tool. I hope Adacore will go even further in its features.
> > Customers wanting Python will use Eclipse instead of GPS anyway, so that 
> > is not an argument either.
> I /fully/ agree.
But the big problem is that AdaCore uses Python extensively.
So Ada enthusiasts who want to build Ada GPS have to use Python.
Are you suggesting that GPS should be built using Eclipse?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-27  9:58     ` Blady
@ 2021-08-28  0:10       ` Roger Mc
  2021-08-28  6:40         ` Jeffrey R. Carter
  0 siblings, 1 reply; 34+ messages in thread
From: Roger Mc @ 2021-08-28  0:10 UTC (permalink / raw)


On Friday, August 27, 2021 at 7:58:46 PM UTC+10, Blady wrote:
> Le 29/07/2021 à 12:47, Rod Kay a écrit : 
> > On 29/7/21 11:09 am, Roger Mc wrote: 
> >> On Wednesday, July 28, 2021 at 7:25:53 PM UTC+10, roda...@gmail.com 
> >> wrote: 
> >> 
> >> Yes! I once tried to build it and found similar problems. 
> >> 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. 
> >> 
> > 
> > I ended up installing the files from 'GNAT/2021/share/gnatstudio' 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
> Hello, 
> 
> 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.

Mac Safari complains that this list's website is insecure.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-28  0:10       ` Roger Mc
@ 2021-08-28  6:40         ` Jeffrey R. Carter
  2021-08-28  7:16           ` Roger Mc
  0 siblings, 1 reply; 34+ messages in thread
From: Jeffrey R. Carter @ 2021-08-28  6:40 UTC (permalink / raw)


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.

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-28  6:40         ` Jeffrey R. Carter
@ 2021-08-28  7:16           ` Roger Mc
  2021-08-28  7:21             ` Simon Wright
  2021-08-28  9:14             ` Jeffrey R. Carter
  0 siblings, 2 replies; 34+ messages in thread
From: Roger Mc @ 2021-08-28  7:16 UTC (permalink / raw)


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. 
> 
> 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
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"?
Sorry if this is off topic.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-28  7:16           ` Roger Mc
@ 2021-08-28  7:21             ` Simon Wright
  2021-08-28  9:14             ` Jeffrey R. Carter
  1 sibling, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-08-28  7:21 UTC (permalink / raw)


Roger Mc <rogermcm2@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
*that* website!!!!

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Building the 2021 source release of GnatStudio
  2021-08-28  7:16           ` Roger Mc
  2021-08-28  7:21             ` Simon Wright
@ 2021-08-28  9:14             ` Jeffrey R. Carter
  1 sibling, 0 replies; 34+ messages in thread
From: Jeffrey R. Carter @ 2021-08-28  9:14 UTC (permalink / raw)


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 
quoted text, I didn't bother to read what you were responding to.

-- 
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2021-08-28  9:14 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-28  9:25 Building the 2021 source release of GnatStudio Rod Kay
2021-07-28 10:49 ` Emmanuel Briot
2021-07-28 14:29   ` Simon Wright
2021-07-29 10:29   ` Rod Kay
2021-07-29  0:49 ` Randy Brukardt
2021-07-29  7:49   ` Luke A. Guest
2021-07-29  8:41     ` Dmitry A. Kazakov
2021-07-29 11:33       ` Stéphane Rivière
2021-07-29 11:58         ` Dmitry A. Kazakov
2021-07-30 11:29           ` Stéphane Rivière
2021-07-30 11:51             ` Emmanuel Briot
2021-07-30 16:59               ` Shark8
2021-07-30 17:07               ` Simon Wright
2021-07-31  9:37               ` Stéphane Rivière
2021-07-31 10:30             ` Dmitry A. Kazakov
2021-07-31 11:58               ` Stéphane Rivière
2021-07-31 12:29                 ` Dmitry A. Kazakov
2021-08-03  1:05                   ` Shark8
2021-08-03  6:30                     ` Dmitry A. Kazakov
2021-08-03  7:20                   ` Stéphane Rivière
2021-08-28  0:08                     ` Roger Mc
2021-07-30  0:21     ` Randy Brukardt
2021-07-29 10:37   ` Rod Kay
2021-07-29 14:37     ` J-P. Rosen
2021-07-29 17:43       ` Shark8
2021-07-29 17:23   ` Shark8
2021-07-29  1:09 ` Roger Mc
2021-07-29 10:47   ` Rod Kay
2021-08-27  9:58     ` Blady
2021-08-28  0:10       ` Roger Mc
2021-08-28  6:40         ` Jeffrey R. Carter
2021-08-28  7:16           ` Roger Mc
2021-08-28  7:21             ` Simon Wright
2021-08-28  9:14             ` Jeffrey R. Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox