* Containers with Ada @ 2000-11-19 0:00 jeltsch 2000-11-19 0:00 ` Robert Dewar ` (5 more replies) 0 siblings, 6 replies; 25+ 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] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch @ 2000-11-19 0:00 ` Robert Dewar 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-19 0:00 ` Ken Garlington ` (4 subsequent siblings) 5 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 2000-11-19 0:00 UTC (permalink / raw) In article <8v8pii$dvo$1@nnrp1.deja.com>, jeltsch@my-deja.com wrote: atform. > > 4. Limitations with controlled types > 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; Simply define the types and instantiations you need at the library level, and parametrize them appropriately. Again, if you post complete examples, it may be easier to help. You are making the mistake of having a preconceived idea of how to do things, and unfortunately the idea is wrong. Try describing what you want to do at a high level, rather than providing solutions that are wrong and complaining about the solutions not working. The trouble with the latter approach is that then we have to guess at the problem you are trying to solve, and this guessing often goes astray. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 ` Robert Dewar @ 2000-11-20 0:00 ` Wolfgang Jeltsch 0 siblings, 0 replies; 25+ messages in thread From: Wolfgang Jeltsch @ 2000-11-20 0:00 UTC (permalink / raw) > Simply define the types and instantiations you need at the > library level, and parametrize them appropriately. What do you mean with "parametrize them appropriately"? > You are making the mistake of having a preconceived idea > of how to do things, and unfortunately the idea is wrong. > Try describing what you want to do at a high level, rather > than providing solutions that are wrong and complaining > about the solutions not working. I simply want to have some list packages I can use nearly everywhere where I need a list. I don't want to have packages for a concrete idea but packages that are universal. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch 2000-11-19 0:00 ` Robert Dewar @ 2000-11-19 0:00 ` Ken Garlington 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-19 0:00 ` Robert Dewar ` (3 subsequent siblings) 5 siblings, 2 replies; 25+ messages in thread From: Ken Garlington @ 2000-11-19 0:00 UTC (permalink / raw) <jeltsch@my-deja.com> wrote in message news:8v8pii$dvo$1@nnrp1.deja.com... : 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. If List contains "thousands of elements", I suspect it's probably not an elementary type [Ada Reference Manual 3.2:3]. (It may _reference_ them, but then only the reference is being passed, not the elements). Therefore, it doesn't have to be passed by copy [ARM 6.2:3], and most compilers won't. Similar rules apply to the returned value. It may be a good idea to declare List a limited type, but not for reasons of controlling the passing convention. : 2. Complicated use of element access with generic procedures Making a type limited does impose some "complications" (an investment that yields impressive returns when used in the right way at the right time), but since you don't have to declare the type limited for performance reasons, I assume this is no longer an issue. : 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. There's nothing in the standard that requires this for the _exact_ example you post, AFAIK. If you really think you're seeing this, you may want to contact GNAT. Note that replacing "Length : Natural" with "Length : Natural := 0" will cause the behavior you describe, as well as a potential GNAT message - "warning: creation of object of this type may raise Storage_Error.". That _is_ consistent with the standard. Here's a sample program I just tried with GNAT 3.12p for Windows, default switches (e.g. no optimizations). It ran immediately on my machine, which shouldn't be the case for the behavior you describe: -- Test_Data_Structure.ads package Test_Data_Structure is subtype Element is Character; type Element_Array is array(Positive range <>) of Element; type List(Length : Natural) is record Elements : Element_Array(1 .. Length) := (others => '?'); end record; end Test_Data_Structure; -- Make_Data_Structure.adb with Ada.Text_IO, Test_Data_Structure; procedure Make_Data_Structure is package Test renames Test_Data_Structure; List_1 : Test.List(1); List_2 : Test.List(2); List_3 : Test.List(3); List_4 : Test.List(4); begin Ada.Text_IO.Put(List_1.Elements(1)); Ada.Text_IO.Put(List_2.Elements(2)); Ada.Text_IO.Put(List_3.Elements(3)); Ada.Text_IO.Put(List_4.Elements(4)); Ada.Text_IO.New_Line; end Make_Data_Structure; : 4. Limitations with controlled types : Because I cannot use unconstrained arrays like in the above example Hopefully, now you can! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 ` Ken Garlington @ 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Wolfgang Jeltsch 1 sibling, 0 replies; 25+ messages in thread From: Wolfgang Jeltsch @ 2000-11-20 0:00 UTC (permalink / raw) > If List contains "thousands of elements", I suspect it's probably not > an elementary type [Ada Reference Manual 3.2:3]. (It may _reference_ > them, but then only the reference is being passed, not the elements). > Therefore, it doesn't have to be passed by copy [ARM 6.2:3], and most > compilers won't. I thought that every type which is not a by-reference type is a by copy type. Thank you for the correction. > Similar rules apply to the returned value. As far as I can see from [ARM 6.5] a type must be limited to be a return-by-reference type. > It may be a good idea to declare List a limited type, but not for > reasons of controlling the passing convention. For what reasons it would be good? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 ` Ken Garlington 2000-11-20 0:00 ` Wolfgang Jeltsch @ 2000-11-20 0:00 ` Wolfgang Jeltsch 1 sibling, 0 replies; 25+ messages in thread From: Wolfgang Jeltsch @ 2000-11-20 0:00 UTC (permalink / raw) > There's nothing in the standard that requires this for the _exact_ > example you post, AFAIK. If you really think you're seeing this, you > may want to contact GNAT. Note that replacing "Length : Natural" with > "Length : Natural := 0" will cause the behavior you describe, as well > as a potential GNAT message - "warning: creation of object of this > type may raise Storage_Error.". That _is_ consistent with the > standard. Sorry, I didn't remember that the problems with memory consumption I had arose when I used a default value for Length. In my original List implementation this was needed for growable lists: type Element_Array is array(Positive range <>); type Buffer(Size : Natural := Init_Size) is record Elements : Element_Array(1 .. Size); end record; type Growable_List is record Element_Buffer : Buffer; Real_Size : Natural :=0; end record; This example is not possible with GNAT why I have to use references to the buffer why Growable_List must be a controlled type. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch 2000-11-19 0:00 ` Robert Dewar 2000-11-19 0:00 ` Ken Garlington @ 2000-11-19 0:00 ` Robert Dewar 2000-11-19 0:00 ` Robert Dewar ` (2 subsequent siblings) 5 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 2000-11-19 0:00 UTC (permalink / raw) In article <8v8pii$dvo$1@nnrp1.deja.com>, jeltsch@my-deja.com wrote: > 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. Nope, that's completely wrong. When there are no default discriminants, the language requires that only the necessary storage for the particular value be allocated, and that's how GNAT is working. Most likely you are confused about the role of default discriminants (although the example you gave does not contain any). The use of default discriminants has profound affects on the way storage is allocated. I would suggest posting complete small examples and asking direct questions about these examples. When you post large brush statements based on incorrect assumptions, it is hard to know where to start to help! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch ` (2 preceding siblings ...) 2000-11-19 0:00 ` Robert Dewar @ 2000-11-19 0:00 ` Robert Dewar 2000-11-19 0:00 ` Robert Dewar 2000-11-20 0:00 ` Marc A. Criley 5 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 2000-11-19 0:00 UTC (permalink / raw) In article <8v8pii$dvo$1@nnrp1.deja.com>, jeltsch@my-deja.com wrote: > 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. This is such a fundamental misconception, that you need to go back and start at square one. No compiler I can imagine would decide that it was more efficient to copy this list if it had thousands of elements. You seem to have somehow picked up the idea that IN parameters are always copied. This of course is NOT the case in Ada. Indeed the expectation is precisely that large objects passed as IN parameters will be passed by reference. The compiler makes the choice based on what is most efficient. YOU are NOT in the business of worrying about efficiency at this level, and as you show, if you do start worrying, you are very likely to get yourself seriously confused :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch ` (3 preceding siblings ...) 2000-11-19 0:00 ` Robert Dewar @ 2000-11-19 0:00 ` Robert Dewar 2000-11-20 4:37 ` Brian Rogoff 2000-11-20 0:00 ` Marc A. Criley 5 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 2000-11-19 0:00 UTC (permalink / raw) It is by the way a definite limitation in Ada 95 that some facilities of the language do not extend fully to nested subprograms (though not quite as much a limitation as not having nested subprograms at all, as in C or C++ :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 ` Robert Dewar @ 2000-11-20 4:37 ` Brian Rogoff 2000-11-20 0:00 ` Ted Dennison 0 siblings, 1 reply; 25+ messages in thread From: Brian Rogoff @ 2000-11-20 4:37 UTC (permalink / raw) On Sun, 19 Nov 2000, Robert Dewar wrote: > It is by the way a definite limitation in Ada 95 that some > facilities of the language do not extend fully to nested > subprograms (though not quite as much a limitation as not > having nested subprograms at all, as in C or C++ :-) I guess for my tastes these restrictions one inherits from the use of controlled types with respect to nested subprograms makes their use for container libraries problematic. I use nested subprograms a lot, even in a low level language like Ada. ("Low level" is not used in a pejorative sense here :). Obviously the restrictions with respect to access to subprogram are bothersome too but if that irritates me I just use another language. -- Brian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 4:37 ` Brian Rogoff @ 2000-11-20 0:00 ` Ted Dennison 2000-11-20 0:00 ` Brian Rogoff 0 siblings, 1 reply; 25+ messages in thread From: Ted Dennison @ 2000-11-20 0:00 UTC (permalink / raw) In article <Pine.BSF.4.21.0011192024450.493-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > I guess for my tastes these restrictions one inherits from the use of > controlled types with respect to nested subprograms makes their use > for container libraries problematic. I use nested subprograms a lot, Its not just controlled types, but derived tagged types in general. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Ted Dennison @ 2000-11-20 0:00 ` Brian Rogoff 0 siblings, 0 replies; 25+ messages in thread From: Brian Rogoff @ 2000-11-20 0:00 UTC (permalink / raw) On Mon, 20 Nov 2000, Ted Dennison wrote: > In article <Pine.BSF.4.21.0011192024450.493-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > > I guess for my tastes these restrictions one inherits from the use of > > controlled types with respect to nested subprograms makes their use > > for container libraries problematic. I use nested subprograms a lot, > > Its not just controlled types, but derived tagged types in general. Yes, I know that. However, one might want to use controlled types even while they don't want to use tagged types. Ada unifies (confuses :) the two notions so you don't have a choice. -- Brian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-19 0:00 Containers with Ada jeltsch ` (4 preceding siblings ...) 2000-11-19 0:00 ` Robert Dewar @ 2000-11-20 0:00 ` Marc A. Criley 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Brian Rogoff 5 siblings, 2 replies; 25+ 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] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Marc A. Criley @ 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Brian Rogoff 1 sibling, 0 replies; 25+ messages in thread From: Wolfgang Jeltsch @ 2000-11-20 0:00 UTC (permalink / raw) > 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. Are any of them open source? If this is the case from where can I download them? It would be interesting for me to see how they have solved the "container problems". > 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. What fields do you think of? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Marc A. Criley 2000-11-20 0:00 ` Wolfgang Jeltsch @ 2000-11-20 0:00 ` Brian Rogoff 2000-11-20 0:00 ` Stephen Leake 1 sibling, 1 reply; 25+ 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] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Brian Rogoff @ 2000-11-20 0:00 ` Stephen Leake 2000-11-20 0:00 ` Brian Rogoff ` (2 more replies) 0 siblings, 3 replies; 25+ 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] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Stephen Leake @ 2000-11-20 0:00 ` Brian Rogoff 2000-11-21 0:00 ` Marc A. Criley 2000-11-21 0:00 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 25+ messages in thread From: Brian Rogoff @ 2000-11-20 0:00 UTC (permalink / raw) On 20 Nov 2000, 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. Obviously. Look at the first two sentences you snipped: >> 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. Now, jeltsch has posted a few more times and it's clear he hasn't looked at www.adapower.com (thank you David Botton, you are awesome!) to see what else is available but I couldn't tell from the first post. > Then they can either just use it, or improve on it, If the license permits... > or start from scratch. In any case, we'll all learn > something (if they tell us :). Yes, unfortunately it is hard to get useful feedback. So, how is SAL going? ;-) -- Brian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Stephen Leake 2000-11-20 0:00 ` Brian Rogoff @ 2000-11-21 0:00 ` Marc A. Criley 2000-11-21 0:00 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 25+ messages in thread From: Marc A. Criley @ 2000-11-21 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? Uhhh..I do. I'm also happy to assist anyone who may need some Ada advice pertaining to whatever it is they may be working on, whether in this forum, gnatlist, or gnat chat (if that somehow gets reformulated back into a public forum). > 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. I guess the problem is that having worked with Ada for over 15 years, I can write container packages in my sleep, but I don't bother since there's a score of variations to pick from. If someone's undertaking such an effort to aid their learning of Ada, then yes, "more power to them!" But otherwise, do something new! I've been working a lot with ASIS (Ada Semantic Information Specification) lately, and if one wants to stay within pure Ada, and is interested in developing development and analysis tools, aids for doing ASIS development would be incredibly welcome. Marc A. Criley Senior Staff Engineer Quadrus Corporation ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-20 0:00 ` Stephen Leake 2000-11-20 0:00 ` Brian Rogoff 2000-11-21 0:00 ` Marc A. Criley @ 2000-11-21 0:00 ` Warren W. Gay VE3WWG 2000-11-21 0:00 ` Stephen Leake 2 siblings, 1 reply; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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 2000-11-22 0:00 ` Containers with Ada Warren W. Gay VE3WWG 0 siblings, 2 replies; 25+ 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] 25+ 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> 2000-11-22 0:00 ` Containers with Ada Warren W. Gay VE3WWG 1 sibling, 1 reply; 25+ 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] 25+ messages in thread
[parent not found: <004d01c0567b$cd4e49c0$b0375140@Fudge>]
* Re: Does anyone use Anna? [not found] ` <004d01c0567b$cd4e49c0$b0375140@Fudge> @ 2000-11-25 0:00 ` Lao Xiao Hai 0 siblings, 0 replies; 25+ messages in thread From: Lao Xiao Hai @ 2000-11-25 0:00 UTC (permalink / raw) JF Harrison wrote: > Hi, > While searching through Amazon.com I found the following text: "Anna : A > Language for Annotating Ada Programs : A Reference Manual (Lecture Notes in > Computer Science, Vol 260)" by David Luckham. Is this used much in the > industry? If not, does it look like it will be? > > Regards, > JF Harrison The Center for Reliable Computing at Stanford University had some researchers, Doug Bryan and Geoff Mendal, working on ANNA. Both have left the Ada community and there seems to be no effort currently in place. I don't think ANNA has ever been updated to correspond to Ada 95. This would make a really good research project for someone if there were any possibility of getting it funded. Richard Riehle > > From the book description at > http://www.amazon.com/exec/obidos/ASIN/0387179801/qid=975111777/sr=1-4/104-1 > 905124-4917565 > > "ANNA is a language extension of ADA to include facilities for formally > specifying the intended behavior of ADA programs. It is designed to meet a > perceived need to augment ADA with precise machine-processable annotations > so that well established formal methods of specification and documentation > can be applied to ADA programs. The current ANNA design includes annotations > of all ADA constructs except tasking. Similar extensions for formal > specification can be made to other Algol-like languages such as Pascal, > PL/1, Concurrent Pascal, and Modula; essentially, these extensions would be > subsets of ANNA. The design of ANNA was undertaken from the beginning with > four principal considerations: 1. Constructing annotations should be easy > for the ADA programmer and should depend as much as possible on notation and > concepts of ADA. 2. ANNA should possess language features that are widely > used in the specification and documentation of programs. 3. ANNA should > provide a framework within which the various established theories of > formally specifying programs may be applied to ADA. 4. Annotations should be > equally well suited for different possible applications during the life > cycle of a program. Such applications include not only testing, debugging > and formal verification of a finished program, but also specification of > program parts during the earlier stages of requirements analysis and program > design." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Containers with Ada 2000-11-21 0:00 ` Stephen Leake 2000-11-22 0:00 ` Containers with Ada (distribution of) Warren W. Gay VE3WWG @ 2000-11-22 0:00 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 25+ messages in thread From: Warren W. Gay VE3WWG @ 2000-11-22 0:00 UTC (permalink / raw) Stephen Leake wrote: > "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes: > > <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. The former is usually the simplest (which is what my normal response is). This leads to a quick solution to the user's email request. The later case usually requires that you contact the author of the offending package, and hope that he'll accept your patches. Then, you must *wait* for it to be released. This process does not help the poor user who has contacted you with a message saying "your software won't compile". The emailing user often has no appreciation for the fact that it _did_ compile with the original components used. Another alternative is to make patches to Florist 1.2 available to address the issue, but this requires the poor user to apply, compile and install them successfully. Many users are not up to this task. Not only that, it requires you to revisit this issue again when Florist 1.3 comes out (assuming that your feedback to the Florist maintainers has not been accepted, or taken to heart, or simply still "in the queue"). [NOTE: I am not picking on Florist here-- only using it as an example] Even when cvs access to the package is available, and even if your changes are adopted (they might be overruled), you then still must get the end user to download those "improved sources" and recompile and install them himself. This is fraut with more frustrated end users, and thus, more emails in my inbox ;-) Anyway, I am just re-stating my original statement here -- standards are necessary to prevent most of this tussle. If there is too much perceived "hassle factor" to use an existing package, I won't use it. If it is small, or if the components extractable from a larger package, then I'll include them in with my sources, so that I can _insulate_ myself from those changes. It would be nice to see more _STANDARDIZED_ packages available. As I posted earlier, standards give the application writer confidence about the future of the API and it's behaviour. > > 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 Certainly, anything that is truly "in development" has to have the caveat that the API is subject to change. This is OK, since it allows others to take advantage of the same work, while it is progressing. Others can contribute (hopefully constructive) criticism, and patches. All I am saying is that using existing packages in a state of "flux" is often more aggrivation than it is worth, considering the long run. Some people like to continue to enhance and build upon various open source projects, and this is necessary for large projects. I myself, have many interests, including building solutions to new problems. As you agreed, we don't like to revisit the same old stuff unnecessarily. -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2000-11-25 0:00 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-19 0:00 Containers with Ada jeltsch 2000-11-19 0:00 ` Robert Dewar 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-19 0:00 ` Ken Garlington 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-19 0:00 ` Robert Dewar 2000-11-19 0:00 ` Robert Dewar 2000-11-19 0:00 ` Robert Dewar 2000-11-20 4:37 ` Brian Rogoff 2000-11-20 0:00 ` Ted Dennison 2000-11-20 0:00 ` Brian Rogoff 2000-11-20 0:00 ` Marc A. Criley 2000-11-20 0:00 ` Wolfgang Jeltsch 2000-11-20 0:00 ` Brian Rogoff 2000-11-20 0:00 ` Stephen Leake 2000-11-20 0:00 ` Brian Rogoff 2000-11-21 0:00 ` Marc A. Criley 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 2000-11-22 0:00 ` Containers with Ada Warren W. Gay VE3WWG
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox