* memory management and productivity @ 2004-06-17 4:56 Russ 2004-06-17 5:15 ` tmoran 2004-06-17 8:07 ` Martin Dowie 0 siblings, 2 replies; 72+ messages in thread From: Russ @ 2004-06-17 4:56 UTC (permalink / raw) The following is an excerpt from an article featured on Slashdot today (6/16/04). The excerpted paragraph is not even the main topic of the article, but it made wonder what chance Ada has in the future without automatic memory management. It seems to me that garbage collection should be optional within the language. excerpt from http://www.joelonsoftware.com/articles/APIWar.html How Microsoft Lost the API War By Joel Spolsky ... A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised. The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically. It can be with reference counting or garbage collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of scripting languages. If your programming language allows you to grab a chunk of memory without thinking about how it's going to be released when you're done with it, you're using a managed-memory language, and you are going to be much more efficient than someone using a language in which you have to explicitly manage memory. Whenever you hear someone bragging about how productive their language is, they're probably getting most of that productivity from the automated memory management, even if they misattribute it. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-17 4:56 memory management and productivity Russ @ 2004-06-17 5:15 ` tmoran 2004-06-17 8:07 ` Martin Dowie 1 sibling, 0 replies; 72+ messages in thread From: tmoran @ 2004-06-17 5:15 UTC (permalink / raw) >If your programming language allows you to grab a >chunk of memory without thinking about how it's going to be released >when you're done with it, you're using a managed-memory language, and >you are going to be much more efficient than someone using a language >in which you have to explicitly manage memory. I guess Ada is a managed-memory language then, since I normally grab a chunk of memory without thinking about how it's going to be released. In fact I don't even think about whether the compiler might actually be doing a heap allocation with hidden pointer, or doing the stack allocation that appears to be happening. And when I use a Controlled type from some library, I let its Finalize do any memory worrying that's needed. Only on rare occasions do I explicitly do a "new" and have to remember to do a "Free". But I sincerely doubt anyway that memory management is the proverbial silver bullet. Yes, it's faster, as well as less buggy, to program in Ada, but it's still not a snap. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-17 4:56 memory management and productivity Russ 2004-06-17 5:15 ` tmoran @ 2004-06-17 8:07 ` Martin Dowie 2004-06-18 23:10 ` Russ 1 sibling, 1 reply; 72+ messages in thread From: Martin Dowie @ 2004-06-17 8:07 UTC (permalink / raw) "Russ" <18k11tm001@sneakemail.com> wrote in message news:bebbba07.0406162056.334745ed@posting.google.com... > The following is an excerpt from an article featured on Slashdot today > (6/16/04). The excerpted paragraph is not even the main topic of the > article, but it made wonder what chance Ada has in the future without > automatic memory management. It seems to me that garbage collection > should be optional within the language. You will be delighted to here that Ada already supports GC thought the use of Controlled types then. And if that weren't enough you can grap "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-17 8:07 ` Martin Dowie @ 2004-06-18 23:10 ` Russ 2004-06-19 9:04 ` Martin Dowie 0 siblings, 1 reply; 72+ messages in thread From: Russ @ 2004-06-18 23:10 UTC (permalink / raw) "Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:<40d15023$1_1@baen1673807.greenlnk.net>... > "Russ" <18k11tm001@sneakemail.com> wrote in message > news:bebbba07.0406162056.334745ed@posting.google.com... > > The following is an excerpt from an article featured on Slashdot today > > (6/16/04). The excerpted paragraph is not even the main topic of the > > article, but it made wonder what chance Ada has in the future without > > automatic memory management. It seems to me that garbage collection > > should be optional within the language. > > You will be delighted to here that Ada already supports GC thought the > use of Controlled types then. And if that weren't enough you can grap > "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. I am indeed delighted to hear that. And if Ada really has automatic memory management capabilities, more people need to know it. However, I am curious about why initialize and finalize are different and better than constructors and destructors in C++. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-18 23:10 ` Russ @ 2004-06-19 9:04 ` Martin Dowie 2004-06-21 4:16 ` Russ 0 siblings, 1 reply; 72+ messages in thread From: Martin Dowie @ 2004-06-19 9:04 UTC (permalink / raw) "Russ" <18k11tm001@sneakemail.com> wrote in message news:bebbba07.0406181510.37b8f5e2@posting.google.com... > > You will be delighted to here that Ada already supports GC thought the > > use of Controlled types then. And if that weren't enough you can grap > > "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. > > I am indeed delighted to hear that. And if Ada really has automatic > memory management capabilities, more people need to know it. Hopefully this thread will breath the life of publicity to this package then :-) > However, I am curious about why initialize and finalize are different > and better than constructors and destructors in C++. I never made such a claim. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-19 9:04 ` Martin Dowie @ 2004-06-21 4:16 ` Russ 2004-06-21 7:29 ` Jano ` (2 more replies) 0 siblings, 3 replies; 72+ messages in thread From: Russ @ 2004-06-21 4:16 UTC (permalink / raw) "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>... > "Russ" <18k11tm001@sneakemail.com> wrote in message > news:bebbba07.0406181510.37b8f5e2@posting.google.com... > > > You will be delighted to here that Ada already supports GC thought the > > > use of Controlled types then. And if that weren't enough you can grap > > > "Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. > > > > I am indeed delighted to hear that. And if Ada really has automatic > > memory management capabilities, more people need to know it. > > Hopefully this thread will breath the life of publicity to this package then > :-) > > > > However, I am curious about why initialize and finalize are different > > and better than constructors and destructors in C++. > > I never made such a claim. Well, if initialize and finalize are fundamentally no different than constructors and destructors, then I conclude that Ada does not have automated memory management any more than C++ has it. (I may be a bit slow, but I catch on eventually.) As for using a library that has memory management built in, that sounds great. I'd just feel a bit better about it if it were in a standard library that everyone agrees on and comes with the language, like STL in C++. Then you could honestly say that Ada has automated memory management built in. (And it would be better than Java's because it would be optional.) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 4:16 ` Russ @ 2004-06-21 7:29 ` Jano 2004-06-21 8:02 ` Martin Dowie ` (3 more replies) 2004-06-21 7:46 ` Martin Dowie 2004-06-21 8:23 ` Dmitry A. Kazakov 2 siblings, 4 replies; 72+ messages in thread From: Jano @ 2004-06-21 7:29 UTC (permalink / raw) Russ wrote: > "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>... > >>"Russ" <18k11tm001@sneakemail.com> wrote in message >>news:bebbba07.0406181510.37b8f5e2@posting.google.com... >> >>>>You will be delighted to here that Ada already supports GC thought the >>>>use of Controlled types then. And if that weren't enough you can grap >>>>"Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. >>> >>>I am indeed delighted to hear that. And if Ada really has automatic >>>memory management capabilities, more people need to know it. >> >>Hopefully this thread will breath the life of publicity to this package then >>:-) >> >> >> >>>However, I am curious about why initialize and finalize are different >>>and better than constructors and destructors in C++. >> >>I never made such a claim. > > > Well, if initialize and finalize are fundamentally no different than > constructors and destructors, then I conclude that Ada does not have > automated memory management any more than C++ has it. (I may be a bit > slow, but I catch on eventually.) It's been so many time since I did C++ that I may be wrong, correct me in that case. IIRC, in C++ you must destroy (delete?) the object to get the destructor called. So, even if you have a carefully built chain of destructors, if at some point you forget to destroy the root, you're leaking. In Ada, when an object goes out of scope (assuming it has been created in the stack and not with the "new" operator), it's automatically finished so you have one less thing to care about. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 7:29 ` Jano @ 2004-06-21 8:02 ` Martin Dowie 2004-06-21 8:22 ` Jano 2004-06-21 22:36 ` Brian May 2004-06-21 8:14 ` Ole-Hjalmar Kristensen ` (2 subsequent siblings) 3 siblings, 2 replies; 72+ messages in thread From: Martin Dowie @ 2004-06-21 8:02 UTC (permalink / raw) "Jano" <notelacreas@porfavor.no> wrote in message news:2jnh22F12nvieU2@uni-berlin.de... > It's been so many time since I did C++ that I may be wrong, correct me > in that case. > > IIRC, in C++ you must destroy (delete?) the object to get the destructor > called. So, even if you have a carefully built chain of destructors, if > at some point you forget to destroy the root, you're leaking. > > In Ada, when an object goes out of scope (assuming it has been created > in the stack and not with the "new" operator), it's automatically > finished so you have one less thing to care about. Not quite true! Try this... BTW Jano - are you ever going to make that announcement in cla? ;-) with Ada.Finalization; package Foo is type Bar is private; type Handle is access all Bar; type Reference is access constant Bar; function Default return Bar; private type Bar is new Ada.Finalization.Controlled with null record; procedure Initialize (B : in out Bar); procedure Finalize (B : in out Bar); end Foo; with Ada.Text_IO; use Ada.Text_IO; package body Foo is function Default return Bar is begin return (Ada.Finalization.Controlled with null record); end Default; procedure Finalize (B : in out Bar) is begin Put_Line ("Finalize"); end Finalize; procedure Initialize (B : in out Bar) is begin Put_Line ("Initialize"); end Initialize; end Foo; with Ada.Text_IO; use Ada.Text_IO; with Foo; procedure Wibble is B : Foo.Handle := new Foo.Bar; C : constant Foo.Reference := new Foo.Bar'(Foo.Default); begin Put_Line ("Wibble"); end Wibble; ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:02 ` Martin Dowie @ 2004-06-21 8:22 ` Jano 2004-06-21 9:07 ` Martin Dowie 2004-06-21 22:36 ` Brian May 1 sibling, 1 reply; 72+ messages in thread From: Jano @ 2004-06-21 8:22 UTC (permalink / raw) Martin Dowie wrote: > "Jano" <notelacreas@porfavor.no> wrote in message > news:2jnh22F12nvieU2@uni-berlin.de... > >>It's been so many time since I did C++ that I may be wrong, correct me >>in that case. >> >>IIRC, in C++ you must destroy (delete?) the object to get the destructor >>called. So, even if you have a carefully built chain of destructors, if >>at some point you forget to destroy the root, you're leaking. >> >>In Ada, when an object goes out of scope (assuming it has been created >>in the stack and not with the "new" operator), it's automatically >>finished so you have one less thing to care about. > I want to add that you also don't need to explicitly destroy object members, of course, since Finalize is called on them automagically... > Not quite true! Try this... I get this: Initialize Finalize Finalize Wibble Finalize Finalize and I'm impressed because I didn't knew these differences. I must however admit that I don't understand exactly what's happening and gvd sigfaults on me (w2000). Could you provide a short explanation please? > BTW Jano - are you ever going to make that announcement in cla? ;-) For the next release... if I get time to do it ;) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:22 ` Jano @ 2004-06-21 9:07 ` Martin Dowie 0 siblings, 0 replies; 72+ messages in thread From: Martin Dowie @ 2004-06-21 9:07 UTC (permalink / raw) "Jano" <notelacreas@porfavor.no> wrote in message news:2jnk5nF12uei1U1@uni-berlin.de... > > Not quite true! Try this... > > I get this: > > Initialize -- Initialize B > Finalize -- Finalize temporary (in ObjectAda you only get one of these... > Finalize -- Finalize temporary ...two temporaries on assignment) > Wibble > Finalize -- Finalize C > Finalize -- Finalize B Not you don't get a call to Initialize on an assignment to an "access constant" as you have to assign a value anyway. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:02 ` Martin Dowie 2004-06-21 8:22 ` Jano @ 2004-06-21 22:36 ` Brian May 2004-06-22 7:47 ` Martin Dowie 1 sibling, 1 reply; 72+ messages in thread From: Brian May @ 2004-06-21 22:36 UTC (permalink / raw) >>>>> "Martin" == Martin Dowie <martin.dowie@baesystems.com> writes: Martin> Not quite true! Try this... I think the finalize routine doesn't get called because the variable drops out of scope, it only gets finalized when the program exits. So you can't rely on this behavior unless your program was going to exit anyway. eg. change the Wibble function to: --- cut --- with Ada.Text_IO; use Ada.Text_IO; with Foo; procedure Wibble is procedure Wobble is B : Foo.Handle := new Foo.Bar; C : constant Foo.Reference := new Foo.Bar'(Foo.Default); begin Put_Line ("Wibble"); end Wobble; begin Wobble; Put_Line ("Wobble"); end Wibble; --- cut --- I get: --- cut --- Initialize Finalize Finalize Wibble Wobble Finalize Finalize --- cut --- Ada can't finalize B or C until the program exits, because these pointers might be duplicated to variables not in the same scope. When you use Free(...) you are telling the compiler that you guarantee this is not the case. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 22:36 ` Brian May @ 2004-06-22 7:47 ` Martin Dowie 0 siblings, 0 replies; 72+ messages in thread From: Martin Dowie @ 2004-06-22 7:47 UTC (permalink / raw) "Brian May" <bam@snoopy.apana.org.au> wrote in message news:sa4vfhkfshy.fsf@snoopy.apana.org.au... > I think the finalize routine doesn't get called because the variable > drops out of scope, it only gets finalized when the program exits. > > So you can't rely on this behavior unless your program was going to > exit anyway. You're absolutely right - but this is still different from C++ just not as different as I'd thought. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 7:29 ` Jano 2004-06-21 8:02 ` Martin Dowie @ 2004-06-21 8:14 ` Ole-Hjalmar Kristensen 2004-06-21 8:27 ` Jano ` (2 more replies) 2004-06-21 8:14 ` Martin Krischik 2004-06-21 17:51 ` Hyman Rosen 3 siblings, 3 replies; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-21 8:14 UTC (permalink / raw) Jano <notelacreas@porfavor.no> writes: > Russ wrote: > > "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<cb0vjl$8hp$1@sparta.btinternet.com>... > > > >>"Russ" <18k11tm001@sneakemail.com> wrote in message > >>news:bebbba07.0406181510.37b8f5e2@posting.google.com... > >> > >>>>You will be delighted to here that Ada already supports GC thought the > >>>>use of Controlled types then. And if that weren't enough you can grap > >>>>"Boehm-Demers-Weiser" GC from AdaCL @ http://adacl.sourceforge.net/. > >>> > >>>I am indeed delighted to hear that. And if Ada really has automatic > >>>memory management capabilities, more people need to know it. > >> > >>Hopefully this thread will breath the life of publicity to this package then > >>:-) > >> > >> > >> > >>>However, I am curious about why initialize and finalize are different > >>>and better than constructors and destructors in C++. > >> > >>I never made such a claim. > > Well, if initialize and finalize are fundamentally no different than > > constructors and destructors, then I conclude that Ada does not have > > automated memory management any more than C++ has it. (I may be a bit > > slow, but I catch on eventually.) > > It's been so many time since I did C++ that I may be wrong, correct me > in that case. > > IIRC, in C++ you must destroy (delete?) the object to get the > destructor called. So, even if you have a carefully built chain of > destructors, if at some point you forget to destroy the root, you're > leaking. Yes, *IF* it has been allocated with new. > > In Ada, when an object goes out of scope (assuming it has been created > in the stack and not with the "new" operator), it's automatically > finished so you have one less thing to care about. This is exactly the same as C++. I would say that Ada and C++ are more or less on equal footing when it comes to garbage collection in practice. -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:14 ` Ole-Hjalmar Kristensen @ 2004-06-21 8:27 ` Jano 2004-06-21 8:29 ` Martin Dowie 2004-06-21 16:31 ` Frank J. Lhota 2 siblings, 0 replies; 72+ messages in thread From: Jano @ 2004-06-21 8:27 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: >>IIRC, in C++ you must destroy (delete?) the object to get the >>destructor called. So, even if you have a carefully built chain of >>destructors, if at some point you forget to destroy the root, you're >>leaking. > > > Yes, *IF* it has been allocated with new. That's what I wasn't sure about. In java you're forced (right this time?) but in C++ I wasn't sure. But as others have noted, indefinite types and containers for them are a blessing. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:14 ` Ole-Hjalmar Kristensen 2004-06-21 8:27 ` Jano @ 2004-06-21 8:29 ` Martin Dowie 2004-06-22 7:53 ` Ole-Hjalmar Kristensen 2004-06-21 16:31 ` Frank J. Lhota 2 siblings, 1 reply; 72+ messages in thread From: Martin Dowie @ 2004-06-21 8:29 UTC (permalink / raw) "Ole-Hjalmar Kristensen" <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM... > > In Ada, when an object goes out of scope (assuming it has been created > > in the stack and not with the "new" operator), it's automatically > > finished so you have one less thing to care about. > > This is exactly the same as C++. I would say that Ada and C++ are > more or less on equal footing when it comes to garbage collection in > practice. No! Please try the example I posted - in Ada an access to a controlled object is automatically finalized - this is different (and better!) than C++. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:29 ` Martin Dowie @ 2004-06-22 7:53 ` Ole-Hjalmar Kristensen 2004-06-26 15:44 ` Robert I. Eachus 0 siblings, 1 reply; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-22 7:53 UTC (permalink / raw) >>>>> "MD" == Martin Dowie <martin.dowie@baesystems.com> writes: MD> "Ole-Hjalmar Kristensen" MD> <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message MD> news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM... >> > In Ada, when an object goes out of scope (assuming it has been created >> > in the stack and not with the "new" operator), it's automatically >> > finished so you have one less thing to care about. >> >> This is exactly the same as C++. I would say that Ada and C++ are >> more or less on equal footing when it comes to garbage collection in >> practice. MD> No! Please try the example I posted - in Ada an access to a controlled MD> object is automatically finalized - this is different (and better!) than MD> C++. MD> Cheers MD> -- Martin Well, perhaps, but what Jano described is exactly like C++. Doesn't the automatic finalization of an access to a controlled object happen only when the *type* goes out of scope? -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-22 7:53 ` Ole-Hjalmar Kristensen @ 2004-06-26 15:44 ` Robert I. Eachus 0 siblings, 0 replies; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 15:44 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > Well, perhaps, but what Jano described is exactly like C++. > Doesn't the automatic finalization of an access to a controlled > object happen only when the *type* goes out of scope? No, as Martin's program shows, finalization occurs when the object or the type can no longer be referenced, no matter how that happens. This means you have to be a bit careful in designing your Finalize procedure. It may be called several times on the same object in complex cases. (The rule is that controlled objects in Ada are always finalized at least once. If you think about a subprogram that is doing clean-up when an exception occurs, you can see why the choice is between at least once and almost always.) But writing Finalize so that it is okay to call it multiple times is usually easy enough to do. Deallocating an object sets the pointer to it to null, and doesn't complain if given a null pointer as an argument. -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:14 ` Ole-Hjalmar Kristensen 2004-06-21 8:27 ` Jano 2004-06-21 8:29 ` Martin Dowie @ 2004-06-21 16:31 ` Frank J. Lhota 2004-06-22 7:58 ` Ole-Hjalmar Kristensen 2 siblings, 1 reply; 72+ messages in thread From: Frank J. Lhota @ 2004-06-21 16:31 UTC (permalink / raw) "Ole-Hjalmar Kristensen" <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM... > > Russ wrote: > Yes, *IF* it has been allocated with new. In C++, all memory allocation / deallocation should be done using the new / delete operators. This is true even for pointers to classes that do not have constructors or destructors. This is because classes often have default constructor / destructor actions that need to be performed for the object to be usable. For example, if the class has any virtual methods, then "jump table" must be set up. Also, if any field / sub-field / sub-sub-field has a constructor / destructor, then this constructor / destructor cannot be ignored. The safe way to change the memory management algorithms for a given C++ class is to define new / delete operators for that class. This will permit the user-defined algorithms for allocation / deallocation to be used for the class without interfering with constructor / destructor actions. This is the C++ equivalent of the Ada "for Name'Storage_Pool use ...;" clause. > This is exactly the same as C++. I would say that Ada and C++ are > more or less on equal footing when it comes to garbage collection in > practice. I agree. It would be more accurate to say that in both Ada and C++, the tools are there to implement your types with GC. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 16:31 ` Frank J. Lhota @ 2004-06-22 7:58 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-22 7:58 UTC (permalink / raw) >>>>> "FJL" == Frank J Lhota <NOSPAM.lhota.adarose@verizon.net> writes: FJL> "Ole-Hjalmar Kristensen" FJL> <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message FJL> news:wvbrsmcp2uqd.fsf@europa1.Norway.Sun.COM... >> > Russ wrote: >> Yes, *IF* it has been allocated with new. FJL> In C++, all memory allocation / deallocation should be done using the new / FJL> delete operators. This is true even for pointers to classes that do not have FJL> constructors or destructors. This is because classes often have default FJL> constructor / destructor actions that need to be performed for the object to FJL> be usable. For example, if the class has any virtual methods, then "jump FJL> table" must be set up. Also, if any field / sub-field / sub-sub-field has a FJL> constructor / destructor, then this constructor / destructor cannot be FJL> ignored. Yes, I agree. I was thinking about stack-allocated objects, where the destructor is called automatically for you upon exit of the varaible's scope. FJL> The safe way to change the memory management algorithms for a given C++ FJL> class is to define new / delete operators for that class. This will permit FJL> the user-defined algorithms for allocation / deallocation to be used for the FJL> class without interfering with constructor / destructor actions. This is the FJL> C++ equivalent of the Ada "for Name'Storage_Pool use ...;" clause. >> This is exactly the same as C++. I would say that Ada and C++ are >> more or less on equal footing when it comes to garbage collection in >> practice. FJL> I agree. It would be more accurate to say that in both Ada and C++, the FJL> tools are there to implement your types with GC. Yes, that would be more accurate, although conservative collectors like Boehm's would probably work with both languages. -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 7:29 ` Jano 2004-06-21 8:02 ` Martin Dowie 2004-06-21 8:14 ` Ole-Hjalmar Kristensen @ 2004-06-21 8:14 ` Martin Krischik 2004-06-21 15:22 ` Hyman Rosen 2004-06-21 17:51 ` Hyman Rosen 3 siblings, 1 reply; 72+ messages in thread From: Martin Krischik @ 2004-06-21 8:14 UTC (permalink / raw) Jano wrote: > It's been so many time since I did C++ that I may be wrong, correct me > in that case. > > IIRC, in C++ you must destroy (delete?) the object to get the destructor > called. So, even if you have a carefully built chain of destructors, if > at some point you forget to destroy the root, you're leaking. > > In Ada, when an object goes out of scope (assuming it has been created > in the stack and not with the "new" operator), it's automatically > finished so you have one less thing to care about. It is the same in Ada as in C++. Both can create object on the heap on stack. The real difference is that Ada has indefinite objects and as a result far less object need to be created on the heap. For example C++ std::vector<> can't store polymorvic objects - Ada soon to come Ada.Containers.Indefinite_Vectors can. With Regards Martin Container Libraries with support for indefinite Object: Booch Components: http://adacl.sf.net Ada.Containers: http://charles.tigris.org. -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 8:14 ` Martin Krischik @ 2004-06-21 15:22 ` Hyman Rosen 2004-06-21 16:47 ` Martin Krischik 0 siblings, 1 reply; 72+ messages in thread From: Hyman Rosen @ 2004-06-21 15:22 UTC (permalink / raw) Martin Krischik wrote: > For example C++ std::vector<> can't store polymorvic objects - Ada soon to > come Ada.Containers.Indefinite_Vectors can. That seems like a neat trick, given that a vector is intended to work like an array, that is, to have a contiguous block of equal-sized objects. How is the container going to work? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 15:22 ` Hyman Rosen @ 2004-06-21 16:47 ` Martin Krischik 0 siblings, 0 replies; 72+ messages in thread From: Martin Krischik @ 2004-06-21 16:47 UTC (permalink / raw) Hyman Rosen wrote: > Martin Krischik wrote: >> For example C++ std::vector<> can't store polymorvic objects - Ada soon >> to come Ada.Containers.Indefinite_Vectors can. > > That seems like a neat trick, given that a vector is > intended to work like an array, > that is, to have a > contiguous block of equal-sized objects. It only has to work like it - internally it might be implemented differently i.E. using dynamic memory. > How is the > container going to work? The trick is that Ada can "clone ()" objects without: class Base { virtual Base* clone(); } That's because Ada knows (by hidden size attribute) how large any object is. Including polymorvic objects. Write any indefinite object to a Stream via 'Output and look at it with hex editor. In that respect Ada is even cooler then Java: You can serialise any object without a Serialiseable interface. So, the truth is that the object is copied into dynamic memory. However, you will never know about it. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 7:29 ` Jano ` (2 preceding siblings ...) 2004-06-21 8:14 ` Martin Krischik @ 2004-06-21 17:51 ` Hyman Rosen 2004-06-22 17:02 ` Pascal Obry 2004-06-26 15:54 ` Robert I. Eachus 3 siblings, 2 replies; 72+ messages in thread From: Hyman Rosen @ 2004-06-21 17:51 UTC (permalink / raw) Jano wrote: > correct me in that case. OK. > IIRC, in C++ you must destroy (delete?) the object to get the destructor > called. So, even if you have a carefully built chain of destructors, if > at some point you forget to destroy the root, you're leaking. > > In Ada, when an object goes out of scope (assuming it has been created > in the stack and not with the "new" operator), it's automatically > finished so you have one less thing to care about. Both in C++ and in Ada, a stack object is finalized/destructed automatically when its scope is exited. I believe, but I'm not sure, that in Ada if a pointer *type* (not a pointer object) goes out of scope, then all objects of that type are deallocated. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 17:51 ` Hyman Rosen @ 2004-06-22 17:02 ` Pascal Obry 2004-06-26 15:54 ` Robert I. Eachus 1 sibling, 0 replies; 72+ messages in thread From: Pascal Obry @ 2004-06-22 17:02 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > I believe, but I'm not sure, that in Ada if a pointer *type* (not > a pointer object) goes out of scope, then all objects of that type > are deallocated. Not sure but I think the above is right if the type has its own storage pool. To be checked though... Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 17:51 ` Hyman Rosen 2004-06-22 17:02 ` Pascal Obry @ 2004-06-26 15:54 ` Robert I. Eachus 1 sibling, 0 replies; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 15:54 UTC (permalink / raw) Hyman Rosen wrote: > I believe, but I'm not sure, that in Ada if a pointer *type* (not > a pointer object) goes out of scope, then all objects of that type > are deallocated. Hmmm, a better description is that if a type goes out of scope, all objects of that type are deallocated. If a storage pool goes out of scope, all objects in the pool are deallocated. If an access type goes out of scope though, nothing special happens. It is easiest to see this by thinking about: declare type Foo is private; Foob: Foo; procedure Fubar(F: in Foo) is type Bar is access all Foo B: Bar := F'access; begin null end; begin Fubar(Foob); end; Obviously you don't want Foob to be deallocated when Bar goes out of scope. B will be deallocated when Fubar returns, but that is because B goes out of scope, not Bar. -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 4:16 ` Russ 2004-06-21 7:29 ` Jano @ 2004-06-21 7:46 ` Martin Dowie 2004-06-21 19:03 ` Russ 2004-06-21 8:23 ` Dmitry A. Kazakov 2 siblings, 1 reply; 72+ messages in thread From: Martin Dowie @ 2004-06-21 7:46 UTC (permalink / raw) "Russ" <18k11tm001@sneakemail.com> wrote in message news:bebbba07.0406202016.1f15c133@posting.google.com... > Well, if initialize and finalize are fundamentally no different than > constructors and destructors, then I conclude that Ada does not have > automated memory management any more than C++ has it. (I may be a bit > slow, but I catch on eventually.) > > As for using a library that has memory management built in, that > sounds great. I'd just feel a bit better about it if it were in a > standard library that everyone agrees on and comes with the language, > like STL in C++. Then you could honestly say that Ada has automated > memory management built in. (And it would be better than Java's > because it would be optional.) Ada does not forbid an implementation for performing GC but there has been zero customer call for it. That's no too surprising - "Sorry, you can't apply brakes/launch missile/shutdown reactor as I'm busy garbage collecting." would not go done well. But for desktop apps or even business apps, it might well be appropriate. Cheers -- Martin ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 7:46 ` Martin Dowie @ 2004-06-21 19:03 ` Russ 2004-06-22 2:39 ` David Starner ` (3 more replies) 0 siblings, 4 replies; 72+ messages in thread From: Russ @ 2004-06-21 19:03 UTC (permalink / raw) "Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:<40d69121$1_1@baen1673807.greenlnk.net>... > "Russ" <18k11tm001@sneakemail.com> wrote in message > news:bebbba07.0406202016.1f15c133@posting.google.com... > > Well, if initialize and finalize are fundamentally no different than > > constructors and destructors, then I conclude that Ada does not have > > automated memory management any more than C++ has it. (I may be a bit > > slow, but I catch on eventually.) > > > > As for using a library that has memory management built in, that > > sounds great. I'd just feel a bit better about it if it were in a > > standard library that everyone agrees on and comes with the language, > > like STL in C++. Then you could honestly say that Ada has automated > > memory management built in. (And it would be better than Java's > > because it would be optional.) > > Ada does not forbid an implementation for performing GC but there > has been zero customer call for it. That's no too surprising - "Sorry, you > can't apply brakes/launch missile/shutdown reactor as I'm busy garbage > collecting." would not go done well. Are you saying that an Ada compiler can implement GC or not? That seems a bit inconsistent to me. How can the same language have it both ways? What if someone tries to port an Ada application that has its own memory management to an Ada compiler that already has it by default? I would think you would at least want it controlled by a compilation flag or some something. > But for desktop apps or even business apps, it might well be appropriate. Which is why it should be under control of the application developer, it seems to me. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 19:03 ` Russ @ 2004-06-22 2:39 ` David Starner 2004-06-22 8:03 ` Ole-Hjalmar Kristensen 2004-06-22 6:09 ` Martin Krischik ` (2 subsequent siblings) 3 siblings, 1 reply; 72+ messages in thread From: David Starner @ 2004-06-22 2:39 UTC (permalink / raw) On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote: > Are you saying that an Ada compiler can implement GC or not? That > seems a bit inconsistent to me. How can the same language have it both > ways? Every language has it both ways. You could link the Boehm-Weiser garbage collector into a C program without any change to the source outside a couple defines on the command line. A Lisp interpreter could choose not to garbage collect memory. Like interpretation, GC is more a feature of choices and tradition than an enforced standard. The advantage of Ada is that the strong typing makes it possible for an advanced GC to find pointers and adjust them when moving things in memory. Ada also makes many of the small, temporary memory uses found in C unnecessary by allowing you to pass things by reference and to pass arrays. > What if someone tries to port an Ada application that has its > own memory management to an Ada compiler that already has it by > default? It depends on the code and on the GC system. If you depend on the details of memory management, then you depend on the details of memory management. If it's pure Ada, it should work; if it's not, it might not work. In any case, well-designed memory management systems are usually easy to pull out or at least write a dummy replacement for. > Which is why it should be under control of the application developer, > it seems to me. But it is. The application developer chooses which compiler to use and which flags to compile it with. If you're compiling for a LISP machine or a JVM, you probably don't have a choice whether or not to use GC. As the only Ada compilers with built-in GC right now are those which compile to the JVM, they don't offer a choice. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-22 2:39 ` David Starner @ 2004-06-22 8:03 ` Ole-Hjalmar Kristensen 2004-06-23 4:41 ` Russ 0 siblings, 1 reply; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-22 8:03 UTC (permalink / raw) >>>>> "DS" == David Starner <dvdeug@email.ro> writes: DS> On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote: >> Are you saying that an Ada compiler can implement GC or not? That >> seems a bit inconsistent to me. How can the same language have it both >> ways? DS> Every language has it both ways. You could link the Boehm-Weiser garbage DS> collector into a C program without any change to the source outside a DS> couple defines on the command line. A Lisp interpreter could choose not to DS> garbage collect memory. Like interpretation, GC is more a feature of DS> choices and tradition than an enforced standard. But the only language which I have used so far which got it quite right IMHO is Modula-3. The programmer is free to choose, and the language guarantees that GC is available. <snip> -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-22 8:03 ` Ole-Hjalmar Kristensen @ 2004-06-23 4:41 ` Russ 2004-06-23 7:41 ` Martin Dowie 2004-06-23 13:11 ` Larry Kilgallen 0 siblings, 2 replies; 72+ messages in thread From: Russ @ 2004-06-23 4:41 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrr7s8qatj.fsf@sun.com>... > >>>>> "DS" == David Starner <dvdeug@email.ro> writes: > > DS> On Mon, 21 Jun 2004 12:03:55 -0700, Russ wrote: > >> Are you saying that an Ada compiler can implement GC or not? That > >> seems a bit inconsistent to me. How can the same language have it both > >> ways? > > DS> Every language has it both ways. You could link the Boehm-Weiser garbage > DS> collector into a C program without any change to the source outside a > DS> couple defines on the command line. A Lisp interpreter could choose not to > DS> garbage collect memory. Like interpretation, GC is more a feature of > DS> choices and tradition than an enforced standard. > > But the only language which I have used so far which got it quite > right IMHO is Modula-3. The programmer is free to choose, and the > language guarantees that GC is available. Bingo. That's exactly what Ada should have. And it shouldn't take a rocket scientist to figure that out. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 4:41 ` Russ @ 2004-06-23 7:41 ` Martin Dowie 2004-06-23 17:36 ` Björn Persson 2004-06-23 13:11 ` Larry Kilgallen 1 sibling, 1 reply; 72+ messages in thread From: Martin Dowie @ 2004-06-23 7:41 UTC (permalink / raw) "Russ" <18k11tm001@sneakemail.com> wrote in message news:bebbba07.0406222041.593ab7c3@posting.google.com... > > But the only language which I have used so far which got it quite > > right IMHO is Modula-3. The programmer is free to choose, and the > > language guarantees that GC is available. > > Bingo. That's exactly what Ada should have. And it shouldn't take a > rocket scientist to figure that out. We could start the ball rolling on getting the AdaCL garbage collector into Ada1X! :-) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 7:41 ` Martin Dowie @ 2004-06-23 17:36 ` Björn Persson 2004-06-23 22:06 ` David Starner 2004-06-23 23:02 ` Russ 0 siblings, 2 replies; 72+ messages in thread From: Björn Persson @ 2004-06-23 17:36 UTC (permalink / raw) Martin Dowie wrote: > "Russ" <18k11tm001@sneakemail.com> wrote in message > news:bebbba07.0406222041.593ab7c3@posting.google.com... > >>>But the only language which I have used so far which got it quite >>>right IMHO is Modula-3. The programmer is free to choose, and the >>>language guarantees that GC is available. >> >>Bingo. That's exactly what Ada should have. And it shouldn't take a >>rocket scientist to figure that out. > > We could start the ball rolling on getting the AdaCL garbage collector into > Ada1X! :-) Could someone enlighten me a little on the mysteries of garbage? Since a garbage collector can apparently be compiled in as a library, why isn't that good enough? Is it a great advantage to have it provided by the compiler instead? -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 17:36 ` Björn Persson @ 2004-06-23 22:06 ` David Starner 2004-06-24 0:34 ` Björn Persson 2004-06-23 23:02 ` Russ 1 sibling, 1 reply; 72+ messages in thread From: David Starner @ 2004-06-23 22:06 UTC (permalink / raw) On Wed, 23 Jun 2004 17:36:23 +0000, Bj�rn Persson wrote: > Could someone enlighten me a little on the mysteries of garbage? > > Since a garbage collector can apparently be compiled in as a library, > why isn't that good enough? Is it a great advantage to have it provided > by the compiler instead? The only library garbage collectors I know about are conservative; they assume that every pointer-size chunk of accessible memory is a pointer, (unless it's in a block of data that was allocated with a special function that tells the GC there are no pointers in that data.) They don't move memory because you can't adjust pointers if you can't tell pointers from integers. A garbage collector that was part of the compiler could tell integers from pointers (that is, be a precise collector instead of a conservative collector) and could move items in memory (which many high-performance GCs do.) This makes easier, for example, for a compiler to scan only the new stuff, which has a shorter live time than the stuff the program has kept around for a while. The first may be more important; a misplaced integer could potentially hold several megabytes of garbage in memory. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 22:06 ` David Starner @ 2004-06-24 0:34 ` Björn Persson 2004-06-24 6:45 ` Martin Krischik 0 siblings, 1 reply; 72+ messages in thread From: Björn Persson @ 2004-06-24 0:34 UTC (permalink / raw) David Starner wrote: > The only library garbage collectors I know about are conservative; they > assume that every pointer-size chunk of accessible memory is a pointer, > (unless it's in a block of data that was allocated with a special function > that tells the GC there are no pointers in that data.) They don't move > memory because you can't adjust pointers if you can't tell pointers from > integers. A garbage collector that was part of the compiler could tell > integers from pointers (that is, be a precise collector instead of a > conservative collector) and could move items in memory (which many > high-performance GCs do.) This makes easier, for example, for a compiler > to scan only the new stuff, which has a shorter live time than the stuff > the program has kept around for a while. The first may be more important; > a misplaced integer could potentially hold several megabytes of garbage in > memory. I see. For a language like Ada, something that can't tell a pointer from an integer clearly isn't as good as it could be. I knew there had to be some drawback with a garbage collector that works for C. :-) -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 0:34 ` Björn Persson @ 2004-06-24 6:45 ` Martin Krischik 2004-06-24 10:27 ` Wes Groleau 0 siblings, 1 reply; 72+ messages in thread From: Martin Krischik @ 2004-06-24 6:45 UTC (permalink / raw) Bjï¿œrn Persson wrote: > David Starner wrote: > >> The only library garbage collectors I know about are conservative; they >> assume that every pointer-size chunk of accessible memory is a pointer, >> (unless it's in a block of data that was allocated with a special >> function that tells the GC there are no pointers in that data.) They >> don't move memory because you can't adjust pointers if you can't tell >> pointers from integers. A garbage collector that was part of the compiler >> could tell integers from pointers (that is, be a precise collector >> instead of a conservative collector) and could move items in memory >> (which many high-performance GCs do.) This makes easier, for example, for >> a compiler to scan only the new stuff, which has a shorter live time than >> the stuff the program has kept around for a while. The first may be more >> important; a misplaced integer could potentially hold several megabytes >> of garbage in memory. > > I see. For a language like Ada, something that can't tell a pointer from > an integer clearly isn't as good as it could be. I knew there had to be > some drawback with a garbage collector that works for C. :-) BTW: In an Ada dialect with a precise collector Unchecked_Convertion between Access and Address/Integer are likely not to work any more. And if you use Unchecked_Deallocation you need to use pragma Controlled as well. Both of which will break existing code :-(. Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 6:45 ` Martin Krischik @ 2004-06-24 10:27 ` Wes Groleau 0 siblings, 0 replies; 72+ messages in thread From: Wes Groleau @ 2004-06-24 10:27 UTC (permalink / raw) Martin Krischik wrote: > BTW: In an Ada dialect with a precise collector Unchecked_Convertion between > Access and Address/Integer are likely not to work any more. Never did work very well--at least not portably. There is no requirement for an access type to actually be the address of the object. Interesting bugs when some C person makes that assumption, and luckily it works. Then two years later, he/she is gone and you change compilers..... -- Wes Groleau A pessimist says the glass is half empty. An optimist says the glass is half full. An engineer says somebody made the glass twice as big as it needed to be. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 17:36 ` Björn Persson 2004-06-23 22:06 ` David Starner @ 2004-06-23 23:02 ` Russ 2004-06-26 16:16 ` Robert I. Eachus 1 sibling, 1 reply; 72+ messages in thread From: Russ @ 2004-06-23 23:02 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<rcjCc.96718$dP1.318279@newsc.telia.net>... > Martin Dowie wrote: > > > "Russ" <18k11tm001@sneakemail.com> wrote in message > > news:bebbba07.0406222041.593ab7c3@posting.google.com... > > > >>>But the only language which I have used so far which got it quite > >>>right IMHO is Modula-3. The programmer is free to choose, and the > >>>language guarantees that GC is available. > >> > >>Bingo. That's exactly what Ada should have. And it shouldn't take a > >>rocket scientist to figure that out. > > > > We could start the ball rolling on getting the AdaCL garbage collector > into > > Ada1X! :-) > > Could someone enlighten me a little on the mysteries of garbage? > > Since a garbage collector can apparently be compiled in as a library, > why isn't that good enough? Is it a great advantage to have it provided > by the compiler instead? Having it as a library is fine with me -- as long as the library is *standard* and available with every Ada compiler (or at least the main free one). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 23:02 ` Russ @ 2004-06-26 16:16 ` Robert I. Eachus 0 siblings, 0 replies; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 16:16 UTC (permalink / raw) Russ wrote: > Having it as a library is fine with me -- as long as the library is > *standard* and available with every Ada compiler (or at least the main > free one). If you want, I write you a generic library for Ada 95 that does garbage collection. All you need to do is wrap Ada.Strings.Unbounded_String in a generic along with Unchecked_Conversion. I've never bothered to do it because the cases where I used the technique, it was better to have a non-generic binding. (Slices of arrays created as intermediate values. Slicing two dimensional arrays was most of the work, not the garbage management.) Incidently, the 'fragile' part of that code is not the garbage collection, it is deciding what the lifetime of a particular slice needs to be. If you make the lifetime too short, you either have code that won't compile or get an exception during testing. If you make the scope too long, you run out of storage. (And yes, the liftime of the object is determined by where it is declared, it is getting those declarations in the right place that is difficult.) -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 4:41 ` Russ 2004-06-23 7:41 ` Martin Dowie @ 2004-06-23 13:11 ` Larry Kilgallen 2004-06-23 17:21 ` Björn Persson ` (5 more replies) 1 sibling, 6 replies; 72+ messages in thread From: Larry Kilgallen @ 2004-06-23 13:11 UTC (permalink / raw) In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > Bingo. That's exactly what Ada should have. And it shouldn't take a > rocket scientist to figure that out. ACT says they have not really seen market demand from their customers, and some of them are presumably rocket scientists. Absent customer demand, there seems no justification for a _requirement_ since Ada already has a _permission_. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 13:11 ` Larry Kilgallen @ 2004-06-23 17:21 ` Björn Persson 2004-06-24 7:35 ` Ole-Hjalmar Kristensen 2004-06-23 18:18 ` Russ ` (4 subsequent siblings) 5 siblings, 1 reply; 72+ messages in thread From: Björn Persson @ 2004-06-23 17:21 UTC (permalink / raw) Larry Kilgallen wrote: > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > >>Bingo. That's exactly what Ada should have. And it shouldn't take a >>rocket scientist to figure that out. > > ACT says they have not really seen market demand from their customers, > and some of them are presumably rocket scientists. Well, I'd think rocket scientists don't want garbage collection. Their programs are real-time systems. Developers of desktop applications are more likely to want garbage collection, but very few of them use Ada, and of those who do, probably very few can afford support contracts from ACT. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 17:21 ` Björn Persson @ 2004-06-24 7:35 ` Ole-Hjalmar Kristensen 2004-06-26 17:10 ` Simon Wright 0 siblings, 1 reply; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-24 7:35 UTC (permalink / raw) >>>>> "BP" == Bj�rn Persson <spam-away@nowhere.nil> writes: BP> Larry Kilgallen wrote: >> In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: >> >>> Bingo. That's exactly what Ada should have. And it shouldn't take a >>> rocket scientist to figure that out. >> ACT says they have not really seen market demand from their >> customers, >> and some of them are presumably rocket scientists. BP> Well, I'd think rocket scientists don't want garbage collection. Their BP> programs are real-time systems. In that case, you do not want any dynamic allocation whatsoever, so the availability of garbage collection is not important. On the other hand, *IF* you can live with dynamic allocation, there are garbage collection algorithms which will give hard real-time performance, provided you have an upper bound on the size of your objects. Baker's treadmill, the incremental copying collector, and reference-counting schemes can all do this with a very slight loss of generality. BP> Developers of desktop applications are more likely to want garbage BP> collection, but very few of them use Ada, and of those who do, BP> probably very few can afford support contracts from ACT. BP> -- BP> Bj�rn Persson PGP key A88682FD BP> omb jor ers @sv ge. BP> r o.b n.p son eri nu -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 7:35 ` Ole-Hjalmar Kristensen @ 2004-06-26 17:10 ` Simon Wright 0 siblings, 0 replies; 72+ messages in thread From: Simon Wright @ 2004-06-26 17:10 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> writes: > >>>>> "BP" == Bj�rn Persson <spam-away@nowhere.nil> writes: > BP> Well, I'd think rocket scientists don't want garbage > BP> collection. Their programs are real-time systems. > > In that case, you do not want any dynamic allocation whatsoever, so > the availability of garbage collection is not important. Depends what you mean by "dynamic allocation". I see nothing wrong with using dynamic allocation so long as the storage pool used behaves appropriately for the requirement. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 13:11 ` Larry Kilgallen 2004-06-23 17:21 ` Björn Persson @ 2004-06-23 18:18 ` Russ 2004-06-23 23:18 ` David Starner 2004-06-23 22:15 ` Larry Kilgallen ` (3 subsequent siblings) 5 siblings, 1 reply; 72+ messages in thread From: Russ @ 2004-06-23 18:18 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<qc2e5zFQJM1y@eisner.encompasserve.org>... > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > Bingo. That's exactly what Ada should have. And it shouldn't take a > > rocket scientist to figure that out. > > ACT says they have not really seen market demand from their customers, > and some of them are presumably rocket scientists. > > Absent customer demand, there seems no justification for a _requirement_ > since Ada already has a _permission_. The rocket scientists probably don't need or want automated memory management for their real-time applications, but desktop application developers probably do. Why not make them both happy? Oh, the desktop developers are not "demanding" it? Of course they aren't, because they aren't using Ada in the first place. And why aren't they using Ada? Perhaps in part because it doesn't have GC. Why wait for your current customers to "demand" something before adding a basic feature that could turn *potential* customers into *actual* customers? I'm afraid that such short-sighted views will only perpetuate the demise of Ada. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 18:18 ` Russ @ 2004-06-23 23:18 ` David Starner 0 siblings, 0 replies; 72+ messages in thread From: David Starner @ 2004-06-23 23:18 UTC (permalink / raw) On Wed, 23 Jun 2004 11:18:09 -0700, Russ wrote: > Oh, the desktop developers are not "demanding" it? Of course they > aren't, because they aren't using Ada in the first place. And why > aren't they using Ada? Perhaps in part because it doesn't have GC. So instead they use ... C++. Ada is not going to make a dent in Perl, Python, or Lisp(s), because they aren't designed for the same types of jobs. As for Java, ACT produced a version of GNAT (JGNAT) that compiled to the JVM (and thus was GCed). They found no (few?) takers, and stopped supporting it. GC just ain't going to get a bunch of programmers using Ada. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 13:11 ` Larry Kilgallen 2004-06-23 17:21 ` Björn Persson 2004-06-23 18:18 ` Russ @ 2004-06-23 22:15 ` Larry Kilgallen [not found] ` <bebbba07.0406231018.21Organization: LJK Software <IKJODEu6UfVI@eisner.encompasserve.org> ` (2 subsequent siblings) 5 siblings, 0 replies; 72+ messages in thread From: Larry Kilgallen @ 2004-06-23 22:15 UTC (permalink / raw) In article <bebbba07.0406231018.21d042db@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > The rocket scientists probably don't need or want automated memory > management for their real-time applications, but desktop application > developers probably do. Why not make them both happy? > > Oh, the desktop developers are not "demanding" it? Of course they > aren't, because they aren't using Ada in the first place. And why > aren't they using Ada? Perhaps in part because it doesn't have GC. They are off using Smalltalk ? Why would they be using that rather than using the "build it yourself" form of garbage collection discussed here, all the time complaining that it was not built in. > Why wait for your current customers to "demand" something before > adding a basic feature that could turn *potential* customers into > *actual* customers? I'm afraid that such short-sighted views will only > perpetuate the demise of Ada. I have the feeling you don't have experience in marketing or overall company finance. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <bebbba07.0406231018.21Organization: LJK Software <IKJODEu6UfVI@eisner.encompasserve.org>]
* Re: memory management and productivity [not found] ` <bebbba07.0406231018.21Organization: LJK Software <IKJODEu6UfVI@eisner.encompasserve.org> @ 2004-06-24 6:40 ` Russ 2004-06-26 16:33 ` Robert I. Eachus 0 siblings, 1 reply; 72+ messages in thread From: Russ @ 2004-06-24 6:40 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<IKJODEu6UfVI@eisner.encompasserve.org>... > In article <bebbba07.0406231018.21d042db@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > The rocket scientists probably don't need or want automated memory > > management for their real-time applications, but desktop application > > developers probably do. Why not make them both happy? > > > > Oh, the desktop developers are not "demanding" it? Of course they > > aren't, because they aren't using Ada in the first place. And why > > aren't they using Ada? Perhaps in part because it doesn't have GC. > > They are off using Smalltalk ? > > Why would they be using that rather than using the "build it yourself" > form of garbage collection discussed here, all the time complaining > that it was not built in. > > > Why wait for your current customers to "demand" something before > > adding a basic feature that could turn *potential* customers into > > *actual* customers? I'm afraid that such short-sighted views will only > > perpetuate the demise of Ada. > > I have the feeling you don't have experience in marketing or overall > company finance. No, I don't. But it seems to me that Ada has a golden opportunity here to provide a clear advantage over both C++ and Java -- and it is declining. C++ has no garbage collection, and development time is two to three times greater as a result (not to mention memory leaks all over the place). Java has GC, but everyone is working overtime to make it work for real time. The obvious solution is to have GC available on demand -- but *optional* at the discretion of the developer. You Ada enthusiasts tell me that the Ada standard "allows" GC but does not require it to be available. Well, as an engineer who would like to promote Ada, I honestly don't know what that means. Does Ada have standard automated memory management or doesn't it? Can I count on it, or can't I? If not, what good is it to me? Maybe you think I am just too simple minded. Well, maybe I am. But so are a lot of other people, including many of the decision-making managers you guys are so fond of. When they compare languages (if they do), one thing they do is to set up a list of check boxes, and one is for GC. As a rule of thumb, a check beats a question mark every time. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 6:40 ` Russ @ 2004-06-26 16:33 ` Robert I. Eachus 2004-06-29 0:33 ` Randy Brukardt 0 siblings, 1 reply; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 16:33 UTC (permalink / raw) Russ wrote: > Maybe you think I am just too simple minded. Well, maybe I am. But so > are a lot of other people, including many of the decision-making > managers you guys are so fond of. When they compare languages (if they > do), one thing they do is to set up a list of check boxes, and one is > for GC. As a rule of thumb, a check beats a question mark every time. Ada does not have a REQUIREMENT for garbage collection. What it has though is a requirement for no memory leaks: AdaRM A.4.5(88): Implementation Requirements No storage associated with an Unbounded_String object shall be lost upon assignment or scope exit. Those words were chosen specifically to require what garbage collection promises, but not to require any particular garbage collection scheme. If the implementor implements this using something other than garbage collection, do you as a user care? I certainly don't think about whether the object will be managed with reference counts, controlled types, or global garbage collection when I use Unbounded_String. All I need to know is that it works, and works means no storage leaks. If I don't want heap allocation, I can use Bounded_String where the RM says: AdaRM A.4.4(106): Implementation Advice Bounded string objects should not be implemented by implicit pointers and dynamic allocation. And as I said in another post, if I want to use similar memory management for arrays of Long_Float, I use Unchecked_Conversion. (Actually I use a record with the array bounds AND an Unbounded_String object.) -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-26 16:33 ` Robert I. Eachus @ 2004-06-29 0:33 ` Randy Brukardt 0 siblings, 0 replies; 72+ messages in thread From: Randy Brukardt @ 2004-06-29 0:33 UTC (permalink / raw) "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:JvCdnWaLWMnaOEDdRVn-jg@comcast.com... ... > Ada does not have a REQUIREMENT for garbage collection. What it has > though is a requirement for no memory leaks: > > AdaRM A.4.5(88): Implementation Requirements > > No storage associated with an Unbounded_String object shall be lost > upon assignment or scope exit. > > Those words were chosen specifically to require what garbage collection > promises, but not to require any particular garbage collection scheme. > If the implementor implements this using something other than garbage > collection, do you as a user care? I certainly don't think about > whether the object will be managed with reference counts, controlled > types, or global garbage collection when I use Unbounded_String. All I > need to know is that it works, and works means no storage leaks. Note that the various containers proposed for Ada 2005 have the same wording and thus the same properties. Using them, Robert can store his array of Long_Floats without any Unchecked_Conversion. Randy. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 13:11 ` Larry Kilgallen ` (3 preceding siblings ...) [not found] ` <bebbba07.0406231018.21Organization: LJK Software <IKJODEu6UfVI@eisner.encompasserve.org> @ 2004-06-24 13:29 ` Stephen Leake 2004-06-24 14:09 ` Hyman Rosen 2004-06-24 19:26 ` Russ 2004-06-24 20:51 ` Larry Kilgallen 5 siblings, 2 replies; 72+ messages in thread From: Stephen Leake @ 2004-06-24 13:29 UTC (permalink / raw) To: comp.lang.ada Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > Bingo. That's exactly what Ada should have. And it shouldn't take a > > rocket scientist to figure that out. > > ACT says they have not really seen market demand from their customers, > and some of them are presumably rocket scientists. Me, for one :). I prefer to manage memory according to the needs of my algorithms and applications, rather than letting some unknown algorithm attempt to do it for me. Ada lets me do this quite nicely. One thing I would like is better testing tools for the GNAT allocator. That's a vendor issue, not a language issue. -- -- Stephe ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 13:29 ` Stephen Leake @ 2004-06-24 14:09 ` Hyman Rosen 2004-06-24 19:58 ` Frank J. Lhota ` (2 more replies) 2004-06-24 19:26 ` Russ 1 sibling, 3 replies; 72+ messages in thread From: Hyman Rosen @ 2004-06-24 14:09 UTC (permalink / raw) Stephen Leake wrote: > I prefer to manage memory according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do > it for me. I prefer to manage registers according to the needs of my algorithms and applications, rather than letting some unknown algorithm attempt to do it for me. That's why I'll never use FORTRAN! ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 14:09 ` Hyman Rosen @ 2004-06-24 19:58 ` Frank J. Lhota 2004-06-25 1:30 ` Stephen Leake 2004-06-25 2:15 ` Russ 2 siblings, 0 replies; 72+ messages in thread From: Frank J. Lhota @ 2004-06-24 19:58 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1088086179.73158@master.nyc.kbcfp.com... > I prefer to manage registers according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do it > for me. That's why I'll never use FORTRAN! LOL! BTW are you writing FORTRAN in all caps for emphasis or to stick with the 1960's programming language naming conventions? A side note: FORTRAN I (three revisions before the widely adapted FORTRAN IV) did have a REGISTER declaration, used in much the same way as the "register" keyword in C/C++. It was used to indicate a variable that was so commonly used that it should be implemented as a register. The FORTRAN 'REGISTER' declaration was dropped after version 1, only to surface again in other languages. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 14:09 ` Hyman Rosen 2004-06-24 19:58 ` Frank J. Lhota @ 2004-06-25 1:30 ` Stephen Leake 2004-06-25 2:15 ` Russ 2 siblings, 0 replies; 72+ messages in thread From: Stephen Leake @ 2004-06-25 1:30 UTC (permalink / raw) To: comp.lang.ada Hyman Rosen <hyrosen@mail.com> writes: > Stephen Leake wrote: > > I prefer to manage memory according to the needs of my algorithms and > > applications, rather than letting some unknown algorithm attempt to do > > it for me. > > I prefer to manage registers according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do it > for me. That's why I'll never use FORTRAN! Well, I see the analogy, but I don't think it's a good one. The advantages of letting an optimizing compiler schedule register usage are well proven. The disadvantages of typical garbage collectors are also well proven. The use of specific memory management schemes for specific application requirements are also well proven. For register scheduling, there are general techniques that produce nearly universally good results. I don't think the same can be said of memory management/garbage collection. On the other hand, I mostly do hard realtime, with little need for dynamic memory management, so I'm not in the best position to judge. -- -- Stephe ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 14:09 ` Hyman Rosen 2004-06-24 19:58 ` Frank J. Lhota 2004-06-25 1:30 ` Stephen Leake @ 2004-06-25 2:15 ` Russ 2 siblings, 0 replies; 72+ messages in thread From: Russ @ 2004-06-25 2:15 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<1088086179.73158@master.nyc.kbcfp.com>... > Stephen Leake wrote: > > I prefer to manage memory according to the needs of my algorithms and > > applications, rather than letting some unknown algorithm attempt to do > > it for me. > > I prefer to manage registers according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do it > for me. That's why I'll never use FORTRAN! I can imagine someone actually saying that. I knew an engineer who at one time refused to use a VT-100 terminal because he didn't trust it as much as he did punch cards. And he was a very good engineer, believe it or not. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 13:29 ` Stephen Leake 2004-06-24 14:09 ` Hyman Rosen @ 2004-06-24 19:26 ` Russ 2004-06-25 1:37 ` Stephen Leake 2004-06-25 8:52 ` David Starner 1 sibling, 2 replies; 72+ messages in thread From: Russ @ 2004-06-24 19:26 UTC (permalink / raw) Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>... > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > > > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > > > Bingo. That's exactly what Ada should have. And it shouldn't take a > > > rocket scientist to figure that out. > > > > ACT says they have not really seen market demand from their customers, > > and some of them are presumably rocket scientists. > > Me, for one :). > > I prefer to manage memory according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do > it for me. Ada lets me do this quite nicely. What's your point? Because you don't want automated memory management, nobody else should want it either? What I'm suggesting would give you what you want and it would also give the desktop and web developers what they want. In other words, it would make Ada a more versatile language. Maybe you don't think that's wise, but if you don't, please don't complain about the fact that Java dwarfs Ada in popularity (and is now being adapted big-time for real-time use by the military). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 19:26 ` Russ @ 2004-06-25 1:37 ` Stephen Leake 2004-06-25 10:13 ` Ole-Hjalmar Kristensen 2004-06-25 23:35 ` Russ 2004-06-25 8:52 ` David Starner 1 sibling, 2 replies; 72+ messages in thread From: Stephen Leake @ 2004-06-25 1:37 UTC (permalink / raw) To: comp.lang.ada 18k11tm001@sneakemail.com (Russ) writes: > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>... > > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > > > > > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > > > > > Bingo. That's exactly what Ada should have. And it shouldn't take a > > > > rocket scientist to figure that out. > > > > > > ACT says they have not really seen market demand from their customers, > > > and some of them are presumably rocket scientists. > > > > Me, for one :). > > > > I prefer to manage memory according to the needs of my algorithms and > > applications, rather than letting some unknown algorithm attempt to do > > it for me. Ada lets me do this quite nicely. > > What's your point? My point is that _this_ "rocket scientist" reaches a different conclusion than you do about the desirability of garbage collection. > Because you don't want automated memory management, nobody else > should want it either? That's not exactly my argument, but it is my conclusion, if by "automated memory management" you mean "garbage collection, as provided by the JVM for example". The term "automated memory management" can mean many things, including typical Ada use of the stack for local variables. So we need clearer definitions before we go any farther. > What I'm suggesting would give you what you want and it would also > give the desktop and web developers what they want. I'm suggesting that "garbage collection" is not what they _need_ (different from what they _want_). > In other words, it would make Ada a more versatile language. Nope. As many have pointed out, Ada the _langauge_ allows for garbage collection, and some implementations have provided it (JGNAT in particular). That has not lead to commercial success. So what has changed, that you think it will lead to commercial success now? Ada provides better ways to manage memory, and programmers that take the time to figure that out don't need traditional "garbage collection". > Maybe you don't think that's wise, but if you don't, please don't > complain about the fact that Java dwarfs Ada in popularity (and is > now being adapted big-time for real-time use by the military). I've never "complained" about that. I'm disappointed in the waste of my tax dollars, but that's nothing new :). -- -- Stephe ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 1:37 ` Stephen Leake @ 2004-06-25 10:13 ` Ole-Hjalmar Kristensen 2004-06-26 0:20 ` David Starner 2004-06-25 23:35 ` Russ 1 sibling, 1 reply; 72+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-06-25 10:13 UTC (permalink / raw) >>>>> "SL" == Stephen Leake <stephen_leake@acm.org> writes: <snip> SL> I'm suggesting that "garbage collection" is not what they _need_ SL> (different from what they _want_). >> In other words, it would make Ada a more versatile language. SL> Nope. SL> As many have pointed out, Ada the _langauge_ allows for garbage SL> collection, and some implementations have provided it (JGNAT in SL> particular). That has not lead to commercial success. So what has SL> changed, that you think it will lead to commercial success now? "Allows for" is not the same as is available. You cannot write a portable Ada application and take advantage of automatic garbage collection. You *can* do that with Java. You can argue that programmers do not need garbage collection, but you cannot stop them from wanting it. But I agree, I do not think that adding garbage collection would make much difference wrt. commercial success of Ada. I think Ada is doomed to forever being a niche language. SL> Ada provides better ways to manage memory, and programmers that take SL> the time to figure that out don't need traditional "garbage SL> collection". Of course yo do not need it, but it can be convenient. >> Maybe you don't think that's wise, but if you don't, please don't >> complain about the fact that Java dwarfs Ada in popularity (and is >> now being adapted big-time for real-time use by the military). SL> I've never "complained" about that. I'm disappointed in the waste of SL> my tax dollars, but that's nothing new :). SL> -- SL> -- Stephe -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 10:13 ` Ole-Hjalmar Kristensen @ 2004-06-26 0:20 ` David Starner 0 siblings, 0 replies; 72+ messages in thread From: David Starner @ 2004-06-26 0:20 UTC (permalink / raw) On Fri, 25 Jun 2004 12:13:34 +0200, Ole-Hjalmar Kristensen wrote: > You *can* do that with Java. You can argue that > programmers do not need garbage collection, but you cannot stop them > from wanting it. Who is wanting it? I'm not seeing the people on this newsgroup demanding it, except those thinking of it as a magic bullet. I'm not seeing the people who use Ada running out and writing garbage collectors. I'm not seeing all the people that are writing code in C and C++, which makes up a large percentage of any Linux distribution, using garbage collectors. Gnome and KDE have no reason not to have a garbage collector, given the number of libraries they already depend on. But they choose not to. All this indicates that GC is not important to many programmers. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 1:37 ` Stephen Leake 2004-06-25 10:13 ` Ole-Hjalmar Kristensen @ 2004-06-25 23:35 ` Russ 2004-06-26 11:27 ` Martin Dowie ` (2 more replies) 1 sibling, 3 replies; 72+ messages in thread From: Russ @ 2004-06-25 23:35 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.153.1088127452.391.comp.lang.ada@ada-france.org>... > 18k11tm001@sneakemail.com (Russ) writes: > > > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<mailman.151.1088083768.391.comp.lang.ada@ada-france.org>... > > > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > > > > > > > In article <bebbba07.0406222041.593ab7c3@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes: > > > > > > > > > Bingo. That's exactly what Ada should have. And it shouldn't take a > > > > > rocket scientist to figure that out. > > > > > > > > ACT says they have not really seen market demand from their customers, > > > > and some of them are presumably rocket scientists. > > > > > > Me, for one :). > > > > > > I prefer to manage memory according to the needs of my algorithms and > > > applications, rather than letting some unknown algorithm attempt to do > > > it for me. Ada lets me do this quite nicely. > > > > What's your point? > > My point is that _this_ "rocket scientist" reaches a different > conclusion than you do about the desirability of garbage collection. > > > Because you don't want automated memory management, nobody else > > should want it either? > > That's not exactly my argument, but it is my conclusion, if by > "automated memory management" you mean "garbage collection, as > provided by the JVM for example". > > The term "automated memory management" can mean many things, including > typical Ada use of the stack for local variables. So we need clearer > definitions before we go any farther. I don't know much about memory management or garbage collection, but I do know that it is considered a great benefit of Java and many other languages. Whatever Ada provides in this regard should be optional at the discretion of the *developer* (not the compiler vendor), and it should be at least as good as the GC in Java for those who choose to use it that way. > > What I'm suggesting would give you what you want and it would also > > give the desktop and web developers what they want. > > I'm suggesting that "garbage collection" is not what they _need_ > (different from what they _want_). Yes, of course, and a C programmer could just as well claim that you don't really need array bound checking. All you need is to be careful not to address your arrays out of bounds. I think you are missing a huge point here. The advantages of automatic memory management are that it is (1) convenient for the developer and (2) much more reliable, just as the automatic array bounds checking is more reliable than a developer's hand-rolled bounds checking. You may neither want or need it for your application, and you shouldn't be forced to use it, but the desktop and web developers should always have it available if they want it. They shouldn't be denied a valuable feature just because you don't want it. > > In other words, it would make Ada a more versatile language. > > Nope. Yup. Look at the amazing popularity of Java. I would venture to say that it is due, in large part, to Java's garbage collection. Java started out as a web language, and it has become a desktop application language too. Now it is so popular that it is starting to push Ada out of its niche in real-time systems. Once a language reaches a certain level of popularity, everyone wants to use it. Your attitude of not caring what desktop/web developers want is a sure-fire way to let Ada die a slow, agonizing death. > As many have pointed out, Ada the _langauge_ allows for garbage > collection, and some implementations have provided it (JGNAT in > particular). That has not lead to commercial success. So what has > changed, that you think it will lead to commercial success now? That's a bit like saying, "Hey, we threw a 60-yard touchdown pass and we still lost the game, so why should we waste our time trying to score touchdowns anymore?" I can't guarantee that GC (or equivalent) will make Ada more popular, but I *can* guarantee that Ada will *not* become more popular if it continues to ignore the needs of the vast majority of developers out there. > Ada provides better ways to manage memory, and programmers that take > the time to figure that out don't need traditional "garbage > collection". So I guess all those Canneige-Mellon and MIT professors who use Java are just simpletons. Hey, I agree that they should use Ada, but I'm not quite as arrogant as you in telling them what they need. > > Maybe you don't think that's wise, but if you don't, please don't > > complain about the fact that Java dwarfs Ada in popularity (and is > > now being adapted big-time for real-time use by the military). > > I've never "complained" about that. I'm disappointed in the waste of > my tax dollars, but that's nothing new :). If self-centered attitudes like yours prevail in the Ada community, I suggest you start getting used to a lot more of the same. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 23:35 ` Russ @ 2004-06-26 11:27 ` Martin Dowie 2004-06-26 13:45 ` Ed Falis 2004-06-26 17:20 ` Robert I. Eachus 2 siblings, 0 replies; 72+ messages in thread From: Martin Dowie @ 2004-06-26 11:27 UTC (permalink / raw) Russ wrote: > Yup. Look at the amazing popularity of Java. I would venture to say > that it is due, in large part, to Java's garbage collection. I don't believe for a minute that Java is popular "in large part" because of GC - much more to do with Sun's $$$$ and a huge built in _standard_ library. Having said that, I don't see any harm in making GC in Ada much more mainstream. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 23:35 ` Russ 2004-06-26 11:27 ` Martin Dowie @ 2004-06-26 13:45 ` Ed Falis 2004-06-26 20:38 ` Russ 2004-06-26 17:20 ` Robert I. Eachus 2 siblings, 1 reply; 72+ messages in thread From: Ed Falis @ 2004-06-26 13:45 UTC (permalink / raw) On 25 Jun 2004 16:35:53 -0700, Russ <18k11tm001@sneakemail.com> wrote: > Yup. Look at the amazing popularity of Java. I would venture to say > that it is due, in large part, to Java's garbage collection. Unfortunately, there are counter-arguments to this conjecture, anyway. Consider Eiffel, a very nice language, quite Ada-like in many ways, with garbage collection and several innovative features (eg design by contract). It is not as popular or as widely used as Ada. Consider that both Aonix (from Intermetrics/Averstar) and AdaCore provided Ada compilers for the JVM, including garbage collection and robust bindings to the Java class libraries. Neither was commercially successful. Consider that when I was at Aonix, I built a setup allowing the use of the Great Circle garbage collector with ObjectAda, and that we advertized the availability of this capability. One copy of GC was sold with ObjectAda if I remember rightly. So, IMO, garbage collection is a nice option to have, but I doubt that it's of the essence of Java's popularity. By the way, I happen to enjoy programming in languages that provide GC, and was pretty heavily involved in almost all of the above. - Ed ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-26 13:45 ` Ed Falis @ 2004-06-26 20:38 ` Russ 2004-06-26 21:36 ` Ludovic Brenta 0 siblings, 1 reply; 72+ messages in thread From: Russ @ 2004-06-26 20:38 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> wrote in message news:<opr97e5lkh5afhvo@localhost>... > On 25 Jun 2004 16:35:53 -0700, Russ <18k11tm001@sneakemail.com> wrote: > > > Yup. Look at the amazing popularity of Java. I would venture to say > > that it is due, in large part, to Java's garbage collection. > > > Unfortunately, there are counter-arguments to this conjecture, anyway. > > Consider Eiffel, a very nice language, quite Ada-like in many ways, with > garbage collection and several innovative features (eg design by > contract). It is not as popular or as widely used as Ada. > > Consider that both Aonix (from Intermetrics/Averstar) and AdaCore provided > Ada compilers for the JVM, including garbage collection and robust > bindings to the Java class libraries. Neither was commercially > successful. Part of the problem, as I see it, is that open-source developers now expect their compiler to be free -- as in beer. So do students. That is a real dilemma for compiler vendors, of course, and I don't envy them. But now that the Ada->JVM compilers have been determined to be commercially unviable, is it conceivable that they could be open-sourced and made available for free -- as in beer *and* speech? Why waste all the effort that went into them? Perhaps a free Ada->JVM compiler with robust bindings to the Java class libraries might be a key to a revival of Ada. Then again, maybe not. But if not, the prospects for a revival of Ada seem rather bleak. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-26 20:38 ` Russ @ 2004-06-26 21:36 ` Ludovic Brenta 2004-06-27 7:54 ` Dmitry A. Kazakov 0 siblings, 1 reply; 72+ messages in thread From: Ludovic Brenta @ 2004-06-26 21:36 UTC (permalink / raw) Russ writes: > Part of the problem, as I see it, is that open-source developers now > expect their compiler to be free -- as in beer. So do students. That > is a real dilemma for compiler vendors, of course, and I don't envy > them. > > But now that the Ada->JVM compilers have been determined to be > commercially unviable, is it conceivable that they could be > open-sourced and made available for free -- as in beer *and* speech? > > Why waste all the effort that went into them? Perhaps a free > Ada->JVM compiler with robust bindings to the Java class libraries > might be a key to a revival of Ada. Then again, maybe not. But if > not, the prospects for a revival of Ada seem rather bleak. JGNAT is free. Anyone interested can get it at no cost, use it for any purpose they wish, change it, and redistribute it along with their changes. So, nothing is lost :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-26 21:36 ` Ludovic Brenta @ 2004-06-27 7:54 ` Dmitry A. Kazakov 0 siblings, 0 replies; 72+ messages in thread From: Dmitry A. Kazakov @ 2004-06-27 7:54 UTC (permalink / raw) On Sat, 26 Jun 2004 23:36:06 +0200, Ludovic Brenta wrote: > Russ writes: >> Part of the problem, as I see it, is that open-source developers now >> expect their compiler to be free -- as in beer. So do students. That >> is a real dilemma for compiler vendors, of course, and I don't envy >> them. >> >> But now that the Ada->JVM compilers have been determined to be >> commercially unviable, is it conceivable that they could be >> open-sourced and made available for free -- as in beer *and* speech? >> >> Why waste all the effort that went into them? Perhaps a free >> Ada->JVM compiler with robust bindings to the Java class libraries >> might be a key to a revival of Ada. Then again, maybe not. But if >> not, the prospects for a revival of Ada seem rather bleak. > > JGNAT is free. Anyone interested can get it at no cost, use it for > any purpose they wish, change it, and redistribute it along with their > changes. So, nothing is lost :) And nothing happens, alas! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-25 23:35 ` Russ 2004-06-26 11:27 ` Martin Dowie 2004-06-26 13:45 ` Ed Falis @ 2004-06-26 17:20 ` Robert I. Eachus 2 siblings, 0 replies; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 17:20 UTC (permalink / raw) Russ wrote: > I don't know much about memory management or garbage collection, but I > do know that it is considered a great benefit of Java and many other > languages. Whatever Ada provides in this regard should be optional at > the discretion of the *developer* (not the compiler vendor), and it > should be at least as good as the GC in Java for those who choose to > use it that way... > I think you are missing a huge point here. The advantages of automatic > memory management are that it is (1) convenient for the developer and > (2) much more reliable, just as the automatic array bounds checking is > more reliable than a developer's hand-rolled bounds checking. > > You may neither want or need it for your application, and you > shouldn't be forced to use it, but the desktop and web developers > should always have it available if they want it. They shouldn't be > denied a valuable feature just because you don't want it. I think you are just not hearing what is being said. Let me try saying it this way. 1) Garbage collection is of great benefit in many languages. 2) Automatic memory management is a big advantage for some programmmers and some programs. So far, so good. But... 3) Ada programmers like the automatic memory management that is a part of Ada, and don't particularly care for garbage collection. Is the memory management that is part of Ada perfect for all applications? No, in fact there are many AI algorithms that work better in a garbage collection environment. Personally I would accept the slight extra work of implementing such an algorithm in Ada using controlled objects rather than use Java or Lisp. But that is because the cost of doing the memory management that way is to me much, much smaller than the debugging advantages of using Ada. Of course, I also get predictable timing by using Ada. YMMV. -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-24 19:26 ` Russ 2004-06-25 1:37 ` Stephen Leake @ 2004-06-25 8:52 ` David Starner 1 sibling, 0 replies; 72+ messages in thread From: David Starner @ 2004-06-25 8:52 UTC (permalink / raw) On Thu, 24 Jun 2004 12:26:34 -0700, Russ wrote: > please > don't complain about the fact that Java dwarfs Ada in popularity Ada with Java's garbage collection was offered for sale. There were no takers. That indicates to me that the problem is far beyond technical issues; Ada's reputation and past history, compared with Sun's marketing savvy, linking Java with the Internet and now a large base of available Java tools is much more important. > (and > is now being adapted big-time for real-time use by the military). Which is a crying shame. The military still uses Vietnam-era planes but won't commit to the programming language they commissioned for any period of time. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-23 13:11 ` Larry Kilgallen ` (4 preceding siblings ...) 2004-06-24 13:29 ` Stephen Leake @ 2004-06-24 20:51 ` Larry Kilgallen 5 siblings, 0 replies; 72+ messages in thread From: Larry Kilgallen @ 2004-06-24 20:51 UTC (permalink / raw) In article <1088086179.73158@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes: > Stephen Leake wrote: >> I prefer to manage memory according to the needs of my algorithms and >> applications, rather than letting some unknown algorithm attempt to do >> it for me. > > I prefer to manage registers according to the needs of my algorithms and > applications, rather than letting some unknown algorithm attempt to do it > for me. That's why I'll never use FORTRAN! You should switch to Bliss, which gives a lot of higher level looping constructs, excellent macro facilities, and the opportunity to micro- manage register usage. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 19:03 ` Russ 2004-06-22 2:39 ` David Starner @ 2004-06-22 6:09 ` Martin Krischik 2004-06-22 10:20 ` Georg Bauhaus 2004-06-26 16:00 ` Robert I. Eachus 3 siblings, 0 replies; 72+ messages in thread From: Martin Krischik @ 2004-06-22 6:09 UTC (permalink / raw) Russ wrote: > "Martin Dowie" <martin.dowie@baesystems.com> wrote in message > news:<40d69121$1_1@baen1673807.greenlnk.net>... >> "Russ" <18k11tm001@sneakemail.com> wrote in message >> news:bebbba07.0406202016.1f15c133@posting.google.com... >> > Well, if initialize and finalize are fundamentally no different than >> > constructors and destructors, then I conclude that Ada does not have >> > automated memory management any more than C++ has it. (I may be a bit >> > slow, but I catch on eventually.) >> > >> > As for using a library that has memory management built in, that >> > sounds great. I'd just feel a bit better about it if it were in a >> > standard library that everyone agrees on and comes with the language, >> > like STL in C++. Then you could honestly say that Ada has automated >> > memory management built in. (And it would be better than Java's >> > because it would be optional.) >> >> Ada does not forbid an implementation for performing GC but there >> has been zero customer call for it. That's no too surprising - "Sorry, >> you can't apply brakes/launch missile/shutdown reactor as I'm busy >> garbage collecting." would not go done well. > > Are you saying that an Ada compiler can implement GC or not? That > seems a bit inconsistent to me. How can the same language have it both > ways? What if someone tries to port an Ada application that has its > own memory management to an Ada compiler that already has it by > default? I would think you would at least want it controlled by a > compilation flag or some something. That's what "pragma Controlled ()" is for. Which is even better then a compiler flag. >> But for desktop apps or even business apps, it might well be appropriate. > > Which is why it should be under control of the application developer, > it seems to me. Well it is. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 19:03 ` Russ 2004-06-22 2:39 ` David Starner 2004-06-22 6:09 ` Martin Krischik @ 2004-06-22 10:20 ` Georg Bauhaus 2004-06-26 16:00 ` Robert I. Eachus 3 siblings, 0 replies; 72+ messages in thread From: Georg Bauhaus @ 2004-06-22 10:20 UTC (permalink / raw) Russ <18k11tm001@sneakemail.com> wrote: : Are you saying that an Ada compiler can implement GC or not? Have you had a look at storage pools? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 19:03 ` Russ ` (2 preceding siblings ...) 2004-06-22 10:20 ` Georg Bauhaus @ 2004-06-26 16:00 ` Robert I. Eachus 3 siblings, 0 replies; 72+ messages in thread From: Robert I. Eachus @ 2004-06-26 16:00 UTC (permalink / raw) Russ wrote: > Are you saying that an Ada compiler can implement GC or not? That > seems a bit inconsistent to me. How can the same language have it both > ways? What if someone tries to port an Ada application that has its > own memory management to an Ada compiler that already has it by > default? I would think you would at least want it controlled by a > compilation flag or some something. Symbolics had an Ada compiler for their systems, which had global garbage collection. I'm not sure about the R1000 Rational hardware. But in any case, this has been the history of global garbage collection in Ada. If the OS supports it, the compiler will do what is necessary to run in that environment. But it is seen more as an extra development cost than a desired feature. (I'm not saying that is why Symbolics went bankrupt. But if there was a big market for Ada with garbage collection, Symbolics might still be in business.) -- Robert I. Eachus "Reason and experience both forbid us to expect that national morality can prevail in exclusion of religious principles." -- George Washington ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 4:16 ` Russ 2004-06-21 7:29 ` Jano 2004-06-21 7:46 ` Martin Dowie @ 2004-06-21 8:23 ` Dmitry A. Kazakov 2 siblings, 0 replies; 72+ messages in thread From: Dmitry A. Kazakov @ 2004-06-21 8:23 UTC (permalink / raw) On 20 Jun 2004 21:16:16 -0700, 18k11tm001@sneakemail.com (Russ) wrote: >Well, if initialize and finalize are fundamentally no different than >constructors and destructors, then I conclude that Ada does not have >automated memory management any more than C++ has it. (I may be a bit >slow, but I catch on eventually.) The difference is that in Ada there is much lesser need in objects allocated in the heap. That makes things a lot easier and safer. Moreover it is also much more efficient, especially in a parallel environment. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity
@ 2004-06-21 10:33 Christoph Karl Walter Grein
2004-06-21 10:38 ` Jano
0 siblings, 1 reply; 72+ messages in thread
From: Christoph Karl Walter Grein @ 2004-06-21 10:33 UTC (permalink / raw)
To: comp.lang.ada
> I get this:
>
> Initialize
> Finalize
> Finalize
> Wibble
> Finalize
> Finalize
>
> and I'm impressed because I didn't knew these differences. I must
> however admit that I don't understand exactly what's happening and gvd
> sigfaults on me (w2000). Could you provide a short explanation please?
The relevant chapter in the RM is not easy to understand. So find here a commented example of initialisation/adjustment/finalization:
http://home.t-online.de/home/christ-usch.grein/AdaMagica/Secretive.html
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: memory management and productivity 2004-06-21 10:33 Christoph Karl Walter Grein @ 2004-06-21 10:38 ` Jano 0 siblings, 0 replies; 72+ messages in thread From: Jano @ 2004-06-21 10:38 UTC (permalink / raw) Christoph Karl Walter Grein wrote: >>I get this: >> >>Initialize >>Finalize >>Finalize >>Wibble >>Finalize >>Finalize >> >>and I'm impressed because I didn't knew these differences. I must >>however admit that I don't understand exactly what's happening and gvd >>sigfaults on me (w2000). Could you provide a short explanation please? > > > The relevant chapter in the RM is not easy to understand. So find here a commented example of initialisation/adjustment/finalization: > > http://home.t-online.de/home/christ-usch.grein/AdaMagica/Secretive.html Thanks! ^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2004-06-29 0:33 UTC | newest] Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-06-17 4:56 memory management and productivity Russ 2004-06-17 5:15 ` tmoran 2004-06-17 8:07 ` Martin Dowie 2004-06-18 23:10 ` Russ 2004-06-19 9:04 ` Martin Dowie 2004-06-21 4:16 ` Russ 2004-06-21 7:29 ` Jano 2004-06-21 8:02 ` Martin Dowie 2004-06-21 8:22 ` Jano 2004-06-21 9:07 ` Martin Dowie 2004-06-21 22:36 ` Brian May 2004-06-22 7:47 ` Martin Dowie 2004-06-21 8:14 ` Ole-Hjalmar Kristensen 2004-06-21 8:27 ` Jano 2004-06-21 8:29 ` Martin Dowie 2004-06-22 7:53 ` Ole-Hjalmar Kristensen 2004-06-26 15:44 ` Robert I. Eachus 2004-06-21 16:31 ` Frank J. Lhota 2004-06-22 7:58 ` Ole-Hjalmar Kristensen 2004-06-21 8:14 ` Martin Krischik 2004-06-21 15:22 ` Hyman Rosen 2004-06-21 16:47 ` Martin Krischik 2004-06-21 17:51 ` Hyman Rosen 2004-06-22 17:02 ` Pascal Obry 2004-06-26 15:54 ` Robert I. Eachus 2004-06-21 7:46 ` Martin Dowie 2004-06-21 19:03 ` Russ 2004-06-22 2:39 ` David Starner 2004-06-22 8:03 ` Ole-Hjalmar Kristensen 2004-06-23 4:41 ` Russ 2004-06-23 7:41 ` Martin Dowie 2004-06-23 17:36 ` Björn Persson 2004-06-23 22:06 ` David Starner 2004-06-24 0:34 ` Björn Persson 2004-06-24 6:45 ` Martin Krischik 2004-06-24 10:27 ` Wes Groleau 2004-06-23 23:02 ` Russ 2004-06-26 16:16 ` Robert I. Eachus 2004-06-23 13:11 ` Larry Kilgallen 2004-06-23 17:21 ` Björn Persson 2004-06-24 7:35 ` Ole-Hjalmar Kristensen 2004-06-26 17:10 ` Simon Wright 2004-06-23 18:18 ` Russ 2004-06-23 23:18 ` David Starner 2004-06-23 22:15 ` Larry Kilgallen [not found] ` <bebbba07.0406231018.21Organization: LJK Software <IKJODEu6UfVI@eisner.encompasserve.org> 2004-06-24 6:40 ` Russ 2004-06-26 16:33 ` Robert I. Eachus 2004-06-29 0:33 ` Randy Brukardt 2004-06-24 13:29 ` Stephen Leake 2004-06-24 14:09 ` Hyman Rosen 2004-06-24 19:58 ` Frank J. Lhota 2004-06-25 1:30 ` Stephen Leake 2004-06-25 2:15 ` Russ 2004-06-24 19:26 ` Russ 2004-06-25 1:37 ` Stephen Leake 2004-06-25 10:13 ` Ole-Hjalmar Kristensen 2004-06-26 0:20 ` David Starner 2004-06-25 23:35 ` Russ 2004-06-26 11:27 ` Martin Dowie 2004-06-26 13:45 ` Ed Falis 2004-06-26 20:38 ` Russ 2004-06-26 21:36 ` Ludovic Brenta 2004-06-27 7:54 ` Dmitry A. Kazakov 2004-06-26 17:20 ` Robert I. Eachus 2004-06-25 8:52 ` David Starner 2004-06-24 20:51 ` Larry Kilgallen 2004-06-22 6:09 ` Martin Krischik 2004-06-22 10:20 ` Georg Bauhaus 2004-06-26 16:00 ` Robert I. Eachus 2004-06-21 8:23 ` Dmitry A. Kazakov -- strict thread matches above, loose matches on Subject: below -- 2004-06-21 10:33 Christoph Karl Walter Grein 2004-06-21 10:38 ` Jano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox