Gnu Emacs Ada mode 7.1.6 released.

Gnu Emacs Ada mode 7.1.6 released.

[Stephen Leake]

Gnu Emacs Ada mode 7.1.6 is now available in GNU ELPA.

This is a bug fix release.

ada-mode and wisi are now compatible with gnat FSF 11, Pro 22,
Community 2021.

-- 
-- Stephe

Re: Gnu Emacs Ada mode 7.1.6 released.

[Fernando Oleo Blanco]

I am sorry for the spam Stephen. I am getting used to these systems 
(first time using USENET). I wanted to respond publicly.
---

Thank you for the update Stephen.

I can confirm that it works with GNAT community 2021. It is the first
time I got it working.

However, a couple of comments. I could not use the build.sh script
directly. The line

WISI_DIR=`ls -d ../wisi*`

matches everything named wisi. In my case it is the following:

../wisi-3.1.5         ../wisitoken-grammar-mode-1.2.0
../wisi-3.1.5.signed  ../wisitoken-grammar-mode-1.2.0.signed

The *.signed entries are files, which screw with gprclean/build. So I
had to run each command manually. That is not a big issue for me, but as
you can understand, it can easily be a headache to a lot of people. For
that reason I would like to propose a small change. The wisitoken
package uses a slightly modified ls command:

export GPR_PROJECT_PATH=`ls -d ../wisi-3.1.?`

This type of pattern matching would solve the issue of finding too many
things. I would change the WISI_DIR entry to

WISI_DIR=`ls -d ../wisi-?.?.?`

Which ensures that only the directory of the package is matched. As far
as I know, the ? pattern matching is POSIX compliant, so it should work
in pretty much any $SHELL.

The second proposal would be to, instead of asking the user to run the
commands directly, that an elisp function is used. For example, the
package pdf-tools requires some compilation in order to use it. It comes
with the elisp function

(pdf-tools-install)

which installs the package, and it is pretty obvious to the user. It
also comes with

(pdf-loader-install)

which is recommended to be used in the configuration file. This function
checks whether the package has already been compiled/installed properly
at boot. If it is, then Emacs just loads it, if not, it gets compiled. I
think this is a much more user friendly experience, it would simplify
the installation process.

In the case of ada-mode, if the compilation fails, some report could be
emitted, such as "No Ada compiler found.", "The GNATCOLL dependencies
have to be installed previous to the compilation, please refer to XXX."
and finally "Compilation failed, please see the compilation
window."/"Compilation successful.". A function the style

(load-or-install-ada-mode)

could be created for this and the user could be requested to run it. Or
when ada-mode is called, that function could be executed. That way even
if the user is not aware of the compilation step, they are informed.
Instead of getting a cryptic wisi error message.

Thank you for your work and fixing the issue with the newer versions of
the compilers!

---
Fernando Oleo Blanco
https://irvise.xyz

Re: Gnu Emacs Ada mode 7.1.6 released.

[Simon Wright]

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

> I can confirm that it works with GNAT community 2021. It is the first
> time I got it working.

In my case it didn't: resurrection of old problems,

sal-gen_unbounded_definite_stacks.adb:209:07: error: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_stacks.adb:216:07: error: access discriminant in return object would be a dangling reference
wisitoken-syntax_trees.ads:620:04: warning: in instantiation at sal-gen_unbounded_definite_vectors.adb:65 [-gnatwv]
wisitoken-syntax_trees.ads:620:04: warning: aggregate not fully initialized [-gnatwv]
etc etc

This is because ada-mode-7.1.6 only "requires" wisi-3.1.3, which was
already installed, rather than the latest 3.1.5 ... install 3.1.5,
*delete 3.1.3*

> However, a couple of comments. I could not use the build.sh script
> directly. The line
>
> WISI_DIR=`ls -d ../wisi*`
>
> matches everything named wisi. In my case it is the following:
>
> ../wisi-3.1.5         ../wisitoken-grammar-mode-1.2.0
> ../wisi-3.1.5.signed  ../wisitoken-grammar-mode-1.2.0.signed

I used

WISI_DIR=`ls -d ../wisi* | grep -v signed`

but Fernando's suggestion is better, I think

Re: Gnu Emacs Ada mode 7.1.6 released.

[Fernando Oleo Blanco]

On 05.08.21 10:58, Simon Wright wrote:
> This is because ada-mode-7.1.6 only "requires" wisi-3.1.3, which was
> already installed, rather than the latest 3.1.5 ... install 3.1.5,
> *delete 3.1.3*

I would like to point out that I had never installed or compiled any of 
the components. Previous to this successful installation, I updated 
_all_ packages. Which yielded the newest version of ada-mode and wisi.

I am just giving a bit more information and context, in case someone 
tries to replicate what I did.

Regards,

-- 
Fernando Oleo Blanco
https://irvise.xyz

Re: Gnu Emacs Ada mode 7.1.6 released.

[Simon Wright]

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

> On 05.08.21 10:58, Simon Wright wrote:
>> This is because ada-mode-7.1.6 only "requires" wisi-3.1.3, which was
>> already installed, rather than the latest 3.1.5 ... install 3.1.5,
>> *delete 3.1.3*
>
> I would like to point out that I had never installed or compiled any
> of the components. Previous to this successful installation, I updated 
> _all_ packages. Which yielded the newest version of ada-mode and wisi.
>
> I am just giving a bit more information and context, in case someone
> tries to replicate what I did.

Thanks for the advice to update all packages (U x in the package list
window), which gives us ada-mode-7.1.7, which includes the "ls -d wisi*"
fix, and builds/works fine on macOS Big Sur with GCC 11.1.0 (see
previous remarks re: gnatcoll-db).

Re: Gnu Emacs Ada mode 7.1.6 released.

[Paul Onions]

On Saturday, 7 August 2021 at 11:35:29 UTC+1, Simon Wright wrote:
> ... builds/works fine on macOS Big Sur with GCC 11.1.0 ...

I'm using the same setup now, but for some reason I'm still seeing error messages about a void-function called wisi--lexer-error.  I can get a working system if I go into the wisi-3.1.5 directory and delete all of the .elc files I find there, but then editing can be very slow (e.g. delay between pressing a key and character appearing in buffer >5 secs sometimes).  Not sure if this is caused by my deleting the .elc files, but it also happened to me when I did the same thing in my workarounds to get the 7.1.4 ada-mode release working.

Paul

Re: Gnu Emacs Ada mode 7.1.6 released.

[Paul Onions]

On Saturday, 7 August 2021 at 17:47:40 UTC+1, Paul Onions wrote:
> ... I'm still seeing error messages about a void-function called wisi--lexer-error.

I think this is due to a missing:-
  (require 'cl-lib)
at the start of wisi-parse-common.el.

Paul

Re: Gnu Emacs Ada mode 7.1.6 released.

[Stephen Leake]

Paul Onions <ponions37@gmail.com> writes:

> On Saturday, 7 August 2021 at 17:47:40 UTC+1, Paul Onions wrote:
>> ... I'm still seeing error messages about a void-function called wisi--lexer-error.
>
> I think this is due to a missing:-
>   (require 'cl-lib)
> at the start of wisi-parse-common.el.

It does make sense that file should have that require; I don't know why
I don't see that error. I'll add it.

-- 
-- Stephe

Re: Gnu Emacs Ada mode 7.1.6 released.

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:
>
>> I can confirm that it works with GNAT community 2021. It is the first
>> time I got it working.
>
> In my case it didn't: resurrection of old problems,
>
> sal-gen_unbounded_definite_stacks.adb:209:07: error: access
> discriminant in return object would be a dangling reference
> sal-gen_unbounded_definite_stacks.adb:216:07: error: access
> discriminant in return object would be a dangling reference
> wisitoken-syntax_trees.ads:620:04: warning: in instantiation at
> sal-gen_unbounded_definite_vectors.adb:65 [-gnatwv]
> wisitoken-syntax_trees.ads:620:04: warning: aggregate not fully
> initialized [-gnatwv]
> etc etc
>
> This is because ada-mode-7.1.6 only "requires" wisi-3.1.3, which was
> already installed, rather than the latest 3.1.5 ... install 3.1.5,
> *delete 3.1.3*

I got a successful build with macOS GNAT CE 2021. However, using it
failed with

Execution of /Users/simon/.emacs.d/elpa/ada-mode-7.1.6/gpr_query terminated by unhandled exception
raised PROGRAM_ERROR : gnatcoll-sql_impl.adb:198 accessibility check failed
Load address: 0x1066e1000
Call stack traceback locations:
0x106932523 0x10693255f 0x10699b420 0x10699b5e9 0x10699b143 0x106988f88 0x1067830d4 0x1066f0fb1 0x106feb430

which is an unfortunate bleeding-edge interaction between the compiler
and gnatcoll-db:v21.0.0 (there are mutterings in the source at this line
about "GNAT bug OB03-009").

Building with FSF GCC 11.1.0 is looking good.

Which version of gnatcoll-db did you use, Fernando? The ada-mode README
isn't very prescriptive.

Re: Gnu Emacs Ada mode 7.1.6 released.

[Fernando Oleo Blanco]

On 05.08.21 15:42, Simon Wright wrote:
> Which version of gnatcoll-db did you use, Fernando? The ada-mode README
> isn't very prescriptive.

Oh, I forgot to mention this.

I used the master branch as of two days ago, so 2021/08/03. I thought 
about downloading a tagged version, as of that day the 21.0.0. But since 
I had already cloned master, I went with it.

I think this issue is related to this commit, which refers to that GNAT 
bug directly: 
https://github.com/AdaCore/gnatcoll-db/commit/c75234037fb4568739435fad204f206afe609a77

I am pretty sure it is the culprit.

Regards,
-- 
Fernando Oleo Blanco
https://irvise.xyz

Re: Gnu Emacs Ada mode 7.1.6 released.

[Manuel Gomez]

Am 5/8/21 um 15:51 schrieb Fernando Oleo Blanco:
> On 05.08.21 15:42, Simon Wright wrote:
>> Which version of gnatcoll-db did you use, Fernando? The ada-mode README
>> isn't very prescriptive.
> 
> Oh, I forgot to mention this.
> 
> I used the master branch as of two days ago, so 2021/08/03. I thought 
> about downloading a tagged version, as of that day the 21.0.0. But since 
> I had already cloned master, I went with it.
> 
> I think this issue is related to this commit, which refers to that GNAT 
> bug directly: 
> https://github.com/AdaCore/gnatcoll-db/commit/c75234037fb4568739435fad204f206afe609a77 
> 
> 
> I am pretty sure it is the culprit.


I share my experience, just in case it's useful for anyone.

I tried with GNAT CE 2021 and gnatcoll-db 2021, but had problems with 
that combination. I finally used gnat-9 and gnatcoll packages provided 
by Ubuntu 20.04, but had to add ".all" for "error: access discriminant 
in return object..." and remove the option to consider warnings as 
errors in "standard_common.gpr". Different compiler versions produce 
different warnings, so that flag might be counterproductive for 
distribution. The problem with 2021 version might have been the same, 
not sure about it.

Regards

Re: Gnu Emacs Ada mode 7.1.6 released.

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

>
> I got a successful build with macOS GNAT CE 2021. However, using it
> failed with
>
> Execution of /Users/simon/.emacs.d/elpa/ada-mode-7.1.6/gpr_query
> terminated by unhandled exception
> raised PROGRAM_ERROR : gnatcoll-sql_impl.adb:198 accessibility check failed
>
> which is an unfortunate bleeding-edge interaction between the compiler
> and gnatcoll-db:v21.0.0 (there are mutterings in the source at this line
> about "GNAT bug OB03-009").

I tried to attach a patch for that, but nntp.aioe.org says "441 Invalid
Content type" even for text/plain. So I include it inline below; it
applies to the 21.2 release branch of gnatcoll-sql from github AdaCore.
I guess I should have included it in 3.1.8.

> Which version of gnatcoll-db did you use, Fernando? The ada-mode README
> isn't very prescriptive.

ada-mode.info has more detail in the Install section.

-------------- gnatcoll-2021-sql.patch -----------------
--- sql/gnatcoll-sql_impl.adb.orig	2021-05-20 01:25:55.000000000 -0700
+++ sql/gnatcoll-sql_impl.adb	2021-06-21 09:44:09.437292100 -0700
@@ -188,15 +188,9 @@
         (Self         : Field;
          To           : in out SQL_Field_List'Class;
          Is_Aggregate : in out Boolean)
-      is
-         FC : access SQL_Field_Internal'Class;
-      begin
+      is begin
          if not Self.Data.Is_Null then
-            --  !!! Could not use Element call result in the
-            --  Append_If_Not_Aggregate parameter because of GNAT bug OB03-009
-
-            FC := Self.Data.Get.Element;
-            Append_If_Not_Aggregate (FC, To, Is_Aggregate);
+            Append_If_Not_Aggregate (Self.Data.Get.Element, To, Is_Aggregate);
          end if;
       end Append_If_Not_Aggregate;
    end Data_Fields;
---------------------------

-- 
-- Stephe

Re: Gnu Emacs Ada mode 7.1.6 released.

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:
>
>> I can confirm that it works with GNAT community 2021. It is the first
>> time I got it working.
>
> In my case it didn't: resurrection of old problems,
>
> This is because ada-mode-7.1.6 only "requires" wisi-3.1.3, 

Sigh. to be fixed in 7.1.8.

I could argue that wisi 3.1.3 is technically correct, since ada-mode
7.1.6 does compile with it. But that's not really the point here; easy
user upgrade is more more important.


-- 
-- Stephe

Re: Gnu Emacs Ada mode 7.1.6 released.

[Stephen Leake]

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

> I am sorry for the spam Stephen. I am getting used to these systems
> (first time using USENET). I wanted to respond publicly.

This is not spam!

> However, a couple of comments. I could not use the build.sh script
> directly. The line
>
> WISI_DIR=`ls -d ../wisi*`
>
> matches everything named wisi. 

Fixed in 7.1.7

> The second proposal would be to, instead of asking the user to run the
> commands directly, that an elisp function is used. 

I keep hoping *someone else* will implement this :).


-- 
-- Stephe