* Status of AdaCL: Ada Class Library @ 2010-02-21 22:09 Michael R 2010-02-22 1:51 ` Björn Persson 2010-02-24 19:54 ` Martin Krischik 0 siblings, 2 replies; 10+ messages in thread From: Michael R @ 2010-02-21 22:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-21 22:09 Status of AdaCL: Ada Class Library Michael R @ 2010-02-22 1:51 ` Björn Persson 2010-02-22 2:07 ` Michael R 2010-02-24 19:56 ` Martin Krischik 2010-02-24 19:54 ` Martin Krischik 1 sibling, 2 replies; 10+ messages in thread From: Björn Persson @ 2010-02-22 1:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-22 1:51 ` Björn Persson @ 2010-02-22 2:07 ` Michael R 2010-02-24 19:56 ` Martin Krischik 1 sibling, 0 replies; 10+ messages in thread From: Michael R @ 2010-02-22 2:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-22 1:51 ` Björn Persson 2010-02-22 2:07 ` Michael R @ 2010-02-24 19:56 ` Martin Krischik 2010-02-24 23:48 ` Randy Brukardt 1 sibling, 1 reply; 10+ messages in thread From: Martin Krischik @ 2010-02-24 19:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-24 19:56 ` Martin Krischik @ 2010-02-24 23:48 ` Randy Brukardt 2010-02-25 9:22 ` Georg Bauhaus 2010-02-25 12:23 ` Stephen Leake 0 siblings, 2 replies; 10+ messages in thread From: Randy Brukardt @ 2010-02-24 23:48 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-24 23:48 ` Randy Brukardt @ 2010-02-25 9:22 ` Georg Bauhaus 2010-02-25 12:23 ` Stephen Leake 1 sibling, 0 replies; 10+ messages in thread From: Georg Bauhaus @ 2010-02-25 9:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-24 23:48 ` Randy Brukardt 2010-02-25 9:22 ` Georg Bauhaus @ 2010-02-25 12:23 ` Stephen Leake 2010-02-25 14:16 ` Alex R. Mosteo 1 sibling, 1 reply; 10+ messages in thread From: Stephen Leake @ 2010-02-25 12:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-25 12:23 ` Stephen Leake @ 2010-02-25 14:16 ` Alex R. Mosteo 2010-02-25 20:19 ` sjw 0 siblings, 1 reply; 10+ messages in thread From: Alex R. Mosteo @ 2010-02-25 14:16 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-25 14:16 ` Alex R. Mosteo @ 2010-02-25 20:19 ` sjw 0 siblings, 0 replies; 10+ messages in thread From: sjw @ 2010-02-25 20:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status of AdaCL: Ada Class Library 2010-02-21 22:09 Status of AdaCL: Ada Class Library Michael R 2010-02-22 1:51 ` Björn Persson @ 2010-02-24 19:54 ` Martin Krischik 1 sibling, 0 replies; 10+ messages in thread From: Martin Krischik @ 2010-02-24 19:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-02-25 20:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-21 22:09 Status of AdaCL: Ada Class Library Michael R 2010-02-22 1:51 ` Björn Persson 2010-02-22 2:07 ` Michael R 2010-02-24 19:56 ` Martin Krischik 2010-02-24 23:48 ` Randy Brukardt 2010-02-25 9:22 ` Georg Bauhaus 2010-02-25 12:23 ` Stephen Leake 2010-02-25 14:16 ` Alex R. Mosteo 2010-02-25 20:19 ` sjw 2010-02-24 19:54 ` Martin Krischik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox