* "Equality operator appears too late"
@ 2018-11-10 10:36 7% JLotty
0 siblings, 0 replies; 7+ results
From: JLotty @ 2018-11-10 10:36 UTC (permalink / raw)
with Ada.Containers.Synchronized_Queue_Interfaces;
with Ada.Containers.Unbounded_Priority_Queues;
procedure Min_Working_Example is
generic
type Data_Type is private;
type Weight_Type is (<>);
with function "<" (Left, Right : Weight_Type) return Boolean is <>;
package Min_Data_Structure is
private
type Data_Rec is record
Data : Data_Type;
Weight : Weight_Type;
end record;
function Get_Priority
(Element : Data_Rec)
return Weight_Type;
function Before
(Left, Right : Weight_Type)
return Boolean;
package Queue_Interface is new Ada.Containers.Synchronized_Queue_Interfaces
(Data_Rec);
package Edge_Queue is new Ada.Containers.Unbounded_Priority_Queues
(Queue_Interfaces => Queue_Interface,
Queue_Priority => Weight_Type,
Get_Priority => Get_Priority,
Before => Before);
end Min_Data_Structure;
package body Min_Data_Structure is
function Get_Priority
(Element : Data_Rec)
return Weight_Type is
(Element.Weight);
function Before
(Left, Right : Weight_Type)
return Boolean is
(Left < Right);
end Min_Data_Structure;
begin
null;
end Min_Working_Example;
==================================================
When compiling the above, I get the following error:
Builder results
min_working_example.adb
27:7 equality operator appears too late
27:7 instantiation error at a-cuprqu.ads:76
The error is occurring when the builder tries to elaborate the Ada.Containers.Unbounded_Priority_Queues package, where and "=" operator is defined on line 76.
I'm running the following command for build:
gprbuild -q -c -f -gnatc -u -Ptest.gpr min_working_example.adb
using version:
GPRBUILD GPL 2017 (20170515) (x86_64-pc-linux-gnu)
Copyright (C) 2004-2017, AdaCore
I don't know what to do from here. Any help you can offer would be appreciated.
^ permalink raw reply [relevance 7%]
* Re: open a file non-blocking ?
@ 2018-02-26 16:41 5% ` Jeffrey R. Carter
0 siblings, 0 replies; 7+ results
From: Jeffrey R. Carter @ 2018-02-26 16:41 UTC (permalink / raw)
> On Saturday, February 24, 2018 at 2:42:30 PM UTC-5, pat...@spellingbeewinnars.org wrote:
>
> There does not seem to be an option to open a file non-blocking. Is there a way?
I guess it depends on what you mean by non-blocking. Some of the responses on
here seem to think it means you can issue a write to the file and it returns
immediately, without waiting for the write to file to complete.
If that's the case, the normal way to deal with this within Ada is something like
package Write_Queue_Interfaces is new
Ada.Containers.Synchronized_Queue_Interfaces
(Element_Type => Ada.Strings.Unbounded.Unbounded_String);
package Write_Queues is new Ada.Containers.Unbounded_Synchornized_Queues
(Queue_Interfaces => Write_Queue_Interfaces);
Write_Queue : Write_Queues.Queue;
task Writer;
task body Writer is
File : Ada.Text_IO.File_Type;
Item : Ada.Strings.Unbounded.Unbounded_String;
begin -- Writer
Ada.Text_IO.Create (File => File, Name => ...);
Forever : loop
Write_Queue.Dequeue (Element => Item);
Ada.Text_IO.Put_Line
(File => File, Item => Ada.Strings.Unbounded.To_String (Item) );
end loop Forever;
end Writer;
Probably in reality you'd want a way to exit the loop and close the file. A task
wishing to write Msg to the file does
Write_Queue.Enqueue
(New_Item => Ada.Strings.Unbounded.To_Unbounded_String (Msg) );
--
Jeff Carter
"He nevere yet no vileynye ne sayde
In al his lyf unto no maner wight."
Canterbury Tales
156
^ permalink raw reply [relevance 5%]
* Re: "STORAGE_ERROR : s-intman.adb:139 explicit raise" from record containing a queue from Ada.Containers.Bounded_Synchronized_Queues in Gnat Ada 2014
2015-02-27 19:26 6% "STORAGE_ERROR : s-intman.adb:139 explicit raise" from record containing a queue from Ada.Containers.Bounded_Synchronized_Queues in Gnat Ada 2014 jocpaine
@ 2015-02-28 21:59 0% ` Stephen Leake
0 siblings, 0 replies; 7+ results
From: Stephen Leake @ 2015-02-28 21:59 UTC (permalink / raw)
jocpaine@googlemail.com writes:
> with Ada.Containers.Synchronized_Queue_Interfaces;
> with Ada.Containers.Bounded_Synchronized_Queues;
>
> procedure Q11 is
>
> package Job_Queues_Interface is
> new Ada.Containers.Synchronized_Queue_Interfaces
> ( Element_Type => Integer );
>
> package Job_Queues_Package is
> new Ada.Containers.Bounded_Synchronized_Queues
> ( Queue_Interfaces => Job_Queues_Interface
> , Default_Capacity => 100
> );
>
> subtype My_Queue_Type is Job_Queues_Package.Queue;
>
> type Job_Queue is record
> Queue: My_Queue_Type;
> end record;
>
> q : Job_Queue;
> -- This is the line causing the error. If I give q
> -- My_Queue_Type instead, the error doesn't happen.
The declaration of Queue in Ada.Containers.Bounded_Synchronized_Queues
includes:
protected type Queue
(Capacity : Count_Type := Default_Capacity;
Ceiling : System.Any_Priority := Default_Ceiling)
with
Priority => Ceiling
is new Queue_Interfaces.Queue with
...
private
List : Implementation.List_Type (Capacity);
end Queue;
List_Type is:
type List_Type (Capacity : Count_Type) is tagged limited record
First, Last : Count_Type := 0;
Length : Count_Type := 0;
Max_Length : Count_Type := 0;
Elements : Element_Array (1 .. Capacity) := (others => <>);
end record;
So if Capacity is large enough, you'll get Storage_Error.
In type Queue, the discriminant Capacity has a default value, which
means it is allowed to be changed, in particular to Count_Type'last,
which is large enough to cause Storage_Error.
If you change Default_Capacity to 2**31-1, you get Storage_Error for
either case.
So apparently GNAT allocates the largest allowed space when you use type
Job_Queue, but when you use the type My_Queu_Type, it allocates the
space needed for the current discriminant.
--
-- Stephe
^ permalink raw reply [relevance 0%]
* "STORAGE_ERROR : s-intman.adb:139 explicit raise" from record containing a queue from Ada.Containers.Bounded_Synchronized_Queues in Gnat Ada 2014
@ 2015-02-27 19:26 6% jocpaine
2015-02-28 21:59 0% ` Stephen Leake
0 siblings, 1 reply; 7+ results
From: jocpaine @ 2015-02-27 19:26 UTC (permalink / raw)
Hi. I've defined a queue type by instantiating Ada.Containers.Bounded_Synchronized_Queues . When I define a record with a field of that type, and then declare a variable of the record type, I get the storage error mentioned in the email subject line. That happens even if I never use the variable. However, if my variable is the queue type, I don't get the error. I'm surprised at that, because I'd expect a one-field record to have exactly the same storage layout as its field, so if one provokes the error, so should the other. That aside though, can anyone suggest a fix?
Google shows me that similar errors have been reported before (not with the queue types): for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42816 , "Bug 42816 - Crash in Ada.Containers.Vectors.Update_Element".
I'm using Gnat Ada 2014: specifically, gnatmake GPL 2014 (20140331) on Ubuntu 14.10 on version 3.16.0-30-generic of the Linux kernel. My program is below. I compiled it by doing
gnatmake q11
from the file q11.adb . Running it by doing
./q11
gives the error.
Here's the program:
with Ada.Containers.Synchronized_Queue_Interfaces;
with Ada.Containers.Bounded_Synchronized_Queues;
procedure Q11 is
package Job_Queues_Interface is
new Ada.Containers.Synchronized_Queue_Interfaces
( Element_Type => Integer );
package Job_Queues_Package is
new Ada.Containers.Bounded_Synchronized_Queues
( Queue_Interfaces => Job_Queues_Interface
, Default_Capacity => 100
);
subtype My_Queue_Type is Job_Queues_Package.Queue;
type Job_Queue is record
Queue: My_Queue_Type;
end record;
q : Job_Queue;
-- This is the line causing the error. If I give q
-- My_Queue_Type instead, the error doesn't happen.
begin
NULL;
end;
Thanks
Jocelyn Ireson-Paine
www.j-paine.org
www.jocelyns-cartoons.uk
^ permalink raw reply [relevance 6%]
* Re: Simp,e example for 2 tasks
@ 2014-09-21 20:33 7% ` Jeffrey Carter
0 siblings, 0 replies; 7+ results
From: Jeffrey Carter @ 2014-09-21 20:33 UTC (permalink / raw)
On 2014-09-21 7:31 AM, Stribor40 wrote:
> Would anyone be able to post simple example of ada program showing 2 tasks
> taking to each other please. For example one task sends message to another
> saying "hi" and second taks replying "hi back".
As others have pointed out, Ada tasking is based on synchronous communication,
not the message queues found in other languages. This why Ada had to introduce
the partition concept to achieve distribution, while Erlang processes distribute
quite nicely by themselves, as the ping-pong example shows.
It follows that to have message passing in Ada one must create the mechanism
that stores a message from one task and allows another task to retrieve it. In
Ada 12 one can use the synchronized-queue containers for that.
with Ada.Containers.Synchronized_Queue_Interfaces;
with Ada.Containers.Bounded_Synchronized_Queues;
with Ada.Strings.Unbounded;
procedure Task_Example is
package String_Queue_IF is new Ada.Containers.Synchronized_Queue_Interfaces
(Element_Type => Ada.Strings.Unbounded.Unbounded_String);
package String_Queues is new Ada.Containers.Bounded_Synchronized_Queues
(Queue_Interfaces => String_Queue_IF, Default_Capacity => 1);
A_To_B : String_Queues.Queue;
B_To_A : String_Queues.Queue;
task A;
task B;
task body A is
Message : Ada.Strings.Unbounded.Unbounded_String;
begin -- A
A_To_B.Enqueue (New_Item => Ada.Strings.Unbounded.To_String ("Hi") );
B_To_A.Dequeue (Element => Message);
end A;
task body B is
Message : Ada.Strings.Unbounded.Unbounded_String;
begin -- B
A_To_B.Dequeue (Element => Message);
B_To_A.Enqueue (New_Item => Ada.Strings.Unbounded.To_String ("Hi back") );
end B;
begin -- Task_Example
null;
end Task_Example;
--
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101
^ permalink raw reply [relevance 7%]
* Re: Safety of unprotected concurrent operations on constant objects
@ 2014-05-05 15:11 4% ` Brad Moore
0 siblings, 0 replies; 7+ results
From: Brad Moore @ 2014-05-05 15:11 UTC (permalink / raw)
On 05/05/2014 2:39 AM, Simon Wright wrote:
> Shark8 <OneWingedShark@gmail.com> writes:
>
>> On 05-May-14 15:23, Brad Moore wrote:
>>> In GNAT any read or write operations on a container that set tamper
>>> flags are ironically not task safe
>>
>> That seems very... odd.
>
> Rationale 05 8.1 [1] says (last para)
>
> "The general rule is given in paragraph 3 of Annex A which says "The
> implementation shall ensure that each language defined subprogram is
> reentrant in the sense that concurrent calls on the same subprogram
> perform as specified, so long as all parameters that could be passed
> by reference denote nonoverlapping objects." So in other words we
> have to protect ourselves by using the normal techniques such as
> protected objects when container operations are invoked concurrently
> on the same object from multiple tasks even if the operations are
> only reading from the container.
Except for containers that are already task safe
(Ada.Containers.Synchronized_Queue_Interfaces)
These paragraph's are actually being revised and are being passed from
the ARG to WG9 for approval at the June WG9 meeting. If approved, (and
most likely will be), then the changes apply to the Ada 2012 standard as
a binding inteterpretation. The changes are mostly clarification to the
existing intent. The existing wording suggested it only applies to calls
to the *same* language defined program, whereas the new wording applies
to calls to *any* language supplied program. Text_IO was also a special
case when involving standard output. The file parameter is assumed to
exist, and implicit, so the rule applies to those calls as well.
The new wording is;
The implementation shall ensure that each language-defined subprogram
is reentrant in the sense that concurrent calls on any language-defined
subprogram perform as specified, so long as all parameters that could be
passed by reference denote nonoverlapping objects.
For the purpose of determining whether concurrent calls on text
input-output subprograms are required to perform as specified above,
when calling a subprogram within Text_IO or its children that implicitly
operates on one of the default input/output files, the subprogram is
considered to have a parameter of Current_Input or Current_Output (as
appropriate).
In addition, the following new AARM notes will be added.
" AARM Ramification: So long as the parameters are disjoint, concurrent
calls on the same language-defined subprogram, and concurrent calls on
two different language-defined subprograms are required to work. But
concurrent calls operating on overlapping objects (be they of the same
or different language-defined subprograms) are NOT required to work
(being erroneous use of shared variables) unless both subprograms are
required to pass the associated parameter by-copy.
This rule applies to all language-defined subprograms, including those
defined in packages that manage some global state (like environment
variables or the current directory). Unless specified above, such
subprograms need to work when the explicit parameters are not
overlapping; in particular, the existence of the global state is not
considered. Packages with global state may require some locking in order
to avoid violating this rule."
>
> AARM12 A.18 (5.m) [2] says
>
> "If containers with similar functionality (but different performance
> characteristics) are provided (by the implementation or by a
> secondary standard), we suggest that a prefix be used to identify the
> class of the functionality: [...] "Ada.Containers.Protected_Maps"
> (for a map which can be accessed by multiple tasks at one time);
> [...]"
Another relevant RM paragraph is;
RM 9.10(11-15) which starts;
"Given an action of assigning to an object, and an action of reading or
updating a part of the same object (or of a neighboring object if the
two are not independently addressable), then the execution of the
actions is erroneous unless the actions are sequential."
>
> Personally I'd like to see the implication (that a standard-compliant
> implementation of Containers need not be task-safe unless the Standard
> specifies that it must be) made more visible.
>
> [1] http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-8-1.html
> [2] http://www.ada-auth.org/standards/12aarm/html/AA-A-18.html#p5.m
>
The synchronized keyword in the visible part of the specification of
Ada.Containers.Synchronous_Queue_Interfaces provides the cue to the
programmer that the container is task safe.
I'm thinking I'd actually like to see something like a Task_Safe aspect
that could be applied to type declarations, and subprograms, that would
make this more clear to users. Having it in the RM is good, but having
it in the package spec would be even better.
Eg. For Ada.Containers.Vectors...
type Vector is tagged private
with
Constant_Indexing => Constant_Reference,
Variable_Indexing => Reference,
Default_Iterator => Iterate,
Iterator_Element => Element_Type,
Task_Safe => False;
Then programmers could apply the aspect to their own abstractions, which
better defines the contract of the subprogram or type.
^ permalink raw reply [relevance 4%]
* strange error in tiny ada 2012 program
@ 2012-07-06 21:55 6% Charly
0 siblings, 0 replies; 7+ results
From: Charly @ 2012-07-06 21:55 UTC (permalink / raw)
Hi all
I installed the new GNAT GPL 2012 and started playing with the new Synchronized_Queue Containers.
Unfortunately I got serverall problems, which can be shown in the following tiny test program
1 with Ada.Containers.Synchronized_Queue_Interfaces;
2 with Ada.Containers.Bounded_Synchronized_Queues;
3 with Ada.Text_IO;
4
5 procedure Ctest is
6
7
8 package Integer_Queue_Interfaces is
9 new Ada.Containers.Synchronized_Queue_Interfaces (Integer);
10
11 package Integer_Queues is
12 new Ada.Containers.Bounded_Synchronized_Queues (Integer_Queue_Interfaces, 10);
13
14 subtype Integer_Queue_Type is Integer_Queues.Queue;
15
16 -- type New_Integer_Queue_Type is new Integer_Queue_Type with null record;
17
18 type Integer_Queue_Record is tagged limited record
19 Queue : Integer_Queue_Type;
20 end record;
21
22 --Integer_Queue1 : Integer_Queue_Type;
23 Integer_Queue2 : Integer_Queue_Record;
24
25 begin
26
27 Ada.Text_IO.Put_Line ("Hello Ada");
28
29 end Ctest;
First problem occured in line 16 where I want to extend the Integer_Queue_Type
but I got an error message:
ctest.adb:16:04: parent type of a record extension cannot be a synchronized tagged type (RM 3.9.1 (3/1))
So I removed the statement and defined a new tagged type with the Integer_Queue_Type as record element
in lines 18 - 20. This variant compiles without messages but now I get an exception STORAGE_ERROR.
addr2line locates the error in line 5 what isn't very usefull. By trial and error I found, that the
error comes from line 23, when I replace it with line 22 the program 'works'.
So my questions are:
Did I make any mistake in this tiny program or is it a bug in the new GNAT version?
How can a extend a proteced type (line 16).
Thanks
^ permalink raw reply [relevance 6%]
Results 1-7 of 7 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2012-07-06 21:55 6% strange error in tiny ada 2012 program Charly
2014-05-02 8:42 Safety of unprotected concurrent operations on constant objects Natasha Kerensikova
2014-05-03 13:43 ` sbelmont700
2014-05-03 20:54 ` Natasha Kerensikova
2014-05-03 21:40 ` Simon Wright
2014-05-04 0:28 ` Jeffrey Carter
2014-05-04 7:46 ` Natasha Kerensikova
2014-05-04 15:18 ` sbelmont700
2014-05-04 15:57 ` Natasha Kerensikova
2014-05-05 19:04 ` Brad Moore
2014-05-05 21:23 ` Brad Moore
2014-05-04 21:44 ` Shark8
2014-05-05 8:39 ` Simon Wright
2014-05-05 15:11 4% ` Brad Moore
2014-09-21 13:31 Simp,e example for 2 tasks Stribor40
2014-09-21 17:00 ` Brad Moore
2014-09-21 20:33 7% ` Jeffrey Carter
2015-02-27 19:26 6% "STORAGE_ERROR : s-intman.adb:139 explicit raise" from record containing a queue from Ada.Containers.Bounded_Synchronized_Queues in Gnat Ada 2014 jocpaine
2015-02-28 21:59 0% ` Stephen Leake
2018-02-24 19:42 open a file non-blocking ? patrick
2018-02-26 2:53 ` Robert Eachus
2018-02-26 16:41 5% ` Jeffrey R. Carter
2018-11-10 10:36 7% "Equality operator appears too late" JLotty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox