Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140222
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Compiler tests |
| Date | 2019-01-25 10:03 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <q2ejd5$cor$1@dont-email.me> (permalink) |
| References | (25 earlier) <GHj2E.194369$gE1.67431@fx02.am4> <q2cj0a$o5t$1@dont-email.me> <aFm2E.274925$3si.175399@fx08.am4> <q2dadm$fae$1@dont-email.me> <4fr2E.149191$iL2.146583@fx17.am4> |
On 24/01/2019 23:46, Bart wrote:
> On 24/01/2019 21:24, David Brown wrote:
>> On 24/01/2019 18:32, Bart wrote:
>
>>> What makes you think my project isn't modular?
>>>
>>
>> Your obsession with single giant files, along with your dismissal of
>> sensible development tools and editors.
>
> You don't seem to understand how a module system works in this kind of
> language.
>
> When you write 'python prog.py' then it will automatically seek out and
> load any dependencies of prog.py, you don't need to list them all in an
> auxiliary file.
Python is an interpreted language, C is not.
>
> The same with my languages.
Fine. C is not like that. So what?
Don't misunderstand me. I have nothing against simple compilation, and
nothing against a module system that finds the files automatically. I
think it would be crazy to invent a new, modern language that did /not/
have automatic module handling. C's method is old fashioned, and comes
from an age of much slower systems - it is highly flexible, but that
often gives programmers too much flexibility and some people write
really jumbled code masses as a result.
So I agree that C has no good module system, and that a module system is
useful. In effect, I use make to compensate for that - so C's lack of
modules is not a problem at all.
What I object to is your attitude to all this. You get several things
completely wrong, IMHO:
1. You think C has a "problem" because it needs a build system to track
multiple files, compilation flags, etc. It does not have a problem - it
simply lacks a particular feature you like in some other languages. The
solution is simple - you use a build system. It really does not matter
if the build system is part of the language, or an external tool you use
with the language. Having it external means it is not standardised - it
also means developers have choices. (Some like make, some like IDE's,
etc.). View it in the same class as an editor.
2. You think that when you have automatic dependency handling in a
language, you don't need a build system. This is wrong - no language
has everything it needs built in. I use "make" along with my Python
projects. If I used your language, I'd use make too. People use "make"
(or other build systems) for compilation, pre-processing,
post-processing, testing, deployment, documentation extraction, and many
other tasks associated with program development.
3. You think "make" is incomprehensible. This is a combination of
laziness on your part, and that some makefiles /are/ hard to understand.
You can choose to write simple or complex makefiles - different people
put different things there. Consider it a program - part of the
project. The more flexible and generic it is, the more complex the
makefile will be to write, but the simpler it will be to use. A simple
makefile might list the source files and dependencies manually. A
complex one will figure them out automatically - simply adding a new C
file to the project directory adds it to the build.
4. You think it is an overwhelming concern that the tools and programs
used are small in size and small in number. Sure, it is convenient if
you need fewer bits and pieces, but it is a very minor issue. What is
important is how convenient they are to use, not what lies behind them.
It is important that when you type "make", you get an appropriate build
of your project - it does not matter if that invokes 2 programs at 1 MB
each, or 200 programs with 10 GB of files behind them.
5. You think that /your/ method of solving problems is inherently
superior to everyone else's. Most programmers are perfectly happy using
a build system of some sort to handle dependencies and modules. For
many, that means an IDE - for others, it means "make", "cmake", "ninja",
or whatever suits their tastes and needs best. Having a language that
lets you do your build with a single command "solves" a non-existent
problem.
>
> I don't use giant files except for C distributions, where they are a
> by-product of how my translator works.
>
> Most build systems will take N source files and produce 1 .exe or .dll
> file.
>
OK.
> My compiler will take N source files and produce 1 .exe or .dll file, or
> sometimes 1 .c file. So the principle is no different. But my compiler
> will do it all in one go and without needing any extra information, by
> making use of its module system.
>
> That means it's more sophisticated that your tools.
>
No, it means it is more limited. If it does the job you need, fine. It
won't do the job I need. I need more from my tools than you can give -
if I were to do my development in your language, with your tools, I
would still need "make" for everything around the build. (And I'd still
use "make" for compilation, even if it were just a single command from a
single C file, because that lets me track the exact version of the
compiler and the exact flags.)
>
>>> gcc cc.c
>>
>> How is it that you think it's fine to give lists of modules to compile
>> in a C file (or "mm" file, or whatever language you use) but if the
>> list is in a file called "Makefile", you'd rather poke your eyes out
>> with a sharp stick?
>
> The vital information needed to build, is primarily a list of modules.
> My language can work that out. C can't (except for specially written
> programs using my experimental -auto option, the idea proposed by Anton
> Shepelev).
For the C language, the concept does not even make sense. For a C
implementation, it does. With an appropriate filesystem layout, gcc and
make can happily find the C files needed and handle dependency
generation. When I add a new C file or header to a project, I put it in
the project directory and type "make". It all works automatically.
People who use IDE's for handling their project builds get the same
level of convenience.
>
> So it needs an explicit list of modules. That's fine. But no makefile
> I've seen has ever been that simple. This is the @ file I use to build
> Seed7:
It is entirely possible to have equally simple makefiles:
CFILES = s7.c runerr.c option.c primitiv.c ...
HFILES = runerr.h option.h primitiv.h ...
CFLAGS = -Os -Wall
program.exe : $(CFILES) $(HFILES)
gcc $(CFLAGS) $(CFILES) -o $@
If you want to find the C files and H files automatically, you can use this:
CFILES = $(wildcard *.c)
HFILES = $(wildcard *.h)
instead of a manual list.
With this, make will recompile everything whenever a C or H file
changes, which is what you like.
The next step up would be to compile to object files, then link:
# Simple generic makefile
CFILES = $(wildcard *.c)
HFILES = $(wildcard *.h)
OFILES = $(CFILES:.c=.o)
CFLAGS = -Os -Wall
LDFLAGS = -Os -Wall
%.o : %.c $(HFILES)
gcc $(CFLAGS) -c $< -o $@
program.exe : $(OFILES)
gcc $(LDFLAGS) $(OFILES) -o $@
That makefile will take all the ".c" files in your directory, compile
them to ".o" object files, then link them to "program.exe". It will
re-compile a C file any time that C file changes, or any of the header
files change. And it will relink program.exe whenever any of the object
files change. It will work fine with parallel builds ("make -j"), and
does incremental building.
It is possible to get a great deal here from just a dozen lines of
makefile. I am sure you can figure out most of what the lines do.
It is also possible to get a lot more complex - I do my builds in trees,
with the generated files separated from the code files, with much more
sophisticated dependency handling, and lots of flags. But you certainly
don't have to do that.
>
> There is nothing to understand about this, it's just a list. The same
> list can work for different compilers. And I could chose to submit the
> list by hand. Or invoke the compiler one at a time for each .c file. It
> is not an obstacle or hindrance to overcome like a makefile file.
>
> This information /HAD TO BE PAINFULLY EXTRACTED FROM AN ACTUAL
> MAKEFILE/. (And there were 17 variations to choose from. Think about it
> - why were there 17 variations? Aren't they just script files and
> therefore ultimately flexible?).
Or you could just use make - adapting one of the makefiles to suit. I
don't know why there are 17 different makefiles here - I did not write
the "seed7" project, nor have I looked at it. It is quite possible to
write makefiles that handle multiple build environments - it's up to the
project developer to choose what suits them.
By the way, "make -n" will print a list of the commands make would have
run. That might make things easier for you in the future.
>
>> That word doesn't even begin to describe you - after all, the
>> technology you reject is decades old.
>
> Yes, it is. Maybe that's why I reject it.
>
Note that it is 40 years old, and still with us. Alternatives have come
and gone, and there are plenty of situations where other build systems
are a better choice. But the fact is, "make" remains popular because it
is really good at the job. It works fine, people use it. It is not
perfect by any means, but none of its problems are enough to stop it
being the tool of choice for a huge number of developers and projects.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
csiph-web