* Ammo-zilla @ 1999-10-23 0:00 Stanley R. Allen 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 0 siblings, 2 replies; 92+ messages in thread From: Stanley R. Allen @ 1999-10-23 0:00 UTC (permalink / raw) If anyone out there is struggling with their organization to retain (or introduce) Ada as an alternative to C++, consider this: http://www.mozilla.org/hacking/portable-cpp.html Imagine what Ada's detractors would be saying if writing portable Ada code was as restrictive as writing C++ code is these days! Other aspects of the Mozilla project may provide interesting insights concerning the impact of language choice on project success; for example, it would be interesting if some study could determine the percentage of Mozilla bugs related to the those characteristics of C/C++ infamous for bug-o-genesis. -- Stanley Allen mailto:s_allen@hso.link.com ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-23 0:00 Ammo-zilla Stanley R. Allen @ 1999-10-24 0:00 ` Aidan Skinner 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1 sibling, 1 reply; 92+ messages in thread From: Aidan Skinner @ 1999-10-24 0:00 UTC (permalink / raw) On Sat, 23 Oct 1999 14:42:39 -0500, Stanley R. Allen <s_allen@hso.link.com> wrote: >could determine the percentage of Mozilla bugs related to the >those characteristics of C/C++ infamous for bug-o-genesis. Having had a quick glance over teh Mozilla bug list, ISTM that there's a lot of memory leaks in it, which Ada is a lot better for. - Aidan (except for code I right when really tired, which for some reason has a tendancy to leak like a sponge) -- "I say we just bury him and eat dessert" http://www.skinner.demon.co.uk/aidan/ ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner @ 1999-10-24 0:00 ` Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner ` (2 more replies) 0 siblings, 3 replies; 92+ messages in thread From: Robert Dewar @ 1999-10-24 0:00 UTC (permalink / raw) In article <slrn8156pm.pl.aidan@skinner.demon.co.uk>, aidan@skinner.demon.co.uk wrote: > that there's > a lot of memory leaks in it, which Ada is a lot better for. Now that's an interesting comment, because to me C++ and Ada are identical in this particular department, can you explain why you think Ada is better wrt memory leaks? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Robert Dewar @ 1999-10-24 0:00 ` Aidan Skinner 1999-10-25 0:00 ` Ammo-zilla Jean-Pierre Rosen 1999-10-24 0:00 ` Ammo-zilla David Botton 1999-10-24 0:00 ` Ammo-zilla Matthew Heaney 2 siblings, 1 reply; 92+ messages in thread From: Aidan Skinner @ 1999-10-24 0:00 UTC (permalink / raw) On Sun, 24 Oct 1999 12:19:26 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: >Now that's an interesting comment, because to me C++ and Ada >are identical in this particular department, can you explain >why you think Ada is better wrt memory leaks? <disclaimer: I don't know C++ terribly well, far worse than I know Ada or Pascal or C> I think it's probably a personal issue, and one of style more than anything else. In C++ I tend to use {pointers|access} types somewhat heavily, in Ada it's very rare that I do so. I'm also a huge fan of Controlled types in Ada, I really like the way that they work and use them extensively, I find the use of Finalize etc to be more intuitive than overloading -> (this is *definately* a style thing, I know). I also find it far easier to be disciplined in my code general with Ada than with C++, although that is almost certainly a style thing (I have similar problems with Java but not as badly, I think it's the syntax[1]). YMMV etc. - Aidan [1] I grew up with Pascal[2], I don't like the way that C like languages look... [2] And Sinclair Spectrum BASIC -- "I say we just bury him and eat dessert" http://www.skinner.demon.co.uk/aidan/ ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner @ 1999-10-25 0:00 ` Jean-Pierre Rosen 0 siblings, 0 replies; 92+ messages in thread From: Jean-Pierre Rosen @ 1999-10-25 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 644 bytes --] Food for thoughts: Aidan Skinner <aidan@skinner.demon.co.uk> a �crit dans le message : slrn816t73.114.aidan@skinner.demon.co.uk... > I also find it far easier to be disciplined in my code general with > Ada than with C++, although that is almost certainly a style thing (I > have similar problems with Java but not as badly, I think it's the > syntax[1]). > Or maybe, people who are naturally disciplined in their thinking habits feel more at ease with Ada than C++ .... -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner @ 1999-10-24 0:00 ` David Botton 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-24 0:00 ` Ammo-zilla Matthew Heaney 2 siblings, 1 reply; 92+ messages in thread From: David Botton @ 1999-10-24 0:00 UTC (permalink / raw) > Now that's an interesting comment, because to me C++ and Ada > are identical in this particular department, can you explain > why you think Ada is better wrt memory leaks? As a result of the excellent design of Ada, I use far more static allocation then dynamic resulting in less chance of memory leaks. Of course once you start playing with the heap its all about personal programmer discipline. David Botton ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla David Botton @ 1999-10-28 0:00 ` Charles Hixson 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby ` (3 more replies) 0 siblings, 4 replies; 92+ messages in thread From: Charles Hixson @ 1999-10-28 0:00 UTC (permalink / raw) I am continually attracted to Ada, however: The Ada approach to memory management reminds me of the PL/1 approach, only simplified a bit. I suppose that you can say that it's better than C++, but that's *REALLY* faint praise. There are a lot of details that I don't fully understand, but this is one of Ada's weaker aspects. The second is the syntax used in "object" declaration. Very clumsy. Now I *do* understand that the reason for this approach is (partially the date of design but also) to allow statically linked programs to be small enough for embedded systems, etc. And it is indeed necessary to enable this. But the cost of a unified design of this nature is that, e.g., garbage collection is eliminated from the language. (The syntax is mainly due to early design.) I feel relativly certain that if the language were to be designed today that many things would have been done differently. David Botton wrote: > > Now that's an interesting comment, because to me C++ and Ada > > are identical in this particular department, can you explain > > why you think Ada is better wrt memory leaks? > > As a result of the excellent design of Ada, I use far more static > allocation then dynamic resulting in less chance of memory leaks. Of > course once you start playing with the heap its all about personal > programmer discipline. > > David Botton ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Charles Hixson @ 1999-10-28 0:00 ` Laurent Guerby 1999-10-28 0:00 ` Ammo-zilla David Starner ` (2 more replies) 1999-10-28 0:00 ` Ammo-zilla Tucker Taft ` (2 subsequent siblings) 3 siblings, 3 replies; 92+ messages in thread From: Laurent Guerby @ 1999-10-28 0:00 UTC (permalink / raw) Charles Hixson <charleshixsn@mail.earthlink.net> writes: > [...] But the cost of a unified design of this nature is that, > e.g., garbage collection is eliminated from the language. [...] Quite the contrary, garbage collection is allowed (but not mandated) by the language (see section 13.11.3 of the Ada 95 RM), and it's of course available for Ada compilers targetting the JVM. --LG ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby @ 1999-10-28 0:00 ` David Starner 1999-10-29 0:00 ` Ammo-zilla Larry Kilgallen ` (2 more replies) 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-29 0:00 ` Ammo-zilla Robert I. Eachus 2 siblings, 3 replies; 92+ messages in thread From: David Starner @ 1999-10-28 0:00 UTC (permalink / raw) On 28 Oct 1999 22:42:52 +0200, Laurent Guerby <guerby@acm.org> wrote: >Charles Hixson <charleshixsn@mail.earthlink.net> writes: >> [...] But the cost of a unified design of this nature is that, >> e.g., garbage collection is eliminated from the language. [...] > >Quite the contrary, garbage collection is allowed (but not mandated) >by the language (see section 13.11.3 of the Ada 95 RM), and it's of >course available for Ada compilers targetting the JVM. Under the "as if" rule, C allows garbage collection, and I've got a C compiler that compiles targetting the JVM. If garbage collection is not mandated, however, then it can't be relied on in Ada code that might run under systems that don't garbage collect - i.e. portable Ada code can't use it. Hence either you deallocate any memory yourself, or suffer garbage leaks while running under a non-garbage collecting system. -- David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla David Starner @ 1999-10-29 0:00 ` Larry Kilgallen 1999-10-29 0:00 ` Ammo-zilla David Starner 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 2 siblings, 1 reply; 92+ messages in thread From: Larry Kilgallen @ 1999-10-29 0:00 UTC (permalink / raw) In article <7vadsp$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) writes: > If garbage collection is not mandated, however, then it can't be relied on > in Ada code that might run under systems that don't garbage collect - i.e. > portable Ada code can't use it. Hence either you deallocate any memory > yourself, or suffer garbage leaks while running under a non-garbage > collecting system. Vendors are free to implement garbage collection and will do so to the extent that the market demands. They have done so, including the vendor of "free" compilers. Larry Kilgallen ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla Larry Kilgallen @ 1999-10-29 0:00 ` David Starner 1999-10-29 0:00 ` Ammo-zilla Tucker Taft ` (4 more replies) 0 siblings, 5 replies; 92+ messages in thread From: David Starner @ 1999-10-29 0:00 UTC (permalink / raw) On Fri, 29 Oct 1999 02:19:10 GMT, Larry Kilgallen <kilgallen@eisner.decus.org> wrote: >In article <7vadsp$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. >(David Starner) writes: > >> If garbage collection is not mandated, however, then it can't be relied on >> in Ada code that might run under systems that don't garbage collect - i.e. >> portable Ada code can't use it. Hence either you deallocate any memory >> yourself, or suffer garbage leaks while running under a non-garbage >> collecting system. > >Vendors are free to implement garbage collection and will do so >to the extent that the market demands. > >They have done so, including the vendor of "free" compilers. I said nothing about vendors. As long as there are otherwise-reasonable Ada compilers that don't garbage collect, good Ada programs must assume they're running on that system. I once pointed out that integer'base could be an infinite precision integer type. (Robert Dewar said yes, but it wasn't something that was going to get added to GNAT.) Let's say that it was added to GNAT. Good portable Ada code still couldn't depend on having 70 digit+ integer types. GC is the same - as long as most systems don't support it, (and I'm not familiar with any major ones that don't run on the JVM that do), you can't depend on it. And as long as you can't depend on it, GC's main advantage - saving the programer trouble worring about memory - is useless. As a side question: Ada 95's designers must have been familiar with Modula 3's support of garbage collection while letting real time stuff keep track of its own memory. What stopped them from adopting something like that for Ada 95? -- David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Starner @ 1999-10-29 0:00 ` Tucker Taft 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke 1999-10-29 0:00 ` Ammo-zilla David Botton ` (3 subsequent siblings) 4 siblings, 1 reply; 92+ messages in thread From: Tucker Taft @ 1999-10-29 0:00 UTC (permalink / raw) David Starner wrote: > ... > As a side question: Ada 95's designers must have been familiar with Modula 3's > support of garbage collection while letting real time stuff keep track of > its own memory. What stopped them from adopting something like that for > Ada 95? Another good question... First, I agree with you that you can't really depend on garbage collection in a langauge until essentially all implementations provide it, so saying that it is allowed is sort of irrelevant. On the other hand, if you happen to be focusing on the Ada->JVM target, you can presume that all implementations (there are only 2 so far) will provide garbage collection, as it is built in to the JVM. One choice you have is to use the third-party "conservative" garbage collectors, essentially the same choice as provided by C++. These work with the same caveats in both Ada and C++. As far as why we didn't have garbage collection for some kinds of memory, and not for others, it was a question of demand, and perceived cost/benefit ratio for a language focused on "critical" systems. Prior to the arrival of Java, garbage collection was definitely not "mainstream." In the long run, making garbage collection a "mainstream" language feature may be Java's biggest contribution to the history of programming language usage. On the other hand, our local experience with Java and garbage collection is that the value it provides is greatest during prototyping. Once you get serious about scalability and performance, you have to go back to being extremely careful about unnecessary object creation, and about effectively "freeing" objects (by nulling-out pointers) as soon as possible. It is true that you don't have to worry about freeing memory too soon, but you do have to worry about making sure that objects do not remain unintentionally "reachable." Personally, I think garbage collection is a way-station toward some better as-yet-to-be-determined approach. There are some interesting languages and languge-theories out there that are based on single-point-of- access to objects. The language Hermes (nee' "Nil") by Strom et al had this as their fundamental storage management approach. It makes a lot of sense for distributed and/or multi-threaded computing, because it addresses storage management, synchronized access, and distribution in one nice package. Getting back to your original question about why not have garbage collection for some kinds of objects, and not for others. Once storage management gets this sophisticated, it begins to become more of a "programming problem" than a "language problem." There were bad experiences with Ada 83 when the language tried to get too high-level, to the point where the programmer had no intuition about the implementation model of the language feature, and implementations varied widely in the relative performance characteristics of different features. Ideally, the ability to do garbage collection could be handed over to the programmer in a way that allowed them to carve up the overall heap space into separate pools with different management approaches in each, and then the programmer, or some third party, would provide managers for these various spaces. We took a baby-step in that direction with the Storage_Pool attribute, but we didn't feel confident in doing too much invention in this area. Luckily, the Ada language design process is much more dynamic now than it was in the period from 1983 to 1990, so as good ideas are proposed and prototyped (perhaps using GNAT), there is a very real chance that they will evolve into parts of the standard. I know that some users of Ada 95 have built quite elaborate garbage collectors on top of the Storage_Pool facility (e.g. the garbage collection built into the ORBExpress/Ada product built by Objective Interface Systems). Perhaps their experience will enable us to develop a more complete user-controlled garbage collection capability for future standardization. For this to be most useful, there *will* need to be a garbage-collecting storage pool manager defined as part of the standard, so it may be used in all Ada code, not just in code written for a compiler that happens to include one. Certainly a key requirement will be that this garbage-collecting manager is not forced on all Ada users, and that it is replacable by the programmer or a third party without having to go back to the compiler vendor, and without having to dismember the rest of the run-time system. It would not be acceptable to follow the Java approach, where garbage collection is an integral part of the JVM, with no well defined way to avoid it or replace it without essentially rewriting the JVM. > -- > David Starner - dstarner98@aasaa.ofe.org -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla Tucker Taft @ 1999-10-30 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 92+ messages in thread From: Lutz Donnerhacke @ 1999-10-30 0:00 UTC (permalink / raw) * Tucker Taft wrote: >For this to be most useful, there *will* need to be a >garbage-collecting storage pool manager defined as part of >the standard, so it may be used in all Ada code, not just in code written >for a compiler that happens to include one. Fine. All work the compiler crew does fine saves hundreds of hours in programmer's cubicles and uncountable hours of bug fixing at customers end. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Tucker Taft @ 1999-10-29 0:00 ` David Botton 1999-10-29 0:00 ` Ammo-zilla mike 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney ` (2 subsequent siblings) 4 siblings, 1 reply; 92+ messages in thread From: David Botton @ 1999-10-29 0:00 UTC (permalink / raw) Perhaps they knew not every one wants GC in their programs, compilers, and environments :-) I often wished when writing Java code that I could force the JVM to clean up what I wanted, when I wanted. David Botton David Starner wrote in message <7vb3c4$8a21@news.cis.okstate.edu>... >What stopped them from adopting something like that for >Ada 95? ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Botton @ 1999-10-29 0:00 ` mike 1999-10-29 0:00 ` Ammo-zilla David Botton ` (2 more replies) 0 siblings, 3 replies; 92+ messages in thread From: mike @ 1999-10-29 0:00 UTC (permalink / raw) In article <7vc2er$128q$1@news.gate.net>, "David says... >I often wished when writing Java code that I could force the JVM to clean up >what I wanted, when I wanted. > >David Botton you can do that. just call the gc(). to clean you local objects, assign 'null' to them first. mike ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla mike @ 1999-10-29 0:00 ` David Botton 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ammo-zilla Geoff Bull 2 siblings, 0 replies; 92+ messages in thread From: David Botton @ 1999-10-29 0:00 UTC (permalink / raw) As pointed out before, that is just a hint to the VM, it doesn't guarantee anything. David Botton mike@home wrote in message <7vco1c$ohs@drn.newsguy.com>... >you can do that. just call the gc(). to clean you local objects, assign >'null' to them first. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla mike 1999-10-29 0:00 ` Ammo-zilla David Botton @ 1999-10-31 0:00 ` Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Charles Hixson 1999-11-01 0:00 ` Ammo-zilla Geoff Bull 2 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-10-31 0:00 UTC (permalink / raw) In article <7vco1c$ohs@drn.newsguy.com>, mike@home wrote: > In article <7vc2er$128q$1@news.gate.net>, "David says... > > >I often wished when writing Java code that I could force the JVM to clean up > >what I wanted, when I wanted. > > > >David Botton > > you can do that. just call the gc(). to clean you local objects, assign > 'null' to them first. No, as far as I know this is a seriously wrong claim. I believe that it is still the case that some (many?) Java systems use conservative garbage collection and thus do not guarantee to free any memory ever (of course most of the time they will free most garbage, they just can't guarantee to!) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-02 0:00 ` Charles Hixson 1999-11-03 0:00 ` Ammo-zilla Wes Groleau 0 siblings, 1 reply; 92+ messages in thread From: Charles Hixson @ 1999-11-02 0:00 UTC (permalink / raw) Robert Dewar wrote: > -- snip > No, as far as I know this is a seriously wrong claim. I believe > that it is still the case that some (many?) Java systems use > conservative garbage collection and thus do not guarantee to > free any memory ever (of course most of the time they will > free most garbage, they just can't guarantee to!) > > Sent via Deja.com http://www.deja.com/ > Before you buy. I believe this to be a -um- "valid" claim. According to the reports that I have heard, the Java (Sun, which version?) garbage collector would collect garbage internally, but would never return the allocated / collected space back to the operating system. This would cause the program to develop a very slow "leak". I don't know how serious this ever became (or, actually, even whether this was true) but this was the claim. So, in some sense, it never did collect and free any memory, although the program was able to re-use it. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-02 0:00 ` Ammo-zilla Charles Hixson @ 1999-11-03 0:00 ` Wes Groleau 0 siblings, 0 replies; 92+ messages in thread From: Wes Groleau @ 1999-11-03 0:00 UTC (permalink / raw) > I believe this to be a -um- "valid" claim. According to the reports > that I have heard, the Java (Sun, which version?) garbage collector > would collect garbage internally, but would never return the allocated / > collected space back to the operating system. This would cause the > program to develop a very slow "leak". I don't know how serious this > ever became (or, actually, even whether this was true) but this was the > claim. So, in some sense, it never did collect and free any memory, > although the program was able to re-use it. This was true of one Ada RTS five years ago, and a current user recently told me it's still true. The vendor offered us as a "fix" a file containing a pragma that made "new" and unch. deall. call malloc and free, respectively! In fact, this vendor's RTS was even worse--free list was never defragmented (coalesced, whatever you want to call it) so that if your allocations varied in size much, you would eventually have NO blocks big enough for another allocation. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla mike 1999-10-29 0:00 ` Ammo-zilla David Botton 1999-10-31 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-01 0:00 ` Geoff Bull 2 siblings, 0 replies; 92+ messages in thread From: Geoff Bull @ 1999-11-01 0:00 UTC (permalink / raw) mike@home wrote: > > In article <7vc2er$128q$1@news.gate.net>, "David says... > > >I often wished when writing Java code that I could force the JVM to clean up > >what I wanted, when I wanted. > > > >David Botton > > you can do that. just call the gc(). to clean you local objects, assign > 'null' to them first. > Explicitly calling the GC is VERY expensive, so you really don't want to do it more often than necessary - and the JVM knows when it is necessary. For the Java I write, performance is important, and I find myself programming to avoid the GC. For "hot" classes I allocate a pool of objects up front, then reuse them, instead of leaving them to the GC. I also give the JVM heaps of memory. BTW, has anybody noticed that Java finalization is broken. System.runFinalizersOnExit is deprecated, so you can't tell if finalizers will ever be run - making them almost completely useless. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Tucker Taft 1999-10-29 0:00 ` Ammo-zilla David Botton @ 1999-10-29 0:00 ` Matthew Heaney 1999-10-29 0:00 ` Ammo-zilla Charles Hixson 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 4 siblings, 1 reply; 92+ messages in thread From: Matthew Heaney @ 1999-10-29 0:00 UTC (permalink / raw) In article <7vb3c4$8a21@news.cis.okstate.edu> , dvdeug@x8b4e53cd. (David Starner) wrote: > And as long as you can't depend on it, GC's main advantage - saving the > programer trouble worring about memory - is useless. But only to the extent that you want portability across Ada compilers. If you're willing to marry a specific compiler, then there's no reason not to depend on GC. Your argument rests on an unstated assumption, which is that you have to be portable. Change that assumption, and your argument is refuted. Portability is an engineering decision. Different shops and different applications will make different choices. -- The political forces that try to eliminate evolution from science classrooms impose a narrow, sectarian doctrine on our educational systems. This imposition represents an affront not only to the constitutional separation of church and state but also to the moral and intellectual integrity embedded in that constitution. <http://www.nabt.org/evolutionks.html> ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney @ 1999-10-29 0:00 ` Charles Hixson 0 siblings, 0 replies; 92+ messages in thread From: Charles Hixson @ 1999-10-29 0:00 UTC (permalink / raw) The real problem is not that is doesn't reliably exist, it's that it doesn't have a well defined interface. An optional annex could solve this. There would need to be a required test to determine whether or not it was present, and a well defined interface to use if it were. Then each program could decide what to do if it were or were not present. As it is... one MUST depend on idiosyncratic behavior which is non-portable. And I *do* want to write portable applications, to the extent possible, given the trade-offs necessary. Matthew Heaney wrote: > In article <7vb3c4$8a21@news.cis.okstate.edu> , dvdeug@x8b4e53cd. (David > Starner) wrote: > > > And as long as you can't depend on it, GC's main advantage - saving the > > programer trouble worring about memory - is useless. > > But only to the extent that you want portability across Ada compilers. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Starner ` (2 preceding siblings ...) 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney @ 1999-10-31 0:00 ` Robert Dewar 1999-10-31 0:00 ` Ammo-zilla David Starner 1999-11-01 0:00 ` Ammo-zilla Robert A Duff 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 4 siblings, 2 replies; 92+ messages in thread From: Robert Dewar @ 1999-10-31 0:00 UTC (permalink / raw) In article <7vb3c4$8a21@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > As a side question: Ada 95's designers must have been familiar > with Modula 3's support of garbage collection while letting > real time stuff keep track of its own memory. What stopped > them from adopting something like that for Ada 95? By the way, speaking as someone quite familiar with garbage collection (remember I chaired WG2.1 for many years, and was responsible for the SPITBOL compilers -- see for example the 1977 paper in SP&E that discusses a new GC algorithm used very successfully in SPITBOL), I find the mixture of low level system facilities, including those that let you break the type model, and GC to be very worrisome, sounds like it can easily create a debugging nightmare. Note that one of the reasons that GC can succeed in Java is the extremely limited nature of the language. GC is more practical in Ada if you severely restrict the subset of Ada you support, and eliminate for instance stuff like Unchecked_Conversion and address overlays. What for instance does it mean to do address overlays that reference the address of some object if the address of that object changes due to GC? I have no idea what a sensible answer to this question might be! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla Robert Dewar @ 1999-10-31 0:00 ` David Starner 1999-11-01 0:00 ` Ammo-zilla Robert Dewar ` (2 more replies) 1999-11-01 0:00 ` Ammo-zilla Robert A Duff 1 sibling, 3 replies; 92+ messages in thread From: David Starner @ 1999-10-31 0:00 UTC (permalink / raw) On Sun, 31 Oct 1999 13:26:48 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: >What for instance does it mean to do address overlays that >reference the address of some object if the address of that >object changes due to GC? I have no idea what a sensible answer >to this question might be! Um, don't move it? Either pick a form of GC that doesn't move objects (the Boehm conservative GC is one that almost becoming the standard for free software, while GCC now uses a rather more sophisticated GC internally that doesn't move stuff), or mark that object as immobile. -- David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla David Starner @ 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Ada and GC. Was: Ammo-zilla Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 2 siblings, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <7vht9i$a2g1@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > or mark that object as immobile. That enormously raises the complexity of a compacting garbage collector, and these things MUST be 100% error free, because bugs in garbage collectors are extremely scary! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Ada and GC. Was: Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla David Starner 1999-11-01 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-01 0:00 ` Vladimir Olensky 1999-11-01 0:00 ` Tucker Taft 1999-11-01 0:00 ` Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 2 siblings, 2 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-01 0:00 UTC (permalink / raw) David Starner wrote in message <7vht9i$a2g1@news.cis.okstate.edu>... >On Sun, 31 Oct 1999 13:26:48 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: >>What for instance does it mean to do address overlays that >>reference the address of some object if the address of that >>object changes due to GC? I have no idea what a sensible answer >>to this question might be! > >Um, don't move it? Either pick a form of GC that doesn't move objects >(the Boehm conservative GC is one that almost becoming the standard >for free software, while GCC now uses a rather more sophisticated GC >internally that doesn't move stuff), or mark that object as immobile. Such problem exists only in the systems where everything is garbage collected. 1. In a system that gives you a choice to use TRACED or UNTRACED by GC objects just do not use TRACED objects if you don't want them to be moved by GC from one memory location to another. Ada 95 is a system that was designed to allow that. 2. Even if object is TRACED by GC it is possible to use a scheme that does not modify memory reference of the TRACED object that is visible to client. Such scheme may use Address Descriptor Table for indirect object reference within GC managed storage pool. This table is part of the GC storage pool manager. Each entry of such table could keep actual memory location of the referenced object and all the additional information that is needed to manage that object. ( e.g - Ref_Count field for simple reference counting GC). With such approach client knows only address of Address Descriptor Table entry for that particular object and the last one does not change when object is moved to the new memory location. There is nothing new in that. It is similar to the protected memory access in operating systems that run in a protected mode. Address of the object is just address of the descriptor table entry for that object and the system itself calculates actual memory address of the referenced object. What is more important such approach provides single_ point_ of_ access for TRACED by GC objects. This in turn could make many things more easy. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-01 0:00 ` Ada and GC. Was: Ammo-zilla Vladimir Olensky @ 1999-11-01 0:00 ` Tucker Taft 1999-11-02 0:00 ` Vladimir Olensky 1999-11-02 0:00 ` Robert Dewar 1999-11-01 0:00 ` Vladimir Olensky 1 sibling, 2 replies; 92+ messages in thread From: Tucker Taft @ 1999-11-01 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > ... > 1. In a system that gives you a choice to use TRACED or UNTRACED > by GC objects just do not use TRACED objects if you don't want > them to be moved by GC from one memory location to another. By the way, don't you generally need to do reference counting rather than tracing-based GC if you have some traced and some untraced objects? If not, how do you deal with pointers to traced objects that exist in untraced objects? (Perhaps disallow at compile-time?) > ... > Regards, > Vladimir Olensky -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-01 0:00 ` Tucker Taft @ 1999-11-02 0:00 ` Vladimir Olensky 1999-11-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-02 0:00 UTC (permalink / raw) Tucker Taft wrote in message <381DD258.B6B11153@averstar.com>... >Vladimir Olensky wrote: >> ... >> 1. In a system that gives you a choice to use TRACED or UNTRACED >> by GC objects just do not use TRACED objects if you don't want >> them to be moved by GC from one memory location to another. > >By the way, don't you generally need to do reference >counting rather than tracing-based GC if you have some >traced and some untraced objects? If not, how do you deal with >pointers to traced objects that exist in untraced objects? >(Perhaps disallow at compile-time?) To be clearer I just used Modula-3 terminology that uses UNTRACED keyword to denote REF TYPES that are pointers that are not controlled by the GC. So in this context TRACED word denotes pointers that are controlled by GC and nothing more (it does not imply any GC mechanism). So I was saying that if one uses TRACED REF TYPE (default in M3) or in Ada "TRACED" ACCESS TYPE that means that this access type and operations with it are provided by the particular GC_storage_manager and that "TRACED" ACCESS TYPE is under full control of that GC manager. This GC_Pointer is of Ada.Finalization.Controlled type. GC manager provides Initialize, Adjust and Finalize operations for the "TRACED" ACCESS TYPE that it exports. Another operation is Create (GC_Ptr, Object_Type) that returns instance of that "TRACED" ACCESS TYPE which essentially is reference to the entry in GC Address Descriptor Table for the created object. That table entry may contain other information needed to implement particular GC management mechanism (it may be Reference_Count field for reference counting mechanism or may be something else). How pool management is implemented is private matter of that GC storage manager. So idea is that externally GC provides control over "TRACED" ACCESS TYPES via Initialize, Adjust and Finalize operations and internally over allocated objects referenced by "TRACED" ACCESS TYPES as well as dereferencing operations. Taking all that into consideration it does not matter where such "TRACED" ACCESS TYPE object (GC_Pointer) is located. Nulling-out such pointer or freeing any dynamically allocated object (which may be allocated by another GC manager) where such GC_Pointer is located will automatically reclaim storage when GC manager will see that there is no more references to the allocated object. As I mentioned in my other post when using such kind of storage pool controlled by GC via it's Address Descriptor Table actual storage pool may even be located on one or several remote machines that may act as Objects Storage Servers for many other machines. In this case local GC storage manager is a client of the remote GC_Storage_Server and we will have some kind of NETWORK_WIDE_VIRTUAL_GARBAGE_COLLECTED_MEMORY. May be I am wrong somewhere. I am not a big expert in GCs. I just let my imagination go where it wants to go. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-01 0:00 ` Tucker Taft 1999-11-02 0:00 ` Vladimir Olensky @ 1999-11-02 0:00 ` Robert Dewar 1999-11-02 0:00 ` Charles Hixson 1 sibling, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-02 0:00 UTC (permalink / raw) In article <381DD258.B6B11153@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > By the way, don't you generally need to do reference > counting rather than tracing-based GC if you have some > traced and some untraced objects? If not, how do you deal > with > pointers to traced objects that exist in untraced objects? > (Perhaps disallow at compile-time?) A general note here is that the Algol-68 literature contains a very thorough treatment of garbage collection in languages of this level, including a full treatment of real-time issues. This literature seems often ignored these days, and I see people reinventing square wheels all the time, especially in the Java context. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-02 0:00 ` Robert Dewar @ 1999-11-02 0:00 ` Charles Hixson 1999-11-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 92+ messages in thread From: Charles Hixson @ 1999-11-02 0:00 UTC (permalink / raw) Given that Ada packages (or at least their private areas) are separate from the rest of the code: garbage collection could achieve almost all of it's desired ends if the implementation of garbage collection within a package *required* that unchecked de/allocation (and other unsafe constructions) not be used within that package. This would allow dynamic constructions that were isolated into separate packages to co-exist with their more consicously manipulated brethern within the same program. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-02 0:00 ` Charles Hixson @ 1999-11-03 0:00 ` Robert Dewar 1999-11-03 0:00 ` Charles Hixson 0 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-03 0:00 UTC (permalink / raw) In article <381F7FFA.FFF5A906@mail.earthlink.net>, Charles Hixson <charleshixsn@mail.earthlink.net> wrote: > This would allow dynamic constructions that were isolated into separate > packages to co-exist with their more consicously manipulated brethern > within the same program. I don't see how this will help at all unless you partition memory into sections that cannot contain mutual pointers ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-03 0:00 ` Robert Dewar @ 1999-11-03 0:00 ` Charles Hixson 0 siblings, 0 replies; 92+ messages in thread From: Charles Hixson @ 1999-11-03 0:00 UTC (permalink / raw) Well... I was thinking that within the {Pragma GC} packages at a minimum the compiler should be able to readily determine which items were pointers and which were not. This would put contraints on type casts (generally a good thing anyway, even if they are sometimes needed), etc. Actually, I was thinking of imposing even stronger limitations, (only manage storage allocated within the package, pass return values out as function values, but no direct access allowed, no publicly visible access variables, any child packages to be subject to GC constraints, etc.). Even if the packages are limited in this manner, most of the advantages of GC can be obtained. If they aren't all needed, then so much the better. The idea here is, when one wants to make use of an efficient GC, then one adopts such constraints as are necessary to make it easy and efficient. But one is able to freely link it to other sections of code that don't have those constraints, so that one can do the parts that it would be difficult to do in the limited framework in a more liberal environment. One just needs to be much more careful with allocated storage when not inside the GC section of the code. And, yes, their use of memory would be nearly disjoint. But this would allow much simpler algorithms to be used for lattice memory structures, etc. And would allow most of the code to be written in the normal manner. I may feel that code would tend to migrate to the GC section, but this would not be a necessity, and certainly the non-GC sections of the code could be expected to be faster. Robert Dewar wrote: > In article <381F7FFA.FFF5A906@mail.earthlink.net>, > Charles Hixson <charleshixsn@mail.earthlink.net> wrote: > > This would allow dynamic constructions that were isolated into > separate > > packages to co-exist with their more consicously manipulated > brethern > > within the same program. > > I don't see how this will help at all unless you partition > memory into sections that cannot contain mutual pointers ... > > Sent via Deja.com http://www.deja.com/ > Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC. Was: Re: Ammo-zilla 1999-11-01 0:00 ` Ada and GC. Was: Ammo-zilla Vladimir Olensky 1999-11-01 0:00 ` Tucker Taft @ 1999-11-01 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-01 0:00 UTC (permalink / raw) Vladimir Olensky wrote in message ... >2. Even if object is TRACED by GC it is possible to use a scheme > that does not modify memory reference of the TRACED object that > is visible to client. > Such scheme may use Address Descriptor Table for indirect object >reference within GC managed storage pool. This table is part of the >GC storage pool manager. < ....> >What is more important such approach provides single_ point_ of_ access >for TRACED by GC objects. This in turn could make many things more easy. One more thing that I forgot to mention: In addition to all said above this approach allows to create TRACED by GC objects not only on local machine but also on any remote machine within distributed application. It is just matter of how that Descriptor Table and associated operations are constructed. So for example it is possible to have high speed LAN (gigabits per seconds data rate) where some machines can serve as Objects Storage Servers which can be accessed by Applications Servers from different machines. Kind of distributed virtual memory. Or such table and GC manager could incorporate CORBA for doing remote object management. All that may be done with needed level of sophistication which would be hidden from the client. May be all that is already done somewhere. If so then it would be nice for such experience to be shared by others ( e.g. via Adapower) Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla David Starner 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ada and GC. Was: Ammo-zilla Vladimir Olensky @ 1999-11-01 0:00 ` Robert Dewar 2 siblings, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <7vht9i$a2g1@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > Um, don't move it? Either pick a form of GC that doesn't move > objects That's very restrictive of course, and means you do not get page relocalization effects, which can be significant. > (the Boehm conservative GC is one that almost becoming the standard > for free software, Conservative GC is very dubious for any mission critical software that has to worry about memory leaks. The idea that any arbitrary object MIGHT fail to be released as a result of bad luck is unacceptable in any environment where you have to be careful about limited memory. > while GCC now uses a rather more sophisticated GC > internally that doesn't move stuff), or mark that object as > immobile. Well of course it is MUCH easier to introduce this kind of specialized GC, you should be able to do the same in Ada by simply defining an appropriate storage pool. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-31 0:00 ` Ammo-zilla David Starner @ 1999-11-01 0:00 ` Robert A Duff 1999-11-01 0:00 ` Ammo-zilla Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1 sibling, 2 replies; 92+ messages in thread From: Robert A Duff @ 1999-11-01 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > By the way, speaking as someone quite familiar with garbage > collection (remember I chaired WG2.1 for many years, and > was responsible for the SPITBOL compilers -- see for example > the 1977 paper in SP&E that discusses a new GC algorithm used > very successfully in SPITBOL), I find the mixture of low level > system facilities, including those that let you break the type > model, and GC to be very worrisome, sounds like it can easily > create a debugging nightmare. Note that one of the reasons that > GC can succeed in Java is the extremely limited nature of the > language. GC is more practical in Ada if you severely restrict > the subset of Ada you support, and eliminate for instance > stuff like Unchecked_Conversion and address overlays. > > What for instance does it mean to do address overlays that > reference the address of some object if the address of that > object changes due to GC? I have no idea what a sensible answer > to this question might be! I think most languages (or implementations thereof) today that support garbage collection also have interfacing-to-C capabilities, which introduces all the issues you're worried about. If you pass pointers into the C world, you end up pinning down objects "by hand" and so forth, and yes, it is error prone and possibly inefficient. I understand your concern, but I don't think it's all that bad -- I don't think it's unreasonable to have Unchecked_Conversion of pointers and garbage collection in the same language. You have to be careful, and you have to minimize and isolate the low-level stuff. After all, the mere existence of Unchecked_Conversion doesn't cause any problems -- you have to *use* it to cause trouble, and that's a programmer's choice. - Bob ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Robert A Duff @ 1999-11-01 0:00 ` Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1 sibling, 0 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-01 0:00 UTC (permalink / raw) Robert A Duff wrote in message ... >Robert Dewar <robert_dewar@my-deja.com> writes: >I understand your concern, but I don't think it's all that bad -- I >don't think it's unreasonable to have Unchecked_Conversion of pointers >and garbage collection in the same language. You have to be careful, >and you have to minimize and isolate the low-level stuff. ^^^^^^^^^^^^^^^^^^^^^^^ In a package that could be marked as UNSAFE ( Modula-3 approach to safety problem) or using "Pragma Unsafe". It would be nice to have such package marker as well as SAFE marker. SAFE marker is simpler to use than put a whole bunch of pragmas: pragma restrictions(AAA) pragma restrictions(BBB) ...... pragma restrictions(ZZZ) One can use that marker for completely safe packages. Otherwise UNSAFE marker could allow even more low-level unsafe operations. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Robert A Duff 1999-11-01 0:00 ` Ammo-zilla Vladimir Olensky @ 1999-11-01 0:00 ` Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Robert A Duff 1 sibling, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <wcc66zmnw0h.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I understand your concern, but I don't think it's all that bad -- I > don't think it's unreasonable to have Unchecked_Conversion of pointers > and garbage collection in the same language. You have to be careful, > and you have to minimize and isolate the low-level stuff. After all, > the mere existence of Unchecked_Conversion doesn't cause any problems -- > you have to *use* it to cause trouble, and that's a programmer's choice. Well do you understand the concern? Have you done debugging in this kind of environment? I have! A bug that damages the integrity of the collection mechanism can often take many garbage collection cycles to make itself known, spreading like a kind of cancer at each garbage collection cycle. Furthermore, the result might just be a subtle memory leak, particularly hard to detect, when the real reason for the problem has been disposed of many GC cycles ago. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-02 0:00 ` Robert A Duff 1999-11-02 0:00 ` Ammo-zilla Robert Dewar 0 siblings, 1 reply; 92+ messages in thread From: Robert A Duff @ 1999-11-02 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > Well do you understand the concern? Have you done debugging in > this kind of environment? I have! Not a whole lot, but I have written mixed Smalltalk and assembly language, and yes, bugs were very nasty once in a while, because the GC destroys the evidence. But if the total amount of assembly is reasonably small, and you know you have a "weird" bug, you can stare at the assembly very carefully until you see it. Or you can set options on the GC that tell it to run more often (so you might get lucky and trip over the bug sooner), or whatever. I've also had experience with mixed Simula and Pascal, and with pure assembly with some ad hoc sort of GC of some data structures. But I've also seen some pretty nasty bugs in non-GC'ed systems, so... In any case, in a garbage-collected system, somebody has to write the garbage collector itself, and that fundamentally requires the kind of low-level features we're talking about -- the GC obviously can't rely on the existence of GC. Bugs in the GC itself have exactly the same sort of nasty consequences we're talking about. > A bug that damages the integrity of the collection mechanism can > often take many garbage collection cycles to make itself known, > spreading like a kind of cancer at each garbage collection > cycle. Furthermore, the result might just be a subtle memory > leak, particularly hard to detect, when the real reason for the > problem has been disposed of many GC cycles ago. - Bob ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-02 0:00 ` Ammo-zilla Robert A Duff @ 1999-11-02 0:00 ` Robert Dewar 1999-11-03 0:00 ` Ammo-zilla Vladimir Olensky 0 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-02 0:00 UTC (permalink / raw) In article <wcck8o0yh5x.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Bugs in the GC itself have exactly the same sort > of nasty consequences we're talking about. Absolutely! And that's what's scary! These bugs in the GC itself are among the most horrible bugs I have ever tackled (the one exception being subtle hardware design errors). The idea that an Ada user with little awareness of what is going on at a low level can create bugs of comparable scariness by casual incorrect use of unchecked conversion seems unacceptably risky to me. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-02 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-03 0:00 ` Vladimir Olensky 1999-11-03 0:00 ` Ammo-zilla Robert Dewar 1999-11-04 0:00 ` Ada GC (was Ammo-zilla) Nick Roberts 0 siblings, 2 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-03 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7vncgr$bpg$1@nnrp1.deja.com>... >In article <wcck8o0yh5x.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: >> Bugs in the GC itself have exactly the same sort >> of nasty consequences we're talking about. > >Absolutely! And that's what's scary! These bugs in the GC itself >are among the most horrible bugs I have ever tackled (the one >exception being subtle hardware design errors). The idea that >an Ada user with little awareness of what is going on at a low >level can create bugs of comparable scariness by casual >incorrect use of unchecked conversion seems unacceptably >risky to me. As for me I fully support that. I think that any unchecked conversions should be disallowed for pointers that are traced by GC. It is not only extremely unsafe but I do not see any sense in that if language is extended to support GC. Any manipulations with such pointers should be allowed only within GC manager package. GC client should not have any access to such operations at all. GC mechanism should be completely hidden from the client. Depending on particular GC mechanism any pointer traced by GC may be not only a pure "ROOT" (in traditional GC terminology) which references object storage location but it may also be a reference to the entry record in GC Address Descriptor Table which in turn in one of it's fields contains the real "ROOT" of the pointers tree/net as well as other necessary fields (referenced object tag, size etc.). Last approach was described in my other posts. For such GC_Pointer unchecked conversions done by the client makes no sense at all. This restriction could be done using language support for GC. Let's suppose that we have additional keyword TRACED that applied to the ACCESS TYPES controlled by GC. (This TRACED ACCESS TYPE could be bound to particular GC using standard Ada construct: for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool). When access type is declared to be traced compiler should not allow any unchecked conversions with that type in standard mode. In may allowed only using additional pragmas. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-03 0:00 ` Ammo-zilla Vladimir Olensky @ 1999-11-03 0:00 ` Robert Dewar 1999-11-04 0:00 ` Ada GC (was Re: Ammo-zilla) Vladimir Olensky 1999-11-04 0:00 ` Ada GC (was Ammo-zilla) Nick Roberts 1 sibling, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-03 0:00 UTC (permalink / raw) In article <s20tckqd24291@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > As for me I fully support that. > I think that any unchecked conversions should > be disallowed for pointers that are traced by GC. > It is not only extremely unsafe but I do not see any sense > in that if language is extended to support GC. But that of course is not enough to prevent scary GC bugs :-) As soon as you allow the type safety of the system to be compromised in any way, it is possible that critical pointers will get damaged. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-03 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-04 0:00 ` Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 92+ messages in thread From: Vladimir Olensky @ 1999-11-04 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>... >In article <s20tckqd24291@corp.supernews.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> As for me I fully support that. >> I think that any unchecked conversions should >> be disallowed for pointers that are traced by GC. >> It is not only extremely unsafe but I do not see any sense >> in that if language is extended to support GC. > >But that of course is not enough to prevent scary GC bugs :-) Yes, I agree this does not prevent GC bugs that may exist in GC implementation itself. But at least that could provide isolation between GC implementation and GC client. The last one will never be able to spoil anything in GC internal data. Also, approach that I discribed yearlier provides additional level of isolation between GC user and GC internal data representation and it also allows to achieve any desired level of sofisticated functionality . Any pointer of "TRACED" ACCESS TYPE should never reference real data. Instead it should only provide access to the Address Descriptor Table entry for the allocated object . Moreover, Address Descriptor Table structure is completely hidden from the user. This is the same as protected memory access in OS running in protected mode. This already proved to be very effective in providing safety and reliability. >As soon as you allow the type safety of the system to be >compromised in any way, it is possible that critical pointers >will get damaged. Again I agree here. And again I would like to recall neat Modula-3 approach to the safety issues that could also be very useful in Ada: Any unsafe operations are allowed only in the modules marked as UNSAFE . This marker says that here programmer and not the system is responsible for safety. In modules without such marker M3 does not allow any unsafe operation and safety is guaranteed by the system itself. Such approach force all (potentially) unsafe operations to be concentrated in few unsafe modules instead of being scatted around. Right now nothing forces Ada programmer (except his/her internal discipline) to concentrate all unsafe operation in special packages. This reminds me discussions Ada vs. C& C++ where many times many people were telling that Ada is better in this respect than C++ as C++ does allow to use unsafe and dangerous C style programming and does not force to use new more safe C++ features. Yes, Ada is much safer itself but it does not force as Modula-3 to put unsafe code in special places where such operations could be easily traced and managed. I think that some ideas implemented in M3 could be very useful in Ada . There is nothing bad in using other's positive experience. Here I could remind that Component Pascal (descendant of Oberon-2) accepted some nice Ada features and they state that Ada positive experiences were taken into account and that sounds good for me. Regards, Vladimir Olensky. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-04 0:00 ` Ada GC (was Re: Ammo-zilla) Vladimir Olensky @ 1999-11-06 0:00 ` Robert Dewar 1999-11-06 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-06 0:00 UTC (permalink / raw) In article <s23mnbp024223@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > > Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>... > >In article <s20tckqd24291@corp.supernews.com>, > > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >> As for me I fully support that. > >> I think that any unchecked conversions should > >> be disallowed for pointers that are traced by GC. > >> It is not only extremely unsafe but I do not see any sense > >> in that if language is extended to support GC. > > > >But that of course is not enough to prevent scary GC bugs :-) > > Yes, I agree this does not prevent GC bugs that may exist > in GC implementation itself. But at least that could provide > isolation between GC implementation and GC client. > The last one will never be able to spoil anything in GC > internal data. Again you miss my point, unless you segregate memory with hardware memory protect, allowing unchecked conversion, and hence address calculations, anywhere, can damage data structures anywhere. I am NOT talking about bugs in the GC implementation itself. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-06 0:00 ` Robert Dewar @ 1999-11-06 0:00 ` Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-06 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>... >In article <s23mnbp024223@corp.supernews.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> >> Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>... >> >In article <s20tckqd24291@corp.supernews.com>, >> > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> >> As for me I fully support that. >> >> I think that any unchecked conversions should >> >> be disallowed for pointers that are traced by GC. >> >> It is not only extremely unsafe but I do not see any sense >> >> in that if language is extended to support GC. >> > >> >But that of course is not enough to prevent scary GC bugs :-) >> >> Yes, I agree this does not prevent GC bugs that may exist >> in GC implementation itself. But at least that could provide >> isolation between GC implementation and GC client. >> The last one will never be able to spoil anything in GC >> internal data. > >Again you miss my point, unless you segregate memory with >hardware memory protect, allowing unchecked conversion, and >hence address calculations, anywhere, can damage data structures >anywhere. I am NOT talking about bugs in the GC implementation >itself. I see your point now. Of course it is very dangerous to perform any calculations (e.g address arithmetic) for something that is hidden behind protection wall and one does not know for sure what is there in reality. This is especially dangerous when different kinds of memory pools are mixed and one does not know for sure on which kind of memory one is trying to perform such operations. It just never come to my mind that someone (one the client's side) could try to do something (using unchecked conversions ) for anything that is behind that protection wall (for me it is a crazy idea). Mapping between external world and internal world relative to that wall could only be allowed to the subsystem responsible for that protection wall. As a matter of fact I do not see the way how one can penetrate in reality through hardware memory protection wall directly using pointer arithmetic. One need to have access to some system resources to do that. But if one could perform such operations with the virtual addresses on this side of the wall and if one does not know how they map to the real physical addresses it could cause problems. On the other hand you already pointed out the way to reduce that danger: ".. unless you segregate memory with hardware memory protect ..". Here I could also add that I think that it is not too dangerous to perform address arithmetic within single allocated chunck of memory providing that measures have been taken to ensure that the result is within memory boundaries of the allocated memory chunck. Reading/Writing data using such resulting address could be dangerous of course. It could be extremely dangerous to use address arithmetic trying to calculate location of the prev/next memory chunk or object in the memory if allocated memory chunks are not contiguous that could be the case when using hardware protected memory. In the best case one will get GPF, in the worst case one may damage data structures. With some overhead some measures could be taken to check pointer validity to increase safety. This could be keeping (hashed) table/list of pointers to allocated objects and use that table/list to check pointer validity . Here I should mention very interesting example in GNAT distribution, namely System.Debug_Pool package that makes use of H-table to keep the status of each storage chunk used in that pool. Generally there could be many approaches to increase safety. One of the nice ones (for me) is to use notion of safe and unsafe modules/packages as in Modula-3 and do not allow any unsafe operations in safe packages. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-06 0:00 ` Vladimir Olensky @ 1999-11-06 0:00 ` Robert Dewar 1999-11-06 0:00 ` Vladimir Olensky 1999-11-09 0:00 ` Robert A Duff 2 siblings, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-06 0:00 UTC (permalink / raw) In article <s27tvo5hhpc65@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > It just never come to my mind that someone (one the client's > side) could try to do something (using unchecked conversions ) > for anything that is behind that protection wall (for me it > is a crazy idea). I guess Vladimir that you have solved the problem that has eluded everyone else in the field, namely how to be absolutely sure that your program is free of errors. We are not talking about DELIBERATE errors here, but for instance of a simple error like using unchecked conversion to do low level buffer copying, and getting the bounds wrong. > As a matter of fact I do not see the way how one can > penetrate in reality through hardware memory protection wall > directly using pointer arithmetic. You are assuming that it is indeed possible to provide the necessary memory protection between collected and non-collected domains. First, my point was about systems where this is not possible. Second: most systems are in practice in this category! > Generally there could be many approaches to increase safety. > One of the nice ones (for me) is to use notion of safe and > unsafe modules/packages as in Modula-3 and do not allow any > unsafe operations in safe packages. But as we are discussing this segregation in what packages are allowed to do is not helpful at all in this case in the absence of the ability to build data allocation firewalls at the hardware level (something that is often not possible, both in embedded systems -- which often lack such memory protection hardware -- and in higher level systems running on top of standard OS's, which lack this kind of capability). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-06 0:00 ` Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar @ 1999-11-06 0:00 ` Vladimir Olensky 1999-11-09 0:00 ` Robert A Duff 2 siblings, 0 replies; 92+ messages in thread From: Vladimir Olensky @ 1999-11-06 0:00 UTC (permalink / raw) > >> > Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>... > >> >But that of course is not enough to prevent scary GC bugs :-) > >> > >> Yes, I agree this does not prevent GC bugs that may exist > >> in GC implementation itself. But at least that could provide > >> isolation between GC implementation and GC client. > >> The last one will never be able to spoil anything in GC > >> internal data. > > > >Again you miss my point, unless you segregate memory with > >hardware memory protect, allowing unchecked conversion, and > >hence address calculations, anywhere, can damage data structures > >anywhere. I am NOT talking about bugs in the GC implementation > >itself. > > With some overhead some measures could be taken to check pointer > validity to increase safety. This could be done by keeping > (hashed) table/list of pointers to allocated objects and > use that table/list to check pointer validity . Here I should > mention very interesting example in GNAT distribution, namely > System.Debug_Pools package that makes use of H-table to keep > the status of each storage chunk used in that pool. > > Generally there could be many approaches to increase safety. > One of the nice ones (for me) is to use notion of safe and unsafe > modules/packages as in Modula-3 and do not allow any unsafe > operations in safe packages. Below is a small illustration to the topic discussed. When using unchecked conversions it is very easy to damage data even without pointer arithmetic. As there is no way now to check VALIDITY of the pointer then after unchecked conversion the result of doing such conversion could be very disastrous. Even if we try to check validity of the object's fields which is referenced by the new pointer this does not help sometimes. Moreover if that pointer is Null then we will have Constraint_Error or Program_Error exception. This shows that for the safety reason applicability area of the T'Valid attribute could be expanded at the expense of some overhead in storage pool management to include validity check for the given pointer that could be done as was discussed in the previous posts. Regards, Vladimir Olensky ---------------------------------------------------- -- Demo: -- Unchecked_Conversion -- bad usage that results in -- data corruption ---------------------------------------------------- with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; with Ada.Unchecked_Conversion; procedure Tst_Acc_Validity is type T is record A : Integer; B : Integer; end record; type T_Ptr is access all T; type Enum is (Mon, Tue, Wed); package En_IO is new Ada.Text_IO.Enumeration_IO(Enum); type S is record A : String (1 .. 10) := " test test"; B : Enum := Tue; end record; type S_Ptr is access all S; function T_To_S_Ptr is new Ada.Unchecked_Conversion(T_Ptr,S_Ptr ); T1 : T_Ptr; S1, S2 : S_Ptr; begin T1 := new T'( A => 177, B => 555); S1:= T_To_S_Ptr(T1); -- if S1'Valid then .... -- no way do do this now, won't compile if S1.B'Valid then Put_Line(" S1.B is valid"); else Put_Line(" S1.B is not valid"); end if; -- does not show that S1.B is invalid New_Line; Put_Line("------------------------ Uncorrupted T1:"); Put(" T1.A = "); Put(T1.A); New_Line; Put(" T1.B = "); Put(T1.B); New_Line; Put_Line("--------------------- Reading S1 from T1 memory area:"); Put(" S1.A = "); Put(S1.A); New_Line; Put(" S1.B = "); En_IO.Put(S1.B); New_Line; S1.A:="write test"; S1.B:=Wed; Put_Line("----- Writing S1 to T1 memory area and reading again:"); Put(" S1.A = "); Put(S1.A); New_Line; Put(" S1.B = "); En_IO.Put(S1.B); New_Line; Put_Line("T1 is corrupted after assigning values to S1 fields:"); Put(" T1.A = "); Put(T1.A); New_Line; Put(" T1.B = "); Put(T1.B); New_Line; Put_Line("----------------------------- Checking S2.B validity:"); -- could result in erroneous execution -- (LRM 13.11.2 (16): Evaluating a name that denotes a nonexistent -- object is erroneous) -- or raise Constraint_Error at a run time if S2.B'Valid then Put_Line(" S2.B is valid"); else Put_Line(" S2.B is not valid"); end if; end Tst_Acc_Validity; ============================================================= Progam output: S1.B is valid ---------------------------------- Uncorrupted T1: T1.A = 177 T1.B = 555 ------------------------------- Reading S1 from T1 memory area: S1.A = _ +\x02 S1.B = MON --------------- Writing S1 to T1 memory area and reading again: S1.A = write test S1.B = WED --------- T1 is corrupted after assigning values to S1 fields: T1.A = 1953067639 T1.B = 1702109285 --------------------------------------- Checking S2.B validity: raised CONSTRAINT_ERROR : tst_acc_validity.adb:95 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-06 0:00 ` Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar 1999-11-06 0:00 ` Vladimir Olensky @ 1999-11-09 0:00 ` Robert A Duff 1999-11-10 0:00 ` Vladimir Olensky 2 siblings, 1 reply; 92+ messages in thread From: Robert A Duff @ 1999-11-09 0:00 UTC (permalink / raw) "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>... > >Again you miss my point, unless you segregate memory with > >hardware memory protect, allowing unchecked conversion, and > >hence address calculations, anywhere, can damage data structures > >anywhere. I am NOT talking about bugs in the GC implementation > >itself. And crossing a hardware protection boundary once for every "new" would be prohibitively expensive (unless you designed the hardware specifically to support such a thing -- even then, it would be expensive). > It just never come to my mind that someone (one the client's side) > could try to do something (using unchecked conversions ) for anything > that is behind that protection wall (for me it is a crazy idea). Bugs are not caused by people *trying* to do something -- they happen by accident! - Bob ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-09 0:00 ` Robert A Duff @ 1999-11-10 0:00 ` Vladimir Olensky 1999-11-10 0:00 ` Richard D Riehle 0 siblings, 1 reply; 92+ messages in thread From: Vladimir Olensky @ 1999-11-10 0:00 UTC (permalink / raw) Robert A Duff wrote in message ... >Bugs are not caused by people *trying* to do something -- they happen by >accident! Yes, no doubt that they happen by accident. But sometimes they happen when someone is trying to do something using unsafe features to achieve some goal that could not be achieved using safe features and then something slips out of control (accidentally) . And this happens not only in programming. As far as access types concerned probability of such bugs could be reduced if it would be possible to extend applicability of the VALID attribute to be used with some of the access types objects (not all but at least for some kind of "TRACED" ACCESS TYPES supported by storage pools with additional management overhead :-). I feel that this could be very useful and it could make the idea behind VALID attribute to be more complete and more in line with the overall Ada ideology. Of course the same goal could be done by putting additional restrictions on usage of some unsafe features but this idea leads to the direction that were followed by some other languages . I feel that the better way (for general purpose programming) is to expand applicability of the existing Ada safety features (making them more complete). VALID attribute falls in this category. I am not insisting on all of that. I am just contemplating. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Vladimir Olensky @ 1999-11-10 0:00 ` Richard D Riehle 1999-11-10 0:00 ` Nick Roberts ` (2 more replies) 0 siblings, 3 replies; 92+ messages in thread From: Richard D Riehle @ 1999-11-10 0:00 UTC (permalink / raw) Robert A Duff wrote in message ... >Bugs are not caused by people *trying* to do something -- they happen by >accident! I usually tell my clients and students to stop using the word "bug" entirely. Software practice is the only engineering wannabee that euphemizes away its mistakes by labeling them bugs. What we call a "bug" is actually a mistake. Someone tried to do something and made a mistake. The mistake results in a defect. The defect is a potential run-time fault. Managers need to take the responsibility for elminating the word "bug" from the vocabulary of their software personnel. There has been some discussion lately of software as an engineering practice. It will not be an engineering discipline until we call a mistake a mistake, forcing personnel to fully accept responsibility for their errors of omission as well as commission. A programmer calls it a bug. An engineer calls it a mistake. Richard Riehle ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Richard D Riehle @ 1999-11-10 0:00 ` Nick Roberts 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Robert I. Eachus 1999-11-10 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 92+ messages in thread From: Nick Roberts @ 1999-11-10 0:00 UTC (permalink / raw) Richard D Riehle wrote: > ... > There has been some discussion lately of software as an engineering > practice. It will not be an engineering discipline until we call a > mistake a mistake, forcing personnel to fully accept responsibility for > their errors of omission as well as commission. A programmer calls it > a bug. An engineer calls it a mistake. And, as a corollary, customers need to be educated into rejecting software with a 'bug' in it just as diligently as they would reject any other product with a defect. It would help for our respective governments (UK, US, and elsewhere) to produce some (not too heavy) legislation to assist in this (e.g. outlawing some of the more outrageous evasions of liability in typical software licences). Sadly, however, I think our politicians have undergone a physical adaptation to their habitat (whereby the brain is replaced by an air sac, for the more efficient generation of hot air). -- Nick Roberts Computer Consultant (UK) http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Nick Roberts @ 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-12 0:00 UTC (permalink / raw) In article <3829D562.5F102A83@callnetuk.com>, Nick Roberts <nickroberts@callnetuk.com> wrote: > And, as a corollary, customers need to be educated into > rejecting software with a 'bug' in it just as diligently as > they would reject any other product with a defect. Well, two points here. One, to the extent that a bug reflects a difference between the spec and the implementation, people are not that diligent, and for good reason, insisting on defect free products would increase their cost. Automobiles for instance virtually always have delivery defects (See Consumer Reports, where it is quite typical to see something like "this car was delivered in excellent shape, there were only 17 defects, only one of them significant"). Two, to the extent that a bug reflects something that people don't like in the *design*, I think they are often more diligent than for other products. You don't generally expect a car maker to send you a new dashboard with the speedometer positioned so you can see if it you are only 5'4" tall, but in the software world, people expect this kind of responsiveness. They don't always get it, but the expectations that software can be improved in this way are greater than for many other products. At the same time, I think we all agree that the practice of rushing things to market with entirely excessive numbers of defects should be punished in the software area by consumer rejection at least as energetically as for other fields. The PC Junior was a bunch of junk, it rightly failed in the marketplace. By contrast, the decrepit version of DOS that Microsoft delivered for use on the 286, which was incapable of taking advantage of the 16 meg addressing and protected capabilities of this chip was an abomination. But it succeeded in the marketplace, despite the presence of a far superior product from DR Research (Flex OS) that took full advantage of the chip. Why? Perhaps this has something to do with the stifling of innovation that the recent finding of facts in the Microsoft case describes in detail. Perhaps it is because consumers are not educated to expect reasonable products in the software area? WHo knows? But either way, it is indeed unacceptable. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Nick Roberts 1999-11-12 0:00 ` Robert Dewar @ 1999-11-12 0:00 ` Robert I. Eachus 1999-11-12 0:00 ` Didier Utheza 1 sibling, 1 reply; 92+ messages in thread From: Robert I. Eachus @ 1999-11-12 0:00 UTC (permalink / raw) Nick Roberts wrote: > And, as a corollary, customers need to be educated into rejecting > software with a 'bug' in it just as diligently as they would reject any > other product with a defect. > > It would help for our respective governments (UK, US, and elsewhere) to > produce some (not too heavy) legislation to assist in this (e.g. > outlawing some of the more outrageous evasions of liability in typical > software licences). Sadly, however, I think our politicians have > undergone a physical adaptation to their habitat (whereby the brain is > replaced by an air sac, for the more efficient generation of hot air). Of course, any such well meaning legislation, if framed too broadly, would do much more harm than good. There are large categories of software where applying techniques appropriate to saftey-critical real-time software would make products unaffordably expensive. But more important there is a class of software where Godel's Proof guarentees that there is at least one bug--like compilers--or where Post's Correspondence Problem prevents proof of compliance with a particular set of requirements. And then there are other problems, like the halting problem, where it is possible to provide a useful implementation, but it is not possible to provide a correct implementation of the requirements. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-12 0:00 ` Robert I. Eachus @ 1999-11-12 0:00 ` Didier Utheza 0 siblings, 0 replies; 92+ messages in thread From: Didier Utheza @ 1999-11-12 0:00 UTC (permalink / raw) To return to the GC problem : as I understood the link, the problem resides in the stability of the program and the compatibility of a GC with a real time system. At the present time, this may actually be two different matters.Just a pure question from a novice in Ada and OOP, can a real time system accomodate the Object Oriented scheme without compromising its stability in the present state of the technology? On the other side, Ada95 is a powerfull programming tool, you can use it to create OSes, real time systems but also simpler programs such as word processors and object oriented interfaces to human subject instead of machine. In the last cases, GC could be acceptable. The time penalty that it is bringing, will not be unacceptable. So maybe a good way of introducing a GC in Ada would be to have a conditional GC that can be turn on or off depending on the type of task that the program is suppose to perform (non time critical and time critical). Greetings. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Richard D Riehle 1999-11-10 0:00 ` Nick Roberts @ 1999-11-10 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 92+ messages in thread From: Robert A Duff @ 1999-11-10 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > I usually tell my clients and students to stop using the word "bug" > entirely. Software practice is the only engineering wannabee that > euphemizes away its mistakes by labeling them bugs. Shrug. I don't use the word "bug" as a euphemism. Bugs are my enemy, and I take them quite seriously. I don't think renaming them "mistakes" or "errors" or "disasters" would change people's attitudes. - Bob ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Re: Ammo-zilla) 1999-11-10 0:00 ` Richard D Riehle 1999-11-10 0:00 ` Nick Roberts 1999-11-10 0:00 ` Robert A Duff @ 1999-11-12 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 92+ messages in thread From: Robert I. Eachus @ 1999-11-12 0:00 UTC (permalink / raw) Richard D Riehle wrote: > What we call a "bug" is actually a mistake. Someone tried to do something > and made a mistake. The mistake results in a defect. The defect is a > potential run-time fault. Managers need to take the responsibility for > elminating the word "bug" from the vocabulary of their software personnel. I have to disagree. Yes, most bugs are mistakes, and are determineded to be design errors or implementation errors. However, there are other categories of bug that do not involve mistakes. For example, ACT considers misleading error messages from the compiler to be bugs. I agree, but since the "right" error messages can only be determined by experience, these bugs are usually not mistakes. As another example, failure to follow coding standards can be mistakes. But if the standard changes, or more likely code developed with one standard is merged with code using a different standard, the discrepancies are bugs. (Not fixing them is a mistake, but at first they are bugs.) Similarly, if you are moving code forward to use a new version of some COTS product, incompatibilies are bugs, but they are normally not mistakes. These conditions are not limited to software. For example, if your job is to modify a transmission design to work with a different engine, there may be many discrepancies to be resolved. These were not originally mistakes, and they will only be potential faults if you fail to resolve them. Or consider circut board layout. If your original try at laying out a board has 73 disconnects, it doesn't mean that you made 73 mistakes. It may take you days to reduce that number to zero (or in some cases to a small number of wires), but that is part of the design process. Some people would go further and say that all potential faults detected during unit test, or even integration test are not mistakes. I don't feel that all fall into that category, but there are certainly cases where the job of integration is to resolve unintended conflicts where there is no blame to be allocated. Of course, one of the nice things about Ada is that there are very few opportunities to innocently create such conflicts. On the other hand using a C++ compiler without namespace support is a mistake, and the blame should be laid somewhere if you get to integration and you have unrepairable naming conflicts. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Ammo-zilla) 1999-11-03 0:00 ` Ammo-zilla Vladimir Olensky 1999-11-03 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-04 0:00 ` Nick Roberts 1999-11-04 0:00 ` Wes Groleau 1 sibling, 1 reply; 92+ messages in thread From: Nick Roberts @ 1999-11-04 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > ... > This restriction could be done using language support for GC. > Let's suppose that we have additional keyword TRACED > that applied to the ACCESS TYPES controlled by GC. > (This TRACED ACCESS TYPE could be bound > to particular GC using standard Ada construct: > for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool). > > When access type is declared to be traced compiler should > not allow any unchecked conversions with that type in standard > mode. > In may allowed only using additional pragmas. Rather than introducing a new reserved word into the Ada syntax, I think all that would be necessary would be for a new standard (abstract) pool type to be defined, derived from Root_Storage_Pool, called Root_Managed_Pool, say. Managed (garbage collecting) pools would all be derived from this type. I think Root_Managed_Pool would have at least one extra primitive operation, to induce a garbage collection and/or object compaction cycle. In order to cause objects referenced by a certain access type to be allocated into a managed pool, one would simply declare a Storage_Pool representation clause for the access type, naming an object of the appropriate managed pool type. Notice how this leaves implementations free to choose to provide garbage collection by default or not (or to select this by pragma, compiler switch, or other option). It would then be the responsibility of the compiler to ensure that all objects of this access type were 'traced', as Vladimir puts it. This means, in practice, that: a type descriptor for the access type must be entered into a 'type descriptor table'; every single object of the access type must be entered into a 'frame object table'; every instance of a value of the access type being loaded into or saved out of a register must be entered into a 'register loading table'; every compound type which can contain one or more values of a traced type is also traced (and so on recursively). The three tables would form part of the static data of the program, and would enable managed pools to determine the size and alignment of every object they contain, and to move those objects about in memory, correcting variables and registers as necessary. In addition, the compiler must provide facilities (to the pool managers) for identifying and freezing those tasks using a managed pool, for reading from and writing to the stack frames and register sets of those tasks, etc. (Or, to put it in simpler terms, no-one should be in doubt as to the complexity of adding GC, nor, for that matter, to the possibility of doing so.) It may well behove a compiler to issue a serious warning for any use of unchecked conversion, deallocation, or access for any traced type. But ultimately, as ever, if the user (Ada programmer) screws up, after having been so warned, he or she only has himself or herself to blame. It would undoubtedly be very useful (and not overly difficult, I think) for the implementor of a managed pool to provide an alternative implementation or mode which (sacrificing some efficiency perhaps) provided various (extra) profiling and debugging facilities relating to the use of the pool. It would be particularly incumbent upon the implementors of managed pools to make special efforts to ensure the correctness of their implementations, since the results of a garbage collector going wrong are always likely to be particularly unfortunate. -- Nick Roberts Computer Consultant (UK) http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada GC (was Ammo-zilla) 1999-11-04 0:00 ` Ada GC (was Ammo-zilla) Nick Roberts @ 1999-11-04 0:00 ` Wes Groleau 0 siblings, 0 replies; 92+ messages in thread From: Wes Groleau @ 1999-11-04 0:00 UTC (permalink / raw) > > This restriction could be done using language support for GC. > > Let's suppose that we have additional keyword TRACED > > that applied to the ACCESS TYPES controlled by GC. > > (This TRACED ACCESS TYPE could be bound > > to particular GC using standard Ada construct: > > for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool). > > > > When access type is declared to be traced compiler should > > not allow any unchecked conversions with that type in standard > > mode. > > In may allowed only using additional pragmas. > > Rather than introducing a new reserved word into the Ada syntax, I think > all that would be necessary would be for a new standard (abstract) pool > type to be defined, derived from Root_Storage_Pool, called > Root_Managed_Pool, say. Managed (garbage collecting) pools would all be > derived from this type. Good ideas, but seems to me (disclaimer: I am not a compiler expert, nor do I play one on Usenet) it would be quite a challenge for the compiler to reliably warn of misuse. Tracking dangerous operations applied directly to an access type is not hard, but what about unchecked conversions, address clauses, or other operations modifying or referencing the objects (or components of the objects) the access type points to? In Ada, access types are often used for dynamic data structures (lists, maps, graphs, stacks, etc.) which often contain nested access objects. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-29 0:00 ` Ammo-zilla David Starner ` (3 preceding siblings ...) 1999-10-31 0:00 ` Ammo-zilla Robert Dewar @ 1999-10-31 0:00 ` Robert Dewar 1999-10-31 0:00 ` Garbage colletion Lutz Donnerhacke 4 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-10-31 0:00 UTC (permalink / raw) In article <7vb3c4$8a21@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > I said nothing about vendors. As long as there are > otherwise-reasonable Ada compilers that don't garbage collect, > good Ada programs must assume they're running on that system. I strongly object to this. There are many optional features in Ada, including for example the entire information systems annex, or complex arithmetic in annex G. It is absolutely perfectly reasonable to write Ada programs using these optional features providing that you have a clear understanding of the requirements you place on the Ada compiler as you do it. > I once pointed out that integer'base could be an infinite > precision integer type. (Robert Dewar said yes, but it wasn't > something that was going to get added to GNAT.) More accurately, he said that it would not be added unless there was significant customer demand -- there is none! > Let's say that it was added to GNAT. > Good portable Ada code still couldn't depend on having 70 > digit+ integer types. There is nothing bad about Ada code that depends on optional features of Ada. Do you really think that any Ada code that uses tasking priorities is bad? Of course not!!! It is just that such code requires an Ada compiler that implements this optional Ada feature. > As a side question: Ada 95's designers must have been familiar > with Modula 3's support of garbage collection while letting > real time stuff keep track of its own memory. What stopped > them from adopting something like that for Ada 95? They were quite familiar, they were unconvinced (perhaps they were unaware of any significant examples of large mission critical real time systems implemented in Modula-3 that they found convincing :-) :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Garbage colletion 1999-10-31 0:00 ` Ammo-zilla Robert Dewar @ 1999-10-31 0:00 ` Lutz Donnerhacke 1999-11-01 0:00 ` Larry Kilgallen ` (2 more replies) 0 siblings, 3 replies; 92+ messages in thread From: Lutz Donnerhacke @ 1999-10-31 0:00 UTC (permalink / raw) * Robert Dewar wrote: >More accurately, he said that it would not be added unless >there was significant customer demand -- there is none! This typ of reasoning is invalid, because a customer who learned to deal with a missing feature clearly does not need it afterwards. This is especially true after all programming examples which required GC are deleted from the hard disk. (Although they were smaller and easier to understand.) \f This is no cry for GC. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-10-31 0:00 ` Garbage colletion Lutz Donnerhacke @ 1999-11-01 0:00 ` Larry Kilgallen 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Robert Dewar 2 siblings, 0 replies; 92+ messages in thread From: Larry Kilgallen @ 1999-11-01 0:00 UTC (permalink / raw) In article <slrn81osi4.940.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes: > * Robert Dewar wrote: >>More accurately, he said that it would not be added unless >>there was significant customer demand -- there is none! > > This typ of reasoning is invalid, because a customer who learned to deal > with a missing feature clearly does not need it afterwards. This is > especially true after all programming examples which required GC are deleted > from the hard disk. (Although they were smaller and easier to understand.) Would you suggest that compiler vendors should specifically target features their customers do not request ? In preference to features their customers _do_ request ? If adding perfect GC cost nothing, I am sure all vendors would quite happily include it. Personally, I am much more concerned with combatting defects than with new features. Larry Kilgallen ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-10-31 0:00 ` Garbage colletion Lutz Donnerhacke 1999-11-01 0:00 ` Larry Kilgallen @ 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Gnat IDE (was: Garbage colletion) Ted Dennison 1999-11-01 0:00 ` Garbage colletion Lutz Donnerhacke 1999-11-01 0:00 ` Robert Dewar 2 siblings, 2 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <slrn81osi4.940.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > * Robert Dewar wrote: > >More accurately, he said that it would not be added unless > >there was significant customer demand -- there is none! > > This typ of reasoning is invalid, because a customer who > learned to deal with a missing feature clearly does not need > it afterwards. Well given the choice between implementing features that customers are actively asking for, and those that none of them are asking for, it is not hard to set priorities. Certainly we do implement features that we feel are important that are NOT on immediate want lists because we think that in the long run they will be useful, but I am afraid that at this point garbage collection does not get high on this priority list either (we regard further work on our integrated development environment for example to have much higher priority). Remember, that unlike most (but not all) the readers here, I know the garbage collected "world" very well, having, as I noted before been chairman of WG2.1 for many years, and having developed the GC algorithms for SPITBOL. Personally I would very much like to see someone develop a GC implementation for GNAT! Indeed, the most constructive thing would be for the GC advocates to spend their time doing that instead of trying to encourage "them" to do it :-) :-) Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Gnat IDE (was: Garbage colletion) 1999-11-01 0:00 ` Robert Dewar @ 1999-11-01 0:00 ` Ted Dennison 1999-11-01 0:00 ` Garbage colletion Lutz Donnerhacke 1 sibling, 0 replies; 92+ messages in thread From: Ted Dennison @ 1999-11-01 0:00 UTC (permalink / raw) In article <7vil9t$vmn$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <slrn81osi4.940.lutz@belenus.iks-jena.de>, > priority list either (we regard further work on our > integrated development environment for example to have > much higher priority). Interesting. I presume you would have portability as a major goal for your IDE. So what are you basing the graphical part off of? Perhaps TK, like was done for GDB/TK? Or are you taking the "Stallman" approach and doing the whole thing in Emacs? -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Gnat IDE (was: Garbage colletion) Ted Dennison @ 1999-11-01 0:00 ` Lutz Donnerhacke 1999-11-01 0:00 ` Robert Dewar 1 sibling, 1 reply; 92+ messages in thread From: Lutz Donnerhacke @ 1999-11-01 0:00 UTC (permalink / raw) * Robert Dewar wrote: >Well given the choice between implementing features that >customers are actively asking for, and those that none of >them are asking for, it is not hard to set priorities. Of course. >Remember, that unlike most (but not all) the readers here, I >know the garbage collected "world" very well, having, as I noted >before been chairman of WG2.1 for many years, and having >developed the GC algorithms for SPITBOL. Personally I would >very much like to see someone develop a GC implementation for >GNAT! As a well implemented storage type in order to include it into a 'required' appendix. >Indeed, the most constructive thing would be for the GC >advocates to spend their time doing that instead of trying to >encourage "them" to do it :-) :-) After learning Ada without GC most programmers learned to deal without it and have some problems to solve. So there is really no need for GC ;-) ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-11-01 0:00 ` Garbage colletion Lutz Donnerhacke @ 1999-11-01 0:00 ` Robert Dewar 1999-11-04 0:00 ` Didier Utheza 0 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <slrn81qgvs.mm.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > After learning Ada without GC most programmers learned to deal > without it and have some problems to solve. So there is really > no need for GC ;-) Well we agree more than you think here. I think if someone did a general GC for GNAT, there would be lots of people interested in it, and after all for many people, since GNAT is on pretty much all machines, they don't mind not being portable to non-GNAT compilers, so even if only GNAT did it, it would still get a lot of use. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-11-01 0:00 ` Robert Dewar @ 1999-11-04 0:00 ` Didier Utheza 1999-11-04 0:00 ` David Starner 0 siblings, 1 reply; 92+ messages in thread From: Didier Utheza @ 1999-11-04 0:00 UTC (permalink / raw) To: Robert Dewar Oberon for Linux is using a garbage collector developed in C. The people that created the compiler just interfaced the GC code to the Oberon compiler. The code is avalaible to the public, the biggest problem with Ada would be to reimplement the GC in native code in the logic of the compiler, but regarding stability, this GC has a good rating! Greeting. On Mon, 1 Nov 1999, Robert Dewar wrote: > In article <slrn81qgvs.mm.lutz@taranis.iks-jena.de>, > lutz@iks-jena.de (Lutz Donnerhacke) wrote: > > After learning Ada without GC most programmers learned to deal > > without it and have some problems to solve. So there is really > > no need for GC ;-) > > Well we agree more than you think here. I think if someone did > a general GC for GNAT, there would be lots of people interested > in it, and after all for many people, since GNAT is on pretty > much all machines, they don't mind not being portable to > non-GNAT compilers, so even if only GNAT did it, it would still > get a lot of use. > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > > ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-11-04 0:00 ` Didier Utheza @ 1999-11-04 0:00 ` David Starner 0 siblings, 0 replies; 92+ messages in thread From: David Starner @ 1999-11-04 0:00 UTC (permalink / raw) On Thu, 4 Nov 1999 15:38:22 -0500, Didier Utheza <ddutheza@bu.edu> wrote: >Oberon for Linux is using a garbage collector developed in C. The people >that created the compiler just interfaced the GC code to the Oberon >compiler. The code is avalaible to the public, the biggest problem with >Ada would be to reimplement the GC in native code in the logic of the >compiler, but regarding stability, this GC has a good rating! >Greeting. Considering how two other compilers based of GCC (gjc & gobjc) use it (the Boehm conservative collector), it probably will be the first compiler interfaced to GNAT. -- David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-10-31 0:00 ` Garbage colletion Lutz Donnerhacke 1999-11-01 0:00 ` Larry Kilgallen 1999-11-01 0:00 ` Robert Dewar @ 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Lutz Donnerhacke 2 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <slrn81osi4.940.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > * Robert Dewar wrote: > >More accurately, he said that it would not be added unless > >there was significant customer demand -- there is none! > > This typ of reasoning is invalid, because a customer who learned to deal > with a missing feature clearly does not need it afterwards. This is > especially true after all programming examples which required GC are deleted > from the hard disk. (Although they were smaller and easier to understand.) > > This is no cry for GC. Actually that last comment is a bit confusing, because the particular issue on which I made the comment you quote above was infinite precision integers :-) :-) Of course you can also claim the above reasoning is invalid for those as well, and indeed your general argument applies to absolutely any neat idea that anyone might have under any circumstance, but we need a better discriminator for priorities than this :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Garbage colletion 1999-11-01 0:00 ` Robert Dewar @ 1999-11-01 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 92+ messages in thread From: Lutz Donnerhacke @ 1999-11-01 0:00 UTC (permalink / raw) * Robert Dewar wrote: >Of course you can also claim the above reasoning is invalid for >those as well, and indeed your general argument applies to >absolutely any neat idea that anyone might have under any >circumstance, but we need a better discriminator for priorities >than this :-) No. It is only valid for problems which arise often enough to newusers. Those problems are common enough to be included in a FAQ. But the main argument against GC is, that real world problems would require to cancel GC ;-) ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Larry Kilgallen @ 1999-10-30 0:00 ` Lutz Donnerhacke 1999-10-30 0:00 ` Ammo-zilla Matthew Heaney 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 2 siblings, 1 reply; 92+ messages in thread From: Lutz Donnerhacke @ 1999-10-30 0:00 UTC (permalink / raw) * David Starner wrote: >If garbage collection is not mandated, however, then it can't be relied on in >Ada code that might run under systems that don't garbage collect - i.e. >portable Ada code can't use it. Hence either you deallocate any memory >yourself, or suffer garbage leaks while running under a non-garbage >collecting system. Almost all memory leaks I came across were caused in an internal handling routine or in returning a pointer to an object leaving the 'free' procedure to the user. Internal routines should define there own access type (and so a seperate allocation pool) and only use pointers of that type. If the access type definition goes out of scope, all objects in this pool can be freed without any need for complex garbage collection. IIUC Ada 95 enforces this. Returning a pointer to an uplevel scope is bad design. If tagged type are used (most cases, due to the well known abstract factory pattern), you can replace your code in almost all cases in the following way: package Factories is type Factory is private; type Object is tagged private; type Object_Ptr is access Object; function Make_A_Pointer_To_Object(f: in Factory) return Object_Ptr; ... end Factories; procedure Do_Something(aFactory: in Factory) an_Object_Ptr: Object_Ptr := Make_A_Pointer_To_Object(aFactory); begin ... Free(po); -- Don't forget it on all possible exits! exception when others => Free(po); -- Don't forget it on all exceptions! raise; -- Fire again. end Do_Something; by: package Factories is type Factory is private; type Object is tagged private; function Make_A_Class_Wide_Object(f: in Factory) return Object'Class; ... end Factories; procedure Do_Something(aFactory: in Factory) an_Object: Object'Class := Make_A_Class_Wide_Object(aFactory); begin ... end Do_Something; In the rare cases where real pointers must be returned to build up a larger dynamic structure the whole structure should be implemented as a seperate package providing a Controlled object. It took me several weeks to determine this. Thanks to the help of the group regulars. I hope I wrote not so much bullshit. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke @ 1999-10-30 0:00 ` Matthew Heaney 0 siblings, 0 replies; 92+ messages in thread From: Matthew Heaney @ 1999-10-30 0:00 UTC (permalink / raw) In article <slrn81mia6.uth.lutz@belenus.iks-jena.de> , lutz@iks-jena.de (Lutz Donnerhacke) wrote: > Returning a pointer to an uplevel scope is bad design. If tagged type are > used (most cases, due to the well known abstract factory pattern), you can > replace your code in almost all cases in the following way: [snipped] >by > package Factories is > type Factory is private; > type Object is tagged private; > function Make_A_Class_Wide_Object(f: in Factory) return Object'Class; > ... > end Factories; > > procedure Do_Something(aFactory: in Factory) > an_Object: Object'Class := Make_A_Class_Wide_Object(aFactory); > begin > ... > end Do_Something; This will work for only trivial cases, because type Object is nonlimited. It's *very* common in Ada95 to use access discriminants to compose abstractions, and this requires a limited type. In fact, I recommend that for doing class-wide programming, you use a limited and indefinite type, like this: package P is type T (<>) is abstract limited private; type T_Access is access all T'Class; <primitive ops takes access params> procedure Free (O : in out T_Access); end P; package P.C is type NT is new T with private; function New_NT (...) return T_Access; <override primitive ops> end P.C; Yes, this returns an access object. Yes, you have to manually call Free. Yes, it's possible to have memory leaks. But wait! You can use a smart pointer to do the memory reclamation automatically, with only a small amount of additional syntactic overhead. The modified packages look like this: package P is type T (<>) is abstract limited private; type T_Access is access all T'Class; <primitive ops takes access params> type T_Handle is private; -- Implemented as a private derivation from Controlled. function "+" (Handle : T_Handle) return T_Access; end P; package P.C is type NT is new T with private; function New_NT (...) return T_Handle; -- Constructor now returns a smart pointer, not raw access object. <override primitive ops> end P.C; I have discussed this issue several times in the Ada95 Design Patterns list, and there's an article (and several more examples) of how to implement a smart pointer. <http://www.acm.org/archives/patterns.html> > In the rare cases where real pointers must be returned to build up a larger > dynamic structure the whole structure should be implemented as a seperate > package providing a Controlled object. Consider using a smart pointer. > It took me several weeks to determine this. Thanks to the help of the group > regulars. I hope I wrote not so much bullshit. Another resource is the Ada95 Design Patterns mailing list. You can subscribe by sending the message (body) subscribe patterns <your full name> to the ACM mailing list server. <mailto:listserv@acm.org> -- Why stop at evolution and cosmology, though? Let's make sure that the schoolkids of Kansas get a really first-rate education by loosening up the teaching standards for other so-called scientific ideas that are, after all, just theories. The atomic theory, for example. The theory of relativity. Heck, the Copernican theory--do we really know that the universe doesn't revolve around the earth? John Rennie, Scientific American, Oct 1999 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Larry Kilgallen 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke @ 1999-10-31 0:00 ` Robert Dewar 2 siblings, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-10-31 0:00 UTC (permalink / raw) In article <7vadsp$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > Under the "as if" rule, C allows garbage collection, and I've > got a C compiler that compiles targetting the JVM. Yes, but the C language, unlike Ada, was not designed to facilitate garbage collection, so it is MUCH tricker to implement GC in C, especially if you really expect to accomodate the typical universe of existing C programs. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby 1999-10-28 0:00 ` Ammo-zilla David Starner @ 1999-10-28 0:00 ` Charles Hixson 1999-10-29 0:00 ` Ada and GC (Was Re: Ammo-zilla) Vladimir Olensky 1999-10-29 0:00 ` Ammo-zilla Robert I. Eachus 2 siblings, 1 reply; 92+ messages in thread From: Charles Hixson @ 1999-10-28 0:00 UTC (permalink / raw) Laurent Guerby wrote: > Quite the contrary, garbage collection is allowed (but not mandated) > by the language (see section 13.11.3 of the Ada 95 RM), and it's of > course available for Ada compilers targetting the JVM. > > --LG I acknowledge the fact. This, however, does not make it into a component of the language. To get it with the JVM one must take the JVM. This does have it's advantages, but it also has disadvantages. The JVM was designed with Java in mind, and no other language can reasonably expect to match it as well. (Even for Java, many folk have objected sufficiently that some companies have written compilers that take Java all the way to machine code...a formidable task!) Also, and speaking particularlly to the point of garbage collection, I would prefer a collector that one could invoke as needed, or at least one that was easy to stop and start. I believe that the gc calls within Java are "hints". ^ permalink raw reply [flat|nested] 92+ messages in thread
* Ada and GC (Was Re: Ammo-zilla) 1999-10-28 0:00 ` Ammo-zilla Charles Hixson @ 1999-10-29 0:00 ` Vladimir Olensky 1999-10-29 0:00 ` David Botton 0 siblings, 1 reply; 92+ messages in thread From: Vladimir Olensky @ 1999-10-29 0:00 UTC (permalink / raw) Charles Hixson wrote in message <3818D4F0.92FC4DC9@mail.earthlink.net>... > Also, and >speaking particularlly to the point of garbage collection, I would >prefer a collector that one could invoke as needed, or at least one that >was easy to stop and start. I believe that the gc calls within Java are >"hints". > Probably Modula-3 GC (exists for more than 10 years) is better "hint" regarding user control over GC. http://www.research.digital.com/SRC/m3sources/html/runtime/src/common/RTColl ector.i3.html http://www.research.digital.com/SRC/m3sources/html/runtime/src/common/RTColl ectorSRC.i3.html These references are also available from the Modula-3 Language definition page: http://www.research.digital.com/SRC/m3defn/html/m3.html There were some concerns that as GC in Ada is not mandatory and it's implementation is up to Ada vendors then using it would lead to loosing portability (compiling and using code originally written for system with GC on a system that does not have GC would lead to memory leaks). To avoid such situation Ada GC could be implemented not within the core system but as separate package. When it WITHed with the user program than it could be invoked for TRACED ACCESS TYPES. So on systems without GC that code just could not be compiled and used without necessary changes. In M3 references by default are traced and when one do not want to use GC with them they are marked as UNTRACED (http://www.research.digital.com/SRC/m3defn/html/refs.html) In Ada references by default are UNTRACED and could be set to TRACED to be handled by the attached (WITHed) GC. Such approach would provide compatibility with the existing Ada design and facilitate better Ada usage for general type applications (not embedded ,real-time and safety critical where unpredictable delays caused by GC are unacceptable). Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC (Was Re: Ammo-zilla) 1999-10-29 0:00 ` Ada and GC (Was Re: Ammo-zilla) Vladimir Olensky @ 1999-10-29 0:00 ` David Botton 1999-10-31 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 92+ messages in thread From: David Botton @ 1999-10-29 0:00 UTC (permalink / raw) I have found many times that GC can be unacceptable do to unpredictable delays even on non-embedded, real-time and safety critical systems. Go explain to a power user of large Java programs why they have to occasionally wait to regain usable control of the application do to GC crunching. (I believe this had a part in the demise of Corel's Java Office Suite. Applix just uses Java like an X terminal and does the real work off site.) David Botton Vladimir Olensky wrote in message ... (not embedded ,real-time and safety critical where >unpredictable >delays caused by GC are unacceptable). ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC (Was Re: Ammo-zilla) 1999-10-29 0:00 ` David Botton @ 1999-10-31 0:00 ` Vladimir Olensky 1999-10-30 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 92+ messages in thread From: Vladimir Olensky @ 1999-10-31 0:00 UTC (permalink / raw) David Botton wrote in message <7vc3v5$1888$1@news.gate.net>... >I have found many times that GC can be unacceptable do to unpredictable >delays even on non-embedded, real-time and safety critical systems. Go >explain to a power user of large Java programs why they have to occasionally >wait to regain usable control of the application do to GC crunching. (I >believe this had a part in the demise of Corel's Java Office Suite. Applix >just uses Java like an X terminal and does the real work off site.) That's why I wrote that Java GC is not a good "hint" for user controlled GC and M3 GC is much better in that respect. My view is that all objects by default should be UNTRACED. Only those objects that are subjected to GC should be marked as TRACED. This approach is opposite to what is done in Modula-3 but it gives full control to the programmer over GC and it also provides compatibility with the current Ada 95 implementations All the traced objects should be allocated in separate storage pool controlled by GC pool storage manager that could provide all needed operations for user to control GC process. I was pleased very much by the nice Tucker Taft post regarding this issue. Now I have a feeling that this issue has grown up and we may expect some progress in this area soon. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC (Was Re: Ammo-zilla) 1999-10-31 0:00 ` Vladimir Olensky @ 1999-10-30 0:00 ` Samuel T. Harris 1999-10-30 0:00 ` David Botton 0 siblings, 1 reply; 92+ messages in thread From: Samuel T. Harris @ 1999-10-30 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > > David Botton wrote in message <7vc3v5$1888$1@news.gate.net>... > >I have found many times that GC can be unacceptable do to unpredictable > >delays even on non-embedded, real-time and safety critical systems. Go > >explain to a power user of large Java programs why they have to > occasionally > >wait to regain usable control of the application do to GC crunching. (I > >believe this had a part in the demise of Corel's Java Office Suite. Applix > >just uses Java like an X terminal and does the real work off site.) > > That's why I wrote that Java GC is not a good "hint" for user controlled GC > and M3 GC is much better in that respect. > > My view is that all objects by default should be UNTRACED. > Only those objects that are subjected to GC should be marked > as TRACED. This approach is opposite to what is done in Modula-3 > but it gives full control to the programmer over GC and it also provides > compatibility with the current Ada 95 implementations > > All the traced objects should be allocated in separate storage pool > controlled > by GC pool storage manager that could provide all needed operations for user > to control GC process. Why not package up this GC as an Ada 95 storage pool and simply associate it to the access types which need GC? With the inclusion of the storage pool concept in Ada 95, I don't see this "to GC or not to GC" within Ada itself as being a _very_ important issue. > > I was pleased very much by the nice Tucker Taft post regarding this > issue. > Now I have a feeling that this issue has grown up and we may expect some > progress in this area soon. > > Regards, > Vladimir Olensky -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ada and GC (Was Re: Ammo-zilla) 1999-10-30 0:00 ` Samuel T. Harris @ 1999-10-30 0:00 ` David Botton 0 siblings, 0 replies; 92+ messages in thread From: David Botton @ 1999-10-30 0:00 UTC (permalink / raw) Sounds like a great group project for the Ada community :-) Perhaps some one should give a crack at starting the project. I'd be happy to put AdaPower at your service. David Botton Samuel T. Harris wrote in message <381B7AA0.65DDACE5@hso.link.com>... >Why not package up this GC as an Ada 95 storage pool and simply >associate >it to the access types which need GC? With the inclusion of the storage >pool >concept in Ada 95, I don't see this "to GC or not to GC" within Ada >itself >as being a _very_ important issue. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby 1999-10-28 0:00 ` Ammo-zilla David Starner 1999-10-28 0:00 ` Ammo-zilla Charles Hixson @ 1999-10-29 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 92+ messages in thread From: Robert I. Eachus @ 1999-10-29 0:00 UTC (permalink / raw) Laurent Guerby wrote: > Quite the contrary, garbage collection is allowed (but not mandated) > by the language (see section 13.11.3 of the Ada 95 RM), and it's of > course available for Ada compilers targetting the JVM. Actually there are some types for which it is mandated: "Implementation Requirements "No storage associated with an Unbounded_String object shall be lost upon assignment or scope exit." RM A.4.5(88) And those for which it is not recommended: "Implementation Advice "Bounded string objects should not be implemented by implicit pointers and dynamic allocation." However I think that one of the easiest and most needed language extensions is to have storage pools with reference counting and with garbage collection predefined. (Probably as generic children of Ada.Finalization.) The first is easily written in a portable manner, but doing GC right for arbitrary types requires compiler support/modifications. (There are various methods, but all require that access values for that storage pool contain more than a simple pointer.) You can create a storage pool with garbage collection semantics without compiler support, but it requires discipline on the part of the programmer. (For example, you create a handle type, and objects designated by handles are treated as referenced during GC, while pointers and 'Access do not cause an object to be recognized as in use.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby @ 1999-10-28 0:00 ` Tucker Taft 1999-10-31 0:00 ` Ammo-zilla Brian Rogoff 1999-10-28 0:00 ` Ammo-zilla Matthew Heaney 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 3 siblings, 1 reply; 92+ messages in thread From: Tucker Taft @ 1999-10-28 0:00 UTC (permalink / raw) Charles Hixson wrote: > > I am continually attracted to Ada, however: > The Ada approach to memory management reminds me of the PL/1 approach, > only simplified a bit. I suppose that you can say that it's better than > C++, but that's *REALLY* faint praise. There are a lot of details that > I don't fully understand, but this is one of Ada's weaker aspects. The > second is the syntax used in "object" declaration. Very clumsy. > > Now I *do* understand that the reason for this approach is (partially > the date of design but also) to allow statically linked programs to be > small enough for embedded systems, etc. And it is indeed necessary to > enable this. But the cost of a unified design of this nature is that, > e.g., garbage collection is eliminated from the language. (The syntax > is mainly due to early design.) I feel relativly certain that if the > language were to be designed today that many things would have been done > differently. That's an interesting question. I have on occasion since we finalized the Ada 95 design thought about how I might design a language if I could really start from scratch. After a huge amount of horsing around, I end up surprisingly close to where Ada 95 is now. For example, you mention the "clumsy" syntax associated with object declarations. It is interesting to note that Haskell, one of the more elegant functional programming languages out there, has essentially the identical object approach as Ada 95, as does CLOS, common lisp object system. If you are used to the notion of an abstract data type, defined by a type and a set of operations, and then you decide you want to support extensibility of abstract data types, then you end up at something very much like Ada 95, Haskell, or CLOS, with the "operation(operand, operand, ...)" or "operand <operator> operand" or "object := operation(operand, operand,...)" syntax familiar from theoretical mathematics and logic. If you instead focus on updating objects as the primary operations of interest, then you end up with the <obj>.<operation> syntax. In some ways, the Ada 95 syntax is more sympathetic with the "value-oriented" (i.e. functional) way of thinking than the "object-oriented" (i.e. side-effecting) way of thinking. The net effect, in any case, is that you can more easily write in a "functional" style in Ada 95 where there is less use of heap-resident read/write objects, and more use of values (rather than objects) of an abstract type being passed around, assigned, declared, etc. One interesting side note -- because Ada is a multi-tasking language, the objects that are designed to retain read/write global state need some kind of synchronization/protection. For such objects (tasks and protected objects), the object.operation(...) syntax is intentionally chosen, because there is clearly a special role played by the "target" task or protected object. By contrast, for value-oriented operations like set union, the symmetrical syntax of "union(set1, set2)" seems far more intuitive than "set1.union(set2)", and the symmetrical syntax is used for such operations in Ada. Speaking from experience of using Java, although the object.operation(...) syntax can be convenient sometimes, surprisingly often I find conceptual operations for which there are at least two conceptual operands, generally of different types/classes, that are just as appropriate (or perhaps, just as inappropriate) as the "prefix" operand in the object.operation(...) syntax. Generally, I suppose the distinction is between operations whose primary role is to update some operand (in which case, it makes sense to be identified specially), versus those operations that create some output given two or more inputs, in which case it is arbitrary which of the inputs ends up being put "out front" in the object.operation(...) syntax. As usual in all such discussions, your mileage may vary... > David Botton wrote: > > > > Now that's an interesting comment, because to me C++ and Ada > > > are identical in this particular department, can you explain > > > why you think Ada is better wrt memory leaks? > > > > As a result of the excellent design of Ada, I use far more static > > allocation then dynamic resulting in less chance of memory leaks. Of > > course once you start playing with the heap its all about personal > > programmer discipline. > > > > David Botton -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Tucker Taft @ 1999-10-31 0:00 ` Brian Rogoff 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 0 siblings, 1 reply; 92+ messages in thread From: Brian Rogoff @ 1999-10-31 0:00 UTC (permalink / raw) On Thu, 28 Oct 1999, Tucker Taft wrote: > Charles Hixson wrote: > > > > I am continually attracted to Ada, however: > > The Ada approach to memory management reminds me of the PL/1 approach, > > only simplified a bit. I suppose that you can say that it's better than > > C++, but that's *REALLY* faint praise. There are a lot of details that > > I don't fully understand, but this is one of Ada's weaker aspects. The > > second is the syntax used in "object" declaration. Very clumsy. > > > > Now I *do* understand that the reason for this approach is (partially > > the date of design but also) to allow statically linked programs to be > > small enough for embedded systems, etc. And it is indeed necessary to > > enable this. But the cost of a unified design of this nature is that, > > e.g., garbage collection is eliminated from the language. (The syntax > > is mainly due to early design.) I feel relativly certain that if the > > language were to be designed today that many things would have been done > > differently. > > That's an interesting question. I have on occasion since we finalized > the Ada 95 design thought about how I might design a language if I > could really start from scratch. After a huge amount of horsing around, > I end up surprisingly close to where Ada 95 is now. For example, > you mention the "clumsy" syntax associated with object declarations. > It is interesting to note that Haskell, one of the more elegant > functional programming languages out there, has essentially the > identical object approach as Ada 95, as does CLOS, common lisp object > system. Haskell doesn't support OOP, in particular, it doesn't support dynamic dispatch so I don't think the comaprison is appropriate. Besides Lisp derivatives like CLOS and Dylan, the only functional programming language I know of which supports OOP is Objective Caml. OCaml uses the distinguished receiver notation with "#" instead of ".". I prefer the Ada notation, but I don't think the notational choice is as big a deal as some people make it out to be. I think if you could design Ada from scratch you could use some more tokens like "[", "]", "{", and "}" instead of using parens for everything. > If you are used to the notion of an abstract data type, defined by a > type and a set of operations, and then you decide you want to support > extensibility of abstract data types, then you end up at something > very much like Ada 95, Haskell, or CLOS, with the > "operation(operand, operand, ...)" or "operand <operator> operand" > or "object := operation(operand, operand,...)" syntax familiar from > theoretical mathematics and logic. If you instead focus on > updating objects as the primary operations of interest, then you end up with > the <obj>.<operation> syntax. In some ways, the Ada 95 syntax is > more sympathetic with the "value-oriented" (i.e. functional) way > of thinking than the "object-oriented" (i.e. side-effecting) way > of thinking. The net effect, in any case, is that you can more easily > write in a "functional" style in Ada 95 where there is less use of > heap-resident read/write objects, and more use of values (rather than > objects) of an abstract type being passed around, assigned, declared, etc. Agreed. Since there is this contingent of functional programming devotees in the Ada community, perhaps we'll see anonymous access to subprogram types, downward closures via access to subprogram, and other FP tools in the next version of Ada :-). -- Brian ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-31 0:00 ` Ammo-zilla Brian Rogoff @ 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Ammo-zilla Brian Rogoff 1999-11-02 0:00 ` Ammo-zilla Robert A Duff 0 siblings, 2 replies; 92+ messages in thread From: Robert Dewar @ 1999-11-01 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9910311929570.12649-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > Haskell doesn't support OOP, in particular, it doesn't support > dynamic dispatch so I don't think the comaprison is > appropriate. I find it continually confusing that people confuse a programming paradigm (OOP) with some features in the language that are useful for supporting this paradigm. The point is of course that dynamic dispatching, type extension, and inheritance, are all generally useful features. They can be used for many things, only one of which is object oriented programming. In fact in my experience, the more common use is simply in making more flexible, reusable abstract data types (many people think they are doing OOP when they do this!) The dot notation and distinguished receiver notions are indeed useful when you are doing OOP, but they get in the way of many other uses of these features (in particular, modeling a dispatching addition operator in this way makes little sense, but there are lots of other answers). So the argument about notation is almost always off center, since on the one hand you have people who are concerned with one very specific use of the features, and on the other hand, you have people who see these features as much more general. The distinction between: Obj.Method1 (X); and Method1 (Obj, X); is basically a rather small syntactic distinction, and there is no issue of loss of expressive power. But if we go entirely to the first notation, then we will lose a lot of generality, generality that will be sorely missed by those of us who use these features all the time in non-OOP contexts. Note in particular that object oriented programming is all about objects which have state. But the basic capabilities (type extension, inheritance, dynamic dispatching) are equally (perhaps more) applicable to pure value oriented programming using conventional abstract data types. In this context, the notion of a distinguished receiver is a distraction if you are just talking about computing an output value from input values. Of course this point has been made many times before, and by many different people, in many different ways, but I have seen nothing stated that would begin to contradict the most useful viewpoint, as expressed above. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-01 0:00 ` Brian Rogoff 1999-11-02 0:00 ` Ammo-zilla Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Robert A Duff 1 sibling, 1 reply; 92+ messages in thread From: Brian Rogoff @ 1999-11-01 0:00 UTC (permalink / raw) On Mon, 1 Nov 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9910311929570.12649-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > Haskell doesn't support OOP, in particular, it doesn't support > > dynamic dispatch so I don't think the comaprison is > > appropriate. > > > I find it continually confusing that people confuse a > programming paradigm (OOP) with some features in the language > that are useful for supporting this paradigm. I'm not confusing anything. Since OOP, and Ada's function call notation are under discussion, comparisons with non-OOP languages are weak. I could just as well argue that since one can do OOP in C (and indeed, many people do!) that C's function call notation for OOP validates the Ada choice. That argument is more powerful too, since the number of C users outnumbers those of Haskell (and CLOS, and Ada combined :-) and stateful programming is more convenient in C than Haskell. No reasonable Haskell user will claim that the Haskell type system supports OOP well. Perhaps with existential types... -- Brian ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Brian Rogoff @ 1999-11-02 0:00 ` Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Brian Rogoff 0 siblings, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-11-02 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9911011726330.5772-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > I find it continually confusing that people confuse a > > programming paradigm (OOP) with some features in the language > > that are useful for supporting this paradigm. > > I'm not confusing anything. Since OOP, and Ada's function call > notation are under discussion, comparisons with non-OOP > languages are weak. To me there is no such thing as an OOP language, since OOP is not a language feature, it is a programming paradigm, which can of course be used in any language. One can certainly discuss the ease and convenience of using this paradigm in a particular language. And one can bias the language syntax to make this particular paradigm particularly convenient. But I think that is a mistake, since the fundamental notions of inheritance, dynamic dispatching, and type extension are far more powerful, and cover a much wider range of programming styles and approaches than simply OOP. If you specialize the syntax too much for OOP, then you will make these useful features much less available for other uses, and that is what has happened in several other languages. I particularly dislike the style of C++ programming where you write conventional abstract data types, with a functional and procedural style, and are then forced into the inappropriate dot notation for calling functions which have nothing whatsoever to do with objects or "distinguished receivers". Maybe my experience is atypical, but I see this kind of C++ program FAR more frequently than I see real object oriented programs (that does not surprise me, the notion of ADT's is to me far more general than the notion of objects). (of course the programmers of these C++ programs are actually under the illusion they are doing object oriented programming, because they are using the word class, and everyone knows that C++ is an "object oriented programming language".) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-02 0:00 ` Ammo-zilla Robert Dewar @ 1999-11-02 0:00 ` Brian Rogoff 0 siblings, 0 replies; 92+ messages in thread From: Brian Rogoff @ 1999-11-02 0:00 UTC (permalink / raw) On Tue, 2 Nov 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9911011726330.5772-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > > > I find it continually confusing that people confuse a > > > programming paradigm (OOP) with some features in the > language > > > that are useful for supporting this paradigm. > > > > I'm not confusing anything. Since OOP, and Ada's function call > > notation are under discussion, comparisons with non-OOP > > languages are weak. > > To me there is no such thing as an OOP language, since OOP is > not a language feature, it is a programming paradigm, which can > of course be used in any language. The fact that you think there is no such thing as an OOP language doesn't stop the many programmers from using the term. I think most people wouldn't put Haskell in that category. Similarly, there may be no such thing as a "functional programming language", but most people would use some criteria (presence of first class functions, lexical scope, ...) to determine membership in this class. This is way off topic, and actually, I agree with almost everything you wrote anyways... -- Brian ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ammo-zilla Brian Rogoff @ 1999-11-02 0:00 ` Robert A Duff 1 sibling, 0 replies; 92+ messages in thread From: Robert A Duff @ 1999-11-02 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > I find it continually confusing that people confuse a > programming paradigm (OOP) with some features in the language > that are useful for supporting this paradigm. I've seen so many conflicting definitions of "OOP" (and Object Oriented Anything Else), that I think the phrase is pretty useless at this point for conveying information other than marketting hype. ;-) Perhaps you should explain which definition you're using in this thread. - Bob ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby 1999-10-28 0:00 ` Ammo-zilla Tucker Taft @ 1999-10-28 0:00 ` Matthew Heaney 1999-10-28 0:00 ` Ammo-zilla mitch 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 3 siblings, 1 reply; 92+ messages in thread From: Matthew Heaney @ 1999-10-28 0:00 UTC (permalink / raw) In article <38189268.43EB150F@mail.earthlink.net> , Charles Hixson <charleshixsn@mail.earthlink.net> wrote: > The second is the syntax used in "object" declaration. Very clumsy. Huh? procedure Do_Something is I : Integer; begin I is an object. What's so "clumsy" about its declaration? > But the cost of a unified design of this nature is that, e.g., garbage > collection is eliminated from the language. (The syntax is mainly due to > early design.) Huh? Ada was carefully designed to allow an implementation to provide garbage collection. Garbage collection is not provided[1] by Ada compiler vendors because users have decided that they don't want it, not because the RM has "eliminated" it. [1] Excepting those implementations of the JVM, which *do* provide garbage collection. -- If we let the Creationists have their way, we may as well go whole hog. Let us reintroduce the flat-earth theory, the chemistry of the four elements, and mediaeval astrology. For these outworn doctrines have just as much claim to rival current scientific views as Creationism does to challenge evolutionary biology. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Matthew Heaney @ 1999-10-28 0:00 ` mitch 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney 0 siblings, 1 reply; 92+ messages in thread From: mitch @ 1999-10-28 0:00 UTC (permalink / raw) In article <3818bec3_4@news1.prserv.net>, "Matthew says... >> The second is the syntax used in "object" declaration. Very clumsy. > >Huh? > >procedure Do_Something is > I : Integer; >begin > >I is an object. What's so "clumsy" about its declaration? > I think he is talking about tagged object. any way, I did program in Java for more than 2 years now. And I still prefer the functional type of programming. I prefer to think of DATA first, then operations on DATA next. I like to see the structure of the data itself as the main focuse, then the operations on that data. So languages like Ada and pascal seem more natural to me, where ADT's and packages fit more with this style of thinking. In Java, where objects are everywhere, and where you have objects inside objects inside objects inside objects, for large complex application, I find that managing and maintaining this is harder than in a language where the Data itself is the center. I still believe in the old saying that a program = Data+Algorithms. or may be I am just getting too old :) mitch ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla mitch @ 1999-10-29 0:00 ` Matthew Heaney 0 siblings, 0 replies; 92+ messages in thread From: Matthew Heaney @ 1999-10-29 0:00 UTC (permalink / raw) In article <7vaie8$2p1@drn.newsguy.com> , mitch@nospam.com wrote: > In article <3818bec3_4@news1.prserv.net>, "Matthew says... > >>> The second is the syntax used in "object" declaration. Very clumsy. >> > >>Huh? >> >>procedure Do_Something is >> I : Integer; >>begin >> >>I is an object. What's so "clumsy" about its declaration? >> > > I think he is talking about tagged object. package P is type T is tagged private; <ops> end P; with P; use P; procedure Do_Something is O : T; begin T is a tagged type. O is a tagged object. What's the problem? -- The theory of evolution is quite rightly called the greatest unifying theory in biology. The diversity of organisms, similarities and differences between kinds of organisms, patterns of distribution and behavior, adaptation and interaction, all this was merely a bewildering chaos of facts until given meaning by the evolutionary theory. Populations, Species, and Evolution Ernst Mayr ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-28 0:00 ` Ammo-zilla Charles Hixson ` (2 preceding siblings ...) 1999-10-28 0:00 ` Ammo-zilla Matthew Heaney @ 1999-10-31 0:00 ` Robert Dewar 3 siblings, 0 replies; 92+ messages in thread From: Robert Dewar @ 1999-10-31 0:00 UTC (permalink / raw) In article <38189268.43EB150F@mail.earthlink.net>, Charles Hixson <charleshixsn@mail.earthlink.net> wrote: > I am continually attracted to Ada, however: > The Ada approach to memory management reminds me of the PL/1 > approach, only simplified a bit. I suspect you don't remember PL/1 storage management that well, because the comparison is inappropriate. PL/1 expected to have manual storage allocation, and the design was focussed in that area, and PL/1 is better than either Ada or C++ from this point of view, in particular with respect to the AREA management facilities. Yet another instance of the general rule "PL/1 is not as bad as people think it is" :-) > I suppose that you can say that it's better than > C++, but that's *REALLY* faint praise. There are a lot of > details that I don't fully understand, but this is one of > Ada's weaker aspects. Clearly you don't fully understand it if you say: > e.g., garbage collection is eliminated from the language. which of course is quite bogus. Indeed the design of Ada very much assumed that garbage collection would be implemented, and the design specifically allows for this. One of the reasons that Unchecked_Deallocation has the status it does is that the designers expected that GC would be generally used. Of course the language design does not REQUIRE garbage collection, and indeed it is rather hard to require this in a formal definition, because it is not really part of the formal semantics (storage allocation is part of the implementation semantics, not the language semantics). Basically a language "requires" GC by not providing any other alternative for manual deallocation (as in Algol-68). The issue of GC was most certainly discussed during the Ada 95 design. I tried indeed to insert a statement into the information systems annex saying that GC was required for that annex, but I got precisely ZERO support from anyone else even for that minor step. The issue in requiring GC is whether indeed it is practical to require GC in a language that is intended to be used in very high efficiency compiled environments, and in embedded realtime environments (remember that the two general purpose languages to have embraced GC, Algol-68 and Java, have not created a track record here, Java has yet to prove itself in these two respects). As to why GC has not in fact been implemented in the Ada world, with the exception of JVM based systems like GNAT-for-Java, the answer is very simple: lack of demand. For example at Ada Core Technologies, we get many customers wanting many enhancements, but GC has never shown up on the radar screen even as a minor pip in this set of requests. > The second is the syntax used in "object" declaration. Very > clumsy. Well anyone can find anything clumsy, but I must say this is very odd, why you would think that: x : int; is any less clumsy than int x; is peculiar to me! But perhaps you have your terminology wrong and don't really mean object declaration at all???? > Now I *do* understand that the reason for this approach Actually, as described above, you don't understand the reason for the design here, which is to be completely neutral on GC, and leave it as something that the implementation will provide if it is useful to do so. > I feel relativly certain that if the > language were to be designed today that many things would have > been done differently. You may feel certain, but in fact I think VERY little has changed that would have resulted in a change in design. The one area I can think of is the "with type". Indeed the ARG is now discussing possible language extensions, and what is interesting about this is that these are relatively few significant suggestions on the table. Certainly in the case of garbage collection there is nothing at all to discuss. No one in their right mind is proposing *removing* unchecked deallocation from the language, so the only issue is whether implementors will provide GC. The answer to that is simple, they will provide it if they see potential customers who want it enough to make the effort worth while. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner 1999-10-24 0:00 ` Ammo-zilla David Botton @ 1999-10-24 0:00 ` Matthew Heaney 2 siblings, 0 replies; 92+ messages in thread From: Matthew Heaney @ 1999-10-24 0:00 UTC (permalink / raw) In article <7uutgd$87h$1@nnrp1.deja.com> , Robert Dewar <robert_dewar@my-deja.com> wrote: >> that there's a lot of memory leaks in it, which Ada is a lot better for. > > > Now that's an interesting comment, because to me C++ and Ada > are identical in this particular department, can you explain > why you think Ada is better wrt memory leaks? I can't speak for the original poster, but perhaps one reason is that functions in Ada can return unconstrained array types, eliminating the need to heap use, and therefore eliminating a source of memory leaks. I agree with Robert, but I'd go further and say that here C++ is superior to Ada95, because you can implement true "smart pointers" (by overriding the dereference operator "->") that reclaim memory automatically. You can do something very similar in Ada95 though, by wrapping the raw access object in a Controlled type and using unary plus to return the value. For example: type Bool_Exp is abstract tagged limited private; type Bool_Exp_Access is access all Bool_Exp'Class; -- Here's the smart pointer type: type Exp_Handle is private; function "+" (Handle : Exp_Handle) return Bool_Exp_Access; The article "Smart Pointers", in the patterns archive, describes the technique. <http://www.acm.org/archives/patterns.html> (Use the search engine for find the word "smart" in the subject line.) Perhaps in a future version of the language controlled-ness (or some other form of garbage collection) can be applied to access types directly. For now, the smart pointer idiom isn't too much pain. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-23 0:00 Ammo-zilla Stanley R. Allen 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner @ 1999-10-24 0:00 ` Robert Dewar 1999-10-24 0:00 ` Ammo-zilla David Botton 1 sibling, 1 reply; 92+ messages in thread From: Robert Dewar @ 1999-10-24 0:00 UTC (permalink / raw) In article <38120FAF.945ADD7D@hso.link.com>, "Stanley R. Allen" <s_allen@hso.link.com> wrote: > > If anyone out there is struggling with their organization to retain > (or introduce) Ada as an alternative to C++, consider this: > > http://www.mozilla.org/hacking/portable-cpp.html > > Imagine what Ada's detractors would be saying if writing portable > Ada code was as restrictive as writing C++ code is these days! Don't use templates!!! A pretty amazing rule, note that it implies, don't use the STL. Of course part of this list just reflects the fact that C++ compilers are WAY behind Ada compilers in conforming to the standard, standard conformance just doesn't seem a very high priority in the C++ world. Still I agree, this is a VERY nice reference (definitely something to add to adapower :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Ammo-zilla 1999-10-24 0:00 ` Ammo-zilla Robert Dewar @ 1999-10-24 0:00 ` David Botton 0 siblings, 0 replies; 92+ messages in thread From: David Botton @ 1999-10-24 0:00 UTC (permalink / raw) Added at http://www.adapower.com/articles David Botton > Still I agree, this is a VERY nice reference (definitely > something to add to adapower :-) ^ permalink raw reply [flat|nested] 92+ messages in thread
end of thread, other threads:[~1999-11-12 0:00 UTC | newest] Thread overview: 92+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-10-23 0:00 Ammo-zilla Stanley R. Allen 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Aidan Skinner 1999-10-25 0:00 ` Ammo-zilla Jean-Pierre Rosen 1999-10-24 0:00 ` Ammo-zilla David Botton 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-28 0:00 ` Ammo-zilla Laurent Guerby 1999-10-28 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Larry Kilgallen 1999-10-29 0:00 ` Ammo-zilla David Starner 1999-10-29 0:00 ` Ammo-zilla Tucker Taft 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke 1999-10-29 0:00 ` Ammo-zilla David Botton 1999-10-29 0:00 ` Ammo-zilla mike 1999-10-29 0:00 ` Ammo-zilla David Botton 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Charles Hixson 1999-11-03 0:00 ` Ammo-zilla Wes Groleau 1999-11-01 0:00 ` Ammo-zilla Geoff Bull 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney 1999-10-29 0:00 ` Ammo-zilla Charles Hixson 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-31 0:00 ` Ammo-zilla David Starner 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ada and GC. Was: Ammo-zilla Vladimir Olensky 1999-11-01 0:00 ` Tucker Taft 1999-11-02 0:00 ` Vladimir Olensky 1999-11-02 0:00 ` Robert Dewar 1999-11-02 0:00 ` Charles Hixson 1999-11-03 0:00 ` Robert Dewar 1999-11-03 0:00 ` Charles Hixson 1999-11-01 0:00 ` Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ammo-zilla Robert A Duff 1999-11-01 0:00 ` Ammo-zilla Vladimir Olensky 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Robert A Duff 1999-11-02 0:00 ` Ammo-zilla Robert Dewar 1999-11-03 0:00 ` Ammo-zilla Vladimir Olensky 1999-11-03 0:00 ` Ammo-zilla Robert Dewar 1999-11-04 0:00 ` Ada GC (was Re: Ammo-zilla) Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar 1999-11-06 0:00 ` Vladimir Olensky 1999-11-06 0:00 ` Robert Dewar 1999-11-06 0:00 ` Vladimir Olensky 1999-11-09 0:00 ` Robert A Duff 1999-11-10 0:00 ` Vladimir Olensky 1999-11-10 0:00 ` Richard D Riehle 1999-11-10 0:00 ` Nick Roberts 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Robert I. Eachus 1999-11-12 0:00 ` Didier Utheza 1999-11-10 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert I. Eachus 1999-11-04 0:00 ` Ada GC (was Ammo-zilla) Nick Roberts 1999-11-04 0:00 ` Wes Groleau 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-31 0:00 ` Garbage colletion Lutz Donnerhacke 1999-11-01 0:00 ` Larry Kilgallen 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Gnat IDE (was: Garbage colletion) Ted Dennison 1999-11-01 0:00 ` Garbage colletion Lutz Donnerhacke 1999-11-01 0:00 ` Robert Dewar 1999-11-04 0:00 ` Didier Utheza 1999-11-04 0:00 ` David Starner 1999-11-01 0:00 ` Robert Dewar 1999-11-01 0:00 ` Lutz Donnerhacke 1999-10-30 0:00 ` Ammo-zilla Lutz Donnerhacke 1999-10-30 0:00 ` Ammo-zilla Matthew Heaney 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-28 0:00 ` Ammo-zilla Charles Hixson 1999-10-29 0:00 ` Ada and GC (Was Re: Ammo-zilla) Vladimir Olensky 1999-10-29 0:00 ` David Botton 1999-10-31 0:00 ` Vladimir Olensky 1999-10-30 0:00 ` Samuel T. Harris 1999-10-30 0:00 ` David Botton 1999-10-29 0:00 ` Ammo-zilla Robert I. Eachus 1999-10-28 0:00 ` Ammo-zilla Tucker Taft 1999-10-31 0:00 ` Ammo-zilla Brian Rogoff 1999-11-01 0:00 ` Ammo-zilla Robert Dewar 1999-11-01 0:00 ` Ammo-zilla Brian Rogoff 1999-11-02 0:00 ` Ammo-zilla Robert Dewar 1999-11-02 0:00 ` Ammo-zilla Brian Rogoff 1999-11-02 0:00 ` Ammo-zilla Robert A Duff 1999-10-28 0:00 ` Ammo-zilla Matthew Heaney 1999-10-28 0:00 ` Ammo-zilla mitch 1999-10-29 0:00 ` Ammo-zilla Matthew Heaney 1999-10-31 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla Matthew Heaney 1999-10-24 0:00 ` Ammo-zilla Robert Dewar 1999-10-24 0:00 ` Ammo-zilla David Botton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox