* Distributed system portability @ 2001-07-29 17:18 Darren New 2001-07-30 8:00 ` Pascal Obry ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Darren New @ 2001-07-29 17:18 UTC (permalink / raw) Is it generally the case that a distributed system compiled on two different architectures can talk to itself? In other words, if I write a distributed system with GNAT, and I compile one portion on Windows and another portion on Linux, are these two systems likely to talk to each other? If not, are the stream formats likely to be compatible? If not, is there a way to redefine the low-level stream operators for things like Integer to ensure that the same format is used at both ends? Or do I need to write translation routines to some architecture-independent format? I'm basically thinking of something where the clients would be distributed, talking between themselves peer-to-peer. Does Ada's portability mean I don't need to write a translate-to-and-from-network-representation layer, because I can use streams? -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. Only a WIMP puts wallpaper on his desktop. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-29 17:18 Distributed system portability Darren New @ 2001-07-30 8:00 ` Pascal Obry 2001-07-31 7:23 ` Frank 2001-07-30 11:22 ` Thierry Lelegard 2001-07-30 15:57 ` Marin David Condic 2 siblings, 1 reply; 16+ messages in thread From: Pascal Obry @ 2001-07-30 8:00 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Is it generally the case that a distributed system compiled on two > different architectures can talk to itself? In other words, if I write a > distributed system with GNAT, and I compile one portion on Windows and > another portion on Linux, are these two systems likely to talk to each > other? No problem with GLADE the GNAT implementation of the distributed Annex. And this is not theory I've done it :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 8:00 ` Pascal Obry @ 2001-07-31 7:23 ` Frank 2001-07-31 16:35 ` Pascal Obry 0 siblings, 1 reply; 16+ messages in thread From: Frank @ 2001-07-31 7:23 UTC (permalink / raw) Hi! How is it with JGNAT, is there a Distributed Annex there? Has anyone tried to distribute a Ada program so that one partition is a native executable, and another is running in the JVM? Can a Ada partition/program/package be recongnized by a Java program as e.g a class (not using Adept)? Linux 6.2- Red Hat/GNAT 3-13p. Frank Pascal Obry <p.obry@wanadoo.fr> wrote in message news:uzo9m3kya.fsf@wanadoo.fr... > > Darren New <dnew@san.rr.com> writes: > > > Is it generally the case that a distributed system compiled on two > > different architectures can talk to itself? In other words, if I write a > > distributed system with GNAT, and I compile one portion on Windows and > > another portion on Linux, are these two systems likely to talk to each > > other? > > No problem with GLADE the GNAT implementation of the distributed Annex. And > this is not theory I've done it :) > > Pascal. > > -- > > --|------------------------------------------------------ > --| Pascal Obry Team-Ada Member > --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE > --|------------------------------------------------------ > --| http://perso.wanadoo.fr/pascal.obry > --| > --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-31 7:23 ` Frank @ 2001-07-31 16:35 ` Pascal Obry 0 siblings, 0 replies; 16+ messages in thread From: Pascal Obry @ 2001-07-31 16:35 UTC (permalink / raw) "Frank" <franjoe@frisurf.no> writes: > Hi! > > How is it with JGNAT, is there a Distributed Annex there? AFAIK there is no GLADE for JGNAT project. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-29 17:18 Distributed system portability Darren New 2001-07-30 8:00 ` Pascal Obry @ 2001-07-30 11:22 ` Thierry Lelegard 2001-07-30 13:05 ` Larry Kilgallen 2001-07-30 15:57 ` Marin David Condic 2 siblings, 1 reply; 16+ messages in thread From: Thierry Lelegard @ 2001-07-30 11:22 UTC (permalink / raw) > Is it generally the case that a distributed system compiled on two > different architectures can talk to itself? In other words, if I write a > distributed system with GNAT, and I compile one portion on Windows and > another portion on Linux, are these two systems likely to talk to each > other? If not, are the stream formats likely to be compatible? If not, > is there a way to redefine the low-level stream operators for things > like Integer to ensure that the same format is used at both ends? Or do > I need to write translation routines to some architecture-independent > format? In pratice, GNAT/GLADE seems to handle this (but I never used it). In theory (although there is no other implementation of DSA than GLADE), there is absolutely no guarantee in the ARM about that. Interoperability is, in my opinion, the biggest hole in Ada95 and writing "open" software in Ada95 is much harder that it could have been if the default representation of streams were standardized. -Thierry ____________________________________________________________________________ Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France Tel: +33 1 71 71 54 30 Fax: +33 1 71 71 52 08 Mobile: +33 6 03 00 65 75 ____________________________________________________________________________ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 11:22 ` Thierry Lelegard @ 2001-07-30 13:05 ` Larry Kilgallen 2001-07-30 16:12 ` Thierry Lelegard 0 siblings, 1 reply; 16+ messages in thread From: Larry Kilgallen @ 2001-07-30 13:05 UTC (permalink / raw) In article <3B654382.B885CE20@canal-plus.fr>, Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes: >> Is it generally the case that a distributed system compiled on two >> different architectures can talk to itself? In other words, if I write a >> distributed system with GNAT, and I compile one portion on Windows and >> another portion on Linux, are these two systems likely to talk to each >> other? If not, are the stream formats likely to be compatible? If not, >> is there a way to redefine the low-level stream operators for things >> like Integer to ensure that the same format is used at both ends? Or do >> I need to write translation routines to some architecture-independent >> format? > > In pratice, GNAT/GLADE seems to handle this (but I never used it). > > In theory (although there is no other implementation of DSA than GLADE), > there is absolutely no guarantee in the ARM about that. Interoperability > is, in my opinion, the biggest hole in Ada95 and writing "open" software > in Ada95 is much harder that it could have been if the default representation > of streams were standardized. When streams go to a file, wouldn't there be a problem with differences between record-oriented file systems and bag-of-bytes oriented file systems ? While the distributed annex may be the topic of this discussion, some may be more interested in making it possible for their streams to be interpreted by other languages. Or is the idea of streams that one should never try to access them from a non-Ada language ? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 13:05 ` Larry Kilgallen @ 2001-07-30 16:12 ` Thierry Lelegard 2001-07-30 21:39 ` Ted Dennison 0 siblings, 1 reply; 16+ messages in thread From: Thierry Lelegard @ 2001-07-30 16:12 UTC (permalink / raw) > When streams go to a file, wouldn't there be a problem with differences > between record-oriented file systems and bag-of-bytes oriented file > systems ? Exactly (I know you are thinking about VMS, which we use as well). In a file, there is the "logical content" (the data) and the physical content (the raw content of the blocks of the file). Both are identical on UNIX but they are not on VMS. But, anyway, the Ada95 streams only care about the "logical content". However, even this logical content is non standard. The very first reason for this is the horrible "type Stream_Element is mod implementation-defined" in Ada.Streams. You cannot base interoperability on an "implementation-defined" feature. > Or is the idea of streams that one should never try to access them > from a non-Ada language ? Yes, for the reason above. -Thierry ____________________________________________________________________________ Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France Tel: +33 1 71 71 54 30 Fax: +33 1 71 71 52 08 Mobile: +33 6 03 00 65 75 ____________________________________________________________________________ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 16:12 ` Thierry Lelegard @ 2001-07-30 21:39 ` Ted Dennison 2001-07-30 22:28 ` tmoran 2001-07-31 7:44 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 16+ messages in thread From: Ted Dennison @ 2001-07-30 21:39 UTC (permalink / raw) In article <3B658765.8F0E0939@canal-plus.fr>, Thierry Lelegard says... >However, even this logical content is non standard. The very first >reason for this is the horrible "type Stream_Element is mod >implementation-defined" in Ada.Streams. You cannot base interoperability >on an "implementation-defined" feature. > >> Or is the idea of streams that one should never try to access them >> from a non-Ada language ? > >Yes, for the reason above. I'd say its a bit worse than that. You really shouldn't try to access them from code that wasn't compiled with the same Ada compiler (unless you are *real* careful). Even the same compiler on different platforms could give different results. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 21:39 ` Ted Dennison @ 2001-07-30 22:28 ` tmoran 2001-07-31 17:36 ` Ted Dennison 2001-07-31 7:44 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 16+ messages in thread From: tmoran @ 2001-07-30 22:28 UTC (permalink / raw) >>> Or is the idea of streams that one should never try to access them >>> from a non-Ada language ? > >I'd say its a bit worse than that. You really shouldn't try to access >them from code that wasn't compiled with the same Ada compiler (unless you >are *real* careful). Even the same compiler on different platforms could >give different results. That's true unless only if (you use default 'read etc) or (the size of Stream_Element is different). The former is easily made false and the latter is rather unlikely to be true, and certainly should not come as a surprise if you are working with such differing machines. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 22:28 ` tmoran @ 2001-07-31 17:36 ` Ted Dennison 2001-07-31 18:15 ` tmoran 0 siblings, 1 reply; 16+ messages in thread From: Ted Dennison @ 2001-07-31 17:36 UTC (permalink / raw) In article <Rbl97.14918$Kd7.9265254@news1.rdc1.sfba.home.com>, tmoran@acm.org says... >>I'd say its a bit worse than that. You really shouldn't try to access >>them from code that wasn't compiled with the same Ada compiler (unless you >>are *real* careful). Even the same compiler on different platforms could >>give different results. > That's true unless only if (you use default 'read etc) or (the size >of Stream_Element is different). The former is easily made false and >the latter is rather unlikely to be true, and certainly should not >come as a surprise if you are working with such differing machines. That's what I meant by "*real* careful". To make sure they match in a specific case, you can just try things out and reimplement yourself whatever doesn't work right because of compiler/target differences. For example, you can implement your own 'Read, 'Write, 'Input, 'Output, and the streams themselves if need be. You can check for Ada.Streams.Stream_Element'size and account for that. However, to make things truly *portable*, so that no such iterative checking is involved, you have to do *all* this (including implementing all the stream attributes for *all* types that will ever be used with the stream, excepting perhaps some composite types). With that much work involved, the streams aren't really providing you much except the supposedly nice syntax. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-31 17:36 ` Ted Dennison @ 2001-07-31 18:15 ` tmoran 2001-07-31 18:55 ` Marin David Condic 2001-07-31 20:26 ` Ted Dennison 0 siblings, 2 replies; 16+ messages in thread From: tmoran @ 2001-07-31 18:15 UTC (permalink / raw) >you have to do *all* this (including implementing all the stream attributes for >*all* types that will ever be used with the stream, excepting perhaps some >composite types). With that much work involved, the streams aren't really >providing you much except the supposedly nice syntax. (I haven't tried this but ...) I think you just have to implement the base types, and you need do it only once. So if you are going to be doing a lot of systems where data goes between a machine of type A and another B with different architecture or compiler, you can implement integer'read etc just once, and all your different programs can use it for integers ... composite types. Isn't that in fact done for the Gnat distributed systems implementation? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-31 18:15 ` tmoran @ 2001-07-31 18:55 ` Marin David Condic 2001-07-31 20:26 ` Ted Dennison 1 sibling, 0 replies; 16+ messages in thread From: Marin David Condic @ 2001-07-31 18:55 UTC (permalink / raw) That might or might not work, depending on what your requirements are for the external representation of the data. If you define the whole thing yourself, then whatever way you output the data is the way you input the data & defining the operations for the primitive types is (probably) good enough. However, you *could* be in trouble if there are requirements to traverse byte boundaries or find things in the middle of words or otherwise have to do something "wierd". You might also discover that this whole thing can get rather painful if you have lots of user defined primitive types. I've seen messages defined in systems that aren't easily dealt with via the Stream attributes. If you're limiting yourself to a subset of the possible representations of messages in a stream, you can get by, but if you have to deal with all of the possibilities it gets complicated. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ <tmoran@acm.org> wrote in message news:QAC97.18171$Kd7.10872006@news1.rdc1.sfba.home.com... > >you have to do *all* this (including implementing all the stream attributes for > >*all* types that will ever be used with the stream, excepting perhaps some > >composite types). With that much work involved, the streams aren't really > >providing you much except the supposedly nice syntax. > (I haven't tried this but ...) I think you just have to implement the > base types, and you need do it only once. So if you are going to be > doing a lot of systems where data goes between a machine of type A and > another B with different architecture or compiler, you can implement > integer'read etc just once, and all your different programs can use it > for integers ... composite types. Isn't that in fact done for the > Gnat distributed systems implementation? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-31 18:15 ` tmoran 2001-07-31 18:55 ` Marin David Condic @ 2001-07-31 20:26 ` Ted Dennison 1 sibling, 0 replies; 16+ messages in thread From: Ted Dennison @ 2001-07-31 20:26 UTC (permalink / raw) In article <QAC97.18171$Kd7.10872006@news1.rdc1.sfba.home.com>, tmoran@acm.org says... > >>you have to do *all* this (including implementing all the stream attributes for >>*all* types that will ever be used with the stream, excepting perhaps some >>composite types). With that much work involved, the streams aren't really >>providing you much except the supposedly nice syntax. > (I haven't tried this but ...) I think you just have to implement the >base types, and you need do it only once. So if you are going to be I have actually done some cross-platform (and cross-vendor) stream work. The approach you mention has the following problems: a) Not all discrete types are predefined. Integer types need not be derived from Integer, and then there's modular types and enumerations. I'd particularly expect to see different sizes used for enumerations. Some compilers might put small ones in a byte, while others would use whatever their machine word is. b) 'Output, 'Input, 'Class'Output, and 'Class'Input must deal with discriminants and unconstrained arrays. The standard says the discriminant/array length has to be written first, but says nothing about how many bytes are used to do it. The discriminant should probably get written using its type's 'Write, but there is no such thing for unconstrained array lengths. Thus you must rewrite 'Input, 'Output, 'Class'Input, and 'Class'Output for all such types (or at least all unconstrained array types, and the 'Write for all the discriminats on the discriminated ones). c) 'Class'Output and 'Class'Input on tagged types also have to deal with the tag. This is done using Tags.Internal_Tag. You can specify the external tag for a tagged type, but not the internal tag. Thus in order to write tagged types portably, you have to provide your own version of 'Class'Output and 'Class'Input for every tagged type. Among other nasty problems, this involves creating an algorithm that can come up with a portable unique tag for any type that might ever get derived from your tagged type. Think on that one for a while... d) One of the compilers I tried this on would not allow attribute definition clauses outside of the declarative section that contained the type in question's definition. That means that any clause for the predefined types would have to be written in Standard (which you cannot change, as per the standard). I don't know if this was allowable behavior, required behavior, or a bug. e) The streams themselves have to be implemented portably (eg: a series of Ada.Streams.Write's on one outputs the same bit pattern in the same order that it does on any other). This is mostly only a problem with user-created streams, as the predefined ones don't seem to leave much room for internal data manipulation. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 21:39 ` Ted Dennison 2001-07-30 22:28 ` tmoran @ 2001-07-31 7:44 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 16+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-07-31 7:44 UTC (permalink / raw) Ted Dennison<dennison@telepath.com> writes: > In article <3B658765.8F0E0939@canal-plus.fr>, Thierry Lelegard says... > >However, even this logical content is non standard. The very first > >reason for this is the horrible "type Stream_Element is mod > >implementation-defined" in Ada.Streams. You cannot base interoperability > >on an "implementation-defined" feature. > > > >> Or is the idea of streams that one should never try to access them > >> from a non-Ada language ? > > > >Yes, for the reason above. > > I'd say its a bit worse than that. You really shouldn't try to access them from > code that wasn't compiled with the same Ada compiler (unless you are *real* > careful). Even the same compiler on different platforms could give different > results. > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com Yes, in this respect Ada is in reality no better and no worse than C, regardless of streams and rep clauses. -- Kabelsalat ist gesund. Ole-Hj. Kristensen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-29 17:18 Distributed system portability Darren New 2001-07-30 8:00 ` Pascal Obry 2001-07-30 11:22 ` Thierry Lelegard @ 2001-07-30 15:57 ` Marin David Condic 2001-07-30 17:17 ` Darren New 2 siblings, 1 reply; 16+ messages in thread From: Marin David Condic @ 2001-07-30 15:57 UTC (permalink / raw) If you are using streams to communicate (perhaps via TCP/IP) between two processes, you've got some questionable portability problems. The ARM doesn't give you any guarantees about the representation of things in a stream - or even that stream elements will be 8 bit bytes, for that matter. So it is conceivable that what you compile on a PC and what you compile on a Sun using the same company's compiler may not actually be able to communicate via this route. You don't get any guarantees that the same compiler on the same machine in two different releases is going to keep the representations the same, so you can't even count on that. That said, one can bring up the practical side of things. It is unlikely that a compiler is going to change representations of various things dramatically from one version (or target) to the next without some good reasons. Its just a whole lot of work to have to change representations or maintain different representations and who needs that? It also has a habit of upsetting customers who didn't think much about the non-portability of this sort of thing. So a practical answer is to determine if the representations are compatible across the platforms of interest and, if so, carefully code to that. Isolate the translation from internal to external form down at a low level so that it is easy to fix. You can take precautions by overriding the 'Read & 'Write (or 'Input and 'Output) operations so that you get precise control, but this is possibly creating a bunch of work and may not fix all your troubles anyway. (Remember, a stream element size is not guaranteed either, so you've got to work around that as well.) Now if you go about using the Distributed Systems Annex, that's a different ball of wax and I'm afraid I've never made use of it to any serious extend & can't help you there. I seem to recall rumors that it followed some conventions for doing RPCs that might border on a "standard" and hence they might be a better way of guaranteeing portability. It all depends on what your system's requirements are. Can you use RPC's or do you have to blip raw bytes back & forth? Now if you have to interface to other systems that might be blipping data up and down the hose in a clearly defined format, you have just kicked the complexity up a notch. (*Bam*! :-) There is no easy way to do this except to roll-your-own WRT getting data into a byte array. If its a fairly fixed set of messages in the catalog, you at least have the help of representation clauses on records and Unchecked_Conversion - and that's better than you get with C, so you're ahead of the game there. If the catalog is large, then you're hosed because there is no really good way of getting there automagically from the 'Read, 'Write, 'Input & 'Output operations. You're going to have to do a lot of work to guarantee representation of every record type you want to send/receive. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Darren New" <dnew@san.rr.com> wrote in message news:3B644557.C599A03C@san.rr.com... > Is it generally the case that a distributed system compiled on two > different architectures can talk to itself? In other words, if I write a > distributed system with GNAT, and I compile one portion on Windows and > another portion on Linux, are these two systems likely to talk to each > other? If not, are the stream formats likely to be compatible? If not, > is there a way to redefine the low-level stream operators for things > like Integer to ensure that the same format is used at both ends? Or do > I need to write translation routines to some architecture-independent > format? > > I'm basically thinking of something where the clients would be > distributed, talking between themselves peer-to-peer. Does Ada's > portability mean I don't need to write a > translate-to-and-from-network-representation layer, because I can use > streams? > > -- > Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. > San Diego, CA, USA (PST). Cryptokeys on demand. > Only a WIMP puts wallpaper on his desktop. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Distributed system portability 2001-07-30 15:57 ` Marin David Condic @ 2001-07-30 17:17 ` Darren New 0 siblings, 0 replies; 16+ messages in thread From: Darren New @ 2001-07-30 17:17 UTC (permalink / raw) Thanks to *everyone* for the comments. I have much food for thought. :-) Actually, my plan is as follows: At each peer, I postulate a single persistant data store holding a rather complex set of data (primarily file attributes and routing information, etc.) I also have a client process to talk to each peer and to its own file store, exchanging data with other file stores. I have the portable spec for the communication messages, but I was hoping to defer having to deal with that for a while, in favor of ensuring that the algorithms will work as I think they will. If I can make the peer-to-peer stuff look like message passing or calls to protected objects, then I can layer the procedures that do the formatting into XML/MIME/BEEP/etc on top once I know it's worthwhile. Of course, this means I also get to release it earlier, with the understanding it only interoperates with certain versions of itself to start. > You're > going to have to do a lot of work to guarantee representation of every > record type you want to send/receive. Yeah. In reality, I've already defined the format in MIME and XML. I was just hoping I wouldn't need to implement the translation from Ada message sends into text libraries and such until after the rest of the system started humming. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com Only a WIMP puts wallpaper on his desktop. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-07-31 20:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-29 17:18 Distributed system portability Darren New 2001-07-30 8:00 ` Pascal Obry 2001-07-31 7:23 ` Frank 2001-07-31 16:35 ` Pascal Obry 2001-07-30 11:22 ` Thierry Lelegard 2001-07-30 13:05 ` Larry Kilgallen 2001-07-30 16:12 ` Thierry Lelegard 2001-07-30 21:39 ` Ted Dennison 2001-07-30 22:28 ` tmoran 2001-07-31 17:36 ` Ted Dennison 2001-07-31 18:15 ` tmoran 2001-07-31 18:55 ` Marin David Condic 2001-07-31 20:26 ` Ted Dennison 2001-07-31 7:44 ` Ole-Hjalmar Kristensen 2001-07-30 15:57 ` Marin David Condic 2001-07-30 17:17 ` Darren New
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox