Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: High level C |
| Date | 2016-08-03 11:56 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <nnt7d2$bpt$1@dont-email.me> (permalink) |
| References | (11 earlier) <kfnfuqpl53h.fsf@x-alumni2.alumni.caltech.edu> <nnmntn$4ps$1@dont-email.me> <kfnlh0gjzll.fsf@x-alumni2.alumni.caltech.edu> <nno29s$csj$1@dont-email.me> <kfn4m71kgc1.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Tim Rentsch wrote: >>> Les Cargill <lcargill99@comcast.com> writes: >>> >>>> Tim Rentsch wrote: >>>>> Les Cargill <lcargill99@comcast.com> writes: >>>>> >>>>>> Tim Rentsch wrote: >>>>>>> Melzzzzz <mel@zzzzz.com> writes: >>>>>>> >>>>>>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>>>>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>>>>>> >>>>>>>>> There is a common belief in some circles that GC incurs a >>>>>>>>> substantial performance penalty relative to manual coding of >>>>>>>>> free(), etc. Experience with actual systems does not bear this >>>>>>>>> out. Indeed, the experience in some large code bases has been >>>>>>>>> that switching to GC actually improves performance. >>>>>>>> >>>>>>>> Care to show links? >>>>>>> >>>>>>> Unfortunately I don't know any. The only specific examples I >>>>>>> know of are proprietary. I am not aware of any where the >>>>>>> results are publically available. >>>>>>> >>>>>>>> I find hardly to believe that deallocation increase >>>>>>>> performance... >>>>>>>> Stopping program to perform memory scan and trashing memory in process >>>>>>>> is faster? how so? >>>>>>> >>>>>>> I think it's pretty easy to understand. If you do manual >>>>>>> deallocation, bookkeeping needs to be done to keep track of what >>>>>>> is referenced to know when something can be deallocated. >>>>>> >>>>>> No, you simply have to have an explicit context for the lifetime of >>>>>> objects. I personally have never witnessed where this was all that >>>>>> onerous. Most things we do can be chunked into "frames" like that. >>>>> >>>>> Certainly that can be done in some cases. I believe there >>>>> are also cases where it cannot be done, or at least cannot >>>>> be done without a fair amount of difficulty. I didn't >>>>> mean to say that getting a performance improvement is >>>>> typical, only that it does sometimes occur in real cases. >>>> >>>> I'm not sure what you're after here. Most 'C' programs I've used >>>> may use dynamic ( or, more probably semi-dynamic) allocation behind >>>> the scenes but applications I've dealt with largely tended to >>>> accumulate a set of buffers and working storage, and after a short >>>> while, became memory-stable. >>>> >>>> For the curious, this does indeed include things that have significant >>>> levels of dynamically configured objects that get created and >>>> destroyed. You can often see the same sort of approach taken in the >>>> Linux kernel - configuration options for the maximum number of object >>>> <x> are part of the kernel build. This creates arrays that are then >>>> dynamically used. >>>> >>>> This is just a very 'C' thing to do. >>> >>> Obviously the behavior depends a lot on the application. At one >>> end of the spectrum, a program to do base64 encoding/decoding is >>> likely to need essentially zero allocated memory. Closer to the >>> other end of the spectrum, a web browser is going to need new >>> memory every time a new web page is opened (and ideally discard >>> it when the page is closed). >> >> So the total number of web browsers in the world probably fits in one >> digit. This is hardly an argument for a language system providing all >> the support for that level of dynamic-ness. > > This comment surprises me coming from you. All the applications > named were meant only as examples in their respective areas of > the spectrum. For the browser area, any large-scale, > long-running application qualifies, and there are lots of those: > databases, word processors, spreadsheets, even text editors. > Let's say a code base of 250,000 lines or more. Naturally there > won't be too many programs of that size, because anything of > such a scale is a significant undertaking to develop. But they > are disproportionally important for that very reason, and also > because their nature requires them to be resiliant in the face > of very long lifetimes. > The question I thought I was answering :) is "what's the value of the language system providing a rich GC functionality." >>> As a rule in my own browser usage, >>> I always open news tabs, and hardly ever close them. (Of course >>> I do close most of them eventually, but not right away.) >> >> I close them as soon as I'm done. I have little doubt that they leak >> memory, at least in terms of how the instrumentation for "memory used" >> is concerned. I can close the whole thing ( after individually closing >> tabs) and memory used drops. But there's a hunk of the executable that >> stays resident after. > > I agree with your observations about memory usage. I suspect > (although of course I don't know) that some of the memory > leak behaviors derives from being overly cautious about > freeing memory that might still be in use. My experience > (admittedly not very diverse) with web browers is that they > never reach a point of being memory stable; at some point > the browser has to be shut down and restarted, in order to > get the ever-increasing amount of unused memory back. > >>> Somewhere in between the end points we might put a compiler. >>> It starts off using a small amount of memory, and allocates as >>> it reads more source. Then there is more allocation during >>> semantic analysis to do type checking, optimization, checks >>> for warning conditions, etc. Of course a compiler might adopt >>> a strategy of simply never deallocating, which is probably >>> workable in some cases. But that's just a poor man's GC - >>> if a program is going to call malloc() and never call free(), >>> assuming it doesn't hide pointers in some sneaky way then >>> it might as well take advantage of drop-in conservative >>> collector, which could allow it to compile larger programs >>> than it could otherwise. >> >> "A compiler" is generally multiple executables. Each has a pretty >> proscribed, even pipe-ey task to perform. They're kinda "stream in, >> stream out" sorts of programs. > > That helps separate the different phases, but the same > observation applies to the phases individually. And some > information needs to be passed or replicated downstream, > for example source location information, so error messages > can be given. The key point is allocation has to be > managed somehow, and potentially unbounded program source > means potentially unbounded allocation for structures to > represent that source. We might take the optimistic view > that the code will simply allocate and never free(), which > actually isn't an unreasonable choice in some situations. > The question is what alternatives are available when we > don't want to make that choice? > >>> Long story short: yes, it depends on the application. But >>> in general the larger the application the more likely it is >>> to be doing a lot of allocation and deallocation, and the >>> more likely it is that deallocation doesn't follow an easily >>> predictable pattern. >> >> So color me less than sympathetic. It all just sounds like people >> throwing up their hands to me. >> >> If I have a point, it is that developing a culture of rational >> ignorance about object lifetimes seems risky to me. I *perceive* this >> as an artifact of people being...traumatized by memory leaks in their >> CS 101 phase and becoming somewhat over-sensitive to it. Or something. >> >> In the larger scheme of things, it's a sufficiently proscribed >> problem that we believe it can be automated, so it should not be too >> much afraid of doing in in other ways, if that makes any sense in the >> first place. > > I don't think GC is any sort of panacea. Using GC doesn't > eliminate the need to think about how memory resources are used, > and it would be foolish to pretend otherwise. Furthermore there > are situations where a malloc/free discipline is a better > choice, or even some more restrictive strategy. (IIRC Knuth > chose a fixed-size allocation arena for TeX so that he could > guarantee reproducible results on different systems.) I think > there are people on both sides of the fence who believe GC is > some sort of utopia (or "utopia"). It isn't. It is just as > wrong to think GC should always be used as to think it should > never be used. In talking about GC and advocating that it be > available as an option in C, my goal is not to get people to > adopt it blindly but to start a real conversation, to be able to > talk about the pluses and minuses without getting bogged down > in various misconceptions (here again, on both sides of the > fence). I have no desire to develop a culture of rational > ignorance - exactly the opposite. > Well, I'm guessing about how this came to pass, so I probably got it wrong. I am just skeptical of the value of GC in general. I don't fully comprehend how it is that doing memory allocation manually is onerous. I don't "do GUIs" so much ( just a little ) so I'm sure that accounts for a lot of the bias. What GUIs I have built use toolchains where objects are still allocated and deallocated in code. >> And to be even more specific, I own things that obviously run Java and >> they tend to be less reliable than the things that run 'C'. I have a >> BluRay player and you have to unplug it from the wall now and again and >> let all the "memory to go a ground state" type thing. > > I have experience with Java but essentially no experience with > the Java community or Java culture. It may be that Java culture, > or some parts of Java culture, take a naive view of how memory > allocation should be dealt with (or not). If that is so then I > would say that is a fault of the Java culture, not a fault of > Java having automatic storage management. (In particular, Java > has weak references in various forms. Java does not (yet?) have > ephemerons, but AIUI there are proposals to add ephemerons to > Java.) > I've seen enough to know that I wouldn't want Java in anything critical. >>> If we weight our samples by how many >>> lines of code are involved, I think most of the code will >>> allocating and deallocating a fair amount. Do you agree >>> with that, or disagree? >> >> I have to admit that I only know on a shallow level. >> >> >>> Your example of the Linux kernel is a good one. However, >>> I think it is not typical of most large C programs. >> >> Yeah, it could easily be a bias - most things I do are closer to >> your base64 converter. They may be in user space, but they tend to be >> very "driver-ey". > > Clearly there are lots of cases, even whole categories of > programs, where conventional management disciplines are a > better choice than dragging in all the machinery needed > for GC. Part of the reason for starting the discussion is > to be able to talk about which are which. > I expect that there are just different cultures, that people who expect 'C' to do GC aren't people who perhaps "should" be looking at 'C'. The competitors to 'C' these days are more on the line of Python and/or Rust. -- Les Cargill
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
csiph-web