Status of AdaCL: Ada Class Library

Status of AdaCL: Ada Class Library

[Michael R]

Hi Folks,

I remembered a previous post on a command line handling library,
searched and found AdaCL.  The
Orto package seems to be something, on the surface, that might be
really useful but it depends on
the Charles library which appears to be a pre-Ada2005 container
library.  The date associated with
the latest release on the download page is 2007-12-09.  Is this
project "dead"?

Take care,
Michael.

Re: Status of AdaCL: Ada Class Library

[Björn Persson]

Michael R wrote:

> I remembered a previous post on a command line handling library,
> searched and found AdaCL.  The
> Orto package seems to be something, on the surface, that might be
> really useful but it depends on
> the Charles library which appears to be a pre-Ada2005 container
> library.  The date associated with
> the latest release on the download page is 2007-12-09.  Is this
> project "dead"?

Orto isn't dead, but it's dormant while I'm focusing on other projects. I 
can't speak for Charles or for the rest of AdaCL, but Orto and EAstrings are 
"alive" and if you find any bugs in them then I want to hear about it.

I had intended to switch from Charles to Ada.Containers, but I changed my 
mind when I learned that Ada.Containers can't even be read by multiple tasks 
at once. As far as I know the Charles containers can be accessed by multiple 
tasks as long as none of them modifies the container. The internal data 
structure in Orto ? which makes use of Charles ? isn't modified after the 
parsing is done, so if you parse the command line before you start any 
additional tasks, you can then freely look up parameters in multiple tasks.

I believe Charles still works, but I could probably use some other container 
library if there is a compelling reason to stop using Charles.

-- 
Bj�rn Persson
PGP key A88682FD

Re: Status of AdaCL: Ada Class Library

[Michael R]

On Feb 21, 5:51 pm, Björn Persson <bj...@xn--rombobjrn-67a.se> wrote:
> Michael R wrote:
> > I remembered a previous post on a command line handling library,
> > searched and found AdaCL.  The
> > Orto package seems to be something, on the surface, that might be
> > really useful but it depends on
> > the Charles library which appears to be a pre-Ada2005 container
> > library.  The date associated with
> > the latest release on the download page is 2007-12-09.  Is this
> > project "dead"?
>
> Orto isn't dead, but it's dormant while I'm focusing on other projects. I
> can't speak for Charles or for the rest of AdaCL, but Orto and EAstrings are
> "alive" and if you find any bugs in them then I want to hear about it.
>
> I had intended to switch from Charles to Ada.Containers, but I changed my
> mind when I learned that Ada.Containers can't even be read by multiple tasks
> at once. As far as I know the Charles containers can be accessed by multiple
> tasks as long as none of them modifies the container. The internal data
> structure in Orto ? which makes use of Charles ? isn't modified after the
> parsing is done, so if you parse the command line before you start any
> additional tasks, you can then freely look up parameters in multiple tasks.
>
> I believe Charles still works, but I could probably use some other container
> library if there is a compelling reason to stop using Charles.
>
> --
> Björn Persson
> PGP key A88682FD

Hi,

Good to know.  I'll try using it.

Take care,
Michael.

Re: Status of AdaCL: Ada Class Library

[Martin Krischik]

Am 21.02.2010, 23:09 Uhr, schrieb Michael R <michael@zanyblue.com>:

> The date associated with
> the latest release on the download page is 2007-12-09.  Is this
> project "dead"?

Not dead as such - just not extended for a while. But if you find a bug  
add it to the tracker and I have a look.

Regards

Martin
-- 
Martin Krischik

Re: Status of AdaCL: Ada Class Library

[Martin Krischik]

Am 22.02.2010, 02:51 Uhr, schrieb Björn Persson <bjorn@rombobjörn.se>:

> I had intended to switch from Charles to Ada.Containers, but I changed my
> mind when I learned that Ada.Containers can't even be read by multiple  
> tasks
> at once.

Makes me glad I choosen the booch components instead.

Martin
-- 
Martin Krischik

Re: Status of AdaCL: Ada Class Library

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Am 22.02.2010, 02:51 Uhr, schrieb Bj�rn Persson <bjorn@rombobj�rn.se>:

> I had intended to switch from Charles to Ada.Containers, but I changed my
> mind when I learned that Ada.Containers can't even be read by multiple
 > tasks at once.

For the record, we've studied this several times and have always concluded 
that hidden synchronization is dangerous. That is, synchronization should be 
explicit. Beyond that, it is impossible to come up with a reasonable 
definition of what should be locked -- it really depends on the use of the 
containers.

In the case of the containers, task safety of iterators and similar features 
is something that defies a reasonable definition. The problem gets worse if 
you include features used together (such as using First and Next to create a 
loop of some sort). We'd probably need to make the locks visible in order 
for them to be useful.

It's easy to wrap container operations in a protected object, and that is 
always allowed (such operations are not potentially blocking). That allows 
tailoring the locking for the actual usage, and even hiding the actual 
container to prevent abuse.

                                 Randy.

Re: Status of AdaCL: Ada Class Library

[Georg Bauhaus]

Randy Brukardt schrieb:
> Am 22.02.2010, 02:51 Uhr, schrieb Bj�rn Persson <bjorn@rombobj�rn.se>:
> 
>> I had intended to switch from Charles to Ada.Containers, but I changed my
>> mind when I learned that Ada.Containers can't even be read by multiple
>  > tasks at once.

> It's easy to wrap container operations in a protected object, and that is 
> always allowed (such operations are not potentially blocking). That allows 
> tailoring the locking for the actual usage, and even hiding the actual 
> container to prevent abuse.

Indeed, arent' there advantages in hiding data stores like
Ada.Containers behind some facade, whether the use is
sequential or not: everything else always smells of
exposed internal data structures, or lack of abstraction.
There need to be good reasons for using List, Set, etc.
as is, I think. Just like there should be good reasons
to expose arrays.

Re: Status of AdaCL: Ada Class Library

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Am 22.02.2010, 02:51 Uhr, schrieb Björn Persson <bjorn@rombobjörn.se>:
>
>> I had intended to switch from Charles to Ada.Containers, but I changed my
>> mind when I learned that Ada.Containers can't even be read by multiple
>  > tasks at once.
>
> For the record, we've studied this several times and have always concluded 
> that hidden synchronization is dangerous. That is, synchronization should be 
> explicit. Beyond that, it is impossible to come up with a reasonable 
> definition of what should be locked -- it really depends on the use of the 
> containers.

I agree with this, but I think the OP was implying that you needed
locking even for read-only access of Ada.Containers from multiple
tasks; is that true? I don't see why it should be; each task declares
its own cursors, which don't interfere with each other.

Of course, there's nothing enforcing the read-only, so this is not
very safe.

-- 
-- Stephe

Re: Status of AdaCL: Ada Class Library

[Alex R. Mosteo]

Stephen Leake wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Am 22.02.2010, 02:51 Uhr, schrieb Björn Persson <bjorn@rombobjörn.se>:
>>
>>> I had intended to switch from Charles to Ada.Containers, but I changed
>>> my mind when I learned that Ada.Containers can't even be read by
>>> multiple
>>  > tasks at once.
>>
>> For the record, we've studied this several times and have always
>> concluded that hidden synchronization is dangerous. That is,
>> synchronization should be explicit. Beyond that, it is impossible to come
>> up with a reasonable definition of what should be locked -- it really
>> depends on the use of the containers.
> 
> I agree with this, but I think the OP was implying that you needed
> locking even for read-only access of Ada.Containers from multiple
> tasks; is that true? I don't see why it should be; each task declares
> its own cursors, which don't interfere with each other.

I think that the downward closure subprograms update some flags inside the 
container. E.g., in gnat doubly linked lists, within the Query_Element:

procedure Query_Element
     (Position : Cursor;
      Process  : not null access procedure (Element : Element_Type));

Pretty read-only, it seems, but inside you find:

      declare
         C : List renames Position.Container.all'Unrestricted_Access.all;
         B : Natural renames C.Busy;
         L : Natural renames C.Lock;

      begin
         B := B + 1;
         L := L + 1;
(...)

So, basically, yes, even certain read-only uses are not thread-safe (Element 
would be, at least in gnat implementation).

Never though of this before, but even wrapping a call to that in a protected 
function would be dangerous, since protected functions are concurrent? And 
that's a procedure with only "in" arguments, which would be callable from 
such a function.

Am I right here?

Re: Status of AdaCL: Ada Class Library

[sjw]

On Feb 25, 2:16 pm, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:

> Never though of this before, but even wrapping a call to that in a protected
> function would be dangerous, since protected functions are concurrent? And
> that's a procedure with only "in" arguments, which would be callable from
> such a function.
>
> Am I right here?

I believe you are: LRM 9.5.1(1), "protected functions provide
concurrent read-only access to the data".

My normal mode of operation is to wrap the use of the Container (OK,
Booch Component!) in a package and use a lock to ensure single-
threaded access, with the Container outside any PO.