* Re: Does anyone use Anna?
@ 2000-11-26 6:30 rasser
0 siblings, 0 replies; 2+ messages in thread
From: rasser @ 2000-11-26 6:30 UTC (permalink / raw)
To: comp.lang.ada
JF Harrison,
I have used it on a personal basis, but I do not think that it has been
used much outside academia circles. The documentation (see link below) is
good but the source is Ada 83 based, so it needs some or a lot of rework
to be Ada 95 based.
If you intend to start something up on ANNA maybe David Botton could add
you to the Lab projects mailto:lab@AdaPower.com
regards /soren
Misc pointers - you should be able to find the referenced book online (as
postscript files) here...
SEI report =>
http://www.sei.cmu.edu/publications/documents/91.reports/91.tr.001.html
The Stanford tools => http://pavg.stanford.edu/
The ANNA tools => ftp://pavg.stanford.edu/pub/anna/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Containers with Ada
@ 2000-11-19 0:00 jeltsch
2000-11-20 0:00 ` Marc A. Criley
0 siblings, 1 reply; 2+ messages in thread
From: jeltsch @ 2000-11-19 0:00 UTC (permalink / raw)
Hello Ada programmers,
I want to write some generic packages for container types - at the moment for
several kinds of lists. At the beginning of this work I thought this wouldn't
be that difficult but now after being faced with a lots of problems I
sometimes wonder if I should go back to C++.
Below I will present some of the difficulties. I would be very pleased if
someone could help me creating problem-oriented packages for containers which
use the advantages of Ada. I hardly can imagine that there are no really good
container implementations in Ada at the moment so there must be a solution.
Now the problems in detail:
1. Copying of large data structures
In my opinion one main problem of Ada is implicit copying of variables. So
it's no good idea to define such a intuitive function like
function Element_At(Current_List : in List; Current_Index : in Index)
return Element;
In this example the list which could contain thousands of elements would
be copied just to get one element out of it. In addition if Element is also
a list the return statement inside Element_At would copy this list.
A first solution could be to define List as limited. But this would be bad
if Element is non-limited because in this case it would make sense to copy
lists and to check them for equality. Moreover Element would have to be
definded as limited to allow lists of lists.
One could also totally avoid "normal" list parameters and use only access
parameters for lists. But that would mean that every list would have to be
aliased and that no constant parameters could be used because acces
parameters cannot be constant.
I took the first solution - defining lists limited and having limited
element types. This has also advantages because lists with other limited
element types become possible. But there are still problems of accessing
list elements as explained in the next section.
2. Complicated use of element access with generic procedures
Accessing a limited element of a limited list which is not visible from
outside the package is as far as I can see only possible in two ways - via
an access value to the element returned by some package subprogram or by a
generic subprogram as explained below. The first way is in my eyes
inacceptable because the access type needed would have to be defined at the
level of the list package instance which would the package user allow to
have "dangling pointers".
The approach I have taken is to define some generic procedures which have a
a procedure as generic parameter. Here are those procedures:
generic
with procedure Edit_Single_Element(Current_Element : in out Element);
procedure Edit_Element(Current_List : in out List;
Current_Index : in Index);
generic
with procedure Read_Single_Element(Current_Element : in out Element);
procedure Read_Element(Current_List : in List;
Current_Index : in Index);
An instance of Edit_Element or Read_Element will call Edit_Single_Element
or Read_Single_Element respectively on the element of Current_List denoted
by Current_Index. That seems to work just fine but it is very complicated
to use. The following example for instance just copies the elements of
Source_List to Dest_List.
for Current_Index in Index range Start .. End loop
declare
procedure Using_Dest_Element(Dest_Element : in out Element) is
procedure Using_Source_Element(Source_Element : in Element) is
begin
Dest_Element := Source_Element;
end Using_Source_Element;
procedure Using_Source_List is
new Read_Element(Using_Source_Element);
begin
Using_Source_List(Source_List, Current_Element);
end Using_Dest_Element;
procedure Using_Dest_List is
new Edit_Element(Using_Dest_Element);
begin
Using_Dest_List(Dest_List, Current_Index)
end;
end loop;
In comparison the same problem with arrays:
for Current_Index in Index range Start .. End loop
Dest_Array(Current_Index) := Source_Array(Current_Index);
end loop;
or just
Dest_Array(Start .. End) := Source_Array(Start .. End);
3. High memory consumption with unconstrained arrays
An easy way to define a type for lists with fixed length would be for
instance
type Element_Array is array(Positive range <>) of Element;
type List(Length : Natural) is record
Elements : Element_Array(1 .. Length);
end record;
With this implementation one could even think of making the whole type
definition public. But one cannot expect that a compiler will generate code
that dynamically allocates memory that is just enough for Elements. As I
can see GNAT doesn't operate with implicit pointers to dynamically
allocated memory but sets the size of List so that it is big enough for
every value for Length. In the above example that means that every List
would (try to) consume about 2 GB of memory on my platform.
4. Limitations with controlled types
Because I cannot use unconstrained arrays like in the above example I use
pointers to arrays (access values). A good implementation should free all
memory consumed by the list when the list ceases to exist. List should
therefore be derived from Limited_Controlled an have a Finalize procedure
which deallocates the element array(s). But controlled types can be only
defined at the library level. So the following example is not possible
which is inacceptable for me:
procedure Act(Limit : in Natural) is
subtype My_Range is Natural range 1 .. Limit;
package My_Lists is new Lists(My_Range);
begin
...
end Act;
Bye, Wolfgang
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-19 0:00 Containers with Ada jeltsch
@ 2000-11-20 0:00 ` Marc A. Criley
2000-11-20 0:00 ` Brian Rogoff
0 siblings, 1 reply; 2+ messages in thread
From: Marc A. Criley @ 2000-11-20 0:00 UTC (permalink / raw)
jeltsch@my-deja.com wrote:
>
> Hello Ada programmers,
> I want to write some generic packages for container types - at the moment for
> several kinds of lists.
Why?
Numerous generic packages for container types already exist--the
original Booch components, the Ada 95 Booch components, the Ada
Structured Library (my personal favorite), PragmAda, and so on.
I would much rather see an individual extend Ada's reach into new fields
in which there's little or no Ada presence, rather than reworking the
same, tired old ground.
Curmudgeonly,
Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-20 0:00 ` Marc A. Criley
@ 2000-11-20 0:00 ` Brian Rogoff
2000-11-20 0:00 ` Stephen Leake
0 siblings, 1 reply; 2+ messages in thread
From: Brian Rogoff @ 2000-11-20 0:00 UTC (permalink / raw)
On Mon, 20 Nov 2000, Marc A. Criley wrote:
> jeltsch@my-deja.com wrote:
> >
> > Hello Ada programmers,
> > I want to write some generic packages for container types - at the moment for
> > several kinds of lists.
>
> Why?
Maybe he doesn't like what's already out there, and thinks he can do
better. Maybe he doesn't like the licenses of the existing libraries.
I could go on but your question shows a real lack of imagination.
> Numerous generic packages for container types already exist--the
> original Booch components, the Ada 95 Booch components, the Ada
> Structured Library (my personal favorite), PragmAda, and so on.
>
> I would much rather see an individual extend Ada's reach into new fields
> in which there's little or no Ada presence, rather than reworking the
> same, tired old ground.
Rather than telling other people what you'd rather they do, why don't
you just go do it yourself? If someone wants to create another container
library in Ada I say "more power to'em!". That ground doesn't look old and
tired to me.
Libertarianly,
-- Brian
> Curmudgeonly,
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-20 0:00 ` Brian Rogoff
@ 2000-11-20 0:00 ` Stephen Leake
2000-11-21 0:00 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 2+ messages in thread
From: Stephen Leake @ 2000-11-20 0:00 UTC (permalink / raw)
Brian Rogoff <bpr@shell5.ba.best.com> writes:
> <snip>
>
> Rather than telling other people what you'd rather they do, why
> don't you just go do it yourself? If someone wants to create another
> container library in Ada I say "more power to'em!". That ground
> doesn't look old and tired to me.
Someone looking to create an Ada library should make an attempt to
find out what's already been done. Then they can either just use it,
or improve on it, or start from scratch. In any case, we'll all learn
something (if they tell us :).
--
-- Stephe
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-20 0:00 ` Stephen Leake
@ 2000-11-21 0:00 ` Warren W. Gay VE3WWG
2000-11-21 0:00 ` Stephen Leake
0 siblings, 1 reply; 2+ messages in thread
From: Warren W. Gay VE3WWG @ 2000-11-21 0:00 UTC (permalink / raw)
Stephen Leake wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
>
> > <snip>
> >
> > Rather than telling other people what you'd rather they do, why
> > don't you just go do it yourself? If someone wants to create another
> > container library in Ada I say "more power to'em!". That ground
> > doesn't look old and tired to me.
>
> Someone looking to create an Ada library should make an attempt to
> find out what's already been done. Then they can either just use it,
> or improve on it, or start from scratch. In any case, we'll all learn
> something (if they tell us :).
There are other factors that must be considered before using an
EXISTING package:
1. - Who controls its design and interface?
2. - Is it likely to undergo changes in the future?
3. - How stable are the various existing releases of this package out there?
If I write an application for donation to the Open Source movement,
these are often deciding factors for me. For example, if I write an
application based upon the florist package, and the package specs
change, then people who try to compile my application are going to
whine to me that it doesn't compile. (Actually, the specs need not change--
for example there can be unresolved links in the library etc. leading to
other build problems).
Many users out there that barely can manage a make command, don't
recognize where the problem lies. Consequently, if I suspect that this
will be a problem, I'll create my own interfaces that are NOT subject
to change (or implementation problems).
Even if issues 1 and 2 are resolved, #3 can be a problem. For example
if there are many distributions out there with busted florist libraries installed,
then I have to either:
a) include comprehensive instructions to the user to identify and upgrade
the offending packages/libraries..
b) or insulate my application from these problems, to avoid whining
emails.
Often, I'll choose "b" because my time is too short to help all the users work
out issue "a".
CONCLUSION:
Consequently, only if a package and most of it's existing versions are stable
and working, will I consider it for an open source project. For internal projects,
this is not really an issue (I can just grumble when it needs adjustment, but then
I only need to fix it once -- not for every other user out there).
> --
> -- Stephe
POSTSCRIPT:
This is the reason I think it is VERY IMPORTANT that standards be developed
for re-usable components. Once the standard is announced, the developer has
some sort of assurance about the interfaces involved, today, and into the future.
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-21 0:00 ` Warren W. Gay VE3WWG
@ 2000-11-21 0:00 ` Stephen Leake
2000-11-21 0:00 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 2+ messages in thread
From: Stephen Leake @ 2000-11-21 0:00 UTC (permalink / raw)
"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> Stephen Leake wrote:
>
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> >
> > > <snip>
> > >
> > > Rather than telling other people what you'd rather they do, why
> > > don't you just go do it yourself? If someone wants to create another
> > > container library in Ada I say "more power to'em!". That ground
> > > doesn't look old and tired to me.
> >
> > Someone looking to create an Ada library should make an attempt to
> > find out what's already been done. Then they can either just use it,
> > or improve on it, or start from scratch. In any case, we'll all learn
> > something (if they tell us :).
>
> There are other factors that must be considered before using an
> EXISTING package:
>
> 1. - Who controls its design and interface?
> 2. - Is it likely to undergo changes in the future?
> 3. - How stable are the various existing releases of this package out there?
All good points.
> <snip discussion of various solutions>
Perhaps a better solution for open source packages is to distribute
exactly the version you test with (which you may have patched), with
the caveat that users who use other versions are on their own.
That's one of the beauties of open source; you can insulate yourself
from all the maintenance issues just by distributing the version of
the source you happened to use.
I would hope you would make an effort to contribute fixes and upgrade
to later versions, but there's really no need to require your users to
do that on their own!
--
-- Stephe
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-21 0:00 ` Stephen Leake
@ 2000-11-21 0:00 ` Warren W. Gay VE3WWG
2000-11-21 0:00 ` Stephen Leake
0 siblings, 1 reply; 2+ messages in thread
From: Warren W. Gay VE3WWG @ 2000-11-21 0:00 UTC (permalink / raw)
Stephen Leake wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > Stephen Leake wrote:
> >
> > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> ...snip...
> > > Someone looking to create an Ada library should make an attempt to
> > > find out what's already been done. Then they can either just use it,
> > > or improve on it, or start from scratch. In any case, we'll all learn
> > > something (if they tell us :).
> >
> > There are other factors that must be considered before using an
> > EXISTING package:
> >
> > 1. - Who controls its design and interface?
> > 2. - Is it likely to undergo changes in the future?
> > 3. - How stable are the various existing releases of this package out there?
>
> All good points.
>
> > <snip discussion of various solutions>
>
> Perhaps a better solution for open source packages is to distribute
> exactly the version you test with (which you may have patched), with
> the caveat that users who use other versions are on their own.
Certainly, that is one solution. For large packages like florist however,
distributing that with a small application goes against the grain, especially
for the user who downloads with 56k modems.
> That's one of the beauties of open source; you can insulate yourself
> from all the maintenance issues just by distributing the version of
> the source you happened to use.
Yes, with the above disadvantage noted. Sometimes, it is possible just
to extract the pieces you need. However, that is not always easy, or even
advisable.
> I would hope you would make an effort to contribute fixes and upgrade
> to later versions, but there's really no need to require your users to
> do that on their own!
>
> --
> -- Stephe
You don't specifically indicate what I should perform "fixes and upgrade
to later versions" for, but I'll assume that you mean my own contributed
applications. If so, then yes indeed. However, some balance is required
here however.
My goal for written applications, is to be the "May Tag repair man". I want to
be able to move onto _NEW_ projects, since time is a limited resource. If I
must keep revisiting an application that does not need enhancing, just to
make it compile and work again, I get rather annoyed (when the change is
seemingly unnecessary).
It's an imperfect world, so I accept the reality that changes are sometimes
required. But IMHO, it should be possible most of the time to build applications
without making a career out of it ;-)
--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada
2000-11-21 0:00 ` Warren W. Gay VE3WWG
@ 2000-11-21 0:00 ` Stephen Leake
2000-11-22 0:00 ` Containers with Ada (distribution of) Warren W. Gay VE3WWG
0 siblings, 1 reply; 2+ messages in thread
From: Stephen Leake @ 2000-11-21 0:00 UTC (permalink / raw)
"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> <snip>
> > Perhaps a better solution for open source packages is to distribute
> > exactly the version you test with (which you may have patched), with
> > the caveat that users who use other versions are on their own.
>
> Certainly, that is one solution. For large packages like florist however,
> distributing that with a small application goes against the grain, especially
> for the user who downloads with 56k modems.
Hmm. If they have the same version, they don't have to download your
copy. If they don't, they can either try it with a different version,
or download your copy. I don't see how they are worse of than if you
did not provide a copy. Ah, maybe you thought I meant the packages
should be bundled in your zip file; probably not.
> <snip>
> > I would hope you would make an effort to contribute fixes and upgrade
> > to later versions, but there's really no need to require your users to
> > do that on their own!
>
> You don't specifically indicate what I should perform "fixes and upgrade
> to later versions" for, but I'll assume that you mean my own contributed
> applications.
Sorry, I wasn't very clear. For example, if you distribute an app that
works with Florist 1.1, but breaks with Florist 1.2, you should either
upgrade your app to work with Florist 1.2, or fix Florist 1.2,
whichever seems more appropriate.
> My goal for written applications, is to be the "May Tag repair man". I want to
> be able to move onto _NEW_ projects, since time is a limited resource. If I
> must keep revisiting an application that does not need enhancing, just to
> make it compile and work again, I get rather annoyed (when the change is
> seemingly unnecessary).
>
> It's an imperfect world, so I accept the reality that changes are sometimes
> required. But IMHO, it should be possible most of the time to build applications
> without making a career out of it ;-)
Yes, I totally agree. I'm working on Windex (a binding to Win32), and
for now I feel free to change the user API, because I know it's pretty
far from right. But at some point, it has to freeze, and just live
with any imperfections.
--
-- Stephe
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Containers with Ada (distribution of)
2000-11-21 0:00 ` Stephen Leake
@ 2000-11-22 0:00 ` Warren W. Gay VE3WWG
[not found] ` <004d01c0567b$cd4e49c0$b0375140@Fudge>
0 siblings, 1 reply; 2+ messages in thread
From: Warren W. Gay VE3WWG @ 2000-11-22 0:00 UTC (permalink / raw)
I neglected to answer one other point, in my previous post..
Stephen Leake wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > <snip>
> > > Perhaps a better solution for open source packages is to distribute
> > > exactly the version you test with (which you may have patched), with
> > > the caveat that users who use other versions are on their own.
> >
> > Certainly, that is one solution. For large packages like florist however,
> > distributing that with a small application goes against the grain, especially
> > for the user who downloads with 56k modems.
>
> Hmm. If they have the same version, they don't have to download your
> copy. If they don't, they can either try it with a different version,
> or download your copy. I don't see how they are worse of than if you
> did not provide a copy. Ah, maybe you thought I meant the packages
> should be bundled in your zip file; probably not.
I had assumed you meant the latter, but no matter...
It is true that you can make copies of an original "package" available on
your own web site (separate from your application's tarball/rpm). However,
this doesn't help with the sunsite.unc.edu ftp site etc. They (like many other
ftp sites), only keep the most recent versions of submitted packages.
IMHO, this is just one more hassle to deal with. I can barely find the
time and inclination to keep my web site up to date as it is ;-)
> -- Stephen
--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-11-26 6:30 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-26 6:30 Does anyone use Anna? rasser
-- strict thread matches above, loose matches on Subject: below --
2000-11-19 0:00 Containers with Ada jeltsch
2000-11-20 0:00 ` Marc A. Criley
2000-11-20 0:00 ` Brian Rogoff
2000-11-20 0:00 ` Stephen Leake
2000-11-21 0:00 ` Warren W. Gay VE3WWG
2000-11-21 0:00 ` Stephen Leake
2000-11-21 0:00 ` Warren W. Gay VE3WWG
2000-11-21 0:00 ` Stephen Leake
2000-11-22 0:00 ` Containers with Ada (distribution of) Warren W. Gay VE3WWG
[not found] ` <004d01c0567b$cd4e49c0$b0375140@Fudge>
2000-11-25 0:00 ` Does anyone use Anna? Lao Xiao Hai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox