* [9fans] Sleep-complexity @ 2005-05-08 12:03 Christoph Lohmann 2005-05-08 12:51 ` Sergey Reva 0 siblings, 1 reply; 26+ messages in thread From: Christoph Lohmann @ 2005-05-08 12:03 UTC (permalink / raw) To: 9fans Good day. Just do be sure that there is no scientifc paper that describes the pro of using for() in sleep(2), as an architecture decision: % cat /n/sources/plan9/sys/src/cmd/sleep.c #include <u.h> #include <libc.h> void main(int argc, char *argv[]) { long secs; if(argc>1) for(secs = atol(argv[1]); secs > 0; secs--) sleep(1000); exits(0); } % cat /sys/src/cmd/sleep.c #include <u.h> #include <libc.h> void main(int argc, char *argv[]) { if(argc>1) sleep(atol(argv[1]) * 1000); exits(0); } % ls -l /386/bin/sleep /386/bin/_sleep --rwxrwxr-x M 8 none sys 3409 May 8 13:43 /386/bin/_sleep --rwxrwxr-x M 8 sys sys 3390 Max 8 13:44 /386/bin/sleep Is there any reason for the for()-loop? Sincerely, Christoph ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 12:03 [9fans] Sleep-complexity Christoph Lohmann @ 2005-05-08 12:51 ` Sergey Reva 2005-05-08 16:50 ` Russ Cox 0 siblings, 1 reply; 26+ messages in thread From: Sergey Reva @ 2005-05-08 12:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hello Fans, > Is there any reason for the for()-loop? Without 'for' you can't call: sleep max-long-value I wont also add question: sysproc.c: > long > syssleep(ulong *arg) > { > int n; > n = arg[0]; > man 2 sleep > int sleep(long millisecs) Why 'n' not defined as long? -- http://rs-rlab.narod.ru mailto:rs_rlab@mail.ru ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 12:51 ` Sergey Reva @ 2005-05-08 16:50 ` Russ Cox 2005-05-08 17:28 ` Dan Cross 0 siblings, 1 reply; 26+ messages in thread From: Russ Cox @ 2005-05-08 16:50 UTC (permalink / raw) To: Sergey Reva, Fans of the OS Plan 9 from Bell Labs > Why 'n' not defined as long? because long and int are the same so it really doesn't matter. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 16:50 ` Russ Cox @ 2005-05-08 17:28 ` Dan Cross 2005-05-08 18:56 ` jmk 2005-05-08 21:12 ` Charles Forsyth 0 siblings, 2 replies; 26+ messages in thread From: Dan Cross @ 2005-05-08 17:28 UTC (permalink / raw) To: Russ Cox, Fans of the OS Plan 9 from Bell Labs On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote: > > Why 'n' not defined as long? > > because long and int are the same so it really doesn't matter. That's not a terribly great assumption to make, is it? - Dan C. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 17:28 ` Dan Cross @ 2005-05-08 18:56 ` jmk 2005-05-08 19:21 ` Bruce Ellis 2005-05-08 22:40 ` Dan Cross 2005-05-08 21:12 ` Charles Forsyth 1 sibling, 2 replies; 26+ messages in thread From: jmk @ 2005-05-08 18:56 UTC (permalink / raw) To: 9fans On Sun May 8 13:29:11 EDT 2005, cross@math.psu.edu wrote: > On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote: > > > Why 'n' not defined as long? > > > > because long and int are the same so it really doesn't matter. > > That's not a terribly great assumption to make, is it? > > - Dan C. It would take a lot of work get get Plan9 to work on a machine where that isn't the case, and I don't see anyone jumping up to do it. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 18:56 ` jmk @ 2005-05-08 19:21 ` Bruce Ellis 2005-05-08 20:54 ` Charles Forsyth 2005-05-08 22:40 ` Dan Cross 1 sibling, 1 reply; 26+ messages in thread From: Bruce Ellis @ 2005-05-08 19:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Kinda reminds me of RedHat for the Alpha. Everything compiled and was distributed. It's just that a lot of things didn't work because of 64 vs 32 bit not to mention that user address space started at 0x100000000. The worst hit was the networking code. I'm sure things are *better* now - certainly the second release I tried had a different set of non-functioning programs. dhog's plan9 was a better choice. brucee On 5/9/05, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote: > On Sun May 8 13:29:11 EDT 2005, cross@math.psu.edu wrote: > > On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote: > > > > Why 'n' not defined as long? > > > > > > because long and int are the same so it really doesn't matter. > > > > That's not a terribly great assumption to make, is it? > > > > - Dan C. > > It would take a lot of work get get Plan9 to work on a > machine where that isn't the case, and I don't see anyone > jumping up to do it. > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 19:21 ` Bruce Ellis @ 2005-05-08 20:54 ` Charles Forsyth 2005-05-08 21:06 ` Charles Forsyth 0 siblings, 1 reply; 26+ messages in thread From: Charles Forsyth @ 2005-05-08 20:54 UTC (permalink / raw) To: 9fans >>dhog's plan9 was a better choice. yes, and it seems to be the correct one for most systems, given existing software -- not just Plan 9, but including Linux -- but evidently some people enjoy inflicting needless pain. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 20:54 ` Charles Forsyth @ 2005-05-08 21:06 ` Charles Forsyth 0 siblings, 0 replies; 26+ messages in thread From: Charles Forsyth @ 2005-05-08 21:06 UTC (permalink / raw) To: 9fans >>but evidently some people enjoy inflicting needless pain. another example is the filth surrounding 64 bit file sizes and offsets on 'nix. (give me strength.) during the early streams/socket wars someone coined the term `incompatibility library'. that's one that purports to provide compatibility with another interface so you can use your existing source and binaries but gets it wrong enough that you need to change and recompile them anyway, so that you didn't need the library. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 18:56 ` jmk 2005-05-08 19:21 ` Bruce Ellis @ 2005-05-08 22:40 ` Dan Cross 2005-05-08 22:59 ` geoff 2005-05-09 7:41 ` David Tolpin 1 sibling, 2 replies; 26+ messages in thread From: Dan Cross @ 2005-05-08 22:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, May 08, 2005 at 02:56:15PM -0400, jmk@plan9.bell-labs.com wrote: > > > because long and int are the same so it really doesn't matter. > > > > That's not a terribly great assumption to make, is it? > > It would take a lot of work get get Plan9 to work on a > machine where that isn't the case, and I don't see anyone > jumping up to do it. That's true, but I still wouldn't go as far as sanctioning the practice. Also, a fair amount of Plan 9 code is now running under various other platforms where that's not necessarily the case via plan9ports. Charles's point about the subtleness of type-sizing not withstanding (in the original case, someone was passing an int in place of a long, which would be promoted automatically), it's still something one should be careful about. All the world is no longer a 32-bit 386. - Dan C. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 22:40 ` Dan Cross @ 2005-05-08 22:59 ` geoff 2005-05-09 7:28 ` Richard Miller ` (2 more replies) 2005-05-09 7:41 ` David Tolpin 1 sibling, 3 replies; 26+ messages in thread From: geoff @ 2005-05-08 22:59 UTC (permalink / raw) To: 9fans > All the world is no longer a 32-bit 386. True, but the pain of the PDP-11-to-VAX migration, when `int' changed from 16 bits to 32, seems to have convinced the standards organisations that they don't want to change the sizes of any integral types. The proposed sizes for 64-bit implementations (in `LLP64') are: 32 bits for int and long, 64 for long long and pointers. And ANSI & POSIX will continue to paper over size differences with *_t types. I'd prefer 64-bit longs and no long longs (or 128-bit long longs), but that seems unlikely given the vast existing corpus of code written without much attention to types. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 22:59 ` geoff @ 2005-05-09 7:28 ` Richard Miller 2005-05-09 13:14 ` Brantley Coile 2005-05-09 16:45 ` Mike Haertel 2 siblings, 0 replies; 26+ messages in thread From: Richard Miller @ 2005-05-09 7:28 UTC (permalink / raw) To: 9fans > True, but the pain of the PDP-11-to-VAX migration, when `int' changed > from 16 bits to 32 s/VAX/Interdata/ -- Richard ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 22:59 ` geoff 2005-05-09 7:28 ` Richard Miller @ 2005-05-09 13:14 ` Brantley Coile 2005-05-09 16:45 ` Mike Haertel 2 siblings, 0 replies; 26+ messages in thread From: Brantley Coile @ 2005-05-09 13:14 UTC (permalink / raw) To: 9fans In thinking about char, short, int, long, long long, it appears that int is an exception. It was supposed to be the natural machine word. Plan 9 uses int, as stated earlier, mostly in loop counters and such things. In that case making int be 64 bits on 64 bit machines would make sense only if loading and storing 64 bits was the just as fast at 32 bits. I don't think I need 64 bits to count to 1000. My main point here is that types describe various sizes of intergers available in a machine. If the machine can do four sizes of integers, then C needs four types to specify them. Brantley ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 22:59 ` geoff 2005-05-09 7:28 ` Richard Miller 2005-05-09 13:14 ` Brantley Coile @ 2005-05-09 16:45 ` Mike Haertel 2005-05-09 20:10 ` Bruce Ellis 2 siblings, 1 reply; 26+ messages in thread From: Mike Haertel @ 2005-05-09 16:45 UTC (permalink / raw) To: 9fans >> All the world is no longer a 32-bit 386. > >True, but the pain of the PDP-11-to-VAX migration, when `int' changed >from 16 bits to 32, seems to have convinced the standards >organisations that they don't want to change the sizes of any integral >types. The proposed sizes for 64-bit implementations (in `LLP64') >are: 32 bits for int and long, 64 for long long and pointers. And >ANSI & POSIX will continue to paper over size differences with *_t >types. > >I'd prefer 64-bit longs and no long longs (or 128-bit long longs), but >that seems unlikely given the vast existing corpus of code written >without much attention to types. Wow, you're a little out of date. The *BSDs and Linux did the Right Thing: on Alpha and AMD64 (the two flavors of which I have personal knowledge) "long" is 64 bits. So the vast corpus of software that has been ported to 64-bit *BSD and Linux systems is now free of the assumption that sizeof (int) == sizeof (long). There is still a pervasive assumption that ints are 32 bits. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-09 16:45 ` Mike Haertel @ 2005-05-09 20:10 ` Bruce Ellis 2005-05-09 22:46 ` Charles Forsyth 0 siblings, 1 reply; 26+ messages in thread From: Bruce Ellis @ 2005-05-09 20:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I'm out of date? RedHat still doesn't *work* on the alpha?! I don't know what the *right thing* is but shipping code that compiles but doesn't work ain't it. brucee > Wow, you're a little out of date. > > The *BSDs and Linux did the Right Thing: on Alpha and AMD64 > (the two flavors of which I have personal knowledge) "long" > is 64 bits. > > So the vast corpus of software that has been ported to > 64-bit *BSD and Linux systems is now free of the assumption > that sizeof (int) == sizeof (long). > > There is still a pervasive assumption that ints are 32 bits. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-09 20:10 ` Bruce Ellis @ 2005-05-09 22:46 ` Charles Forsyth 0 siblings, 0 replies; 26+ messages in thread From: Charles Forsyth @ 2005-05-09 22:46 UTC (permalink / raw) To: 9fans >>I don't know what the *right thing* is but shipping code that >>compiles but doesn't work ain't it. i also looked at the most up-to-date versions of several utilities and they do not, in fact, do the `right thing'. i mentioned `incompatibility libraries'? well, there's a technique with wider scope. that's where you get everyone to change their programs to leave things in nearly the same shape (except perhaps for bugs introduced thereby). (Governments are prone to this.) ``Something must be done. This is something. Therefore we must do it.'' -- Yes, Prime Minister ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 22:40 ` Dan Cross 2005-05-08 22:59 ` geoff @ 2005-05-09 7:41 ` David Tolpin 1 sibling, 0 replies; 26+ messages in thread From: David Tolpin @ 2005-05-09 7:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > All the world is no longer a 32-bit 386. > 640 kilobytes of RAM is enough for everybody. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 17:28 ` Dan Cross 2005-05-08 18:56 ` jmk @ 2005-05-08 21:12 ` Charles Forsyth 2005-05-09 13:29 ` Nigel Roles 2005-05-10 17:09 ` boyd, rounin 1 sibling, 2 replies; 26+ messages in thread From: Charles Forsyth @ 2005-05-08 21:12 UTC (permalink / raw) To: 9fans >> because long and int are the same so it really doesn't matter. >That's not a terribly great assumption to make, is it? the assumption usually made in practice is a little more subtle: int <= long[=32] < long long [=64]. most older programs tended to use int for things such as for loop values, that probably needed to be at least 16 bits, but might not need to be as much as 32. by contrast, a `long' quite often needed to be 32 bits, and often that was `no more, no less'. it's historically consistent and works well enough. u32int etc are used a bit more these days, but not exclusively. the other subtle assumptions concern pointers and integers. as it happens, the best choice there is happily consistent with dhog's, although he didn't face that problem in his alpha port. it does need source code changes, but with care, they tend to be fairly limited, outside the kernel. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 21:12 ` Charles Forsyth @ 2005-05-09 13:29 ` Nigel Roles 2005-05-09 14:03 ` Charles Forsyth 2005-05-10 17:09 ` boyd, rounin 1 sibling, 1 reply; 26+ messages in thread From: Nigel Roles @ 2005-05-09 13:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >the assumption usually made in practice is a little more subtle: >int <= long[=32] < long long [=64]. most older programs tended >to use int for things such as for loop values, that probably needed to be >at least 16 bits, but might not need to be as much as 32. >by contrast, a `long' quite often needed to be 32 bits, and often >that was `no more, no less'. > > > I'll probably regret this, but the gcc x86_64 approach hasn't worked out too badly. When we did our 64 bit port recently, it was only cases of trying to stash a pointer in an int which bit us. When I say us, I mean the authors of certain Linux packages. At one time I thought there was a maxim of "int is the efficient machine size, long is big enough to hold a pointer", so gcc x86_64 can claim to meet that reasoning. Nigel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-09 13:29 ` Nigel Roles @ 2005-05-09 14:03 ` Charles Forsyth 0 siblings, 0 replies; 26+ messages in thread From: Charles Forsyth @ 2005-05-09 14:03 UTC (permalink / raw) To: 9fans i'd suspect that the gcc 64-bit long forces more changes than the other approach, because i tried both with plan 9, and subsequently looked at a fair bit of non-plan9 code. in fact, i tried x86_64's approach first for just the reason given: code that fiddles with pointers as ints (in plan 9) often uses ulong, though not invariably so, and having long as 64 bits keeps that code working. as it turns out, relatively few things these days--certainly in plan 9-- fiddle with pointers as integers (directly, that is, not say through varargs). those can be found by the compiler (as gcc does with pointer -> int on amd64). by contrast, it's very hard for a compiler to find, reliably, instances where long is assumed to be 32 bits. bitmasks, loop bounds, ... there are surprisingly many, things break weirdly, often obscurely, or just on boundary cases, and having found myself in a world of pain... i changed my mind. all is relative sweetness and light. at least the compiler moans instead of me. non-plan9 code might go a little better because most of (say) the FSF code probably assumes int is 32, so programmers typically put the subtle 32-bit assumptions on `int', not `long'. thus when long changes, it's less troublesome. even so, quite a few do use long in contexts where 64-bits is not particularly useful, probably not intended, and 32 bits would be a better representation. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-08 21:12 ` Charles Forsyth 2005-05-09 13:29 ` Nigel Roles @ 2005-05-10 17:09 ` boyd, rounin 2005-05-10 17:15 ` jmk 1 sibling, 1 reply; 26+ messages in thread From: boyd, rounin @ 2005-05-10 17:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> because long and int are the same so it really doesn't matter. > >That's not a terribly great assumption to make, is it? no. as for the alpha: i tried to argue with CRL about their appalling choice integral type sizes, to no avail. -- MGRS 31U DQ 52572 12604 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 17:09 ` boyd, rounin @ 2005-05-10 17:15 ` jmk 2005-05-10 18:34 ` boyd, rounin 0 siblings, 1 reply; 26+ messages in thread From: jmk @ 2005-05-10 17:15 UTC (permalink / raw) To: 9fans On Tue May 10 13:10:50 EDT 2005, boyd@insultant.net wrote: > >> because long and int are the same so it really doesn't matter. > > > >That's not a terribly great assumption to make, is it? > > no. > > as for the alpha: i tried to argue with CRL about their > appalling choice integral type sizes, to no avail. > -- > MGRS 31U DQ 52572 12604 what was their choice? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 17:15 ` jmk @ 2005-05-10 18:34 ` boyd, rounin 2005-05-10 18:39 ` rog 2005-05-10 19:27 ` Ronald G. Minnich 0 siblings, 2 replies; 26+ messages in thread From: boyd, rounin @ 2005-05-10 18:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > what was their choice? long == 64 bits int == 32 bits short == 16 bits i argued: long == 32 bits int == 64 bits short == 16 bits based on 'int' being a machine word. -- MGRS 31U DQ 52572 12604 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 18:34 ` boyd, rounin @ 2005-05-10 18:39 ` rog 2005-05-10 19:27 ` Ronald G. Minnich 1 sibling, 0 replies; 26+ messages in thread From: rog @ 2005-05-10 18:39 UTC (permalink / raw) To: 9fans > i argued: > > long == 32 bits > int == 64 bits > short == 16 bits > > based on 'int' being a machine word. ha ha ha! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 18:34 ` boyd, rounin 2005-05-10 18:39 ` rog @ 2005-05-10 19:27 ` Ronald G. Minnich 2005-05-10 21:02 ` David Leimbach 1 sibling, 1 reply; 26+ messages in thread From: Ronald G. Minnich @ 2005-05-10 19:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, 10 May 2005, boyd, rounin wrote: > > what was their choice? > > long == 64 bits > int == 32 bits > short == 16 bits > > i argued: > > long == 32 bits > int == 64 bits > short == 16 bits IIRC that is what SGI did, correct? ron ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 19:27 ` Ronald G. Minnich @ 2005-05-10 21:02 ` David Leimbach 2005-05-10 21:20 ` Bruce Ellis 0 siblings, 1 reply; 26+ messages in thread From: David Leimbach @ 2005-05-10 21:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 5/10/05, Ronald G. Minnich <rminnich@lanl.gov> wrote: > > > On Tue, 10 May 2005, boyd, rounin wrote: > > > > what was their choice? > > > > long == 64 bits > > int == 32 bits > > short == 16 bits > > > > i argued: > > > > long == 32 bits > > int == 64 bits > > short == 16 bits > > IIRC that is what SGI did, correct? > That would violate the C standard. sizeof (short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). I doubt anyone did this. > ron > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] Sleep-complexity 2005-05-10 21:02 ` David Leimbach @ 2005-05-10 21:20 ` Bruce Ellis 0 siblings, 0 replies; 26+ messages in thread From: Bruce Ellis @ 2005-05-10 21:20 UTC (permalink / raw) To: David Leimbach, Fans of the OS Plan 9 from Bell Labs some standards/people need to be violated - with extreme prejudice. brucee On 5/11/05, David Leimbach <leimy2k@gmail.com> wrote: > On 5/10/05, Ronald G. Minnich <rminnich@lanl.gov> wrote: > > > > > > On Tue, 10 May 2005, boyd, rounin wrote: > > > > > > what was their choice? > > > > > > long == 64 bits > > > int == 32 bits > > > short == 16 bits > > > > > > i argued: > > > > > > long == 32 bits > > > int == 64 bits > > > short == 16 bits > > > > IIRC that is what SGI did, correct? > > > > That would violate the C standard. > > sizeof (short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). > > I doubt anyone did this. > > > ron > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-05-10 21:20 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-08 12:03 [9fans] Sleep-complexity Christoph Lohmann 2005-05-08 12:51 ` Sergey Reva 2005-05-08 16:50 ` Russ Cox 2005-05-08 17:28 ` Dan Cross 2005-05-08 18:56 ` jmk 2005-05-08 19:21 ` Bruce Ellis 2005-05-08 20:54 ` Charles Forsyth 2005-05-08 21:06 ` Charles Forsyth 2005-05-08 22:40 ` Dan Cross 2005-05-08 22:59 ` geoff 2005-05-09 7:28 ` Richard Miller 2005-05-09 13:14 ` Brantley Coile 2005-05-09 16:45 ` Mike Haertel 2005-05-09 20:10 ` Bruce Ellis 2005-05-09 22:46 ` Charles Forsyth 2005-05-09 7:41 ` David Tolpin 2005-05-08 21:12 ` Charles Forsyth 2005-05-09 13:29 ` Nigel Roles 2005-05-09 14:03 ` Charles Forsyth 2005-05-10 17:09 ` boyd, rounin 2005-05-10 17:15 ` jmk 2005-05-10 18:34 ` boyd, rounin 2005-05-10 18:39 ` rog 2005-05-10 19:27 ` Ronald G. Minnich 2005-05-10 21:02 ` David Leimbach 2005-05-10 21:20 ` Bruce Ellis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).