Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Daniel Norber]

The standard ADA.Containers library is not prepared for Ravenscar use.
Even bounded versions, like Bounded_double_Linked_List have several violations of Ravenscar, like Implicit_Heap_Allocation when i try to instantiate it, and bind it.


I've Found ADA95 booch ADT, but is not ready for the new ADA2012 aspects that let you write something like this:

for E of List loop
  E:= E + 1;
  --E is a reference. That increases performance with big structures.
end loop;

Someone know a modern ADA2012 third party ADT that compliances Ravenscar?.
Seems like ADA forgot Ravenscar users when they released 2005 containers.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Shark8]

On Tuesday, August 28, 2018 at 6:06:20 AM UTC-6, Daniel Norber wrote:
>
> Someone know a modern ADA2012 third party ADT that compliances Ravenscar?.
> Seems like ADA forgot Ravenscar users when they released 2005 containers.

You could try the Ada.Containers.Formal_* containers, IIRC they are designed to work with full SPARK and should work with Ravenscar. The other item you might want to check out is the red-black tree (Ada.Containers.Red_Black_Trees) that some of the Formal_* containers use in GNAT.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Daniel Norber]

El martes, 28 de agosto de 2018, 16:48:12 (UTC+2), Shark8  escribió:
> On Tuesday, August 28, 2018 at 6:06:20 AM UTC-6, Daniel Norber wrote:
> >
> > Someone know a modern ADA2012 third party ADT that compliances Ravenscar?.
> > Seems like ADA forgot Ravenscar users when they released 2005 containers.
> 
> You could try the Ada.Containers.Formal_* containers, IIRC they are designed to work with full SPARK and should work with Ravenscar. The other item you might want to check out is the red-black tree (Ada.Containers.Red_Black_Trees) that some of the Formal_* containers use in GNAT.

Thank you. You save my day with Formal_* containers.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Simon Wright]

Daniel Norber <danielnorberto@gmail.com> writes:

> The standard ADA.Containers library is not prepared for Ravenscar use.
> Even bounded versions, like Bounded_double_Linked_List have several
> violations of Ravenscar, like Implicit_Heap_Allocation when i try to
> instantiate it, and bind it.

Which compiler are you using? I ask because I encountered this with GCC
4.9.1 & GNAT GPL 2014

A workround (which allowed the package which revealed the problem to be
built) was to explicitly state the restriction in the body:

   pragma Restrictions (No_Implicit_Heap_Allocations);

   with Ada.Containers.Bounded_Vectors;

   package body Containing is

      subtype Index is Natural range 0 .. 19;
      subtype Line is String (1 .. 20);

      package Line_Vectors
        is new Ada.Containers.Bounded_Vectors (Index_Type   => Index,
                                               Element_Type => Line);

making it a compiler error. Of course, that's not going to help with the
unbounded Containers.

> I've Found ADA95 booch ADT, but is not ready for the new ADA2012
> aspects that let you write something like this:
>
> for E of List loop
>   E:= E + 1;
>   --E is a reference. That increases performance with big structures.
> end loop;

Not sure that would actually be a performance improvement.

> Someone know a modern ADA2012 third party ADT that compliances
> Ravenscar?.  Seems like ADA forgot Ravenscar users when they released
> 2005 containers.

The list of restriction violations for Bounded_Doubly_Linked_Lists (from
the ALI) for CE 2018 is

RV NO_ACCESS_SUBPROGRAMS
RV NO_DIRECT_BOOLEAN_OPERATORS
RV NO_DISPATCH
RV NO_EXCEPTIONS
RV NO_FINALIZATION
RV NO_NESTED_FINALIZATION
RV NO_RECURSION
RV NO_STANDARD_STORAGE_POOLS
RV NO_STREAMS
RV NO_UNCHECKED_ACCESS
RV NO_DEFAULT_INITIALIZATION
RV NO_DYNAMIC_SIZED_OBJECTS
RV NO_IMPLEMENTATION_ATTRIBUTES
RV NO_IMPLEMENTATION_PRAGMAS
RV NO_IMPLICIT_ALIASING
RV SPARK_05

I don't think any of those are non-Ravenscar?

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Daniel Norber]

> 
> > The standard ADA.Containers library is not prepared for Ravenscar use.
> > Even bounded versions, like Bounded_double_Linked_List have several
> > violations of Ravenscar, like Implicit_Heap_Allocation when i try to
> > instantiate it, and bind it.
> 
> Which compiler are you using? I ask because I encountered this with GCC
> 4.9.1 & GNAT GPL 2014
> 
> A workround (which allowed the package which revealed the problem to be
> built) was to explicitly state the restriction in the body:
> 
>    pragma Restrictions (No_Implicit_Heap_Allocations);
> 
>    with Ada.Containers.Bounded_Vectors;
> 
>    package body Containing is
> 
>       subtype Index is Natural range 0 .. 19;
>       subtype Line is String (1 .. 20);
> 
>       package Line_Vectors
>         is new Ada.Containers.Bounded_Vectors (Index_Type   => Index,
>                                                Element_Type => Line);
> 
> making it a compiler error. Of course, that's not going to help with the
> unbounded Containers.
> 
> > I've Found ADA95 booch ADT, but is not ready for the new ADA2012
> > aspects that let you write something like this:
> >
> > for E of List loop
> >   E:= E + 1;
> >   --E is a reference. That increases performance with big structures.
> > end loop;
> 
> Not sure that would actually be a performance improvement.
> 
> > Someone know a modern ADA2012 third party ADT that compliances
> > Ravenscar?.  Seems like ADA forgot Ravenscar users when they released
> > 2005 containers.
> 
> The list of restriction violations for Bounded_Doubly_Linked_Lists (from
> the ALI) for CE 2018 is
> 
> RV NO_ACCESS_SUBPROGRAMS
> RV NO_DIRECT_BOOLEAN_OPERATORS
> RV NO_DISPATCH
> RV NO_EXCEPTIONS
> RV NO_FINALIZATION
> RV NO_NESTED_FINALIZATION
> RV NO_RECURSION
> RV NO_STANDARD_STORAGE_POOLS
> RV NO_STREAMS
> RV NO_UNCHECKED_ACCESS
> RV NO_DEFAULT_INITIALIZATION
> RV NO_DYNAMIC_SIZED_OBJECTS
> RV NO_IMPLEMENTATION_ATTRIBUTES
> RV NO_IMPLEMENTATION_PRAGMAS
> RV NO_IMPLICIT_ALIASING
> RV SPARK_05
> 
> I don't think any of those are non-Ravenscar?

Thank you. The workaround you sayed works for me: Eplicit write the  pragma Restrictions (No_Implicit_Heap_Allocations) 
Yes, seems to be a problem of compiler becouse at the end no implicit heap allocation was used.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Randy Brukardt]

"Daniel Norber" <danielnorberto@gmail.com> wrote in message 
news:eec01618-ee08-4f7e-be3d-cb16ef2beb4b@googlegroups.com...
>
> The standard ADA.Containers library is not prepared for Ravenscar use.
> Even bounded versions, like Bounded_double_Linked_List have several 
> violations
>of Ravenscar, like Implicit_Heap_Allocation when i try to instantiate it, 
>and bind it.

The bounded versions aren't supposed to have any heap allocation, see for 
instance A.18.19(16/3). I'd expect that to be a requirement for a compiler 
supporting Ravenscar.

The other versions aren't intended to be used in safety-critical 
environments where heap use has to be constrained.

I'd suggest that this is a compiler bug that ought to be reported to your 
vendor. (And Simon suggests that it might have been an old bug already fixed 
in the current versions.)

                                            Randy.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Jere]

On Tuesday, August 28, 2018 at 8:24:23 PM UTC-4, Randy Brukardt wrote:
> "Daniel Norber" wrote in message 
> >
> > The standard ADA.Containers library is not prepared for Ravenscar use.
> > Even bounded versions, like Bounded_double_Linked_List have several 
> > violations
> >of Ravenscar, like Implicit_Heap_Allocation when i try to instantiate it, 
> >and bind it.
> 
> The bounded versions aren't supposed to have any heap allocation, see for 
> instance A.18.19(16/3). I'd expect that to be a requirement for a compiler 
> supporting Ravenscar.
> 
> The other versions aren't intended to be used in safety-critical 
> environments where heap use has to be constrained.
> 
> I'd suggest that this is a compiler bug that ought to be reported to your 
> vendor. (And Simon suggests that it might have been an old bug already fixed 
> in the current versions.)
> 
>                                             Randy.

I have a question about this as it has always bothered me.  The
section that specifies that is under Implementation Advice, which
doesn't sound binding.  That sounds more like it is a suggestion
to the vendor rather than a requirement.  Is Implementation
Advice such that a conforming Ada compiler must follow it
(so not really advice at that point)?  I've intentionally avoided
bounded containers in situations where I want portability for
some of my embedded targets that don't use heap because it 
doesn't sound guaranteed that it will not use heap, even
if my current compiler implements it that way now.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Jeffrey R. Carter]

On 08/30/2018 02:21 AM, Jere wrote:
> 
> I have a question about this as it has always bothered me.  The
> section that specifies that is under Implementation Advice, which
> doesn't sound binding.  That sounds more like it is a suggestion
> to the vendor rather than a requirement.  Is Implementation
> Advice such that a conforming Ada compiler must follow it
> (so not really advice at that point)?  I've intentionally avoided
> bounded containers in situations where I want portability for
> some of my embedded targets that don't use heap because it
> doesn't sound guaranteed that it will not use heap, even
> if my current compiler implements it that way now.

Technically, it's advice and implementations don't have to follow it. It's 
usually done as advice when it may not be possible to follow for some targets. 
My experience has been that vendors try to follow the advice if possible.

 From another point of view, the standard containers are not guaranteed to be 
suitable for applications that have specific requirements for their data 
structures. If you have such specific requirements, you should probably use data 
structures that you are sure meet them. So if you want bounded components that 
you know for sure don't do any heap allocation, you should use something like 
the PragmAda Reusable Components' bounded components, or write your own.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[AdaMagica]

Am Donnerstag, 30. August 2018 02:21:54 UTC+2 schrieb Jere:
> I have a question about this as it has always bothered me.  The
> section that specifies that is under Implementation Advice, which
> doesn't sound binding.  That sounds more like it is a suggestion
> to the vendor rather than a requirement.  Is Implementation
> Advice such that a conforming Ada compiler must follow it
> (so not really advice at that point)?  I've intentionally avoided
> bounded containers in situations where I want portability for
> some of my embedded targets that don't use heap because it 
> doesn't sound guaranteed that it will not use heap, even
> if my current compiler implements it that way now.

See AARM 1.1.2 for the structure of the RM, especially (37,37.a-d) for Implementation Advice.

Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:69e04c61-8ea3-40e2-bb9d-e5a128247df3@googlegroups.com...
> On Tuesday, August 28, 2018 at 8:24:23 PM UTC-4, Randy Brukardt wrote:
...
> I have a question about this as it has always bothered me.  The
> section that specifies that is under Implementation Advice, which
> doesn't sound binding.

Correct.

> That sounds more like it is a suggestion
> to the vendor rather than a requirement.  Is Implementation
> Advice such that a conforming Ada compiler must follow it
> (so not really advice at that point)?

No, but a conforming compiler needs to document any advice that they don't 
follow. The only problem with that is that I'm not aware of any compilers 
that actually do that (at least in an easy-to-use-form). Ada 83 compilers 
used to be required to have an annex F for validation purposes (note: it's 
Annex M in Ada 95 and later), but that requirement was dropped decades ago.

I once tried to do this documentation, but that that time there was no 
listing of Implementation Advice and as such I ended up abandoning it almost 
immediately. (We've since corrected that oversight in the Standard.) One of 
the major problems is that for a lot of these things, it would require a lot 
of compiler spelunking to figure it out what actually happens. (You would 
need to keep track of them as things are implemented to even have a chance.) 
It's easier to answer specific questions than to track down several hundred 
obscure issues that no one may ever care about.

> I've intentionally avoided
> bounded containers in situations where I want portability for
> some of my embedded targets that don't use heap because it
> doesn't sound guaranteed that it will not use heap, even
> if my current compiler implements it that way now.

In theory, you compiler vendor is supposed to tell you if they do any such 
things. In practice, it would be bizarre to support Ravenscar and then not 
let any containers work with it. Only a crazy vendor would do that on 
purpose, and surely any sane ones would take a priority change request on 
such things. (Janus/Ada doesn't support Ravenscar, and it's nearly 
impossible to write a generic that doesn't use the heap, but no one is going 
to expect to use Janus/Ada in such an environment anyway. But even so, we 
don't plan to use any explicit heap in the bounded containers -- whatever 
implicit stuff the compiler does is not really under the control of a 
programmer.)

In practice, I would be surprised if a vendor suddenly started using heap 
intentionally in one of these containers. Most likely, if they are 
targetting no-heap applications, they're well aware that bounded containers 
are supposed to be used in such scenarios, and would intend to keep that the 
case.

Note that there never is a guarantee of anything with a new compiler 
version: a new bug could cause your code to not compile or malfunction; new 
enforcement of a previously missed rule could cause your code to be 
rejected, and so on. Some care is always required.

                                                         Randy.