======================================================================= 1 ===
Date:    01 Jun 1995 00:28:19 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: more m3build wishes

Farshad's question about using m3build to generate documentation
reminded me of something else I'd like to do with m3build.

Basically, I'd like it to be possible to integrate RCS into m3build,
so that whenever a package properly compiles it checks all the source
files in using a new minor revision.

Similarly, when a package is shipped, a new major revision could be
checked in.

If nobody else has done this, I may try it sometime.  Any ideas or
comments?
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 2 ===
Date:    Thu, 01 Jun 95 13:58:37 -0700
From:    kalsow@pa.dec.com
Subject: Re: more m3build wishes 

Spencer:

   From the little that I've explored, it seems that m3build
   is just short of being a language in and among itself.

It is.  Quake is a generic language with procedures, loops, conditionals
variables, arrays, lists, and strings.

Farshad:
  I think that within SRC, there is a system called Vesta that is used
  for systems management for the sort of things you describe.

Yes and No.  Vesta I is gone, Vesta II is being built.
So far we haven't used Vesta for Modula-3.  

Farshad:
  As far as I understand, m3build was supposed to be the sort of minimum
  stuff you need to compile Modula-3 programs. It is supposed to be easy
  on the novice. Quake seems to be somewhat arbitrary basis for m3build;
  I think an equivalent system can be built on top of other scripting
  languages such as Python or Tcl. 

Certainly.  We just needed something that supported reasonable
abstraction (i.e. procedures) and lists.

Farshad:
  I think the addition of the hooks to trigger at various events
  (somewhat like a metaobject protocol) seems to be consistent with
  m3build's original design goal as it doesn't make it harder for
  novices to use m3build.

The goal of m3build was to produce short and portable makefiles that
hid the operational aspects of building.  The current system builds
a bunch of lists (e.g. MODULE_SOURCES, IMPORT_LIBS, ...) and
invokes m3.  Unlike C systems, m3 decides which sources to recompile.

The hooks already exist to invoke user code before m3 is invoked.
These hooks could easily look around for RCS directories and missing
sources or do most anything you'd like.

Simply removing the "readonly" in front of the definitions of "interface",
"module", and friends in COMMON would allow users to override the
definitions of these functions.  For example,

          old_interface_proc = interface
          proc interface (x) is
            old_interface_proc (x)
            ...
          end

With a little creativity, who knows what might be accomplished?

  - Bill Kalsow




======================================================================= 3 ===
Date:    Thu, 1 Jun 95 11:51:58 GMT
From:    buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409)
Subject: Re: Can someone explain this behaviour?

Blair MacIntyre (bm@shadow.cs.columbia.edu) wrote:
: What I'm wonder is, why can't I create a subrange that has
: FIRST(INTEGER) in it.


: TYPE T = BITS 32 FOR [FIRST(INTEGER)..LAST(INTEGER)];
: TYPE R = BITS 32 FOR [-2147483647..2147483647];

[...]

: All this makes sence.  However, I cannot change "R" to match INTEGER
: and T, like this:

: 	TYPE R = BITS 32 FOR [-2147483648..2147483647];

: or I get the following error:
:  "../src/Main.m3", line 5: illegal integer literal, zero used

Same Problem as in C, C++, Pascal, Algol68, ...

Try 
	TYPE R = BITS 32 FOR [-2147483647 -1..2147483647];

``-2147483648'' is not a literal, but the constant expression
``(- (2147483648))''. And ``2147483648'' is not a valid integer
literal, but out of range. 

The real problem is, the integer range is asymetric. 
``- FIRST(INTEGER)'' is not in the integer range on twos-complement
cpus. 


There are no negative integer type constants in Modula3. There are
also no negative floatingpoint constants in Modula3, but it dosn't
result in this sort of errors, cause the floatingpoint range is
symetric.


				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

 /|)	Andreas Buschmann
/-|)	SEL Stuttgart US/END

	buschman@lts.sel.alcatel.de


======================================================================= 4 ===
Date:    01 Jun 1995 15:46:12 GMT
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: more m3build wishes


In article <BM.95May31202820@shadow.cs.columbia.edu> bm@shadow.cs.columbia.edu 
(Blair MacIntyre) writes:

   Basically, I'd like it to be possible to integrate RCS into m3build,
   so that whenever a package properly compiles it checks all the source
   files in using a new minor revision.

   Similarly, when a package is shipped, a new major revision could be
   checked in.

   If nobody else has done this, I may try it sometime.  Any ideas or
   comments?

Good idea! You can also do automatic check out like what GNU make does
if the file doesn't appear to exist in the src directory, and there is
an RCS directory.

I don't know anyone who's done it, but it doesn't sound too hard. But
what if I want to use CVS or Siphon?

It seems to me that all these sorts of requests are symptoms of a more
global need for some "hooks" in m3build where the user can register
handlers for doing useful things when certain interesting events (for
example, successful or unsuccessful compilation of module or interface
or package, or shipping) take place.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 5 ===
Date:    Thu, 1 Jun 1995 16:05:22 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: more m3build wishes


Hmm, if too much stuff gets integrated "into" m3build, it'll be
a gigantic mess.

I'm far from a m3build expert, in fact I consider myself a blatant
novice :)  I just feel that it might be a better idea to create
"hooks" from m3build to the package that you want to do the RCS, etc.
type stuff.

Maybe this is already possible, but it'd be nice if the build system
were extensible so that you could call external procedures and/or
programs while doing things.  From the little that I've explored, it
seems that m3build is just short of being a language in and among
itself.

Hmm, here's a thought.  Maybe the build environment should also be
a semi-high level language tailored to deal with the compilation
rules of other languages?  I'm assuming that m3build isn't quite
that powerful, but I may be wrong.

Anybody that's ever had to suffer with Makefiles should rejoice
over m3build, but that doesn't mean that improvements should stop.
I think integrating other "build" tools with m3build is a great
idea, but I hope that every new improvement doesn't involve
changing how things work in general.

I guess I should examine the m3build stuff more closely in my
spare time.

----------------------------------------------------------------------
Spencer Allain                    E-mail:  spencer@era.com
Engineering Research Associates   Phone :  (703) 734-8800 x1414
1595 Spring Hill Road             Fax   :  (703) 827-9411
Vienna, VA  22182-2235
----------------------------------------------------------------------



======================================================================= 6 ===
Date:    01 Jun 1995 02:29:20 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: WinNT porting of standard M3 packages

I'd like to talk to anyone else using modula-3 on NT.  I've finally
gotten NT and spent a little while today and yesterday installing it
and Modula3.  The biggest problem is that some of the standard
packages don't work.

Obviously, X11R4 and anything it depends on won't work (unless, I
suppose, you had X installed on NT).  I'm not too worried about that
right now.

But, I do need netobj and obliq to work.  The netobjd distributed with
3.5.2 crashes in a variety of interesting ways, so I was wondering if
anyone else has it working.
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 7 ===
Date:    01 Jun 1995 02:46:17 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Re: WinNT porting of standard M3 packages

More interesting details about netobjd on NT.

In another post (subject: "Can someone explain this behaviour?"), I
ask about subrange types.

In particular, WireRep.m3 bombs out on NT with an Illegal value error
since FIRST(INTEGER) is not in the Int32 subrange, yet that is what is
being returned by "ROUND(Time.Now())" in the following statement (I
changed the type definition of Int32 and printed out the value of myTs).

	VAR myTs: Int32 := ROUND(Time.Now());

So, that no longer bombs, although I suspect having ROUND(Time.Now())
return -2147483648 is symptomatic of other problems.

However, after that, netobjd dies in the startup initialization of
TCP.m3 
(the first line of this routine fails:
 PROCEDURE Init() =
  VAR data: WinSock.WSAData;
  BEGIN
    IF WinSock.WSAStartup(WinSockVersion, ADR(data)) # 0 THEN Die(); END;
    Process.RegisterExitor(Exitor);
  END Init;
)

I'm using stock Windows NT 3.5 from the CD (something like build 808).
Does TCP work yet?  I'd heard a while ago that people were working on
it but it wasn't 100% yet ... is this a side effect of this?
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 8 ===
Date:    01 Jun 1995 02:38:42 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Can someone explain this behaviour?

What I'm wonder is, why can't I create a subrange that has
FIRST(INTEGER) in it.

In WireRep.m3, we have the following type defined:

  Int32 = BITS 32 FOR [-2147483647..2147483647];

If I run the following program:

MODULE Main;
IMPORT Fmt, IO;

TYPE T = BITS 32 FOR [FIRST(INTEGER)..LAST(INTEGER)];
TYPE R = BITS 32 FOR [-2147483647..2147483647];

BEGIN
	IO.Put("Bits in INTEGER: " & Fmt.Int(BITSIZE(INTEGER)) & "\n");
	IO.Put(" from: " & Fmt.Int(FIRST(INTEGER)) & "\n");
	IO.Put(" to: " & Fmt.Int(LAST(INTEGER)) & "\n");
	IO.Put("Bits in T: " & Fmt.Int(BITSIZE(T)) & "\n");
	IO.Put(" from: " & Fmt.Int(FIRST(T)) & "\n");
	IO.Put(" to: " & Fmt.Int(LAST(T)) & "\n");
	IO.Put("Bits in R: " & Fmt.Int(BITSIZE(R)) & "\n");
	IO.Put(" from: " & Fmt.Int(FIRST(R)) & "\n");
	IO.Put(" to: " & Fmt.Int(LAST(R)) & "\n");
END Main.
	
I get this output (on SPARC and NT):
Bits in INTEGER: 32
 from: -2147483648
 to: 2147483647
Bits in T: 32
 from: -2147483648
 to: 2147483647
Bits in R: 32
 from: -2147483647
 to: 2147483647

All this makes sence.  However, I cannot change "R" to match INTEGER
and T, like this:

	TYPE R = BITS 32 FOR [-2147483648..2147483647];

or I get the following error:
 "../src/Main.m3", line 5: illegal integer literal, zero used

The reason this came up is that the following line in WireRep.m3 was
bombing out netobjd on NT (with an Illegal value error):

	VAR myTs: Int32 := ROUND(Time.Now());

Changing Int32 to be the same as "T" above fixed that problem, since
"myTs" was being assigned -2147483648 (yes, I think that this is a
sign of other problems, but I'm not attempting to address them here).
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 9 ===
Date:    01 Jun 1995 17:22:56 GMT
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Modula-3 and mixed language kernel coding


In article <DAGENAIS.95May31090223@notung.vlsi.polymtl.ca> dagenais@notung.vlsi
.polymtl.ca (Michel Dagenais) writes:

      Building new releases of m3 is a problem even for those of us in
      an institutional environment. I have found that to reliably
      install it I had better have in the region of 200M or over.

   Things may have improved since packages are built and cleaned one
   after another instead of building everything and then cleaning.  In
   any case 200MB costs about 100$, slightly more expensive than a
   book.

That's true if you "own" the machine you are using to program in
Modula-3. Now, suppose you don't have the root password on your
system, and the system admin doesn't agree with your economic
analysis...

      For some time now I've wondered whether it wouldn't be possible to
      distribute m3 as binaries.
      ...
      To deal with the problem of those with limited space, a distribution of
      binaries only, with none of the sources would result presumably in a
      requirement of <20M disk.

   As mentioned in the FAQ, I have been offering for some time binaries for
   LINUX, LINUXELF, SPARC, HPPA, FreeBSD, NeXT on ftp.vlsi.polymtl.ca
   in pub/m3.

Perhaps what we need is a *minimal* m3 distribution. Even in source
form, a minimal SRC M3 distribution (even when you include libm3)
should not be very large these days.

Note that the problem with the sizes still holds for the binary
release. That is, if all of the packages are included, the binary
release of SRC Modula-3 is quite large (and the way things are
organized, it is not easy to separate the essential parts of the
release from the bonus stuff if you don't have a lot of disk space.)

Given proper organization, the large size of the library should be an
advantage, and not a problem!

(Michel you may want to keep the following in mind in the
re-organization of your ftp site. I don't know if your ftp server
allows this but it may be worth a try:)

Here as idea for a minimal release of SRC Modula-3:

- Make a directory on the ftp.vlsi... server and call it "minimal".

- In "minimal", make links to all the required files and directories
  for a minimal distribution from (expanded version of) the standard
  distribution.

- Now, combining the link-directory with automatic tar'ing, you can
  allow users to download a minimal distribution easily.

I imagine this "virtual directory" containing the minimal release
should be relatively easy to maintain in the long run.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 10 ===
Date:    Thu, 1 Jun 1995 17:37:59 -0400
From:    wds@research.nj.nec.com (Warren Smith)
Subject: (none)

To m3@src.dec.com
QUESTIONS ABOUT MODULA 3

1. I'm presently thinking about writing a chess program,
and if I do, it is going to be in either modula-3 or C++.
Anybody have any feedback on which is the better choice?

2. Has anybody got a set of benchmarks comparing C and modula-3 speed?
In particular something heavy in allocation and garbage collection?

3. The SRC modula-3 compiler does not work with the latest GNU
assembler on SGI machines when "-g" is turned on (as it must be if you
want to use the profiler or the debugger). This may be due to the switch
between ELF and COFF binaries? When will this be fixed?

4. I generally like modula-3 syntax, but the gratuitous refusal to
allow you to be concise annoys me. Why DO and THEN and BEGIN and END;
rather than (as in C) { and }?  Less to remember, less to type,
editors with paren matching do the right thing, C syntax wins on all
counts here.

5. I find it understandable that modula-3 does not have macros...
but they nevertheless can be useful. For instance, in my chess program
I want to represent the board with an array of 64 squares
ordered A1,B1,...H1,A2,...H2,...A8,...H8.
In C I can initialize arrays using a 64-argument macro
boardfull(x1,...,x64)
which allows me to use a picture of the board in array initializations

RankForWhite[] = boardfull(
7,7,7,7,7,7,7,7,
6,6,6,6,6,6,6,6,
5,5,5,5,5,5,5,5,
4,4,4,4,4,4,4,4,
3,3,3,3,3,3,3,3,
2,2,2,2,2,2,2,2,
1,1,1,1,1,1,1,1,
0,0,0,0,0,0,0,0);

and it would be the wrong thing (chess-wise) if it had to be
RankForWhite[] = {0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,...7,7,7,7,7,7,7,7};

So C macros increase my expressive power and make my program readable
in this instance.  Modula-3? Noooo!

6. Another thing I can use macros for in C (I admit, it is disgusting
looking and I hate to do it) is to make custom iterators. E.g. in chess:
   loop over all pieces attacking square X { stuff; }
There appears to be no way to make custom iterators in modula-3?

7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor
DEC alpha machine? Or will the compiler just put all threads on a single
one of those 4 processors...?

------------------------------------
From:   Warren D. Smith  (Research Staff; Library Committee Chair)
NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA

Phone: (609) 951-2717   Web: http://www.neci.nj.nec.com/homepages/smith.html
Email: wds@research.NJ.NEC.COM    Fax:   (609) 951-2496  ("for W.D.Smith 1D04")



======================================================================= 11 ===
Date:    Thu, 1 Jun 1995 19:10:09 GMT
From:    bwbecker@dragon.uwaterloo.ca (Byron Weber Becker)
Subject: Re: Help with WWW documentation of M3 sources

In article <HUDSON.95May31103435@yough.cs.umass.edu>, hudson@cs.umass.edu wrote
:

> I looked into a similar problem a few weeks ago and their seems to be a bug i
n
> some versions of Netscape tickled when you have a trailing / on your URL.

Thanks, but I don't see any trailing /s on my URLs.

Byron

-- 
Byron Weber Becker                        Voice: (519)888-4567 x4661
Lecturer/Advisor                                  Fax: (519)885-1208
Department of Computer Science   e-mail:bwbecker@dragon.uwaterloo.ca
University of Waterloo
Waterloo, ONT  N2L 3G1  CANADA


======================================================================= 12 ===
Date:    Thu, 1 Jun 1995 20:22:28 -0400
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: more m3build wishes


Bill said:

>Simply removing the "readonly" in front of the definitions of "interface",
>"module", and friends in COMMON would allow users to override the
>definitions of these functions.  For example,
>
>          old_interface_proc = interface
>          proc interface (x) is
>            old_interface_proc (x)
>            ...
>          end
>
>With a little creativity, who knows what might be accomplished?

This is interesting. I had thought about uses of readonly, but never
thought that of this one. One nice syntactic sugar will then be to include:

  extension interface (x) is
    ...
  end

to be syntactic sugar for Bill's fragment.

This way I could have in the m3makefile for pacakge "documentation":

  extension interface(x) is
    make_doc(x & ".i3")
  end

  extension module(x) is
    ...
  end

and then just do

  import (documentation)

in order to make documentation happen.

Then again, simpler semantics is nice too. Great trick, Bill!

-- Farshad

--
Farshad Nayeri
nayeri@gte.com




======================================================================= 13 ===
Date:    Fri, 2 Jun 1995 05:03:45 GMT
From:    iec@netcom5.netcom.com (Interstate Electronics Corp)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

 > Brian, someone has worked on a gcc implementation of Modula-3, I do not
 > know what state it is in, but it was in reasonable working shape on a
 > VAX a while back!

The only other implementation attempts I'm aware of are an early
attempt by Olivetti (subsequently dropped) and that of Eliot Moss'
group at UMass Amherst.  

The latter was planned to be the GNU Modula-3 compiler, but budget
problems and the excellent quality of the DEC SRC compiler (which now uses
gcc, anyway) put that project into deep background.
-- 
--
========================================================================
Mike Elliott              mre@emerald.ccss.com               mre@lpf.org
========================================================================


======================================================================= 14 ===
Date:    Fri, 2 Jun 1995 09:52:50 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Concurrency

I would be interested to know what (if any) views the m3 developers have on
the problems of supporting true concurrency.

Lately, I have been carrying out some performance tests of a database
system I am developing in m3. I've been running it on a dual processor
server so I only have half the processor power available to me.

A more subtle problem however, is the effect on I/O scheduling of running a
'concurrent' system in a single thread. In particular, in my case, having
the I/O processors running concurrently with the rest of the system would
undoubtedly improve peformance dramatically.

What plans, if any, are there for providing such support?

As I see it there are various levels:

1. Full concurrency for all threads. Would mean making all global variables
shared.

2. Optional concurrency and sharing. A new type of fork which generates a
new    process and some language constructs to indicate variables are
shared between concurrent processes

3. Subroutine support (which probably exists already).





======================================================================= 15 ===
Date:    Fri, 2 Jun 1995 18:43:01 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: Concurrency

>
>Global variables ! Banish them from your code or protect them mutex
>locks.
>
I think you miss the point. I use the term global variables a little
loosely perhaps.

I have a specific appliaction in mind but I'm sure the requirements are
fairly general.

To deal with the particular in case some light will come out of it:

I have a page formatted I/O system which includes a multi-megabyte page
cache. Pages are written from and read into the cache by I/O processors.

I/O processors take requests of a queue, satisfy the requests and then
signal their completion.

Within a single address space this all works in a fairly simple but
inefficient manner. I/O does not proceed in a truly concurrent manner.

Now I know I can implement some sort of independent I/O processor by the
use of shared memory, semaphores and the rest. I have many years of
experience in implementing such systems.

However, the model that m3 provides is nearly sufficient. What it lacks is
the ability to

1. Fork() a separate process (in the OS sense)

2. Provide some mechanism whereby logically related, but independently
executing processes can access memory in each others address space.

For example, in my case I want to either be able to declare cache buffers
and perhaps I/O queue objects as being shared in some sense or have some
efficient way of making them appear in each others address space.

Efficiency is important. People worry about 5 extra instruction inserted
here and there for stack checking while all the time megabytes of
information are being copied over and over from process to process. That is
why I want my storage truly shared where that is appropriate.

If modula 3 is really going to become a fully usable systems language I
believe it is going to have to face up to the problems of true concurrency.
By the way, I don't expect modula3 or it's runtime to provide concurrency
where the underlying system doesn't.  What I do hope for is that it will
give us access to what are fairly generally available OS features.




======================================================================= 16 ===
Date:    Sat, 3 Jun 95 12:18:14 BST
From:    sknee@client44.comlab (Simon Knee)
Subject: Calling M3 from C

How do I call Modula-3 procedures from inside some
C code in release 3.5.2?

In Modula-3 2.11 I would put Name__procedure in my C code
to call the Modula-3 procedure Name.procedure.

You might ask why??  Well I am using lex and yacc to build
a parse tree of Modula-3 objects.

On another point - It is really annoying that all of the
libraries have changed from 2.11 -> 3.5.2.  Now I have got
to recode a lot of my Modula-3 programs to use the new
interfaces.  I thought that a strong point of the language
was code reuse - that goes out the window a bit if the libraries
that come with the distribution change.

Thanks,

Simon Knee,
Programming Research Group,
Oxford University
UK.


======================================================================= 17 ===
Date:    3 Jun 1995 09:39:07 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: more m3build wishes

In article <SPENCER.95Jun1120522@calvin.ERA.COM>,
Spencer Allain <spencer@ERA.COM> wrote:
>
>Hmm, if too much stuff gets integrated "into" m3build, it'll be
>a gigantic mess.

Seconded.

[snip]>
>Maybe this is already possible, but it'd be nice if the build system
>were extensible so that you could call external procedures and/or
>programs while doing things.  From the little that I've explored, it
>seems that m3build is just short of being a language in and among
>itself.
>
>Hmm, here's a thought.  Maybe the build environment should also be
>a semi-high level language tailored to deal with the compilation
>rules of other languages?  I'm assuming that m3build isn't quite
>that powerful, but I may be wrong.
>

 Indeed, it occurs that perhaps a solution might be to write a
simple Modula-3 interpreter using the AST toolkit (this has been done
as a part II project here; well, almost), and use that to direct builds.
The supported subset needn't be that large, since libraries can be linked and
called directly (though we would need dynamic linking), and if the interpreter
 is linked into the driver, we can potentially eliminate m3build and quake
altogether (though whether this is desirable or not is another issue). There is
also the advantage that generic modules and others need not have separate .tmpl
files (though source code or dynamic linking will have to be available for the
interpreter).

In fact, if we are prepared to put up with having to write intermediate
stages, there doesn't seem any need for an interpreter at all. As long
as we have a bootstrap (import(libm3)/import(paths)/implementation(Boot)/
program(makesimple) for example), we can build our build programs
iteratively. However, I think this is likely to be inadequate from speed,
debugging, portability, and usability points of view.

 For a simple m3makefile, something along the lines of :

MODULE Build EXPORTS Main;

<*BUILD IMPORT LIBRARY MyBuildLibrary*>

IMPORT BuildUtils, MyBuild;

VAR

  info : BuildUtils.T := NEW(BuildUtils.T).init();
  table : BuildUtils.Template := BuildUtils.Import("libm3","Table");
BEGIN
 info.ImportLib("libm3");
 info.ImportLib("netobj");
 info.ImportLib("mylib","/home/rrw1000/m3/mylib");
 table.Build(info,"TEXT","Text");
 info.Module("Test");

 info.Build("Main");
 MyBuild.Log(info);
END Build.

 ... which would have the fixed `m3makefile' :

import(Build) % For convenience
implementation([whatever])
program([whatever])

 I think it might be interesting to build a system like this, but I doubt
it would be terribly usable :-(.

[snip]



Richard.
-- 
`The past tempts us; the present confuses us; the future frightens us -  and
our lives slip away moment by moment - lost in that vast, terrible inbetween'
                                                       (Babylon 5)
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 18 ===
Date:    3 Jun 1995 01:29:20 GMT
From:    bluemist@seanet.com (Jim Brumbaugh)
Subject: M3 FAQ?

I've tried accessing the Modula-3 FAQ through WWW and both FAQ's I 
located seem to be unaccessable. Could someone point me to a resource to 
locate a FAQ?

Furthermore I am interested in an OS/2 version of M3. I noticed that 
there seems to be a NT version and that there may be a GNU version which 
can be recompiled currently stalled in the works.

Is this information accurate and is there a M3 compiler available (or in 
the works) for OS/2?

Many thanks.

 
|For consumer, technical, and marketing information about Geos call:
|1-800-824-4558 | Geos- The best little GUI on the face of the third planet!
|For demonstration ftp to- ftp://130.219.44.141/pub/geos/publish
|Jim Brumbaugh-  Internet: bluemist@seanet.com   Fido: 1:343/179



======================================================================= 19 ===
Date:    3 Jun 95 22:39:11
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: M3 FAQ?


In article <3qodtg$20d@kaleka.seanet.com> bluemist@seanet.com (Jim Brumbaugh) w
rites:

   I've tried accessing the Modula-3 FAQ through WWW and both FAQ's I
   located seem to be unaccessable. Could someone point me to a
   resource to locate a FAQ?

Try ftp.vlsi.polymtl.ca:/pub/m3/faq.html. I just tried it and it
worked. If you can't access it, feel free to write me and I will
e-mail you a copy.

   Furthermore I am interested in an OS/2 version of M3. I noticed that 
   there seems to be a NT version and that there may be a GNU version which 
   can be recompiled currently stalled in the works.

SRC Modula-3 works under NT and Win'95. People have posted interest
and some committment to an OS/2 port, but I haven't heard of too much
progress yet. Such a port is probably not too hard (as compared to,
say, a Mac port!)

Until then, you may want to try one of the DOS ports of SRC Modula-3
and run them from DOS emulation (?)

-- Farshad
--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 20 ===
Date:    Sun, 4 Jun 1995 03:45:23 GMT
From:    hgeorge@eskimo.com (Harry George)
Subject: M3 version of MFC on WinNT?

Thanks to Kalsow and Nayeri, I'm rolling with M3 on WinNT.  First obvious
task is to put an OOP wrapper on Win32.  The obvious approach is to
use the same inheritance tree and naming scheme as Microsoft's
Foundation Classes (MFC).  That way the mental skills are more or less
transportable from M3 to C++.  It makes life easier for C++ folk to
take a look at M3, and it makes M3'ers more or less capable of
doing MFC-based C++ (BYOBB bring your own barf bag)

So, I'm in the process of generating a m3MFC library with MfcBase and
MfcGDI modules.

It occurred to me that someone may
   a) already have done it
   b) is part way there
   c) would like to participate
   d) would like to kibbitz, bitch, offer sage advice, etc.

Let me know.
way there, or would like to 
-- 
--------------------
Harry George
email: hgeorge@eskimo.com
smail: 22608 90th Ave W / Edmonds WA 98026
quote: <under construction>



======================================================================= 21 ===
Date:    Mon, 5 Jun 1995 12:38:06 GMT
From:    hgeorge@eskimo.com (Harry George)
Subject: Re: Calling M3 from C

In article <1995Jun3.121814.27673@inca.comlab.ox.ac.uk>, 
sknee@client44.comlab says...
>
>How do I call Modula-3 procedures from inside some
>C code in release 3.5.2?
>

I'd like an answer too.  Even if it requires turning off gc.

<snip>

>On another point - It is really annoying that all of the
>libraries have changed from 2.11 -> 3.5.2.  Now I have got
>to recode a lot of my Modula-3 programs to use the new
>interfaces.  I thought that a strong point of the language
>was code reuse - that goes out the window a bit if the libraries
>that come with the distribution change.
>

I'm moving from 2.11 to 3.5.2 myself, and I realize it is frustrating.
But it is also important to allow and support such reorganizations of the 
libraries at this stage in the language's development.  A cleanup
now makes it all the more viable as it moves into broader use.  So
the pioneers have to a) stress the language by writing "real" programs,
and b) encourage changes which lead to conceptual simplification, 
even when that means revising existing code.

>Thanks,
>
>Simon Knee,
>Programming Research Group,
>Oxford University
>UK.

-- 
--------------------
Harry George
email: hgeorge@eskimo.com
smail: 22608 90th Ave W / Edmonds WA 98026
quote: <under construction>



======================================================================= 22 ===
Date:    Mon, 5 Jun 1995 09:46:31 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Re: Concurrency

Mike Douglass writes:
 > However, the model that m3 provides is nearly sufficient. What it lacks is
 > the ability to
 > 
 > 1. Fork() a separate process (in the OS sense)
 > 

I'm not sure what you mean by this. This could mean 
   (1) Fork() an entirely new address space;  
   (2) create a new stack and PC that shares the address space of the caller of
 Fork;
   (3) mean create a new OS level process that shares a caller-defined set of r
esources
      with the invoker of 'Fork'.

 > 2. Provide some mechanism whereby logically related, but independently
 > executing processes can access memory in each others address space.
 > 
 > For example, in my case I want to either be able to declare cache buffers
 > and perhaps I/O queue objects as being shared in some sense or have some
 > efficient way of making them appear in each others address space.
 > 
 > Efficiency is important. People worry about 5 extra instruction inserted
 > here and there for stack checking while all the time megabytes of
 > information are being copied over and over from process to process. That is
 > why I want my storage truly shared where that is appropriate.
 > 
 > If modula 3 is really going to become a fully usable systems language I
 > believe it is going to have to face up to the problems of true concurrency.
 > By the way, I don't expect modula3 or it's runtime to provide concurrency
 > where the underlying system doesn't.  What I do hope for is that it will
 > give us access to what are fairly generally available OS features.
 > 
 > 

The thread specification assumes an evironment where threads may be executing 
concurrently on different processors. It is not the case that all implementatio
ns
of the thread specification support that assumption; however if you program to
the thread specification and you move from an environment where this assumption
doesn't hold to one where it does hold, your system should have the same behavi
or
as it did before.

While the threads interface  is silent on the matter of address spaces, it in 
fact gives  you (2) above. That is, there seems to be the implicit assumption t
hat
state visible in one thread can be made visible to another thread without any
special action on the part of either thread. A newly created thread runs in the
same address space as the invoker of 'Fork'. Whether or not this thread is capa
ble
of being run on a separate processor is implementation dependent. A permissible
 
implementation of 'Thread.Fork' would be one in which the child ran as a separa
te
OS level process, but where its address-space was mapped one-to-one with the pa
rent,
and where changes in address space mappings were synchronized between the paren
t and
child in both directions.

The current runtime does use OS-level threads on Windows-NT and Win95 and
I have a buggy version that uses Solaris threads/LWPS on Solaris-2 systems. 

The libraries that are designed to make use of multithreading (Trestle, FormsVB
T,
VBTKit, etc) are all designed assuming that the runtime supports threads that
are capable of being run on independent processors, although the default Unix
implementation doesn't not provide that capability.

What the thread interface does not give you is the ability to linguistically
control visibility of information between two threads. That is, it does not 
admit the notion (at the language level) of thread private state except through
the standard M3 mechanisms of objects/closures. It sounds like you want somethi
ng closer
to (3) above, where two independent address spaces can share some state without
any special action on the part of processes executing in either address space.

If this is a correct characterization of what you want, then I would characteri
ze this
ability as being OS dependent, and could see providing an OS dependent interfac
e for 
creating this kind of process. As far as I know, only SGI and Plan9 currently a
llow
for this kind of process creation. 

--geoff



======================================================================= 23 ===
Date:    5 Jun 1995 19:20:34 GMT
From:    John Riley <johnr@juliet.ll.mit.edu>
Subject: Installing the Linux bineries

I have unpacked the stripped binaries on my system but there doesn't
seem to be any directions on what to do next.  Can anyone give me
any information on environment variables, links, etc.

I will be grateful for any help.
Thanks,
JPR



======================================================================= 24 ===
Date:    5 Jun 1995 19:35:27 -0400
From:    dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

"Does anyone know if the FSF will separate their backend more from their
front ends?  The current hack of adding a m3.c file to the gcc compiler
is fine, but even SRC has problems using the gcc backend optimizations
properly."

I doubt it, what possible FSF goal can be met by such a separation, it
would seem to promote exactly that which FSF tries hard to prevent, the
creation of proprietary technologies which make use of free software.



======================================================================= 25 ===
Date:    Mon, 5 Jun 1995 20:35:56 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: Calling M3 from C

In article <D9p9rJ.ECo@eskimo.com> hgeorge@eskimo.com (Harry George) writes:

   In article <1995Jun3.121814.27673@inca.comlab.ox.ac.uk>, 
   sknee@client44.comlab says...
   >
   >How do I call Modula-3 procedures from inside some
   >C code in release 3.5.2?
   >

   I'd like an answer too.  Even if it requires turning off gc.

   >Thanks,
   >
   >Simon Knee,
   >Programming Research Group,
   >Oxford University
   >UK.

   -- 
   --------------------
   Harry George
   email: hgeorge@eskimo.com
   smail: 22608 90th Ave W / Edmonds WA 98026
   quote: <under construction>

Hmm, this seems to be a very popular question lately.

It is a very good question to ask in fact, since a "good" answer
solves several problems that chain off one another.

1) It allows us to easily call m3 from C programs.
   (This is the obvious answer)

  2) If we have [1] we have a semi-portable way of calling m3
     from other languages that can export C functions.
     (This is still not as powerful as ILU, but allows non-class stuff
      to be passed around easily)

     3) If we have [2] we have a "better" way to switch from another
        language to m3.
        (This is part of the c->c++ theory, although it doesn't always
         work, it sure sells on managers)

        4) We can possibly convince managers (or customers) that m3
           is a better solution for the type of problem being worked
           on, and the change can be slightly incremental.
           (This should be done *only* for projects where the
            benefits of m3 outweigh the language presently being used)

Ok, so it's not a perfect chain, but it does show how a seemingly
inconsequential thing can greatly impact the future.  I believe 
that if there were a way to "easily" call m3 from C code, it would 
pave the way for conversion.

----------------------------------------------------------------------
Spencer Allain                    E-mail:  spencer@era.com
Engineering Research Associates   Phone :  (703) 734-8800 x1414
1595 Spring Hill Road             Fax   :  (703) 827-9411
Vienna, VA  22182-2235
----------------------------------------------------------------------


======================================================================= 26 ===
Date:    5 Jun 95 21:31:34
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <dewar.802395267@gnat> dewar@cs.nyu.edu (Robert Dewar) writes:

   "Does anyone know if the FSF will separate their backend more from their
   front ends?  The current hack of adding a m3.c file to the gcc compiler
   is fine, but even SRC has problems using the gcc backend optimizations
   properly."

   I doubt it, what possible FSF goal can be met by such a separation, it
   would seem to promote exactly that which FSF tries hard to prevent, the
   creation of proprietary technologies which make use of free software.

I suspect that soon enough, the gcc-based backend for SRC Modula-3 is
going to be replaced by a "direct" code-generation for important
platforms. The Windows release of SRC Modula-3 supports COFF directly,
and efforts are underway for a direct ELF generation for LINUX
although I hear Linux ELF support itself is not completely robust yet.
Granted, this will not be as optimized as gcc, but for many uses this
doesn't matter, especially for CS1 and CS2 courses.

I actually find the gcc-backend to be a pain throughout the
development as it slows things down considerably. By bypassing
gcc-backend, M3 has a very good chance of having a super-fast
(incremental) development environment.

(I must admit, I don't know the complete context of this discussion. I
better start reading comp.lang.ada.)

-- Farshad
--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 27 ===
Date:    5 Jun 1995 19:49:09 GMT
From:    "Marc E. Fiuczynski" <mef@cs.washington.edu>
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

iec@netcom5.netcom.com (Interstate Electronics Corp) wrote:
> > Brian, someone has worked on a gcc implementation of Modula-3, I do not
> > know what state it is in, but it was in reasonable working shape on a
> > VAX a while back!
>
>The only other implementation attempts I'm aware of are an early
>attempt by Olivetti (subsequently dropped) and that of Eliot Moss'
>group at UMass Amherst.  
>
>The latter was planned to be the GNU Modula-3 compiler, but budget
>problems and the excellent quality of the DEC SRC compiler (which now uses
>gcc, anyway) put that project into deep background.
>-- 
>--
>========================================================================
>Mike Elliott              mre@emerald.ccss.com               mre@lpf.org
>========================================================================

Does anyone know if the FSF will separate their backend more from their
front ends?  The current hack of adding a m3.c file to the gcc compiler
is fine, but even SRC has problems using the gcc backend optimizations
properly.  

Marc



======================================================================= 28 ===
Date:    5 Jun 1995 19:54:14 GMT
From:    sims@linux.acsys.com (dave sims)
Subject: when NEW fails, revisited

What should I do when NEW fails to allocate memory?

I recall the discussion in comp.lang.modula3 sometime back about
possible solutions and workarounds.  However, I don't recall if anyone
agreed on anything.  As far as I know, the DEC SRC distribution always
terminates the program with an error message.

I've written a couple servers using the DEC SRC Modula-3 distribution.
They are intended to be used in a commercial environment.  Needless to
say, having such a program crash when it runs out of memory isn't
acceptable.

Any suggestions?  What about the suggestion that the program raise an
'OutOfMemory' exception?

thanks for any help,
dave sims
-- 
Dave Sims
sims@usa.acsys.com
KC5JKN


======================================================================= 29 ===
Date:    Tue, 6 Jun 1995 09:18:34 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: when NEW fails, revisited

>What should I do when NEW fails to allocate memory?
>
>I recall the discussion in comp.lang.modula3 sometime back about
>possible solutions and workarounds.  However, I don't recall if anyone
>agreed on anything.  As far as I know, the DEC SRC distribution always
>terminates the program with an error message.
>
>I've written a couple servers using the DEC SRC Modula-3 distribution.
>They are intended to be used in a commercial environment.  Needless to
>say, having such a program crash when it runs out of memory isn't
>acceptable.
>
>Any suggestions?  What about the suggestion that the program raise an
>'OutOfMemory' exception?
>

I too would like to see an implementation that allows the possibility of
recovery when the application runs out of memory. I'd also like that
generalised to cope with other kinds of runtime failure.

The exception mechanism seems to be the most appropriate choice.

Perhaps as an intermediate step, would it be possible to provide us with a
new NEW which raises an exception for out of memory.

I presume at least one major problem is that the recovery may fail because
of lack of memory. We might at least get a chance to keep going though.




======================================================================= 30 ===
Date:    6 Jun 95 08:53:35
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Installing the Linux bineries


   I have unpacked the stripped binaries on my system but there doesn't
   seem to be any directions on what to do next.  Can anyone give me
   any information on environment variables, links, etc.

Basically setup your PATH and LD_LIBRARY PATH variables. From the README
(for LINUXELF):

ftp> cd bin-strip
ftp> get modula3-3.5.1.tar.Z
ftp> quit
me> mkdir -p /usr/local/soft
me> gunzip <modula3-3.5.1.tar.Z | (cd /usr/local/soft; tar xf -)
me> setenv PATH $PATH:/usr/local/soft/modula3-3.5.1/bin
me> setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/usr/local/soft/modula3-3.5.1/lib/m
3/LINUXELF

--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 31 ===
Date:    Tue, 6 Jun 1995 11:52:07 PDT
From:    jacobi.PARC@xerox.com
Subject: Re: when NEW fails, revisited

When you really run out of memory all hell breaks loose.  It is too late to 
handle the case.  If you want to handle running out of memory you'd have
to watch the free memory space and reduce allocating more memory long
before you will run out. 

Anyway, if you have an operating system, virtual memory will pitch
in when you run out of real memory.  Most often the application might 
start trashing long before it really runs out of virtual memory.

The exception mechanism just isn't the right way to handle out of memory. 
You need prevention, not recovery.

>Perhaps as an intermediate step, would it be possible to provide us with a
>new NEW which raises an exception for out of memory.
This wouldn't help.  Just think when one thread allocates too much memory
and it will raise that exception, no other thread will be able to allocate memo
ry 
either. 

Chris


======================================================================= 32 ===
Date:    6 Jun 1995 12:55:04 GMT
From:    vleuge00@marvin.informatik.uni-dortmund.de (Dirk Vleugels)
Subject: Re: Installing the Linux bineries

John Riley (johnr@juliet.ll.mit.edu) wrote:
: I have unpacked the stripped binaries on my system but there doesn't
: seem to be any directions on what to do next.  Can anyone give me
: any information on environment variables, links, etc.

Same for me! Another question: I use the modula-3.3.4 (??) version and would
like to use it with ILU-1.8. Is this possible? Any documentation available?

: I will be grateful for any help.
: Thanks,
: JPR

Dirk


======================================================================= 33 ===
Date:    Tue, 6 Jun 1995 15:10:53 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: when NEW fails, revisited

>When you really run out of memory all hell breaks loose.  It is too late to
>handle the case.  If you want to handle running out of memory you'd have
>to watch the free memory space and reduce allocating more memory long
>before you will run out.
>
>Anyway, if you have an operating system, virtual memory will pitch
>in when you run out of real memory.  Most often the application might
>start trashing long before it really runs out of virtual memory.
>
>The exception mechanism just isn't the right way to handle out of memory.
>You need prevention, not recovery.
>
I'm aware of that but there are many examples of programs which currently
handle running out of memory (by which I meant VM in any case) in a
graceful manner.

For example, in a gui application an appropriate approach might be to shut
a window down. This is what the mail client does on my machine. I get an
alert box telling me which window it is shutting, I click and it's done. No
problem.

The alternative is for the whole application to just exit sideways (as some
others do). That often is a problem.

Many systems set limits on the amount of memory (virtual) that a process
can own. It is these limits we might hit. In fact it's one of those limits
my mail client hits. Having VM limits is good. It prevents one process
killing everything. But we have to be able to cope with them.

How do we keep a check on memory?

1. The runtime system allows us to see how close we are to running out.
2. We define a threshold.
3. We do all our allocation through routines that check the above and then
probably raise an exception when we run out.

It would be much easier if we could devise some way of setting off an alarm
when we hit some limit.





======================================================================= 34 ===
Date:    6 Jun 1995 18:00:38 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Re: when NEW fails, revisited

In article <3qvnd6$g6l@mtv.acsys.com>, dave sims <sims@linux.acsys.com> wrote:
>What should I do when NEW fails to allocate memory?
>
>I recall the discussion in comp.lang.modula3 sometime back about
>possible solutions and workarounds.  However, I don't recall if anyone
>agreed on anything.  

My guess is you'll have to pick one of these and implement it.  I
think deciding on the policy is the hard part.  Myself, I would lean
toward being able to register procedures (closures) that are called
when memory runs out, and changing the allocator to call those
procedures when memory runs out.  This gives you a chance to try to
reclaim memory or to try to terminate the address space gracefully.

What do C/C++ programmers do about memory exhaustion?

Norman


======================================================================= 35 ===
Date:    Tue, 6 Jun 1995 17:53:32 GMT
From:    kominek@links.uwaterloo.ca ()
Subject: Re: Calling M3 from C

:   >How do I call Modula-3 procedures from inside some
:   >C code in release 3.5.2?
:
: It is a very good question to ask in fact, since a "good" answer
: solves several problems that chain off one another.
:
:  [ 4-level chain answer ]
:
: Spencer Allain                    E-mail:  spencer@era.com


You forgot to mention a salient point. One of the major forms of
commercial software development is the creation and sale of libraries.
The creation of good libraries is made easier by Modula-3, but if you
want to stay in business they _must_ be callable from C. As it stands,
application vendors can get down to work, but library vendors are not
in a viable position.

John Kominek
---------------------------------
Department of Applied Mathematics
University of Waterloo
Waterloo, Ontario, Canada
N2L 3G1
---------------------------------




======================================================================= 36 ===
Date:    Wed, 7 Jun 1995 08:58:15 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Re: when NEW fails, revisited

	<3r2546$qbt@lowell.bellcore.com>Cc: m3@src.dec.com
In-Reply-To: <3r2546$qbt@lowell.bellcore.com>
Distribution: world
X-Received: from suneast.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3)
X-Received: by src-mail.pa.dec.com; id AA08490; Wed, 7 Jun 95 06:10:42 -0700
X-Newsgroups: comp.lang.modula3
X-Received: from cloyd.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117
)
X-Received: from Sun.COM by inet-gw-2.pa.dec.com (5.65/24Feb95)
X-Received: by cloyd.East.Sun.COM (5.x/SMI-SVR4)
X-Received: from East.Sun.COM (eastmail1.East.Sun.COM) by Sun.COM (sun-barr.Sun
.COM)
X-Received: by src-news.pa.dec.com; id AA26152; Wed, 7 Jun 95 06:10:43 -0700

Norman Ramsey writes:
 > In article <3qvnd6$g6l@mtv.acsys.com>, dave sims <sims@linux.acsys.com> wrot
e:
 > >What should I do when NEW fails to allocate memory?
 > >
 > >I recall the discussion in comp.lang.modula3 sometime back about
 > >possible solutions and workarounds.  However, I don't recall if anyone
 > >agreed on anything.  
 > 
 > My guess is you'll have to pick one of these and implement it.  I
 > think deciding on the policy is the hard part.  Myself, I would lean
 > toward being able to register procedures (closures) that are called
 > when memory runs out, and changing the allocator to call those
 > procedures when memory runs out.  This gives you a chance to try to
 > reclaim memory or to try to terminate the address space gracefully.
 > 

I think the tough issues revolve around the issues of multithreading,
especially on systems that allow threads to run concurrently on different
processors.

Maybe it's time for someone to go back and summarize the issues.

 > What do C/C++ programmers do about memory exhaustion?
 > 

Fail horribly...The only large system I've seen that actually dealt
with memory allocation failure was CodeCenter/ObjectCenter. When the 
environment (as opposed to the application running in the environment)
was unable to allocate more memory, it issued a dialog that allowed
you to add more swap space. I imagine that all the resources necessary 
to create this dialog were statically allocated or allocated early during
the initialization of the environment.


--geoff


======================================================================= 37 ===
Date:    7 Jun 1995 18:23:25 GMT
From:    "Marc E. Fiuczynski" <mef@cs.washington.edu>
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

It seems that it would be beneficial to the FSF to separate their backend 
from their frontend. Many of the backend optimizations are applicable to
Fortran, Ada, M3, C and friends, and possibly other languages.  The FSF
already provides a set of nice compiler tools, and separating the backend
would not only assist them in developing different frontends quickly, but
allow projects, like SRC M3, to take advantage of their software.

What would be required to separate the backend?  I guess someone has to 
define an acceptable intermediate representation that the frontends compile 
to and then have the backend read that back in.  This is what M3 does right
now, however, I doubt that its the format that every other frontend will 
want to agree to.

Marc


cracauer@wavehh.hanse.de (Martin Cracauer) wrote:
>dewar@cs.nyu.edu (Robert Dewar) writes:
>
>>"Does anyone know if the FSF will separate their backend more from their
>>front ends?  The current hack of adding a m3.c file to the gcc compiler
>>is fine, but even SRC has problems using the gcc backend optimizations
>>properly."
>
>>I doubt it, what possible FSF goal can be met by such a separation, it
>>would seem to promote exactly that which FSF tries hard to prevent, the
>>creation of proprietary technologies which make use of free software.
>
>I don't think so. IMHO, the only reason why the separation isn't done
>is that noone spent the time on it.
>
>The GNU-Objective-C folks, for example, would be very happy to have
>their frontend mixed with the C++ frontent to allow Objctive-C++
>programs. That would be much easier with a cleaner compiler
>structure and better documentation would pull it out of deep magic so
>that some mortal could do this.
>
>From what I heared, the FSF would be happy to make the gcc backend an
>easier-to-use tool for language implementors. The backend has to be
>modified anyway to allow better optimization for the deeper pipelines
>of modern CPUs.
>
>If the current way to implement m3 causes major overhead, maybe the
>time required for every m3-inside-gcc-backend release would be better
>invested in turning gcc into something that causes less overhead.
>
>Martin





======================================================================= 38 ===
Date:    Wed, 7 Jun 95 10:15:38 GMT
From:    cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

dewar@cs.nyu.edu (Robert Dewar) writes:

>"Does anyone know if the FSF will separate their backend more from their
>front ends?  The current hack of adding a m3.c file to the gcc compiler
>is fine, but even SRC has problems using the gcc backend optimizations
>properly."

>I doubt it, what possible FSF goal can be met by such a separation, it
>would seem to promote exactly that which FSF tries hard to prevent, the
>creation of proprietary technologies which make use of free software.

I don't think so. IMHO, the only reason why the separation isn't done
is that noone spent the time on it.

The GNU-Objective-C folks, for example, would be very happy to have
their frontend mixed with the C++ frontent to allow Objctive-C++
programs. That would be much easier with a cleaner compiler
structure and better documentation would pull it out of deep magic so
that some mortal could do this.

>From what I heared, the FSF would be happy to make the gcc backend an
easier-to-use tool for language implementors. The backend has to be
modified anyway to allow better optimization for the deeper pipelines
of modern CPUs.

If the current way to implement m3 causes major overhead, maybe the
time required for every m3-inside-gcc-backend release would be better
invested in turning gcc into something that causes less overhead.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>. No NeXTMail, please.
 Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a 
 private address. At (netless) work programming in data analysis.


======================================================================= 39 ===
Date:    Wed, 7 Jun 1995 14:26:35 GMT
From:    freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman)
Subject: Re: [C++ or M3]

In article <199506012137.RAA12434@iris51> wds@research.nj.nec.com (Warren Smith
) writes:
> QUESTIONS ABOUT MODULA 3
> 
> 1. I'm presently thinking about writing a chess program,
> and if I do, it is going to be in either modula-3 or C++.
> Anybody have any feedback on which is the better choice?

how much time do you have? ;-) I'm an M3 exile, having been forced back
to C++, and to me there is no question--I find myself spending, say, 
40% of my time worrying about memory management (even with all
the usual tricks) which, curiously, is about how much longer it
takes me to write C++ programs. I also deeply miss having exceptions
as part of signatures, partial revelations, lots of robust libraries
(with no clashes over basic types such as strings), integrated threads,
etc, etc. Furthermore, there are two very serious maintenance issues:

1) C++ provides no help getting your modules initialised in the right 
   order. With threads spinning as well, this can be a major pain.
2) what can you expect from a language (ie. C++) in which you can read
   the statement 'a = b + c' and have _no_idea_ what it does.

> 2. Has anybody got a set of benchmarks comparing C and modula-3 speed?
> In particular something heavy in allocation and garbage collection?
I don't as such, but I spent a summer at SRC implementing a desktop
video widget that had also been implemented in C(++?)/Motif. The 
performance was comparable (ours was slightly slower but with slightly
less latency). If allocation and GC is a real cost, you do like you
do in C and manage free lists--except you don't worry about it at 
all until it proves a problem.

> 4. I generally like modula-3 syntax, but the gratuitous refusal to
> allow you to be concise annoys me. Why DO and THEN and BEGIN and END;
> rather than (as in C) { and }?  Less to remember, less to type,
> editors with paren matching do the right thing, C syntax wins on all
> counts here.
If this is really a problem, then preprocess it :). Most of us seem to
have got used to it,  it can be clearer than parentheses--depending 
on your editing/pretty-printing environment, and the emacs
mode does most of the work for you. This could be argued over but
is surely not a reason for rejecting the whole language.

> 5. I find it understandable that modula-3 does not have macros...
> but they nevertheless can be useful. For instance, in my chess program
> I want to represent the board with an array of 64 squares
> ordered A1,B1,...H1,A2,...H2,...A8,...H8.
> In C I can initialize arrays using a 64-argument macro
> boardfull(x1,...,x64)
> which allows me to use a picture of the board in array initializations
> 
> RankForWhite[] = boardfull(
> 7,7,7,7,7,7,7,7,
> 6,6,6,6,6,6,6,6,
> 5,5,5,5,5,5,5,5,
> 4,4,4,4,4,4,4,4,
> 3,3,3,3,3,3,3,3,
> 2,2,2,2,2,2,2,2,
> 1,1,1,1,1,1,1,1,
> 0,0,0,0,0,0,0,0);
> 
> and it would be the wrong thing (chess-wise) if it had to be
> RankForWhite[] = {0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,...7,7,7,7,7,7,7,7};
> 
> So C macros increase my expressive power and make my program readable
> in this instance.  Modula-3? Noooo!
How does a 64-argument macro differ from a 64-argument procedure to
do the same thing? Furthermore, in this particular case, I think
you can use structure assignments, so it looks the same anyway. 
(someone back me up on this?).

> 6. Another thing I can use macros for in C (I admit, it is disgusting
> looking and I hate to do it) is to make custom iterators. E.g. in chess:
>    loop over all pieces attacking square X { stuff; }
> There appears to be no way to make custom iterators in modula-3?
this is an issue of program structure, and depends on how you write
your looping code. You could write an iterator object (maybe there's one
already in a library) with 'test' and 'apply' methods so the loop
would like:

   FOR i := 0 TO LAST(array) DO
      IF iterator.test(array[i]) THEN
        iterator.apply(array[i])
      END;
   END;

much clearer than hiding it all in a macro. Check out the Patterns book
(Gamma et al) for lots of descriptions of this sort of stuff. 

> 7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor
> DEC alpha machine? Or will the compiler just put all threads on a single
> one of those 4 processors...?
pass.

finally, you might note that there is only one Modula-3 definition, which
is clear and implementable. A significant issue with C++ is which 
implementation of which dialect you intend to choose.

good luck,

steve

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Steve Freeman, Research Scientist, Rank Xerox France.

Surface:  Rank Xerox Research Centre,
          6, chemin de Maupertuis, 38240 Meylan, France.
Internet: steve.freeman@xerox.fr
Phone:    +33 76 61 50 21
Fax:      +33 76 61 50 99


but wotthehel wotthehel
toujours gai
  -- mehitabel the cat


======================================================================= 40 ===
Date:    7 Jun 1995 08:35:43 GMT
From:    pucci@cli.di.unipi.it (Igor Pucci)
Subject: modula3 from C




======================================================================= 41 ===
Date:    8 Jun 1995 15:30:05 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)



> >I doubt it, what possible FSF goal can be met by such a separation, it
> >would seem to promote exactly that which FSF tries hard to prevent, the
> >creation of proprietary technologies which make use of free software.
> 
> I don't think so. IMHO, the only reason why the separation isn't done
> is that noone spent the time on it.

No.  I recently talked to Richard Stallman on the phone.  He is quite
concerned that the current technique used by the Modula-3 compiler
will subvert the FSF goals.  The FSF CopyLeft virus does not
infect programs across process boundaries.  You must link with
FSF code to become infected.  So, the SRC Modula-3 front-end is
not infected.  We could charge a bundle for anyone using it :-). 

In principle, compiling to C and using gcc out-of-the-box as a
backend produces the same result.  But, C isn't a very good
intermediate language and it makes it quite difficult to get
reasonable debugging information into the symbol tables.

  - Bill Kalsow



======================================================================= 42 ===
Date:    07 Jun 1995 19:04:09 GMT
From:    kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: when NEW fails, revisited

In article <3r2546$qbt@lowell.bellcore.com>
norman@flaubert.bellcore.com (Norman Ramsey) writes:

    [...]
|> What do C/C++ programmers do about memory exhaustion?

Core dump.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung




======================================================================= 43 ===
Date:    7 Jun 95 08:32:22
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: when NEW fails, revisited


   I too would like to see an implementation that allows the possibility of
   recovery when the application runs out of memory. I'd also like that
   generalised to cope with other kinds of runtime failure.

   The exception mechanism seems to be the most appropriate choice.

   Perhaps as an intermediate step, would it be possible to provide us with a
   new NEW which raises an exception for out of memory.

   I presume at least one major problem is that the recovery may fail because
   of lack of memory. We might at least get a chance to keep going though.

A very long and detailed explanation about why this was extremely difficult
was posted by the DEC SRC people about 6 months ago. You should be
able to find it in the archives in: 

gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3



--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 44 ===
Date:    8 Jun 95 12:20:43
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: [C++ or M3]


In article <3r69u4$8hb@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) wri
tes:

   In article <NAYERI.95Jun7185912@tahoe.gte.com>, nayeri@gte.com (Farshad Naye
ri) writes:
   |> 
   |>[interesting things about threads cut]
   [someone thinks that M3 syntax is heavy and I agree]
   |
   |> I agree with Steve's sentiments about the syntax. You can either
   |> accept it or just pre-process "your own" syntax into M3. One such
   |> syntax was created by Andrew Myers at MIT. 

   Now the question, I'd like to see this "modified" syntax, is this
   available on the net ?

   Thanks.

(Note that Andrew's syntax still keeps the "end", I think, but takes
away other things that annoys some people like upper-case keywords,
and semicolons.)

(From a posting in Feb 1994:)

Just pick up Andrew Myers's m3process preprocessor, which transforms
m3su (a dialect of Modula-3 without semicolons and upper-case
keywords) to standard Modula-3.  The man page and sources are
available by anonymous ftp in the directory

    pion.lcs.mit.edu:/pub/m3su

(Pion's internet address is 18.26.0.64).

[Can we put this in the FAQ answers, if it isn't already, and I am
 stating to feel a distinct need for a gopher service that allows
 interactive searches over the M3 postings. I never can figure out how
 to make kwic work. Perhaps this is another FAQ.]

--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 45 ===
Date:    08 Jun 1995 21:51:24 GMT
From:    jackg@downhaul.crc.ricoh.com (Jack Greenbaum)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <3r4qqt$rkj@nntp5.u.washington.edu> "Marc E. Fiuczynski" <mef@cs.was
hington.edu> writes:

   It seems that it would be beneficial to the FSF to separate their backend 
   from their frontend. Many of the backend optimizations are applicable to
   Fortran, Ada, M3, C and friends, and possibly other languages. 
[...]
   What would be required to separate the backend?  I guess someone has to 
   define an acceptable intermediate representation that the frontends compile 
   to and then have the backend read that back in.  

What am I missing here? The gcc intermediate representation, RTL, is
quite seperate from the front end parse tree representation, the "tree"
data structures. RTL is the most well documented part of GCC, while
building a new front end is certainly black magic. 

So what parts of RTL back end are people complaining about being tied to
the front end? Is it that you bascially have to use the GCC front end to
make RTL that is the complaint?
--
Jack Greenbaum -- Research Engineer, Ricoh California Research Center
---------------------------------------------------------------------
Digital: jackg@crc.ricoh.com   |  http://www.crc.ricoh.com/~jackg
---------------------------------------------------------------------
Analog:  (415) 496-5711 voice  |  2882 Sand Hill Rd. Suite 115
         (415) 854-8740 fax    |  Menlo Park, CA 94025-7002
---------------------------------------------------------------------
-- 
Jack Greenbaum -- Research Engineer, Ricoh California Research Center
---------------------------------------------------------------------
Digital: jackg@crc.ricoh.com   |  http://www.crc.ricoh.com/~jackg
---------------------------------------------------------------------


======================================================================= 46 ===
Date:    7 Jun 95 18:59:12
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: [C++ or M3]


In article <FREEMAN.95Jun7162635@coolidge.coolidge.grenoble.xerox.fr> freeman@c
oolidge.coolidge.grenoble.xerox.fr (Steve Freeman) writes:

  Warren Smith says:

   > 7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor
   > DEC alpha machine? Or will the compiler just put all threads on a single
   > one of those 4 processors...?
   pass.

I will pick up where Steve left off.

The language definition allows both cases. The exact behavior depends
on the implementation of M3 threads on a particular platform (but the
Thread INTERFACE general semantics are preserved even in the
multi-processor case.) If the M3 thread implementation uses native
threads (like the Windows port of SRC Modula-3), and if native threads
are allocated to various processors by the operating system, then you
will have multiple threads "really" run in parallel. Geoff Wyant is
working on a port to Solaris 2 native threads.

There also possibilities for exploiting parallelism via Network
Objects. I seem to recall someone at Caltech doing this, but it may be
an overkill for your uses.

With comparable amount of work done, I think you'd do better with
Modula-3. (I am speculating that) your chess program may involve a lot
of search, which means heavy use of memory management to keep things
sane, and coordinating multiple threads for the search.  The
integrated threads and garbage collection make it easy to "alert" a
thread to abort and not worry too much about the memory that was
allocated to it.

If you are interested in doing a GUI for your system, it probably is
easier to do GUIs for concurrent programs using Trestle. It is also
easy to learn and well-documented; this way you can forget the X event
loop for the most part.

I agree with Steve's sentiments about the syntax. You can either
accept it or just pre-process "your own" syntax into M3. One such
syntax was created by Andrew Meyers at MIT. 

-- Farshad

--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 47 ===
Date:    08 Jun 1995 15:43:25 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

When one discusses seperating the front end from the backend we need to
remember that as languages advance the need to pass semantic information to
the backend only increases. For example, accurate garbage collection requires
the gcc backend to understand object data structures so it can distinguish
between pointers to TRACED objects and pointers to UNTRACED objects. This
information must be combined with backend tasks such as stack frame layout.
Add requirements like debugging optimized code and we start to see an
increased amount of 'front end' knowledge needed by the backend.

- Rick
--

       Richard L. Hudson  -  Hudson@cs.umass.edu; (413) 545-1220; 
       Advanced Languages Project - University Computing Services
       Lederle Graduate Research Center
       University of Massachusetts             Amherst, MA  01003


======================================================================= 48 ===
Date:    8 Jun 1995 18:14:25 GMT
From:    tlh20@thor.cam.ac.uk (Tim Harris)
Subject: Re: Help with WWW documentation of M3 sources

>>    2. If I view that copy using Netscape 1.1 from a Mac, all
>>    the HTML markup codes are displayed.  Looks ugly; not
>>    usable.

Netscape is thinking the file is a text file. This is likely to be because
the server told it that it was a text file :-). I had this problem on
my machine using the NCSA httpd. 

The work-around is to modify the mime-types file in the configuration
directory (by default I think that's /usr/local/etc/httpd/conf) and find
the line starting text/html. This line lists file extensions for which
the daemon should tell the client that the file is HTML, so adding
i3 and m3 on the end should make them be recognised correctly.

Admittedly the word starting with k and ending with ludge springs to
mind (what if another user has a normal modula-3 program which they
want to be available as text?) - but I think that's about as well as
it can be done without large-scale changing of the links in the M3
files.

Hope it works!

tim

-- 
---------- Tim Harris | --'What shall we do tonight Brain?' "The same thing
46k Churchill College | ---we do every night, Pinky, we're going to take over
----Cambridge CB3 0DS | ---the world" - Pinky and Brain, who are cartoon mice
------tlh20@cam.ac.uk | - http://www.chu.cam.ac.uk/home/tlh20/home.html ------


======================================================================= 49 ===
Date:    9 Jun 1995 00:14:38 GMT
From:    pbh@cs.sunysb.edu (Peter B. Henderson)
Subject: Comments on Chess Playing Program

I am posting this for Warren Smith.  Maybe of interest to some of you.
--
Peter B. Henderson
pbh@sbcs.sunysb.edu
Department of Computer Science, SUNY at Stony Brook
Stony Brook, N.Y.  11794-4400

-------- Warren's comments start here --------

Tests of runtime speed modula-3 vs C, also comments on language choice
for implementing a chess playing program.
----------------------------------------------------------------------
By  Warren D. Smith,  wds@research.NJ.NEC.COM 
(Now also T, Chez Scheme, and Standard ML of New Jersey, thanks to
Kevin Lang and Andrew Wright for writing those. This arose from my
desire to write a chess program and decide between C and m3.)

test1: a 1000000 iter loop with a bunch of bit-ops and array accesses.
Incidentally this test reveals that neither C nor modula-3 compilers
have tables of special cases of common operations, such as, e.g. x MOD
64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x,
etc. Pretty damn stupid of certain compiler writers.
(Later note.... actually C does have some such optimizations, but
only for unsigned ints...)

test2: make a 1000 node binary tree and do a 1000000 random insertions and
deletions from it. (Tests data structures and malloc/free/garbage collect.)

fib: find fibonacci(33)=5702887 by the slow (exp time)
recursion. Tests recursion.

josephus: go round a 200000 element circular list deleting every 47th
guy until 1 left.  (Tests linked lists and malloc/free/garbage
collect.)

test3: 10000000 iter loop with heavy flow control via if/else and
a bunch of bit and array ops. Mildly similar in some ways to hottest code 
(sweep moves) in chess prog "flea".

chesstest: an entire small chess program, material only eval,
   search to depth 4 + quiescence on all 299 reinfeld WAC test positions.
   (also tried gelfer testset.)
A sad thing happened on this test program: it crashed the m3 compiler!!!
However, Garrett was able to find the compiler bug and modify my program
to avoid exciting it.

Results (runtime in user sec on iris51):
            gcc   gcc -O5 cc -O4    m3    m3 -O       t   chezO3  sml
test1       97.3   43.6     45.5  142.5   51.7
test2       12.2    9.8      9.8   24.9   26.7 (!)
fib         14.5    9.5      5.9   10.1   10.1        8.2  21.0  11.3
josephus    12.3    7.3      6.5   35.8   31.0       16.4  17.5   9.5
test3       23.8    6.2      8.1   16.8    8.7       27    58    31
   the following were run on zeitgeist instead of iris51, and cc -O2 not O4.
chesstest WAC               42.5          69.0
chesstest gelfer            49.4          79.2

I am still tempted to go with modula-3 over C++, despite
paying a factor of 3-5 on linked list malloc'd and garbage collected
stuff (and I am also informed that nested subroutine declarations and
calls to procedures passed as parameters, will be slower in m3 than C),
because I know the main time consumer in a chess prog will
be bit-op and array and recursion stuff, and on this, the time hit is
only a factor of 1.1-1.7. 

In our chess test the runtime ratio was 1 : 1.62.


I suspect that upon tweaking the hot parts of the code in both C and
m3 for more speed, that more will be gained in the m3 tweaking than in
the C tweaking since we can put the hot m3 code portions in small
"unsafe modules" in which runtime checking is turned off. So in chess I
suspect the final runtime ratio will be a factor of 1.3, not 1.6. This
is acceptable.  On the other hand, the factor 4-9 runtime hits in
chezO3, sml, and T on test3, make them unnacceptable. But the garbage
collection / malloc / pointer following performance of sml (josephus) is very
impressive; one wishes m3 could duplicate it...

The reasons (ignoring speed) why m3 is the right language for a
chessprog are: it is designed to support large multimodule programs, C
was not (only as an afterthought) and the safety of m3 (no memory
leaks! no out of bounds array accesses!) will lead to tremendous reduction in
debugging time. Also m3 is easier to learn than C++ and there is a nice
online HTML tutorial for it.

The main reasons to prefer C over m3 are, in my view, ones of language
support.  Kalsow at DEC SRC tells me that DEC has 1.5 people working
full time to support m3, and m3 is only a "research project" not an
officially supported "product". For C, it is 1000s of programmers.
Under those circs, that m3 compiler crash scared the shit out of me.
The m3gdb debugger does not work on our SGI machines but does work on
our LINUX machines. The m3pp pretty printer is rather poor performing and
buggy (the cb C beautifier isnt so great either, though).

Feedback I get from net people:
> Which is better for a chess prog, C or m3?
 kalsow@pa.dec.com (Bill Kalsow, mr. Modula-3)
That depends on whether you're going to use any of the features of
Modula-3 that aren't in C++ (e.g.  threads, garbage collection, a rich
standard library) or vice versa (e.g. multiple inheritance, operator
overloading). It is for large multifile programs that m3 really
shines.  [WDS: all this favors m3 for me.]

> Can I trust SRC to support me and fix such bugs fast?
Richard Watts (rrw1000@cam.ac.uk):
 By and large, yes. I've never known them not to fix a bug they have
been provided with the fix for [WDS: Oh, great. This is what the
software community calls "good"], and they're by and large very good
at fixing errors in new releases. That said, obscure bugs for which
you haven't got a fix or good tracing information, or machine-specific
bugs for platforms SRC haven't got tend not to be fixed by SRC -
people like me get to them first :-).

> m3gdb debugger?
 m3gdb is temperamental at the best of times. I've just about given up
on it myself as being more trouble than it's worth :-(. Luckily, M3 is
sufficiently clear that code walk-throughs and diagnostics seem to work
almost as well.

> I am sure modula-3 is the better choice, EXCEPT
> that it looks to me like DEC has pretty much thrown it
> to the wolves and don't officially support it, etc.

Tim Mann  <mann@pa.dec.com>:
"DEC has thrown it to the wolves" is not an accurate picture.  Modula-3
has *always* been a research project, completely unsupported except
for the time that a few folks here at the Systems Research Center
(and elsewhere) are able to put into it.  You cannot expect support.
After all, you are not paying for support, nor is anybody else.
It is much like GNU software---user supported.  Nevertheless, the
people working on it here are very good, and the user community is
growing.  The decision is similar to deciding whether to base part
of your project on some GNU software.

Peter Moylan <peter@fourier.newcastle.edu.au>:
Here's a useful hint to people, like me, who have to do some
projects in C but are unhappy about the exorbitant time C demands
for program design and maintenance.

A year or two ago I tried the experiment of developing a C
program by first writing it (and testing it, of course) in
Modula-2, and then hand-translating it into C.  This really
works!  Not only did I get a program that was more readable and
maintainable than usual, but the initial development time went
down quite substantially.  Since then I've done all my C
programming that way.

Sure, at first sight it sounds as if you're doing double the
work.  But, believe me, you really do win in terms of time
invested.  The hand-translating is somewhat tedious, but not as
bad as you might at first think.  The reason it's a win is
mostly due to the fact that you spent practically no time on
debugging.

------------------
I think the Moylan experiment says it all.

In the worst case, where the m3 compiler completely blows up on us and
we have to translate our enitre m3 program into C (probability = 0.1)
we lose a month, but according to Moylan, we would have gained more
than a month anyway! I think the probability is more like 0.3 that, if
we try to write it in C++, I will end up going nuts with bug
explosions. And by use of RCS to keep track of versions,
we can easily go back to the latest version which did not excite an
m3 compiler bug, so it will not be that hard to avoid them (I hope...).

------------------------------------
From:   Warren D. Smith  (Research Staff; Library Committee Chair)
NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA

Phone: (609) 951-2717   Web: http://www.neci.nj.nec.com/homepages/smith.html
Email: wds@research.NJ.NEC.COM    Fax:   (609) 951-2496  ("for W.D.Smith 1D04"




======================================================================= 50 ===
Date:    08 Jun 1995 23:09:24 GMT
From:    eric@telebit.com (Eric Smith)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <dewar.802395267@gnat> dewar@cs.nyu.edu (Robert Dewar) writes:
> I doubt it, what possible FSF goal can be met by such a separation, it
> would seem to promote exactly that which FSF tries hard to prevent, the
> creation of proprietary technologies which make use of free software.

While I doubt they'll do it, I don't think it is in any way inconsistent
with their goals.  If they get people to write front ends (proprietary or
not) for their back end, that will get more people to use their copylefted
back end, and will eventually get people to write more copylefted front ends.



======================================================================= 51 ===
Date:    8 Jun 95 18:58:24
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: src-m3 for Linux

In article <3r69vi$ioq@martha.utk.edu> elemings@unix1.utm.edu (Eric Lemings) wr
ites:

   What directory can I find the SRC distribution on gatekeeper.dec.com?

gateekeeper.dec.com:/pub/DEC/Modula-3.

The subdirectory "release-3.5.2" is the most current release. 3.5.3 is
in testing phase right now.

-- Farshad

--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 52 ===
Date:    9 Jun 1995 01:58:07 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <ERIC.95Jun8160924@marble.telebit.com> eric@telebit.com (Eric Smith)
 writes:
>While I doubt they'll do it, I don't think it is in any way inconsistent
>with their goals.  If they get people to write front ends (proprietary or
>not) for their back end, that will get more people to use their copylefted
>back end, and will eventually get people to write more copylefted front ends.

No, you misunderstand the priorities of the FSF.  The most important
goal, by far, is preventing free software from being subverted and
used in a proprietary fashion.  Everything else, including trying to
increase use of FSF software, is a distant second.


======================================================================= 53 ===
Date:    8 Jun 1995 07:47:16 GMT
From:    hebert@prism.uvsq.fr (Renaud HEBERT)
Subject: Re: [C++ or M3]

In article <NAYERI.95Jun7185912@tahoe.gte.com>, nayeri@gte.com (Farshad Nayeri)
 writes:
|> 
|>[interesting things about threads cut]
[someone thinks that M3 syntax is heavy and I agree]
|> I agree with Steve's sentiments about the syntax. You can either
|> accept it or just pre-process "your own" syntax into M3. One such
|> syntax was created by Andrew Meyers at MIT. 
No the question, I'd like to see this "modified" syntax, is this available on
the net ?

Thanks.
|> 
|> -- Farshad
|> 
|> --
|> Farshad Nayeri
|> nayeri@gte.com
|> 
|>   ``Obviously, in each of these cases design decisions have been made,
|>     but unfortunately they were wrong.'' --Victor Papanek, 
|>                                            Design for the Real World

-- 
Renaud HEBERT	       E-mail: Renaud.Hebert@prism.uvsq.fr
Serveur Mosaic:        http://www.prism.uvsq.fr



======================================================================= 54 ===
Date:    7 Jun 1995 22:00:04 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <3qvn3l$bue@nntp5.u.washington.edu> "Marc E. Fiuczynski" <mef@cs.was
hington.edu> writes:
>Does anyone know if the FSF will separate their backend more from their
>front ends?  The current hack of adding a m3.c file to the gcc compiler
>is fine, but even SRC has problems using the gcc backend optimizations
>properly.  

They have been separated since GCC 2.6.0.  Each language front-end
resides in its own subdirectory from GCC.  The configure script
looks for which languages you have (by searching all
subdirectories for Make-lang.in) and stitches things together.


======================================================================= 55 ===
Date:    09 Jun 1995 15:58:20 GMT
From:    nayeri@gte.com (Farshad Nayeri)
Subject: When NEW fails (summary)


The following is my summary (in form of question and answers) on the
topic of dealing with allocation failure in SRC Modula-3. 

The questions and answers are based on my interpretations and do not
represent opinions of the participants in the conversation. I'd be
happy to hear from you about corrections or include your contributed
Q&A's on this topic.

The detailed account of some of the postings (as well as this summary)
is filed as: 

             ftp.gte.com:/pub/m3/notes/When-NEW-fails.txt.


-- Farshad


                          When New Fails
                               or
              Dealing With Allocation Failures in Modula-3


Q: What does SRC Modula-3 do when NEW is called and virtual memory is
   exhausted?

A: It crashes with a checked run-time error.


Q: The fact that NEW crashes if there is not enough memory is
   inconvenient. Why can't we have it raise an exception or return
   NIL?

A: Chaning NEW semantics at this point is difficult since so many
   programs are not prepared to deal with an exception or a NIL
   result. In fact, to have NEW raise an exception means that you need
   to be aware of this exception practically at all times. This will
   affect most Modula-3 programs which don't care about such
   conditions. 


Q: So, changing NEW is not the right thing to do. What about having an
   internal routine such as RTAllocator.New* to return either a NIL or
   raise an exception. In the future such an interface can become part
   of the 'standard'.

A: This makes more sense, but we still need to find out what the
   semantics of such an interface would be and how to go about
   implementing it. As for it becoming a part of the 'standard', it
   may restrict implementations too much to put this into the
   standard.


Q: As for the semantics of RTAllocator.New*, why not call some
   programmer-defined handler when memory is low, like what C++
   implements "new"?

   This way the programmer can allocate a 'safety net' block of memory
   and register a callback that will free the safety net, sets a flag,
   and returns. The handler is called upon an out-of-memory condition
   and the callers of NEW can check for the flag and when it is set,
   they will treat the call to NEW as invalid.

A: This solution includes a race condition since another thread could
   run and do an allocation between the time the faulting NEW returns
   and when the handler's actions take place. (Perhaps this can be
   mimimized by adding some slop to the safety net.)

   In general, it is hard to come up with a mechanism that will work
   well in a multi-threaded environment. First, the procedures
   notified can't acquire locks or call most procedures in other
   modules.  Second, it requires a new collection to run synchronously
   after the procedures to see if enough space has been freed and
   whether some of the procedures must be called again; this causes an
   interruption of service. [I need to be convinced of this.]


Q: What about having a thread to sit in the background and monitoring
   the allocator's limits, or have the programmer check before
   allocating something if there is enough room for it?

A: Unfortunately, since the collector can't move some of the objects,
   it is hard to predict if for example, 1M free heap would allow a 1M
   object could be allocated. A fragmented 1M heap wouldn't allow
   allocation of 1M objects, because some objects may be "pinned down"
   in the heap by the collector.


Q: Why can't we ask the collector what is the largest contiguous space
   available at the moment? Surely if I ask for something smaller than
   the largest contiguous space currently available I should be able
   to get at it. This may be too optimistic in many cases but it may
   work for programs that want to be "extra careful".

A: [Presumably this is going to be too small for most cases? Or that
   garbage collectors don't have the information available easily.]


Q: Maybe we could operate in a failsafe mode at all times, where the
   allocator always allocates enough to make sure it will make it to
   the next collection. 

A: Yes, a complicated scheme like this is possible, but it is messy
   and will involve a lot of work. Besides, it is not clear if it will
   be that useful.


Q: What do most C programs do in low memory conditions?

A: Most of them fail with an unchecked run-time error. There are few
   carefully programmed applications that avoid this problem.  Some
   examples are multi-window GUI applications that close some windows
   in low-memory conditions. Some (such as GNU Emacs) don't allow the
   user to allocate the memory until some more memory is gathered. But
   most C programs are single-threaded which will make this problem
   easier to deal with.


Q: What do multiple threads have to do with this?

A: If RTAllocator.New* raises an exception when the memory is too low
   (and therefore stop you from allocating), how are you going to stop
   other threads from allocating more memory?


Q: What if you set a flag, alert all the threads to terminate, and
   then raise an exception?

A: This is quite messy!


Q: I want to deal with low-memory situations now. Which interface do I
   use to look up how much heap there is, etc.?

A: [Don't know.]


Q: So, what is this all good for?

A: Someone's master's project! Any volunteers?

--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 56 ===
Date:    9 Jun 95 08:11:46 GMT
From:    Iovely1@aol.com
Subject: ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles


---------------------
Forwarded message:
Subj:    ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles
Date:    95-06-08 23:58:25 EDT
From:    Iovely1

To:      comp.society.futures@paris.ics.uci.edu
To:      universe.net.events@paris.ics.uci.edu
To:      bit.listserv.sportpsy@paris.ics.uci.edu
To:      rabbit.customers@paris.ics.uci.edu
To:      resif.info.amiga@paris.ics.uci.edu
To:      alt.sports.basketball.nba.hou-rockets@paris.ics.uci.edu
To:      bionet.molbio.evolution@paris.ics.uci.edu
To:      uiuc.ncsa.hci@paris.ics.uci.edu


---------------------
Forwarded message:
Subj:    ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles
Date:    95-06-08 23:37:57 EDT
From:    Iovely1

To:      bionet.metabolic-reg@paris.ics.uci.edu
To:      sfnet.harrastus.visailu@paris.ics.uci.edu
To:      uk.lisp@paris.ics.uci.edu
To:      uk.media@paris.ics.uci.edu
To:      uk.misc@paris.ics.uci.edu
To:      uk.net@paris.ics.uci.edu
To:      pdx.music@paris.ics.uci.edu
To:      pdx.online@paris.ics.uci.edu

CHEAPEST USA MAG SUB AGENCY - SHIPS WORLDWIDE + FREE 1yrSUB

Hi, my name is Susan Loring and I recently started using a magazine
subscription club in the USA that has a FREE 1 yr. magazine subscription deal
with your first paid order- and I have been very pleased with them.    They
have over 1,500 different USA titles that they can ship to any country on a
subscription basis.  They saved me a lot of money on my Economist
subscription:  over $40 off the best subscription price on I had seen
anywhere else and they got me a great deal on USA Today newspaper, which
arrives the same day as the cover date.  (I still don't know how they manage
to do that!)

They will send you some FREE info. via E-mail (the short version (around 40K)
of their catalogue, or if you request it the DELUXE LONG VERSION (around
400K-big and juicey) !)...if you fill out the form below.

Please do not email me as I am just a happy customer and a *busy* student.  I
don't have time to even complete my thesis in time, let alone run my
part-time software business!  Email them directly at:
       julie12@freenet.fsu.edu


*------------cut here-----------------------------------------------*
REQUEST FOR MORE INFO:  please copy this section *only* and email to:
                                  julie12@freenet.fsu.edu

(sorry, but they cannot acknowledge incomplete forms sent back)

Name:
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Name of USA mags you currently get:
Name of USA mags you would like price quotes on when we call you:
Do you want the short (~40K) or long version (~400K) of our
catalogue emailed to you?:
How did you hear about us (name of person who referred you or the area of the
internet that you saw us mentioned in):  Susan Loring
060995 par
*------------cut here-----------------------------------------------*


They guarantee to beat all their competitors' prices. Sometimes they are less
than half of the next best deal I have been able to find and other times,
just a little cheaper - but I have never found a lower rate yet.  They
assured me that if I ever do, they will beat it.

They have been very helpful and helped me change my address from the USA to
Finland and then back again when I moved last month.  They are very
knowledgeable about addressing mags worldwide.

They have a deal where you can get a free 1 yr. sub to a new magazine from a
special list of over 300 popular titles published in the USA.   They will
give you this free 1 yr. sub when you place your first paid order with them
to a renewal or new subscription to any of the over 1,500 different popular
USA titles they sell.

They can arrange delivery to virtually any country and I think they have
clients in around 35 or 36 countries now.  Outside the USA there is a charge
for foreign postage and handling (on both paid and freebie subs) that varies
from magazine to magazine.  I have found their staff to be very friendly and
courteous.  They even helped me with an address change when I moved from one
country to another.

The owner thinks of his service as a "club" and his clients as "members"
(even though there is no extra fee to become a member - your first purchase
automatically makes you a member) and he is real picky about who he accepts
as a new member.   When he sets you up as a new member, he himself calls you
personally on the phone to explain how he works his deal, or sometimes he has
one of his assistants call.  He is kind of quirky sometimes - he insists on
setting up new members by phone so he can say hi to everyone (I sure wouldn't
want to have his phone bills!),  but you can place future orders (after your
first order) via E-mail.

He has some really friendly young ladies working for him, who seem to know
just as much as he does about this magazine stuff.  If you live overseas, he
will even call you there, as long as you are interested, but I think he still
makes all his overseas calls on the weekends, I guess cause the long distance
rates are cheaper then.

He only likes to take new members from referrals from satisfied existing
members and he does virtually no advertising- so you can email me and I will
forward your message on to him as a referral.   When I got set-up, they had a
2-3 week waiting list for new members to be called back so that they could
join up. (Once you are an existing member, they help you immediately when you
call. )  I think they are able to get back to prospective new members  the
same day or within a few days now, as they have increased their staff.  I am
not sure about this.........but if you email the above form to them, that is
the way to get started!

They will send you some FREE info. via E-mail (the short version (around 40K)
of their catalogue, or if you request it the DELUXE LONG VERSION (around
400K-big and juicey) !)...if you fill out the form near the top of this
message.

They then send you email  that outlines how his club works and the list of
free choices that you can choose from, as well as the entire list of what he
sells;  and then they will give you a quick (3-5 minute) friendly,
no-pressure no-obligation call to explain everything to you personally and
answer all your questions.

Here is a list of some of the 1500+ titles that they sell (for your free
selection with your first paid order, approximately one-fifth of these appear
on their special freebies list).

ACCENT
ACCENT ON LIVING
ACCESSORIES
ACTION COMICS
ACTION PURSUIT GAMES
ADIRONDACK LIFE
ADVENTURE WEST
ADVENTURES OF SUPERMAN (COMIC)
ADVERTISING AGE
ADVOCATE
AFRICAN PROFILES INTERNATIONAL
AIR CLASSICS
AIR COMBAT
AIR FORCE TIMES
AIR & SPACE
ALASKA
ALASKA MEN
ALASKA OUTDOORS
ALBUQUERQUE MONTHLY
ALFRED HITCHCOCK MYSTERY
ALLURE
ALOHA
AMATEUR RADIO TECHNICAL JOURNAL
AMAZING SPIDERMAN (COMIC)
AMERCAN HEALTH
AMERICA'S CIVIL WAR
AMERICAN ARTIST
AMERICAN ASTROLOGY
AMERICAN BABY
AMERICAN BABY
AMERICAN  CAGE BIRD
AMERICAN COLLECTOR'S JOURNAL
AMERICAN COTTON GROWER
AMERICAN COWBOY
AMERICAN COWBOY
AMERICAN DEMOGRAPHICS
AMERICAN FORESTS
AMERICAN FRUIT GROWER
AMERICAN HANDGUNNER
AMERICAN HEALTH
AMERICAN HERITAGE (HARD COVER)
AMERICAN HERITAGE INVENTION & TECHNOLOGY
AMERICAN HERITAGE (SOFT COVER)
AMERICAN HISTORY ILLUSTRATED
AMERICAN JOURNAL OF MATERNAL / CHILD NURSING
AMERICAN JOURNAL OF NURSING
AMERICAN LIQUIDATION MONTHLY
AMERICAN PHOTO
AMERICAN SALON
AMERICAN SPECTATOR
AMERICAN SQUARE DANCE
AMERICAN VEGETABLE GROWER
AMERICAN VISIONS
AMERICAN WOODWORKER
AMERICANA
AMERICAS (ENGLISH)
AMERICAS (SPANISH)
AMIGA WORLD
ANALOG SCIENCE FICTION / FACT
ANTIQUE TRADER WEEKLY
ANTIQUES
ANTIQUING AMERICA
AQUARIUM FISH
ARCHAEOLOGY
ARCHITECTURAL DIGEST
ARCHITECTURE
ARIEL
ARMY TIMES
ART & ANTIQUES
ART & ANTIQUES INVESTMENT REPORT
ART IN AMERICA
ARTIST'S MAGAZINE
ARTNEWS
ARTS &  ACTIVITIES
ASIAN SOURCES (COMPUTER PRODUCTS)
ASIAN SOURCES (ELECTRONIC COMPONENTS)
ASIAN SOURCES (ELECTRONICS)
ASIAN SOURCES (GIFTS & HOME)
ASIAN SOURCES (HARDWARE)
ASIMOV'S SCIENCE FICTION
ASTROLOGY
ATLANTA
ATLANTA HOMES & LIFESTYLES
ATLANTIC MONTHLY
AUDIO
AUDIO / VIDEO INTERIORS
AUDUBON
AUTO RACING DIGEST
AUTOMOBILE
AUTOMOTIVE NEWS
AUTOMUNDO
AUTOTRONICS
AUTOWEEK
AVENGERS (COMIC)
AVENGERS WEST COAST (COMIC)
AVIATION HERITAGE
BACK STAGE
BACKPACKER
BACKSTRETCH
BALTIMORE
BANK NOTE REPORTER
BARBIE (COMIC)
BARBIE FASHION BOOK (COMIC)
BARBIE MAGAZINE
BARELY LEGAL
BARTER NEWS
BASEBALL CARD PRICE GUIDE
BASEBALL CARDS MAGAZINE
BASEBALL DIGEST
BASEBALL WEEKLY (USA TODAY)
BASKETBALL DIGEST
BASKETBALL WEEKLY
BASS PLAYER
BASS & WALLEYE BOATS
BASSIN'
BATMAN (COMIC)
BEAVIS  & BUTTHEAD
BERKSHIRE
BEST RECIPES
BETTER HOMES & GARDENS
BEVERAGE WORLD
BEVERAGE WORLD
BIBLE REVIEW
BIBLICAL ARCHAEOLOGY REVIEW
BICYCLE GUIDE
BICYCLING
BIG BEAUTIFUL WOMAN (BBW)
BIRD TALK
BIRDER'S WORLD
BLACK AXE (COMIC)
BLACK BELT
BLACK COLLEGIAN
BLACK ELEGANCE
BLACK ENTERPRISE
BLOOD HORSE
BLUE & GOLD ILLUSTRATED
BOARDROOM REPORTS
BOATING
BOATING WORLD
BODY - MIND - SPIRIT
BON APPETIT
BOSTON MAGAZINE
BOTTOM LINE / PERSONAL
BOW & ARROW
BOW & ARROW HUNTING
BOW HUNTING WORLD
BOWHUNTER
BOWHUNTING
BOWHUNTING WORLD
BOWLING DIGEST
BOWMASTERS
BOXING ILLUSTRATED
BOY'S LIFE
BRIDAL GUIDE
BRIDES
BRITISH CAR
BRITISH HERITAGE
BROADCASTING
BUCKHUNTERS DIGEST
BUENHOGAR
BUSINESS PUBLISHING
BUSINESS START-UPS
BUSINESS WEEK
BUZZ (TALK OF LOS ANGELES)
BYTE
CABLE (COMIC)
CALIFORNIA JOURNAL
CAMCORDER
CAMERA & DARKROOM
CAMPUS LIFE
CANDY INDUSTRY
CANOE
CAPPER'S
CAPTAIN AMERICA (COMIC)
CAR AUDIO & ELECTRONICS
CAR COLLECTOR & CAR CLASSICS
CAR CRAFT
CAR & DRIVER
CAR STEREO REVIEW
CARAS DE PUERTO RICO
CARD COLLECTOR'S PRICE GUIDE
CARIBBEAN TRAVEL & LIFE
CARS & PARTS
CASH SAVER
CAT FANCY
CATALOG SHOPPING
CATHOLIC DIGEST
CATHOLIC FAMILY BIBLE
CATTLEMAN
CATWOMAN (COMIC)
CD REVIEW
CD-ROM TODAY
CD-ROM WORLD
CENTRAL FLORIDA CAREER GUIDE (W/UPDATES)
CHAMPION CROSSWORD PUZZLES
CHAMPION VARIETY PUZZLES
CHAMPION VARIETY REVIEW
CHANGES
CHARISMA & CHRISTIAN LIFE
CHATELAINE (IN ENGLISH)
CHATELAINE (IN FRENCH)
CHESAPEAKE BAY
CHEVY HIGH PERFORMANCE
CHIC
CHICAGO
CHILD
CHILD LIFE
CHILDREN'S ALBUM
CHILDREN'S CLASSICS
CHILDREN'S DIGEST
CHILDREN'S PLAYMATE
CHOCOLATIER
CHRISTIAN HISTORY
CHRISTIAN PARENTING TODAY
CHRISTIAN READER
CHRISTIAN SCIENCE MONITOR
CHRISTIANITY TODAY
CIRCLE TRACK
CIRCUS
CIVIL WAR CHRONICLES
CIVIL WAR TIMES
CLASSIC AUTO RESTORER
CLEVELAND MAGAZINE
COACH
COIFFURE DE PARIS
COIN PRICES
COIN WORLD
COINAGE
COINS MAGAZINE
COLLECTOR EDITIONS
COLLECTORS MART
COLLECTORS NEWS
COLLECTORS NEWS
COLLEGE SPORTS
COLONIAL HOMES
COLORADO BUSINESS
COLORADO HOMES & LIFESTYLES
COLUMBIA JOURNALISM REVIEW
COMIC BOOK COLLECTOR
COMIC BOOK COLLECTOR'S PRICE GUIDE
COMIC SCENE
COMICS BUYERS GUIDE
COMICS SCENE
COMMON CAUSE
COMMONWEAL
COMPUTER GAME REVIEW & CD-ROM ENTERTAINMENT
COMPUTER GAMING WORLD
COMPUTER LIFE
COMPUTER SHOPPER
COMPUTERWORLD
CONAN CLASSICS (COMIC)
CONAN SAGA (COMIC)
CONAN THE ADVENTURER (COMIC)
CONDE NASTE TRAVELER
CONSUMER REPORTS
CONSUMER REPORTS ON HEALTH
CONSUMER REPORTS TRAVEL LETTER
CONSUMER RESEARCH
CONSUMERS DIGEST
CONSUMERS RESEARCH
CONTEMPORARY CHRISTIAN MUSIC
COOK'S ILLUSTRATED
COOKBOOK DIGEST
COOKING LIGHT
CORVETTE FEVER
COSMOPOLITAN
COSMOPOLITAN EN ESPANOL
COUNTRY
COUNTRY ACCENTS
COUNTRY AMERICA
COUNTRY FEVER
COUNTRY GUIDE
COUNTRY HANDCRAFTS
COUNTRY HOME
COUNTRY HOME FOLK CRAFTS
COUNTRY JOURNAL
COUNTRY JOURNAL
COUNTRY LIVING
COUNTRY MUSIC
COUNTRY MUSIC CITY NEWS
COUNTRY SAMPLER
COUNTRY WOMAN
CQ RADIO AMATEURS JOURNAL
CRAFTING TODAY
CRAFTS
CRAFTS 'N THINGS
CRAFTWORKS FOR THE HOME
CRAIN'S NEW YORK BUSINESS
CRAYOLA KIDS
CREATIVE CLASSROOM
CREATIVE KIDS
CREATIVE QUILTING
CREATIVE REAL ESTATE
CREATIVE WOODWORKING & CRAFTS
CRICKET
CROCHET DIGEST
CROCHET FANTASY
CROCHET HOME
CROCHET WORLD
CROCHET WORLD SPECIALS
CROSS COUNTRY SKIER
CROSS STITCH
CROSS STITCH PLUS
CROSS STITCHER
CROSSSTITCH & COUNTRY CRAFTS
CRUISE TRAVEL
CRUISE TRAVEL
CRUISES & TOURS
CRUISING WORLD
CUSTOM & CLASSIC TRUCKS
CUSTOMER ASSURANCE REPORT
CUSTOMER SERVICE NEWSLETTER
CYCLE WORLD
DAILY NEWS RECORD
DANCE
DAREDEVIL (COMIC)
DARKHAWK (COMIC)
DAS LEBEN
DATA BASED ADVISOR
DAYTIME TV
DBMS (DATABASE MANAGEMENT SYSTEMS)
DEATH'S HEAD II (COMIC)
DEBATE ISSUES
DECORATING DIGEST
DECORATIVE ARTIST'S WORKBOOK
DECORATIVE ARTS PAINTING
DECORATVE WOODCRAFTS
DEER & DEER HUNTING
DEFENSE NEWS
DELAWARE TODAY
DELL CROSSWORD PUZZLES
DELL CROSSWORD SPECIAL
DELL CROSSWORDS & VARIETY PUZZLES
DELL HOROSCOPE
DELL LOGIC PUZZLES
DELL OFFICIAL CROSSWORD PUZZLES
DELL OFFICIAL PENCIL PUZZLE & WORD GAMES
DELL OFFICIAL WORD SEARCH PUZZLES
DELL PENCIL PUZZLES & WORD GAMES
DELL POCKET CROSSWORD PUZZLES
DELL POCKET CROSSWORD PUZZLES
DELL WORD SEARCH PUZZLES
DES
DESKTOP VIDEO WORLD
DESSERTS
DETAILS
DETECTIVE COMICS
DETROIT MONTHLY
DIRT BIKE
DISCIPLESHIP JOURNAL
DISCOUNT STORE NEWS
DISCOVER
DISCOVER DIVING
DISNEY ADVENTURES
DISNEY'S HOW IT WORKS
DISTRIBUTION CENTER MANAGEMENT
DOG FANCY
DOG WORLD
DOLL CASTLE NEWS
DOLL DESIGNS
DOLL LIFE
DOLL WORLD
DOLLMAKING
DOLLS
DOOM 2099 (COMIC)
DOWN EAST
DOWN MEMORY LANE
DOWNBEAT
DR. DOBB'S JOURNAL
DR. STRANGE (COMIC)
DRUG & COSMETIC INDUSTRY
EARLY AMERICAN LIFE
EARLY CHILDHOOD NEWS
EARLY CHILDHOOD TODAY
EARTH
EARTH JOURNAL
EASY FAST "N FUN CROSSWORDS
EATING WELL
EBONY
EBONY MAN (EM)
ECONOMIST
ECOTRAVELER
ELECTRONIC GAMES
ELECTRONIC GAMING MONTHLY
ELECTRONIC LEARNING
ELECTRONICS NOW
ELITE MAGAZINE
ELLE (AMERICAN)
ELLE DECOR
ELLERY QUEEN'S MYSTERY
ELLERY QUEEN'S MYSTERY
EM (EBONY MAN)
EMERGE
ENGINEERING NEWS RECORD (ENR)
ENTERTAINMENT WEEKLY (EW)
ENTREE
ENTREPRENEUR
ENVIRONMENT
EQUITIES
EQUUS
ESQUIRE
ESSENCE
EUROPEAN CAR
EXCALIBUR (COMIC)
EXCEPTIONAL PARENT
EXECUTIVE FEMALE
FAITH & STUFF
FAMILY CIRCLE
FAMILY HANDYMAN
FAMILY LIFE
FANCY FOOD & CANDY
FANGORIA
FANTASTIC FOUR (COMIC)
FANTASY & SCIENCE FICTION
FAR OUT
FARM BUILDING NEWS
FARM & RANCH LIVING
FARMERS DIGEST
FASHION GUIDE
FASHION KNITTING
FATE
FEDERAL TIMES
FEMALE BODYBUILDING
FIELD & STREAM
FIGHTING KNIVES
FIGHTING STARS NINJA MAGAZINE
FILM THREAT
FINANCIAL TIMES OF LONDON (MON - SAT)
FINANCIAL WORLD
FINE GARDENING
FINE HOMEBUILDING
FINE WOODWORKING
FIREHOUSE
FISHING FACTS
FISHING & HUNTING NEWS
FISHING WORLD
FIVE LITER MUSTANG
FLARE
FLASH (COMIC)
FLEX
FLOORING
FLORIDA LIVING
FLORIDA SPORTSMAN
FLORIDA TREND
FLORIDA VACATION RENTALS
FLOWER & GARDEN
FLY FISHERMAN
FLY FISHING
FLYING
FLYING MODELS
FOOD & WINE
FOOTBALL DIGEST
FOOTBALL NEWS
FORBES
FORCE WORKS (COMIC)
FOREIGN AFFAIRS
FOREIGN POLICY
FORTUNE
FORUM (PENTHOUSE)
FOUR WHEEL / OFF ROAD
FOUR WHEELER
FRONT PAGE DETECTIVE
FUN-ZONE
FUR - FISH - GAME
FUTURIFIC
FUTURIFIC
G.I. JOE (COMIC)
GAME PLAYERS NINTENDO GUIDE
GAME PLAYERS NINTENDO - SEGA
GAME PLAYERS PC ENTERTAINMENT
GAMEPRO
GAMES
GARBAGE
GEMS & GEMNOLOGY
GEMS & GEMNOLOGY
GENTLEMEN'S QUARTERLY (GQ)
GEOMUNDO
GET RICH NEWS
GHOST RIDER 2099 (COMIC)
GHOST RIDER / BLAZE (COMIC)
GHOST RIDER (COMIC)
GIFTS & DECORATIVE ACCESSORIES
GIFTWARE NEWS
GLAMOUR
GLASS DIGEST
GLEANINGS IN BEE CULTURE
GOD'S WORD TODAY
GOLDMINE
GOLF DIGEST
GOLF FOR WOMEN
GOLF MAGAZINE
GOLF TIPS
GOLF WEEK
GOLF WORLD
GOLFING
GOOD DAY SUNSHINE
GOOD HOUSEKEEPING
GOOD OLD DAYS
GOOD OLD DAYS SPECIALS
GOURMET
GREEN LANTERN (COMIC)
GRIT
GROO (COMIC)
GROWING UP WITH SCIENCE
GUARDIANS OF THE GALAXY (COMIC)
GUIDEPOSTS
GUIDEPOSTS (LARGE PRINT EDITION)
GUN DOG
GUN LIST
GUN WORLD
GUNS
GUNS & AMMO
GUNS & AMMO
HAIR ADDITIONS
HAIR & BEAUTY NEWS
HANDCRAFT ILLUSTRATED
HANDGUNNING
HANDGUNS
HARPER'S BAZAAR
HARPER'S BAZAAR EN ESPANOL
HARPER'S MAGAZINE
HARROWERS (COMIC)
HARVARD BUSINESS REVIEW
HAWAII
HEALTH
HELLSTORM (COMIC)
HERALD TRIBUNE CROSSWORD PUZZLES ONLY
HERALD TRIBUNE & OTHER CROSSWORD GAMES
HERO ILLUSRATED
HIGHLANDER
HIGHLIGHTS
HIGHLIGHTS
HISPANIC
HISTORIC PRESERVATION
HOCKEY DIGEST
HOCKEY NEWS
HOLLYWOOD STUDIO
HOLLYWOOD STUDIO MAG THEN & NOW
HOMBRE DE MUNDO
HOME COOKING
HOME GYM & FITNESS
HOME MAGAZINE
HOME MAGAZINE
HOME MECHANIX
HOME OFFICE COMPUTING
HONOLULU
HOOKED IN CROCHET
HORIZON
HOROSCOPE
HOROSCOPE/ A PERSONAL DAILY GUIDE FOR EVERYONE
HOROSCOPE / DELL
HORSE & HORSEMAN
HORSE & HORSEMAN
HORSE ILLUSTRATED
HORSE & RIDER
HORSEPLAY
HORTICULTURE
HOT BOAT
HOT ROD
HOT ROD HARLEYS
HOUSE BEAUTIFUL
HOUSTON METROPOLITAN
HOUSTON PEOPLE
HOUSTON PROFILES
HOW
HUDSON VALLEY
HUMPTY DUMPTY
HUNTING
HUSTLER
HUSTLER'S BUSTY BEAUTIES
HUSTLER'S EROTIC VIDEO GUIDE
HUSTLER'S FANTASIES
HUSTLER'S HUMOR
I LOVE CATS
IDEAS
IDEAS PARA SU HOGAR
ILLUSTRATED BIBLE FOR CHILDREN
IMPORT AUTO PARTS & ACCESSORIES
IN BUSINESS
IN-FISHERMAN
INC.
INCOME OPPORTUNITIES
INCOME PLUS
INCREDIBLE HULK (COMIC)
INDIVIDUAL INVESTOR
IINDUSTRIAL MARKET PLACE
INSIDE EDGE
INSIDE IRELAND
INSIDE KARATE
INSIDE KUNG FU
INSIDE SPORTS
INSIGHT
INSTITUTIONAL INVESTOR
INSTRUCTOR
INTERIOR DECORATOR'S HANDBOOK
INTERIOR DESIGN
INTERIORS
INTERNATIONAL LIVING
INTERNATIONAL NURSING INDEX
INTERNET WORLD
INTERVIEW
INTIMATE FASHION NEWS
INVESTOR'S DAILY
IRON MAN (COMIC)
ISLANDS
ISRAEL SCENE
JACK & JILL
JERSEY WOMAN
JERUSALEM POST INTERNATIONAL WEEKLY EDITION
JERUSALEM REPORT
JET
JEWISH EXPONENT
JEWISH HOMEMAKER
JEWISH POST & OPINION
JEWISH PRESS
JUSTICE LEAGUE AMERICA (COMIC)
JUSTICE LEAGUE EUROPE ( COMIC)
KARATE / KUNG FU ILLUSTATED
KEYBOARD
KID CITY
KIDSPORTS
KIPLINGER'S PERSONAL FINANCE
KIT CAR
KITPLANES
KNIFE WORLD
KNITTING DIGEST
KNITTING WORLD
L'ACTUALITE
LA LUZ
LA VIE
LADIES HOME JOURNAL
LADY'S CIRCLE
LADYBUG
LAKELAND BOATING
LAN MAGAZINE (LOCAL AREA NETWORK)
LAPIDARY JOURNAL
LEADERSHIP
LEARNING '94
LEFTHANDER
LEGAL GUIDE FOR THE FAMILY
LEGION OF SUPER-HEROES (COMIC)
LET'S LIVE
LIBRARY OF NATURAL WONDERS
LIFE
LIGHTING DIMENSIONS
LINK-UP
LINN'S STAMP NEWS
LITTLE MERMAID
LLUMO VOGUE
LONGEVITY
LOONEY TUNES (COMIC)
LOOSE CHANGE
LOS ANGELES
LOTTERY PLAYERS MAGAZINE
MAC HOME JOURNAL
MACLEANS
MACUSER
MACWORLD
MADEMOISELLE
MARKETERS FORUM
MARRIAGE PARTNERSHIP
MARVEL AGE (COMIC)
MARVEL COMICS PRESENTS
MARVEL TALES SPIDERMAN (COMIC)
MCCALL'S
MCCALL'S NEEDLEWORK & CRAFTS
MECANICA POPULAR
MECHANICA POPULAR
MEDIA & METHODS
MEDICAL & HEALTH ENCYCLOPEDIA
MEDICAL HOTLINE
MEDICAL UPDATE
MEGA PLAY
MEMPHIS MAGAZINE
MEN'S CONFIDENTIAL
MEN'S FITNESS
MEN'S HEALTH
MEN'S JOURNAL
METROPOLIS
METROPOLITAN HOME
MICKEY MOUSE
MICRO COMPUTER JOURNAL
MICROSOFT SYSTEMS JOURNAL
MID-ATLANTIC COUNTRY
MIDSTREAM
MIDWEST LIVING
MILITARY HISTORY
MILWAUKEE
MINISTRIES TODAY
MINNESOTA MONTHLY
MIRABELLA
MOBILE OFFICE
MODEL AIRPLANE NEWS
MODEL NEWS
MODEL SHOPPER
MODELS & TALENT/CASTING NEWS
MODERN BRIDE
MODERN GUN
MODERN HORSE BREEDING
MODERN SALON
MOMENT
MONEY
MONEYPAPER
MOODY MAGAZINE
MOODY MONTHLY
MOPAR MUSCLE
MORIBUS (COMIC)
MOTHER EARTH NEWS
MOTHER JONES
MOTHERING
MOTOR BOATING & SAILING
MOTOR TREND
MOTORCROSS ACTION
MOTORCYCLE CONSUMER NEWS
MOTORCYCLIST
MOTORHOME
MOUNTAIN BIKE
MOVIE MARKETPLACE
MOVIELINE
MUNDO 21
MUSCLE & FITNESS
MUSCLECAR REVIEW
MUSICIAN
MUSTANG MONTHLY
MUSTANGS & FORDS
MUSTANGS MONTHLY
NAILS
NAMOR (COMIC)
NATION
NATION'S BUSINESS
NATION'S RESTAURANT NEWS
NATIONAL AUCTION REPORT
NATIONAL ENQUIRER
NATIONAL FISHERMAN
NATIONAL LAW JOURNAL
NATIONAL OTC STOCK JOURNAL
NATIONAL PARK MAGAZINE
NATIONAL REVIEW
NATIONAL TRIAL LAWYER
NATURAL HEALTH
NATURAL HISTORY
NAVY TIMES
NBA INSIDE STUFF
*THE NET* (about the Internet)
NEEDLE & CRAFT
NEVADA MAGAZINE
NEW AGE JOURNAL
NEW BUSINESS OPPORTUNITIES
NEW CHOICES
NEW ENGLAND JOURNAL OF MEDICINE
NEW FARM
NEW JERSEY MONTHLY
NEW JERSEY OUTDOORS
NEW MEXICO
NEW REPUBLIC
NEW TITANS (COMIC)
NEW WARRIORS (COMIC)
NEW WOMAN
NEW YORK MAGAZINE
NEW YORK REVIEW OF BOOKS
NEW YORKER
NEWSWEEK
NICE & EASY FAMILY COOKBOOK
NIGHT TRASHER (COMIC)
NIGHT WATCH (COMIC)
NO-TILL FARMER
NORTH FLORIDA LIVING
NORTH SHORE (CHICAGO)
NOVA (COMIC)
NUMISMATIC NEWS
NURSING
NUTRITION & DIETARY CONSULTANT
NUTRITION HEALTH REVIEW
OCCASIONAL BULLETIN
OFF ROAD
OFFICIAL CROSSWORD PUZZLES
OFFICIAL DETECTIVE
OFFICIAL MAJOR LEAGUE BASEBALL ROOKIE LEAGUE MAGAZINE FOR KIDS
OFFICIAL PENCIL PUZZLES / WORD GAMES
OFFICIAL US CUSTOM HOUSE GUIDE
OFFICIAL WORD SEARCH PUZZLES
OLD CARS NEWS & MARKETPLACE
OLD CARS PRICE GUIDE
OLD HOUSE JOURNAL
OLD TIME CROCHET
OMNI
ONLINE ACCESS
ONSAT
OPEN WHEEL
OPERA NEWS
OPPORTUNITY MAGAZINE
ORGANIC GARDENING
OUTDOOR LIFE
OUTDOOR PHOTOGRAPHER
OUTDOOR PRESS
OUTSIDE
OVERDRIVE
PACIFIC NORTHWEST
PACK -O-FUN
PADDLE SPORTS
PADDLER
PAINTWORKS
PALM BEACH LIFE
PALM SPRINGS LIFE
PARENTING
PARENTS
PARENTS OF TEENAGERS
PASSION
PASSION FOR MEN
PC COMPUTING
PC GAMER
PC GAMES
PC KIDS
PC LAPTOP
PC MAGAZINE
PC NOVICE
PC TODAY
PC WORLD
PC WORLD LOTUS EDITION
PC WORLD MULTI MEDIA EDITION
PCM
PENNSYLVANIA SPORTSMAN
PENTHOUSE
PENTHOUSE LETTERS
PEOPLE
PET DEALER
PHILADELPHIA
PHOENIX HOME & GARDEN
PHOTOGRAPH COLLECTOR
PHOTOGRAPHIC
PINHEAD (COMIC)
PLANE & PILOT
PLASTIC CANVAS
PLASTIC CANVAS & MORE
PLASTIC CANVAS WORLD
PLAYBOY
PLAYGIRL
PLAYTHINGS
POCKET CROSSWORD PUZZLES
POLO
POPULAR COMMUNICATIONS
POPULAR ELECTRONICS
POPULAR HOT RODDING
POPULAR MECHANICS
POPULAR PHOTOGRAPHY
POPULAR SCIENCE
POPULAR WOODWORKING
PORTABLE COMPUTING
POST SCRIPT
POST SCRIPTS: ESSAYS IN FILM & THE HUMANITIES
POWDER
POWER & MOTOR YACHT
PRACTICAL HORSEMAN
PREMIERE
PRESENT TENSE
PREVENTION
PRIVATE PILOT
PRO FOOTBALL WEEKLY
PROGRESSIVE
PROGRESSIVE FARMER
PROTESTANT DELUXE BIBLE
PROTESTANT FAMILY BIBLE
PSYCHOLOGY TODAY
PUBLISH
PULSE
PUNISHER 2099 (COMIC)
PUNISHER (COMIC)
PUNISHER WAR JOURNAL (COMIC)
PUNISHER WAR ZONE (COMIC)
QUASAR (COMIC)
QUICK & EASY CRAFTS
QUICK & EASY CROCHET
QUICK & EASY NEEDLECRAFT
QUICK & EASY PLASTIC CANVAS
QUICK & EASY QUILTING
QUILT WORLD
QUILTER'S NEWSLETTER
QUILTER'S TREASURY
QUILTER'S TREASURY
QUILTING INTERNATIONAL
QUILTMAKER
RAILROAD MODEL CRAFTSMAN
RAPPAGES
RAPPORT
RAVAGE 2099 (COMIC)
REAL PEOPLE
REALTY MAGAZINE
REDBOOK
REMINISCE
REN & STIMPY (COMIC)
RETIREMENT INCOME NEWSLETTER
RIDER
RIGHT ON
RIP
ROAD RIDER
ROAD & TRACK
ROBB REPORT
ROCK & GEM
ROD & CUSTOM
ROLLING STONE
RUNNER'S WORLD
RUNNING TIMES
RURAL BUILDER
S.W.A.T.
SABERTOOTH CLASSICS (COMIC)
SADDLE & BRIDE
SAIL
SAILING
SAILING WORLD
SALTWATER SPORTSMAN
SAN DIEGO HOME & GARDEN
SAN DIEGO MAGAZINE
SAN FRANCISCO
SASSY
SATELLITE TV PRE-VUE
SATELLITE TV WEEK
SATURDAY EVENING POST
SAVAGE SWORD OF CONAN (COMIC)
SCHOLASTIC COACH
SCHOOL & COLLEGE
SCIENCE LIBRARY
SCIENCE NEWS
SCIENCE OF MIND
SCIENCES
SCIENTIFIC AMERICAN
SCUBA DIVING
SCUBA TIMES
SEA MAGAZINE
SECRET DEFENDERS (COMIC)
SELF
SESAME STREET
SEVENTEEN
SEVENTY-THREE AMATEUR RADIO
SEW NEWS
SEYBOLD REPORT ON DESKTOP PUBLISHING
SHAPE
SHOOTING TIMES
SHOP TALK
SHORT STORY INTERNATIONAL
SHOW BIZ / CASTING NEWS
SHOW BIZ NEWS/MODEL NEWS
SHOWBOATS INTERNATIONAL
SIDEKICKS
SIDEKICKS SOCCER
SILVER SABLE (COMIC)
SILVER SURFER (COMIC)
SIMPLY CROSS STITCH
SKATEBOARDING
SKI
SKIING
SKIN DIVER
SKIN & INK
SMITHSONIAN
SNOW COUNTRY
SNOW GOER
SNOW WEEK
SNOWBOARDING
SNOWMOBILE
SOAP OPERA DIGEST
SOAP OPERA MAGAZINE
SOAP OPERA STARS
SOCCER AMERICA
SOCCER DIGEST
SOCCER INTERNATIONAL
SOUNDINGS
SOUTH FLORIDA
SOUTHERN ACCENTS
SOUTHERN BOATING
SOUTHERN HOMES
SOUTHERN LIVING
SOUTHERN OUTDOORS
SPACE NEWS
SPECIAL EVENTS
SPECIAL SITUATIONS REPORT
SPECIALTY CAR
SPECTACULAR SPIDERMAN (COMIC)
SPIDERMAN 2099 (COMIC)
SPIDERMAN CLASSIC (COMIC)
SPIDERMAN (COMIC)
SPIN
SPORT
SPORT DIVER
SPORT FISHING
SPORT RIDER
SPORT TRUCK
SPORTING CLASSICS
SPORTING NEWS
SPORTS AFIELD
SPORTS CARD TRADER
SPORTS COLLECTORS DIGEST
SPORTS ILLUSTRATED
SPORTS ILLUSTRATED FOR KIDS
SPORTSWEAR INTERNATIONAL
SPOTLIGHT
STAR
STAR TREK (COMIC)
STAR TREK : THE NEXT GENERATION (COMIC)
STARLOG
STEREO REVIEW
STITCH 'N SEW QUILTS
STOCK CAR RACING
STONE SOUP
STORY
STUDIO USA
STYLE TRENDS
SUCCESS
SUCCESSFUL RETIREMENT
SUNBONNET CRAFTS
SUNSET
SUPER CHEVY
SUPER COMPUTING REVIEW
SUPER CYCLE
SUPER FORD
SUPER NES BUYERS GUIDE
SUPER STOCK & DRAG ILLUSTRATED
SUPERCYCLE
SUPERMAN - MAN OF STEEL (COMIC)
SURFER
SURFING
SURPRISES
SWAP USA
SWAT
T-SHIRT RETAILER
TAMPA BAY CAREER GUIDE (WITH UPDATES)
TASTE OF HOME
TAX HOTLINE
TCI
TEACHING PRE K-8
TECHNOLOGY & LEARNING
TEDDY BEAR REVIEW
TEEN
TEEN BEAT
TEENAGE MUTANT NINJA TURTLES (COMIC)
TEK WORLD (COMIC)
TENNIS
TEXAS FISH & GAME
TEXAS GARDENER
THE SCIENCES
THEATRE CRAFTS
THEOLOGY TODAY
THOR (COMIC)
THREADS
THREE-TWO-ONE CONTACT
THUNDERSTRIKE (COMIC)
TIME
TODAY'S CATHOLIC TEACHER
TODAY'S CHRISTIAN WOMAN
TOLE WORLD
TOTAL HEALTH
TOURING AMERICA
TOWN & COUNTRY
TOY SHOP
TRACK & FIELD NEWS
TRADING CARDS
TRADITIONAL HOME
TRADITIONAL QUILTER
TRAILER BOATS
TRAILER LIFE
TRANSFORMERS GENERATION 2 (COMIC)
TRANSWORLD SKATEBOARDING
TRAPPER & PREDATOR CALLER
TRAVEL 50 & BEYOND
TRAVEL AMERICA
TRAVEL HOLIDAY
TRAVEL & LEISURE
TRAVELAMERICA
TREASURE
TRIATHLETE
TRUE DETECTIVE
TRUE STORY
TU
TURKEY & TURKEY HUNTING
TURTLE
TV CROSSWORDS
TV HOST
TV Y NOVELAS  (PUERTO RICO)
TV Y NOVELAS  (USA)
TWINS
UNCANNY X-MEN (COMIC)
UNDERWATER USA
UNIQUE HAIR & BEAUTY
UNIQUE HOMES
US AVIATOR
US CATHOLIC
US MAGAZINE
US NEWS & WORLD REPORT
USA TODAY
UTNE READER
VACATIONS
VANIDADES
VANITY FAIR
VARIATIONS (PENTHOUSE)
VARIETY (WEEKLY)
VEGETARIAN TIMES
VEGGIE LIFE

and many, many more!!!

Once you get in, you'll love them. I do.  For more info,  just fill out the
form near the top of this message and email it to their email address shown
there.


Thanks,

Susan Loring



======================================================================= 57 ===
Date:    9 Jun 1995 17:04:32 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)


In article <JACKG.95Jun8145124@downhaul.crc.ricoh.com>, jackg@downhaul.crc.rico
h.com (Jack Greenbaum) writes:
> 
> What am I missing here? The gcc intermediate representation, RTL, is
> quite seperate from the front end parse tree representation, the "tree"
> data structures. RTL is the most well documented part of GCC, while
> building a new front end is certainly black magic. 

Yes, but the RTL is machine-specific.  If you want to use gcc to
as a high-leverage, already-ported backend, you must generate "trees".
Generating well-formed trees is difficult.  I know of no written
spec for what's a well-formed tree.

  - Bill Kalsow



======================================================================= 58 ===
Date:    Fri, 09 Jun 95 10:20:20 -0700
From:    mcjones@pa.dec.com
Subject: Re: when NEW fails, revisited

Michel notes:

    A very long and detailed explanation about why this was extremely 
    difficult was posted by the DEC SRC people about 6 months ago. 
    You should be able to find it in the archives in: 

    gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3 

In particular, the message is archived in the file 94-08.Z in the 
directory Michel specified.  Here is the header: 

    Date:    Wed, 24 Aug 94 09:05:33 -0700
    From:    mcjones@src.dec.com
    Subject: Re: Robustness, <*FATAL*>, NEW()


Paul McJones
mcjones@pa.dec.com
Digital Equipment Corporation
Systems Research Center


======================================================================= 59 ===
Date:    9 Jun 1995 17:07:04 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Help with WWW documentation of M3 sources


In article <3r7em1$jks@lyra.csx.cam.ac.uk>, tlh20@thor.cam.ac.uk (Tim Harris) w
rites:

> The work-around is to modify the mime-types file in the configuration
> directory (by default I think that's /usr/local/etc/httpd/conf) and find
> the line starting text/html. This line lists file extensions for which
> the daemon should tell the client that the file is HTML, so adding
> i3 and m3 on the end should make them be recognised correctly.
> 
> Admittedly the word starting with k and ending with ludge springs to
> mind (what if another user has a normal modula-3 program which they
> want to be available as text?) - but I think that's about as well as
> it can be done without large-scale changing of the links in the M3
> files.

Yes.  I changed the program that generates the static HTML from Modula-3
sources to add ".html" to every file.  The new web will be availible
in the next release.

  - Bill Kalsow



======================================================================= 60 ===
Date:    9 Jun 1995 08:21:32 GMT
From:    hebert@prism.uvsq.fr (Renaud HEBERT)
Subject: Re: Comments on Chess Playing Program

In article <3r83pf$29p@newsserv.cs.sunysb.edu>, pbh@cs.sunysb.edu (Peter B. Hen
derson) writes:
|> I am posting this for Warren Smith.  Maybe of interest to some of you.
|> --
|> Peter B. Henderson
|> pbh@sbcs.sunysb.edu
|> Department of Computer Science, SUNY at Stony Brook
|> Stony Brook, N.Y.  11794-4400
|> 
|> -------- Warren's comments start here --------
|> 
|> Tests of runtime speed modula-3 vs C, also comments on language choice
|> for implementing a chess playing program.
|> ----------------------------------------------------------------------
|> By  Warren D. Smith,  wds@research.NJ.NEC.COM 
|> (Now also T, Chez Scheme, and Standard ML of New Jersey, thanks to
|> Kevin Lang and Andrew Wright for writing those. This arose from my
|> desire to write a chess program and decide between C and m3.)
|> 
|> test1: a 1000000 iter loop with a bunch of bit-ops and array accesses.
|> Incidentally this test reveals that neither C nor modula-3 compilers
|> have tables of special cases of common operations, such as, e.g. x MOD
|> 64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x,
|> etc. Pretty damn stupid of certain compiler writers.
|> (Later note.... actually C does have some such optimizations, but
|> only for unsigned ints...)
Yes because in fact if x is negative x/2 isn't the same thing as x >> 1 in C,
because of the rounding.

-- 
Renaud HEBERT	       E-mail: Renaud.Hebert@prism.uvsq.fr
Serveur Mosaic:        http://www.prism.uvsq.fr



======================================================================= 61 ===
Date:    9 Jun 1995 17:16:38 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Comments on Chess Playing Program


In article <3r83pf$29p@newsserv.cs.sunysb.edu>, pbh@cs.sunysb.edu (Peter B. Hen
derson) writes:
> I am posting this for Warren Smith.  Maybe of interest to some of you.
> --

> -------- Warren's comments start here --------

> test1: a 1000000 iter loop with a bunch of bit-ops and array accesses.
> Incidentally this test reveals that neither C nor modula-3 compilers
> have tables of special cases of common operations, such as, e.g. x MOD
> 64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x,
> etc. Pretty damn stupid of certain compiler writers.
> (Later note.... actually C does have some such optimizations, but
> only for unsigned ints...)

Modula-3 defines:

    x DIV y  == FLOOR (x / y)
    x MOD y  == x - y * (x DIV y)

Before you get your "pretty damn smart" compiler writer merit badge,
try x=-1 in your examples...

 - Bill Kalsow



======================================================================= 62 ===
Date:    Fri, 9 Jun 1995 17:59:24 GMT
From:    smcneil@netcom.com (Sean McNeil)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <3r9uv0$5ea@src-news.pa.dec.com>,
Bill Kalsow <kalsow@src.dec.com> wrote:
>
>In article <JACKG.95Jun8145124@downhaul.crc.ricoh.com>, jackg@downhaul.crc.ric
oh.com (Jack Greenbaum) writes:
>> 
>> What am I missing here? The gcc intermediate representation, RTL, is
>> quite seperate from the front end parse tree representation, the "tree"
>> data structures. RTL is the most well documented part of GCC, while
>> building a new front end is certainly black magic. 
>
>Yes, but the RTL is machine-specific.  If you want to use gcc to
>as a high-leverage, already-ported backend, you must generate "trees".
>Generating well-formed trees is difficult.  I know of no written
>spec for what's a well-formed tree.
>

I am also confused.  From my understanding the RTL is not machine-specific.
As far as I know, there are currently several front-ends for gcc (C, C++,
Ada, and Fortran are the ones I know of).  None of these front-ends are
different from platform to platform.  So, I should think that the RTL is
robust enough for any front-end you might want to write.  Like Modula-3.
-- 
-- Sean McNeil                                       smcneil@netcom.com
--  Please append a :-) to any and all comments as I am never serious.


======================================================================= 63 ===
Date:    9 Jun 1995 23:09:14 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)


In article <smcneilD9x3B0.1Dt@netcom.com>, smcneil@netcom.com (Sean McNeil) wri
tes:

> I am also confused.  From my understanding the RTL is not machine-specific.
> As far as I know, there are currently several front-ends for gcc (C, C++,
> Ada, and Fortran are the ones I know of).  None of these front-ends are
> different from platform to platform.  So, I should think that the RTL is
> robust enough for any front-end you might want to write.  Like Modula-3.

Yes, you are confused.  RTL is machine-specific.  Its *syntax*
(ie. parentheses) is not.  Each of the existing frontends generates
a "tree".  Then, somewhat magically, the trees are transformed into
machine-dependent RTL.  RTL encodes all sorts of machine dependencies
like register numbers and calling conventions.  Go read the sources.

  - Bill Kalsow



======================================================================= 64 ===
Date:    8 Jun 1995 07:48:02 GMT
From:    elemings@unix1.utm.edu (Eric Lemings)
Subject: Re: src-m3 for Linux

Torsten R. Kirschner (torki@file01.mpfpi-muenchen.mpg.de) wrote:

: as far as the SRC source destribution is concerned, the closest FTP mirror
: of gatekeeper.dec.com to Ulm in Germany might be ftp.informatik.tu-
: muenchen.de or ftp.leo.org/pub/comp/programming/languages/Modula-3.

What directory can I find the SRC distribution on gatekeeper.dec.com?

Eric Lemings



======================================================================= 65 ===
Date:    09 Jun 1995 22:41:02 GMT
From:    bm@roadkill.cs.columbia.edu (Blair MacIntyre)
Subject: Re: When NEW fails (summary)

>>>>> On 09 Jun 1995 15:58:20 GMT, nayeri@gte.com (Farshad Nayeri)
>>>>> said:

Farshad> The following is my summary (in form of question and answers) on the
Farshad> topic of dealing with allocation failure in SRC Modula-3. 

I bought most of what you said, but I need convincing on the following
point: 

Farshad> Q: The fact that NEW crashes if there is not enough memory is
Farshad>    inconvenient. Why can't we have it raise an exception or return
Farshad>    NIL?

Farshad> A: Chaning NEW semantics at this point is difficult since so many
Farshad>    programs are not prepared to deal with an exception or a NIL
Farshad>    result. In fact, to have NEW raise an exception means that you need
Farshad>    to be aware of this exception practically at all times. This will
Farshad>    affect most Modula-3 programs which don't care about such
Farshad>    conditions. 

At first glance, it would appear that the only effect on the libraries
of raising new would be a plethora of "unhandled exception" warnings
during the next compile.  These could be fixed very fast by adding 
<*FATAL OutOfMemory*> to the files in question.

More importantly, current libraries that bomb right now with out of
memory conditions would continue to bomb.  While not exactly what we
want, this would give no change in behaviour.  So, programs that don't
care about memory problems would behave as they now do.

I realize that it would take a fair amount of cleaning up to actually
make many of the libraries percolate the exception up to the user, but
it would seem to me to be worth it.  So much so that I would volunteer
to help tidy things up.  Since it's mostly a busy-work exercise, if we
got a dozen people to add to the "RAISES" clauses of the various
library routines, things would move along quickly.

Be that as it may, I prefer the solution of registering routines to be
called when memory runs out.  That way, a programmer could free up memory
used for things like caches when it gets low, without having to worry
about handling exceptions.

As for the multithreaded issues, it would seem to me that if the
allocator calls these routines inside a mutex, then tries again to
allocate the required when they have all been called and the garbage
collector given a chance to collect, there would be no multithreading
conflicts.

--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 66 ===
Date:    9 Jun 1995 18:43:47 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <smcneilD9x3B0.1Dt@netcom.com> smcneil@netcom.com (Sean McNeil) writ
es:
>I am also confused.  From my understanding the RTL is not machine-specific.
>As far as I know, there are currently several front-ends for gcc (C, C++,
>Ada, and Fortran are the ones I know of).  None of these front-ends are
>different from platform to platform.  So, I should think that the RTL is
>robust enough for any front-end you might want to write.  Like Modula-3.

The RTL *format* is machine-independent, so that the optimizer can
work on it.

The actual RTL *values* for a particular function are machine-
specific since they are a representation of the machine language.

However, front ends do not generate RTL.  They build expression trees
(which are completely machine-independent) and call function in the
backend that generate RTL from them.

Front ends are not *entirely* machine-independent, though, since they
sometimes need to know such things as sizes, alignments, and
enddianness.  This is why it is easier to write front ends linked with
the backend instead of splitting them into two programs.


======================================================================= 67 ===
Date:    09 Jun 1995 23:37:01 GMT
From:    sean@mcneil.ni.net (Sean McNeil)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <3ra4p3$a88@cmcl2.NYU.EDU> kenner@lab.ultra.nyu.edu (Richard Kenner)
 writes:

   The RTL *format* is machine-independent, so that the optimizer can
   work on it.

   The actual RTL *values* for a particular function are machine-
   specific since they are a representation of the machine language.

   However, front ends do not generate RTL.  They build expression trees
   (which are completely machine-independent) and call function in the
   backend that generate RTL from them.

   Front ends are not *entirely* machine-independent, though, since they
   sometimes need to know such things as sizes, alignments, and
   enddianness.  This is why it is easier to write front ends linked with
   the backend instead of splitting them into two programs.

OK, but then I see nothing preventing a Modula-3 front-end that creates
expression trees from being implemented.  The RTL level is, I assume,
the level where people porting to new platforms must contend with.  Front-
ends would just generate mostly machine-independant expression trees
with a few hints from the back-end on the architecture of the machine
(like endian-ness and required alignment and so forth).

I seem to recall this thread being about technical problems in using
gcc as a back-end to a Modula-3 compiler.  I still don't see any
problem if the front-end generates the expression trees correctly.
Is the problem that this is not properly documented?  Perhaps the
GNAT team and the people/person doing g77 could assist in documenting
this better.

Sean McNeil


======================================================================= 68 ===
Date:    Fri, 9 Jun 1995 15:45:17 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: Comments on Chess Playing Program

In article <3r83pf$29p@newsserv.cs.sunysb.edu> pbh@cs.sunysb.edu (Peter B. Hend
erson) writes:

   I am posting this for Warren Smith.  Maybe of interest to some of you.
   --
   Peter B. Henderson
   pbh@sbcs.sunysb.edu
   Department of Computer Science, SUNY at Stony Brook
   Stony Brook, N.Y.  11794-4400

   -------- Warren's comments start here --------

   Tests of runtime speed modula-3 vs C, also comments on language choice
   for implementing a chess playing program.

[snip interesting stats on C vs m3]	
   ----------------------------------------------------------------------
   I am still tempted to go with modula-3 over C++, despite
   paying a factor of 3-5 on linked list malloc'd and garbage collected
   stuff (and I am also informed that nested subroutine declarations and
   calls to procedures passed as parameters, will be slower in m3 than C),
   because I know the main time consumer in a chess prog will
   be bit-op and array and recursion stuff, and on this, the time hit is
   only a factor of 1.1-1.7. 

Unless I'm mistaken, those test were only C vs Modula-3 and not C++
vs Modula-3.  Even though C++ is a better C, once you attempt to use
the O-O techniques the actual performance times get closer to the
Modula-3 times.  I don't even want to talk about compilation times,
due to inconsequential changes in a class's private representation.

   In our chess test the runtime ratio was 1 : 1.62.

[snip optimization comments]
	
   The reasons (ignoring speed) why m3 is the right language for a
   chessprog are: it is designed to support large multimodule programs, C
   was not (only as an afterthought) and the safety of m3 (no memory
   leaks! no out of bounds array accesses!) will lead to tremendous reduction i
n
   debugging time. Also m3 is easier to learn than C++ and there is a nice
   online HTML tutorial for it.

C++ doesn't have much cleaner support for large multimodule programs,
unless you encapsulate everything in the class or wait several years
before some of the compiler writers are able to get namespaces working.
(actually namespaces should be easy to implement, but they have more
than enough other problems to keep themselves busy)

[snip reasons for preferring C]

   Feedback I get from net people:
   > Which is better for a chess prog, C or m3?
    kalsow@pa.dec.com (Bill Kalsow, mr. Modula-3)
   That depends on whether you're going to use any of the features of
   Modula-3 that aren't in C++ (e.g.  threads, garbage collection, a rich
   standard library) or vice versa (e.g. multiple inheritance, operator
   overloading). It is for large multifile programs that m3 really
   shines.  [WDS: all this favors m3 for me.]

Multiple inheritance does have it's uses, I think I've actually used
it once, but I've written thousands of lines of code that wouldn't
have benefited from it.  In fact, C++'s multiple inheritance has
inconsistencies, and if you really want to play with MI, I suggest
you look at Eiffel or Sather.  Operator overloading is useful, but
can get you into trouble, in fact we 'have' to use it in addition
to templates to simulate a simple type of RTTI at compile time.

Garbage collection is a big win.  More time is spent in the debugger
when writing C++ programs due to a deletion of some memory when
it shouldn't have been, and the program continues along its merry
way until sometime in the future some other access to the memory
causes everything to fail miserably.  This can account for a LOT
of time.

Threads are very nice, but I doubt that many people use them on
their first cut at a program until they've grown more accustomed
to the multi-threading concept.

The standard library is by far a significant reason to choose
Modula-3.  Some day real soon I've been assured that the STL
(Standard Template Library) for C++ will be blessed.  This will
include a String Class (most people have library collisions with
this because every library writer chose to implement their own
String class)  Part of the delay is that they want everything in
STL to fit together.  I'm still not sure if they are going to 
include exception handling in the first release.  The Modula-3
standard library alreay is filled with exception handling, and
is multi-thread safe.  Don't even ask about multi-threading and
C++ (it's considered the operating system's problem).

   > Can I trust SRC to support me and fix such bugs fast?
   Richard Watts (rrw1000@cam.ac.uk):
    By and large, yes. I've never known them not to fix a bug they have
   been provided with the fix for [WDS: Oh, great. This is what the
   software community calls "good"], and they're by and large very good
   at fixing errors in new releases. That said, obscure bugs for which
   you haven't got a fix or good tracing information, or machine-specific
   bugs for platforms SRC haven't got tend not to be fixed by SRC -
   people like me get to them first :-).

I don't know how many bugs the SRC compiler has, but I've been using
g++ for over a year (and while it's one of the best C++ compilers) we
send in a bug report almost once a week.  Causing the compiler to fail
occasionally is considered normal.  So far, I haven't done anything
nasty enough to cause the Modula-3 compiler to fail, but then, it
actually implements the whole language, whereas there isn't a C++
compiler that comes close to implementing the C++ language (that is
still a moving target that won't be fully defined until 1997).

   > m3gdb debugger?
    m3gdb is temperamental at the best of times. I've just about given up
   on it myself as being more trouble than it's worth :-(. Luckily, M3 is
   sufficiently clear that code walk-throughs and diagnostics seem to work
   almost as well.

Hmm, I haven't had to resort to using m3gdb, but I'm well acquainted with
the regular gdb debugger.  I wish that I weren't, but I've managed to
demangle just about every piece of infomation it gives you.  Unfortunately,
many problems can't be traced because you slam into a virtual pointer.

   > I am sure modula-3 is the better choice, EXCEPT
   > that it looks to me like DEC has pretty much thrown it
   > to the wolves and don't officially support it, etc.

[snip comments about things being thrown to wolves]

I've personally received very good help from the people in the modula-3
newsgroup, and don't worry about being thrown to the wolves for
support.

Ask a simple question in the C++ newsgroup and you'll either find a
helpful person or two (there are some in and among the fray) or you'll
probably get some comment about referening to some page in the ARM.
The ARM is the Annotated Reference Manual, and although it is out
of date on some issues, it's still considered the C++ programmer's
bible.  (BTW, it's not an inexpensive book)

I've noticed that since the Modula-3 language carries around little
baggage, I don't need to ask as many questions.  When learing C++, I
had to first get past the syntax, then understand the "proper" way
to do things by interpreting what the ARM said, and then just using
trial-and-error to figure out what parts of the language definition
that my particular compiler could handle.

Porting code from one compiler to another is a horrendous task since
each compiler has it's own special deficiencies.  This is only one
of the many reasons that we are hoping to use some different languages
on contracts that don't specifically require C++.

If I were to have to choose between C++ and Modula-3, even given my
extra expertise in C++ already, I would clearly choose Modula-3.  I am
sick and tired of constantly fighting C++ in order to get my tasks
done.  I prefer to work "with" a language, not spend all day trying
to "by-pass" its weaknesses.

   ------------------------------------
   From:   Warren D. Smith  (Research Staff; Library Committee Chair)
   NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA

   Phone: (609) 951-2717   Web: http://www.neci.nj.nec.com/homepages/smith.html
   Email: wds@research.NJ.NEC.COM    Fax:   (609) 951-2496  ("for W.D.Smith 1D0
4"


----------------------------------------------------------------------
Spencer Allain                    E-mail:  spencer@era.com
Engineering Research Associates   Phone :  (703) 734-8800 x1414
1595 Spring Hill Road             Fax   :  (703) 827-9411
Vienna, VA  22182-2235
----------------------------------------------------------------------


======================================================================= 69 ===
Date:    10 Jun 1995 15:11:17 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: Comments on Chess Playing Program

>>>>> "Peter" == Peter B Henderson <pbh@cs.sunysb.edu> writes:

 > I am posting this for Warren Smith.  Maybe of interest to some of you.  --
 > -------- Warren's comments start here --------
 > josephus: go round a 200000 element circular list deleting every 47th guy
 > until 1 left.  (Tests linked lists and malloc/free/garbage collect.)

 > But the garbage collection / malloc /
 > pointer following performance of sml (josephus) is very impressive; one
 > wishes m3 could duplicate it...

Interesting, recalling the Lisp Gabriel benchmark wars of the mid 80s,
benchmarks for the sake of numbers is silly without understanding why the
numbers were different. This in mind, most GCs are called when there is a need
for more memory. Josephus seems to allocate and then delete, the GC is
probable never run.
- Rick
--

       Richard L. Hudson  -  Hudson@cs.umass.edu; (413) 545-1220; 
       Advanced Languages Project - University Computing Services
       Lederle Graduate Research Center
       University of Massachusetts             Amherst, MA  01003


======================================================================= 70 ===
Date:    10 Jun 1995 11:55:36 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <SEAN.95Jun9193701@mcneil.ni.net> sean@mcneil.ni.net (Sean McNeil) w
rites:
>I still don't see any problem if the front-end generates the expression
>trees correctly. Is the problem that this is not properly documented? 

Yes, that's the major problem.  Luckily, there just isn't that much to
document, though, since the interface is fairly straightforward, but
it can be hard to find out where to start.  Unlike config files, there
are relatively few back ends to look at.  But the best way to do it is
to copy pieces from other front ends.

>Perhaps the GNAT team and the people/person doing g77 could assist in
>documenting this better.

The only person on the GNAT team who looks at GCC trees much is me.
g77 is a one person project and I doubt he's interested in creating
documentation.

I gave a tutorial on GCC for POPL and prepared about 135 slides, 1/3
of which are on the front end interface.  I also wrote a front end for
a "toy" language that was about 1,000 lines of code.

If anybody wants these, let me know.


======================================================================= 71 ===
Date:    10 Jun 95 22:41:35 GMT
From:    stj@cornell.edu ("stj@cornell.edu")
Subject: ===>> FREE 1 yr. Magazine Sub sent worldwide- 300+ Popular USA Titles 
(fwd)



---------- Forwarded message ----------
Date: Sat, 10 Jun 1995 17:43:18 -0400 (edt)
From: stj@cornell.edu <stj@cornell.edu>
To: sbionet.metabolic-reg@paris.ics.uci.edu,
    sfnet.harrastus.visailu@paris.ics.uci.edu, uk.lisp@paris.ics.uci.edu,
    uk.media@paris.ics.uci.edu, uk.misc@paris.ics.uci.edu,
    uk.net@paris.ics.uci.edu, pdx.music@paris.ics.uci.edu,
    pdx.online@paris.ics.uci.edu
Subject: ===>> FREE 1 yr. Magazine Sub sent worldwide- 300+ Popular USA Titles

CHEAPEST USA MAG SUB AGENCY - SHIPS WORLDWIDE + FREE 1yrSUB

Hi, my name is Susan Johnson and I recently started using a magazine
subscription club in the USA that has a FREE 1 yr. magazine subscription
deal with your first paid order- and I have been very pleased with
them.    They have over 1,500 different USA titles that they can ship to
any country on a subscription basis.  They saved me a lot of money on my
Economist subscription:  over $40 off the best subscription price on I
had seen anywhere else and they got me a great deal on USA Today
newspaper, which arrives the same day as the cover date.  (I still don't
know how they manage to do that!)

They will send you some FREE info. via E-mail (the short version (around
40K) of their catalogue, or if you request it the DELUXE LONG VERSION
(around 400K-big and juicey) !)...if you fill out the form below.

Please do not email me as I am just a happy customer and a *busy*
student.  I don't have time to even complete my thesis in time, let alone
run my part-time software business!  Email them directly at:
suschow@freenet.fsu.edu


*------------cut here-----------------------------------------------*
REQUEST FOR MORE INFO:  please copy this section *only* and email to:
                                  suschow@freenet.fsu.edu

(sorry, but they cannot acknowledge incomplete forms sent back)

Name:
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Name of USA mags you currently get:
Name of USA mags you would like price quotes on when we call you:
Do you want the short (~40K) or long version (~400K) of our
catalogue emailed to you?:
How did you hear about us (name of person who referred you or the area of
the internet that you saw us mentioned in):  Susan Johnson
061095 p
*------------cut here-----------------------------------------------*


They guarantee to beat all their competitors' prices. Sometimes they are
less than half of the next best deal I have been able to find and other
times, just a little cheaper - but I have never found a lower rate yet.
They assured me that if I ever do, they will beat it.

They have been very helpful and helped me change my address from the USA
to Finland and then back again when I moved last month.  They are very
knowledgeable about addressing mags worldwide.

They have a deal where you can get a free 1 yr. sub to a new magazine
from a special list of over 300 popular titles published in the USA.
They will give you this free 1 yr. sub when you place your first paid
order with them to a renewal or new subscription to any of the over 1,500
different popular USA titles they sell.

They can arrange delivery to virtually any country and I think they have
clients in around 35 or 36 countries now.  Outside the USA there is a
charge for foreign postage and handling (on both paid and freebie subs)
that varies from magazine to magazine.  I have found their staff to be
very friendly and courteous.  They even helped me with an address change
when I moved from one country to another.

The owner thinks of his service as a "club" and his clients as "members"
(even though there is no extra fee to become a member - your first
purchase automatically makes you a member) and he is real picky about who
he accepts as a new member.   When he sets you up as a new member, he
himself calls you personally on the phone to explain how he works his
deal, or sometimes he has one of his assistants call.  He is kind of
quirky sometimes - he insists on setting up new members by phone so he
can say hi to everyone (I sure wouldn't want to have his phone bills!),
but you can place future orders (after your first order) via E-mail.

He has some really friendly young ladies working for him, who seem to
know just as much as he does about this magazine stuff.  If you live
overseas, he will even call you there, as long as you are interested, but
I think he still makes all his overseas calls on the weekends, I guess
cause the long distance rates are cheaper then.

He only likes to take new members from referrals from satisfied existing
members and he does virtually no advertising- so you can email me and I
will forward your message on to him as a referral.   When I got set-up,
they had a 2-3 week waiting list for new members to be called back so
that they could join up. (Once you are an existing member, they help you
immediately when you call. )  I think they are able to get back to
prospective new members  the same day or within a few days now, as they
have increased their staff.  I am not sure about this.........but if you
email the above form to them, that is the way to get started!

They will send you some FREE info. via E-mail (the short version (around
40K) of their catalogue, or if you request it the DELUXE LONG VERSION
(around 400K-big and juicey) !)...if you fill out the form near the top
of this message.

They then send you email  that outlines how his club works and the list
of free choices that you can choose from, as well as the entire list of
what he sells;  and then they will give you a quick (3-5 minute)
friendly, no-pressure no-obligation call to explain everything to you
personally and answer all your questions.

Here is a list of some of the 1500+ titles that they sell (for your free
selection with your first paid order, approximately one-fifth of these
appear on their special freebies list).

ACCENT
ACCENT ON LIVING
ACCESSORIES
ACTION COMICS
ACTION PURSUIT GAMES
ADIRONDACK LIFE
ADVENTURE WEST
ADVENTURES OF SUPERMAN (COMIC)
ADVERTISING AGE
ADVOCATE
AFRICAN PROFILES INTERNATIONAL
AIR CLASSICS
AIR COMBAT
AIR FORCE TIMES
AIR & SPACE
ALASKA
ALASKA MEN
ALASKA OUTDOORS
ALBUQUERQUE MONTHLY
ALFRED HITCHCOCK MYSTERY
ALLURE
ALOHA
AMATEUR RADIO TECHNICAL JOURNAL
AMAZING SPIDERMAN (COMIC)
AMERCAN HEALTH
AMERICA'S CIVIL WAR
AMERICAN ARTIST
AMERICAN ASTROLOGY
AMERICAN BABY
AMERICAN BABY
AMERICAN  CAGE BIRD
AMERICAN COLLECTOR'S JOURNAL
AMERICAN COTTON GROWER
AMERICAN COWBOY
AMERICAN COWBOY
AMERICAN DEMOGRAPHICS
AMERICAN FORESTS
AMERICAN FRUIT GROWER
AMERICAN HANDGUNNER
AMERICAN HEALTH
AMERICAN HERITAGE (HARD COVER)
AMERICAN HERITAGE INVENTION & TECHNOLOGY
AMERICAN HERITAGE (SOFT COVER)
AMERICAN HISTORY ILLUSTRATED
AMERICAN JOURNAL OF MATERNAL / CHILD NURSING
AMERICAN JOURNAL OF NURSING
AMERICAN LIQUIDATION MONTHLY
AMERICAN PHOTO
AMERICAN SALON
AMERICAN SPECTATOR
AMERICAN SQUARE DANCE
AMERICAN VEGETABLE GROWER
AMERICAN VISIONS
AMERICAN WOODWORKER
AMERICANA
AMERICAS (ENGLISH)
AMERICAS (SPANISH)
AMIGA WORLD
ANALOG SCIENCE FICTION / FACT
ANTIQUE TRADER WEEKLY
ANTIQUES
ANTIQUING AMERICA
AQUARIUM FISH
ARCHAEOLOGY
ARCHITECTURAL DIGEST
ARCHITECTURE
ARIEL
ARMY TIMES
ART & ANTIQUES
ART & ANTIQUES INVESTMENT REPORT
ART IN AMERICA
ARTIST'S MAGAZINE
ARTNEWS
ARTS &  ACTIVITIES
ASIAN SOURCES (COMPUTER PRODUCTS)
ASIAN SOURCES (ELECTRONIC COMPONENTS)
ASIAN SOURCES (ELECTRONICS)
ASIAN SOURCES (GIFTS & HOME)
ASIAN SOURCES (HARDWARE)
ASIMOV'S SCIENCE FICTION
ASTROLOGY
ATLANTA
ATLANTA HOMES & LIFESTYLES
ATLANTIC MONTHLY
AUDIO
AUDIO / VIDEO INTERIORS
AUDUBON
AUTO RACING DIGEST
AUTOMOBILE
AUTOMOTIVE NEWS
AUTOMUNDO
AUTOTRONICS
AUTOWEEK
AVENGERS (COMIC)
AVENGERS WEST COAST (COMIC)
AVIATION HERITAGE
BACK STAGE
BACKPACKER
BACKSTRETCH
BALTIMORE
BANK NOTE REPORTER
BARBIE (COMIC)
BARBIE FASHION BOOK (COMIC)
BARBIE MAGAZINE
BARELY LEGAL
BARTER NEWS
BASEBALL CARD PRICE GUIDE
BASEBALL CARDS MAGAZINE
BASEBALL DIGEST
BASEBALL WEEKLY (USA TODAY)
BASKETBALL DIGEST
BASKETBALL WEEKLY
BASS PLAYER
BASS & WALLEYE BOATS
BASSIN'
BATMAN (COMIC)
BEAVIS  & BUTTHEAD
BERKSHIRE
BEST RECIPES
BETTER HOMES & GARDENS
BEVERAGE WORLD
BEVERAGE WORLD
BIBLE REVIEW
BIBLICAL ARCHAEOLOGY REVIEW
BICYCLE GUIDE
BICYCLING
BIG BEAUTIFUL WOMAN (BBW)
BIRD TALK
BIRDER'S WORLD
BLACK AXE (COMIC)
BLACK BELT
BLACK COLLEGIAN
BLACK ELEGANCE
BLACK ENTERPRISE
BLOOD HORSE
BLUE & GOLD ILLUSTRATED
BOARDROOM REPORTS
BOATING
BOATING WORLD
BODY - MIND - SPIRIT
BON APPETIT
BOSTON MAGAZINE
BOTTOM LINE / PERSONAL
BOW & ARROW
BOW & ARROW HUNTING
BOW HUNTING WORLD
BOWHUNTER
BOWHUNTING
BOWHUNTING WORLD
BOWLING DIGEST
BOWMASTERS
BOXING ILLUSTRATED
BOY'S LIFE
BRIDAL GUIDE
BRIDES
BRITISH CAR
BRITISH HERITAGE
BROADCASTING
BUCKHUNTERS DIGEST
BUENHOGAR
BUSINESS PUBLISHING
BUSINESS START-UPS
BUSINESS WEEK
BUZZ (TALK OF LOS ANGELES)
BYTE
CABLE (COMIC)
CALIFORNIA JOURNAL
CAMCORDER
CAMERA & DARKROOM
CAMPUS LIFE
CANDY INDUSTRY
CANOE
CAPPER'S
CAPTAIN AMERICA (COMIC)
CAR AUDIO & ELECTRONICS
CAR COLLECTOR & CAR CLASSICS
CAR CRAFT
CAR & DRIVER
CAR STEREO REVIEW
CARAS DE PUERTO RICO
CARD COLLECTOR'S PRICE GUIDE
CARIBBEAN TRAVEL & LIFE
CARS & PARTS
CASH SAVER
CAT FANCY
CATALOG SHOPPING
CATHOLIC DIGEST
CATHOLIC FAMILY BIBLE
CATTLEMAN
CATWOMAN (COMIC)
CD REVIEW
CD-ROM TODAY
CD-ROM WORLD
CENTRAL FLORIDA CAREER GUIDE (W/UPDATES)
CHAMPION CROSSWORD PUZZLES
CHAMPION VARIETY PUZZLES
CHAMPION VARIETY REVIEW
CHANGES
CHARISMA & CHRISTIAN LIFE
CHATELAINE (IN ENGLISH)
CHATELAINE (IN FRENCH)
CHESAPEAKE BAY
CHEVY HIGH PERFORMANCE
CHIC
CHICAGO
CHILD
CHILD LIFE
CHILDREN'S ALBUM
CHILDREN'S CLASSICS
CHILDREN'S DIGEST
CHILDREN'S PLAYMATE
CHOCOLATIER
CHRISTIAN HISTORY
CHRISTIAN PARENTING TODAY
CHRISTIAN READER
CHRISTIAN SCIENCE MONITOR
CHRISTIANITY TODAY
CIRCLE TRACK
CIRCUS
CIVIL WAR CHRONICLES
CIVIL WAR TIMES
CLASSIC AUTO RESTORER
CLEVELAND MAGAZINE
COACH
COIFFURE DE PARIS
COIN PRICES
COIN WORLD
COINAGE
COINS MAGAZINE
COLLECTOR EDITIONS
COLLECTORS MART
COLLECTORS NEWS
COLLECTORS NEWS
COLLEGE SPORTS
COLONIAL HOMES
COLORADO BUSINESS
COLORADO HOMES & LIFESTYLES
COLUMBIA JOURNALISM REVIEW
COMIC BOOK COLLECTOR
COMIC BOOK COLLECTOR'S PRICE GUIDE
COMIC SCENE
COMICS BUYERS GUIDE
COMICS SCENE
COMMON CAUSE
COMMONWEAL
COMPUTER GAME REVIEW & CD-ROM ENTERTAINMENT
COMPUTER GAMING WORLD
COMPUTER LIFE
COMPUTER SHOPPER
COMPUTERWORLD
CONAN CLASSICS (COMIC)
CONAN SAGA (COMIC)
CONAN THE ADVENTURER (COMIC)
CONDE NASTE TRAVELER
CONSUMER REPORTS
CONSUMER REPORTS ON HEALTH
CONSUMER REPORTS TRAVEL LETTER
CONSUMER RESEARCH
CONSUMERS DIGEST
CONSUMERS RESEARCH
CONTEMPORARY CHRISTIAN MUSIC
COOK'S ILLUSTRATED
COOKBOOK DIGEST
COOKING LIGHT
CORVETTE FEVER
COSMOPOLITAN
COSMOPOLITAN EN ESPANOL
COUNTRY
COUNTRY ACCENTS
COUNTRY AMERICA
COUNTRY FEVER
COUNTRY GUIDE
COUNTRY HANDCRAFTS
COUNTRY HOME
COUNTRY HOME FOLK CRAFTS
COUNTRY JOURNAL
COUNTRY JOURNAL
COUNTRY LIVING
COUNTRY MUSIC
COUNTRY MUSIC CITY NEWS
COUNTRY SAMPLER
COUNTRY WOMAN
CQ RADIO AMATEURS JOURNAL
CRAFTING TODAY
CRAFTS
CRAFTS 'N THINGS
CRAFTWORKS FOR THE HOME
CRAIN'S NEW YORK BUSINESS
CRAYOLA KIDS
CREATIVE CLASSROOM
CREATIVE KIDS
CREATIVE QUILTING
CREATIVE REAL ESTATE
CREATIVE WOODWORKING & CRAFTS
CRICKET
CROCHET DIGEST
CROCHET FANTASY
CROCHET HOME
CROCHET WORLD
CROCHET WORLD SPECIALS
CROSS COUNTRY SKIER
CROSS STITCH
CROSS STITCH PLUS
CROSS STITCHER
CROSSSTITCH & COUNTRY CRAFTS
CRUISE TRAVEL
CRUISE TRAVEL
CRUISES & TOURS
CRUISING WORLD
CUSTOM & CLASSIC TRUCKS
CUSTOMER ASSURANCE REPORT
CUSTOMER SERVICE NEWSLETTER
CYCLE WORLD
DAILY NEWS RECORD
DANCE
DAREDEVIL (COMIC)
DARKHAWK (COMIC)
DAS LEBEN
DATA BASED ADVISOR
DAYTIME TV
DBMS (DATABASE MANAGEMENT SYSTEMS)
DEATH'S HEAD II (COMIC)
DEBATE ISSUES
DECORATING DIGEST
DECORATIVE ARTIST'S WORKBOOK
DECORATIVE ARTS PAINTING
DECORATVE WOODCRAFTS
DEER & DEER HUNTING
DEFENSE NEWS
DELAWARE TODAY
DELL CROSSWORD PUZZLES
DELL CROSSWORD SPECIAL
DELL CROSSWORDS & VARIETY PUZZLES
DELL HOROSCOPE
DELL LOGIC PUZZLES
DELL OFFICIAL CROSSWORD PUZZLES
DELL OFFICIAL PENCIL PUZZLE & WORD GAMES
DELL OFFICIAL WORD SEARCH PUZZLES
DELL PENCIL PUZZLES & WORD GAMES
DELL POCKET CROSSWORD PUZZLES
DELL POCKET CROSSWORD PUZZLES
DELL WORD SEARCH PUZZLES
DES
DESKTOP VIDEO WORLD
DESSERTS
DETAILS
DETECTIVE COMICS
DETROIT MONTHLY
DIRT BIKE
DISCIPLESHIP JOURNAL
DISCOUNT STORE NEWS
DISCOVER
DISCOVER DIVING
DISNEY ADVENTURES
DISNEY'S HOW IT WORKS
DISTRIBUTION CENTER MANAGEMENT
DOG FANCY
DOG WORLD
DOLL CASTLE NEWS
DOLL DESIGNS
DOLL LIFE
DOLL WORLD
DOLLMAKING
DOLLS
DOOM 2099 (COMIC)
DOWN EAST
DOWN MEMORY LANE
DOWNBEAT
DR. DOBB'S JOURNAL
DR. STRANGE (COMIC)
DRUG & COSMETIC INDUSTRY
EARLY AMERICAN LIFE
EARLY CHILDHOOD NEWS
EARLY CHILDHOOD TODAY
EARTH
EARTH JOURNAL
EASY FAST "N FUN CROSSWORDS
EATING WELL
EBONY
EBONY MAN (EM)
ECONOMIST
ECOTRAVELER
ELECTRONIC GAMES
ELECTRONIC GAMING MONTHLY
ELECTRONIC LEARNING
ELECTRONICS NOW
ELITE MAGAZINE
ELLE (AMERICAN)
ELLE DECOR
ELLERY QUEEN'S MYSTERY
ELLERY QUEEN'S MYSTERY
EM (EBONY MAN)
EMERGE
ENGINEERING NEWS RECORD (ENR)
ENTERTAINMENT WEEKLY (EW)
ENTREE
ENTREPRENEUR
ENVIRONMENT
EQUITIES
EQUUS
ESQUIRE
ESSENCE
EUROPEAN CAR
EXCALIBUR (COMIC)
EXCEPTIONAL PARENT
EXECUTIVE FEMALE
FAITH & STUFF
FAMILY CIRCLE
FAMILY HANDYMAN
FAMILY LIFE
FANCY FOOD & CANDY
FANGORIA
FANTASTIC FOUR (COMIC)
FANTASY & SCIENCE FICTION
FAR OUT
FARM BUILDING NEWS
FARM & RANCH LIVING
FARMERS DIGEST
FASHION GUIDE
FASHION KNITTING
FATE
FEDERAL TIMES
FEMALE BODYBUILDING
FIELD & STREAM
FIGHTING KNIVES
FIGHTING STARS NINJA MAGAZINE
FILM THREAT
FINANCIAL TIMES OF LONDON (MON - SAT)
FINANCIAL WORLD
FINE GARDENING
FINE HOMEBUILDING
FINE WOODWORKING
FIREHOUSE
FISHING FACTS
FISHING & HUNTING NEWS
FISHING WORLD
FIVE LITER MUSTANG
FLARE
FLASH (COMIC)
FLEX
FLOORING
FLORIDA LIVING
FLORIDA SPORTSMAN
FLORIDA TREND
FLORIDA VACATION RENTALS
FLOWER & GARDEN
FLY FISHERMAN
FLY FISHING
FLYING
FLYING MODELS
FOOD & WINE
FOOTBALL DIGEST
FOOTBALL NEWS
FORBES
FORCE WORKS (COMIC)
FOREIGN AFFAIRS
FOREIGN POLICY
FORTUNE
FORUM (PENTHOUSE)
FOUR WHEEL / OFF ROAD
FOUR WHEELER
FRONT PAGE DETECTIVE
FUN-ZONE
FUR - FISH - GAME
FUTURIFIC
FUTURIFIC
G.I. JOE (COMIC)
GAME PLAYERS NINTENDO GUIDE
GAME PLAYERS NINTENDO - SEGA
GAME PLAYERS PC ENTERTAINMENT
GAMEPRO
GAMES
GARBAGE
GEMS & GEMNOLOGY
GEMS & GEMNOLOGY
GENTLEMEN'S QUARTERLY (GQ)
GEOMUNDO
GET RICH NEWS
GHOST RIDER 2099 (COMIC)
GHOST RIDER / BLAZE (COMIC)
GHOST RIDER (COMIC)
GIFTS & DECORATIVE ACCESSORIES
GIFTWARE NEWS
GLAMOUR
GLASS DIGEST
GLEANINGS IN BEE CULTURE
GOD'S WORD TODAY
GOLDMINE
GOLF DIGEST
GOLF FOR WOMEN
GOLF MAGAZINE
GOLF TIPS
GOLF WEEK
GOLF WORLD
GOLFING
GOOD DAY SUNSHINE
GOOD HOUSEKEEPING
GOOD OLD DAYS
GOOD OLD DAYS SPECIALS
GOURMET
GREEN LANTERN (COMIC)
GRIT
GROO (COMIC)
GROWING UP WITH SCIENCE
GUARDIANS OF THE GALAXY (COMIC)
GUIDEPOSTS
GUIDEPOSTS (LARGE PRINT EDITION)
GUN DOG
GUN LIST
GUN WORLD
GUNS
GUNS & AMMO
GUNS & AMMO
HAIR ADDITIONS
HAIR & BEAUTY NEWS
HANDCRAFT ILLUSTRATED
HANDGUNNING
HANDGUNS
HARPER'S BAZAAR
HARPER'S BAZAAR EN ESPANOL
HARPER'S MAGAZINE
HARROWERS (COMIC)
HARVARD BUSINESS REVIEW
HAWAII
HEALTH
HELLSTORM (COMIC)
HERALD TRIBUNE CROSSWORD PUZZLES ONLY
HERALD TRIBUNE & OTHER CROSSWORD GAMES
HERO ILLUSRATED
HIGHLANDER
HIGHLIGHTS
HIGHLIGHTS
HISPANIC
HISTORIC PRESERVATION
HOCKEY DIGEST
HOCKEY NEWS
HOLLYWOOD STUDIO
HOLLYWOOD STUDIO MAG THEN & NOW
HOMBRE DE MUNDO
HOME COOKING
HOME GYM & FITNESS
HOME MAGAZINE
HOME MAGAZINE
HOME MECHANIX
HOME OFFICE COMPUTING
HONOLULU
HOOKED IN CROCHET
HORIZON
HOROSCOPE
HOROSCOPE/ A PERSONAL DAILY GUIDE FOR EVERYONE
HOROSCOPE / DELL
HORSE & HORSEMAN
HORSE & HORSEMAN
HORSE ILLUSTRATED
HORSE & RIDER
HORSEPLAY
HORTICULTURE
HOT BOAT
HOT ROD
HOT ROD HARLEYS
HOUSE BEAUTIFUL
HOUSTON METROPOLITAN
HOUSTON PEOPLE
HOUSTON PROFILES
HOW
HUDSON VALLEY
HUMPTY DUMPTY
HUNTING
HUSTLER
HUSTLER'S BUSTY BEAUTIES
HUSTLER'S EROTIC VIDEO GUIDE
HUSTLER'S FANTASIES
HUSTLER'S HUMOR
I LOVE CATS
IDEAS
IDEAS PARA SU HOGAR
ILLUSTRATED BIBLE FOR CHILDREN
IMPORT AUTO PARTS & ACCESSORIES
IN BUSINESS
IN-FISHERMAN
INC.
INCOME OPPORTUNITIES
INCOME PLUS
INCREDIBLE HULK (COMIC)
INDIVIDUAL INVESTOR
IINDUSTRIAL MARKET PLACE
INSIDE EDGE
INSIDE IRELAND
INSIDE KARATE
INSIDE KUNG FU
INSIDE SPORTS
INSIGHT
INSTITUTIONAL INVESTOR
INSTRUCTOR
INTERIOR DECORATOR'S HANDBOOK
INTERIOR DESIGN
INTERIORS
INTERNATIONAL LIVING
INTERNATIONAL NURSING INDEX
INTERNET WORLD
INTERVIEW
INTIMATE FASHION NEWS
INVESTOR'S DAILY
IRON MAN (COMIC)
ISLANDS
ISRAEL SCENE
JACK & JILL
JERSEY WOMAN
JERUSALEM POST INTERNATIONAL WEEKLY EDITION
JERUSALEM REPORT
JET
JEWISH EXPONENT
JEWISH HOMEMAKER
JEWISH POST & OPINION
JEWISH PRESS
JUSTICE LEAGUE AMERICA (COMIC)
JUSTICE LEAGUE EUROPE ( COMIC)
KARATE / KUNG FU ILLUSTATED
KEYBOARD
KID CITY
KIDSPORTS
KIPLINGER'S PERSONAL FINANCE
KIT CAR
KITPLANES
KNIFE WORLD
KNITTING DIGEST
KNITTING WORLD
L'ACTUALITE
LA LUZ
LA VIE
LADIES HOME JOURNAL
LADY'S CIRCLE
LADYBUG
LAKELAND BOATING
LAN MAGAZINE (LOCAL AREA NETWORK)
LAPIDARY JOURNAL
LEADERSHIP
LEARNING '94
LEFTHANDER
LEGAL GUIDE FOR THE FAMILY
LEGION OF SUPER-HEROES (COMIC)
LET'S LIVE
LIBRARY OF NATURAL WONDERS
LIFE
LIGHTING DIMENSIONS
LINK-UP
LINN'S STAMP NEWS
LITTLE MERMAID
LLUMO VOGUE
LONGEVITY
LOONEY TUNES (COMIC)
LOOSE CHANGE
LOS ANGELES
LOTTERY PLAYERS MAGAZINE
MAC HOME JOURNAL
MACLEANS
MACUSER
MACWORLD
MADEMOISELLE
MARKETERS FORUM
MARRIAGE PARTNERSHIP
MARVEL AGE (COMIC)
MARVEL COMICS PRESENTS
MARVEL TALES SPIDERMAN (COMIC)
MCCALL'S
MCCALL'S NEEDLEWORK & CRAFTS
MECANICA POPULAR
MECHANICA POPULAR
MEDIA & METHODS
MEDICAL & HEALTH ENCYCLOPEDIA
MEDICAL HOTLINE
MEDICAL UPDATE
MEGA PLAY
MEMPHIS MAGAZINE
MEN'S CONFIDENTIAL
MEN'S FITNESS
MEN'S HEALTH
MEN'S JOURNAL
METROPOLIS
METROPOLITAN HOME
MICKEY MOUSE
MICRO COMPUTER JOURNAL
MICROSOFT SYSTEMS JOURNAL
MID-ATLANTIC COUNTRY
MIDSTREAM
MIDWEST LIVING
MILITARY HISTORY
MILWAUKEE
MINISTRIES TODAY
MINNESOTA MONTHLY
MIRABELLA
MOBILE OFFICE
MODEL AIRPLANE NEWS
MODEL NEWS
MODEL SHOPPER
MODELS & TALENT/CASTING NEWS
MODERN BRIDE
MODERN GUN
MODERN HORSE BREEDING
MODERN SALON
MOMENT
MONEY
MONEYPAPER
MOODY MAGAZINE
MOODY MONTHLY
MOPAR MUSCLE
MORIBUS (COMIC)
MOTHER EARTH NEWS
MOTHER JONES
MOTHERING
MOTOR BOATING & SAILING
MOTOR TREND
MOTORCROSS ACTION
MOTORCYCLE CONSUMER NEWS
MOTORCYCLIST
MOTORHOME
MOUNTAIN BIKE
MOVIE MARKETPLACE
MOVIELINE
MUNDO 21
MUSCLE & FITNESS
MUSCLECAR REVIEW
MUSICIAN
MUSTANG MONTHLY
MUSTANGS & FORDS
MUSTANGS MONTHLY
NAILS
NAMOR (COMIC)
NATION
NATION'S BUSINESS
NATION'S RESTAURANT NEWS
NATIONAL AUCTION REPORT
NATIONAL ENQUIRER
NATIONAL FISHERMAN
NATIONAL LAW JOURNAL
NATIONAL OTC STOCK JOURNAL
NATIONAL PARK MAGAZINE
NATIONAL REVIEW
NATIONAL TRIAL LAWYER
NATURAL HEALTH
NATURAL HISTORY
NAVY TIMES
NBA INSIDE STUFF
*THE NET* (about the Internet)
NEEDLE & CRAFT
NEVADA MAGAZINE
NEW AGE JOURNAL
NEW BUSINESS OPPORTUNITIES
NEW CHOICES
NEW ENGLAND JOURNAL OF MEDICINE
NEW FARM
NEW JERSEY MONTHLY
NEW JERSEY OUTDOORS
NEW MEXICO
NEW REPUBLIC
NEW TITANS (COMIC)
NEW WARRIORS (COMIC)
NEW WOMAN
NEW YORK MAGAZINE
NEW YORK REVIEW OF BOOKS
NEW YORKER
NEWSWEEK
NICE & EASY FAMILY COOKBOOK
NIGHT TRASHER (COMIC)
NIGHT WATCH (COMIC)
NO-TILL FARMER
NORTH FLORIDA LIVING
NORTH SHORE (CHICAGO)
NOVA (COMIC)
NUMISMATIC NEWS
NURSING
NUTRITION & DIETARY CONSULTANT
NUTRITION HEALTH REVIEW
OCCASIONAL BULLETIN
OFF ROAD
OFFICIAL CROSSWORD PUZZLES
OFFICIAL DETECTIVE
OFFICIAL MAJOR LEAGUE BASEBALL ROOKIE LEAGUE MAGAZINE FOR KIDS
OFFICIAL PENCIL PUZZLES / WORD GAMES
OFFICIAL US CUSTOM HOUSE GUIDE
OFFICIAL WORD SEARCH PUZZLES
OLD CARS NEWS & MARKETPLACE
OLD CARS PRICE GUIDE
OLD HOUSE JOURNAL
OLD TIME CROCHET
OMNI
ONLINE ACCESS
ONSAT
OPEN WHEEL
OPERA NEWS
OPPORTUNITY MAGAZINE
ORGANIC GARDENING
OUTDOOR LIFE
OUTDOOR PHOTOGRAPHER
OUTDOOR PRESS
OUTSIDE
OVERDRIVE
PACIFIC NORTHWEST
PACK -O-FUN
PADDLE SPORTS
PADDLER
PAINTWORKS
PALM BEACH LIFE
PALM SPRINGS LIFE
PARENTING
PARENTS
PARENTS OF TEENAGERS
PASSION
PASSION FOR MEN
PC COMPUTING
PC GAMER
PC GAMES
PC KIDS
PC LAPTOP
PC MAGAZINE
PC NOVICE
PC TODAY
PC WORLD
PC WORLD LOTUS EDITION
PC WORLD MULTI MEDIA EDITION
PCM
PENNSYLVANIA SPORTSMAN
PENTHOUSE
PENTHOUSE LETTERS
PEOPLE
PET DEALER
PHILADELPHIA
PHOENIX HOME & GARDEN
PHOTOGRAPH COLLECTOR
PHOTOGRAPHIC
PINHEAD (COMIC)
PLANE & PILOT
PLASTIC CANVAS
PLASTIC CANVAS & MORE
PLASTIC CANVAS WORLD
PLAYBOY
PLAYGIRL
PLAYTHINGS
POCKET CROSSWORD PUZZLES
POLO
POPULAR COMMUNICATIONS
POPULAR ELECTRONICS
POPULAR HOT RODDING
POPULAR MECHANICS
POPULAR PHOTOGRAPHY
POPULAR SCIENCE
POPULAR WOODWORKING
PORTABLE COMPUTING
POST SCRIPT
POST SCRIPTS: ESSAYS IN FILM & THE HUMANITIES
POWDER
POWER & MOTOR YACHT
PRACTICAL HORSEMAN
PREMIERE
PRESENT TENSE
PREVENTION
PRIVATE PILOT
PRO FOOTBALL WEEKLY
PROGRESSIVE
PROGRESSIVE FARMER
PROTESTANT DELUXE BIBLE
PROTESTANT FAMILY BIBLE
PSYCHOLOGY TODAY
PUBLISH
PULSE
PUNISHER 2099 (COMIC)
PUNISHER (COMIC)
PUNISHER WAR JOURNAL (COMIC)
PUNISHER WAR ZONE (COMIC)
QUASAR (COMIC)
QUICK & EASY CRAFTS
QUICK & EASY CROCHET
QUICK & EASY NEEDLECRAFT
?QUICK & EASY PLASTIC CANVAS
QUICK & EASY QUILTING
QUILT WORLD
QUILTER'S NEWSLETTER
QUILTER'S TREASURY
QUILTER'S TREASURY
QUILTING INTERNATIONAL
QUILTMAKER
RAILROAD MODEL CRAFTSMAN
RAPPAGES
RAPPORT
RAVAGE 2099 (COMIC)
REAL PEOPLE
REALTY MAGAZINE
REDBOOK
REMINISCE
REN & STIMPY (COMIC)
RETIREMENT INCOME NEWSLETTER
RIDER
RIGHT ON
RIP
ROAD RIDER
ROAD & TRACK
ROBB REPORT
ROCK & GEM
ROD & CUSTOM
ROLLING STONE
RUNNER'S WORLD
RUNNING TIMES
RURAL BUILDER
S.W.A.T.
SABERTOOTH CLASSICS (COMIC)
SADDLE & BRIDE
SAIL
SAILING
SAILING WORLD
SALTWATER SPORTSMAN
SAN DIEGO HOME & GARDEN
SAN DIEGO MAGAZINE
SAN FRANCISCO
SASSY
SATELLITE TV PRE-VUE
SATELLITE TV WEEK
SATURDAY EVENING POST
SAVAGE SWORD OF CONAN (COMIC)
SCHOLASTIC COACH
SCHOOL & COLLEGE
SCIENCE LIBRARY
SCIENCE NEWS
SCIENCE OF MIND
SCIENCES
SCIENTIFIC AMERICAN
SCUBA DIVING
SCUBA TIMES
SEA MAGAZINE
SECRET DEFENDERS (COMIC)
SELF
SESAME STREET
SEVENTEEN
SEVENTY-THREE AMATEUR RADIO
SEW NEWS
SEYBOLD REPORT ON DESKTOP PUBLISHING
SHAPE
SHOOTING TIMES
SHOP TALK
SHORT STORY INTERNATIONAL
SHOW BIZ / CASTING NEWS
SHOW BIZ NEWS/MODEL NEWS
SHOWBOATS INTERNATIONAL
SIDEKICKS
SIDEKICKS SOCCER
SILVER SABLE (COMIC)
SILVER SURFER (COMIC)
SIMPLY CROSS STITCH
SKATEBOARDING
SKI
SKIING
SKIN DIVER
SKIN & INK
SMITHSONIAN
SNOW COUNTRY
SNOW GOER
SNOW WEEK
SNOWBOARDING
SNOWMOBILE
SOAP OPERA DIGEST
SOAP OPERA MAGAZINE
SOAP OPERA STARS
SOCCER AMERICA
SOCCER DIGEST
SOCCER INTERNATIONAL
SOUNDINGS
SOUTH FLORIDA
SOUTHERN ACCENTS
SOUTHERN BOATING
SOUTHERN HOMES
SOUTHERN LIVING
SOUTHERN OUTDOORS
SPACE NEWS
SPECIAL EVENTS
SPECIAL SITUATIONS REPORT
SPECIALTY CAR
SPECTACULAR SPIDERMAN (COMIC)
SPIDERMAN 2099 (COMIC)
SPIDERMAN CLASSIC (COMIC)
SPIDERMAN (COMIC)
SPIN
SPORT
SPORT DIVER
SPORT FISHING
SPORT RIDER
SPORT TRUCK
SPORTING CLASSICS
SPORTING NEWS
SPORTS AFIELD
SPORTS CARD TRADER
SPORTS COLLECTORS DIGEST
SPORTS ILLUSTRATED
SPORTS ILLUSTRATED FOR KIDS
SPORTSWEAR INTERNATIONAL
SPOTLIGHT
STAR
STAR TREK (COMIC)
STAR TREK : THE NEXT GENERATION (COMIC)
STARLOG
STEREO REVIEW
STITCH 'N SEW QUILTS
STOCK CAR RACING
STONE SOUP
STORY
STUDIO USA
STYLE TRENDS
SUCCESS
SUCCESSFUL RETIREMENT
SUNBONNET CRAFTS
SUNSET
SUPER CHEVY
SUPER COMPUTING REVIEW
SUPER CYCLE
SUPER FORD
SUPER NES BUYERS GUIDE
SUPER STOCK & DRAG ILLUSTRATED
SUPERCYCLE
SUPERMAN - MAN OF STEEL (COMIC)
SURFER
SURFING
SURPRISES
SWAP USA
SWAT
T-SHIRT RETAILER
TAMPA BAY CAREER GUIDE (WITH UPDATES)
TASTE OF HOME
TAX HOTLINE
TCI
TEACHING PRE K-8
TECHNOLOGY & LEARNING
TEDDY BEAR REVIEW
TEEN
TEEN BEAT
TEENAGE MUTANT NINJA TURTLES (COMIC)
TEK WORLD (COMIC)
TENNIS
TEXAS FISH & GAME
TEXAS GARDENER
THE SCIENCES
THEATRE CRAFTS
THEOLOGY TODAY
THOR (COMIC)
THREADS
THREE-TWO-ONE CONTACT
THUNDERSTRIKE (COMIC)
TIME
TODAY'S CATHOLIC TEACHER
TODAY'S CHRISTIAN WOMAN
TOLE WORLD
TOTAL HEALTH
TOURING AMERICA
TOWN & COUNTRY
TOY SHOP
TRACK & FIELD NEWS
TRADING CARDS
TRADITIONAL HOME
TRADITIONAL QUILTER
TRAILER BOATS
TRAILER LIFE
TRANSFORMERS GENERATION 2 (COMIC)
TRANSWORLD SKATEBOARDING
TRAPPER & PREDATOR CALLER
TRAVEL 50 & BEYOND
TRAVEL AMERICA
TRAVEL HOLIDAY
TRAVEL & LEISURE
TRAVELAMERICA
TREASURE
TRIATHLETE
TRUE DETECTIVE
TRUE STORY
TU
TURKEY & TURKEY HUNTING
TURTLE
TV CROSSWORDS
TV HOST
TV Y NOVELAS  (PUERTO RICO)
TV Y NOVELAS  (USA)
TWINS
UNCANNY X-MEN (COMIC)
UNDERWATER USA
UNIQUE HAIR & BEAUTY
UNIQUE HOMES
US AVIATOR
US CATHOLIC
US MAGAZINE
US NEWS & WORLD REPORT
USA TODAY
UTNE READER
VACATIONS
VANIDADES
VANITY FAIR
VARIATIONS (PENTHOUSE)
VARIETY (WEEKLY)
VEGETARIAN TIMES
VEGGIE LIFE

and many, many more!!!

Once you get in, you'll love them. I do.  For more info,  just fill out
the form near the top of this message and email it to their email address
shown there.


Thanks,

Susan Johnson





======================================================================= 72 ===
Date:    8 Jun 1995 02:37:46 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <3r4qqt$rkj@nntp5.u.washington.edu> "Marc E. Fiuczynski" <mef@cs.was
hington.edu> writes:
>It seems that it would be beneficial to the FSF to separate their backend 
>from their frontend. Many of the backend optimizations are applicable to
>Fortran, Ada, M3, C and friends, and possibly other languages.  The FSF
>already provides a set of nice compiler tools, and separating the backend
>would not only assist them in developing different frontends quickly, but
>allow projects, like SRC M3, to take advantage of their software.

I don't follow the logic here.  The existing front ends already have
the use of these optimizations and backend technology by virtue of
being linked in with it.  How does this improve if they are not linked
together as one image?

Initially, the GNAT project, for bootstrapping reasons, had its front
end write out its annotated Ada syntax tree (NOT the representation
used by GCC) and have it read back in by a small (6,000 line) GCC
front end.   We have now merged these three pieces into a single image;
the 6,000 line program is called Gigi (GNAT-to-GCC).

However, currently, Gigi makes extensive calls into front end
routines.  The front end also calls the backend to do things besides
compiling (such as finding out various sizes and machine parameters).
It is also possible for the backend (via callbacks) to call parts of
the front end.

If these were split into separate programs, all these tasks would be
much harder.  We merged them into one program precisely to make our
task simpler.

>What would be required to separate the backend?  I guess someone has to 
>define an acceptable intermediate representation that the frontends compile 
>to and then have the backend read that back in. 

But the interface between the front ends and the backend is
procedural, and does not involve forming a data structure by the front
end and reading it in the backend.

Doing such a split would:

(1) Inflict serious damage to the concept of free software.
(2) Make it harder for people to write efficient front ends.
(3) Take considerable resources in designing, writing, and testing
such an interface.

I don't understand why anybody would want to do this.


======================================================================= 73 ===
Date:    8 Jun 95 08:55:18
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: when NEW fails, revisited

In article <9506071258.AA11543@cloyd.East.Sun.COM> gwyant@cloyd.East.Sun.COM (G
eoffrey Wyant - Sun Microsystems Labs BOS) writes:

   Maybe it's time for someone to go back and summarize the issues.

I agree with Geoff on the need for a summary. I will see if I can find
the old article posted by Paul McJones and add the new points to it in
a little bit. For now, I want to respond to something Geoff said.

    > What do C/C++ programmers do about memory exhaustion?
    > 

   Fail horribly... [... CodeCenter's behavior was omitted.]

While this may be true for UNIX-based C/C++ programs, C programs
running on not-so-programmer-friendly operating systems such as the
Macintosh deal with lack of memory much more gracefully.

Take Adobe Photoshop, for example. It uses a scratch disk for
"emulating" virtual memory; it warns you if you don't have enough
scratch disk; it warns you when it thinks your operation will take too
much memory to complete, and in the worst case, it will cancel your
operation. (Though Photoshop, having a very simple application flow,
and "internal" virtual memory is probably not a great comparison.)

Macintosh Finder will close windows when it realizes you are close to
being out of memory. I bet if you put it in weird situations it will
not address them, but its policy works for the most part.

When there is not enough memory, Macintosh PrintMonitor asks you
whether you want to "bring it to the front" (and therefore give it
more memory) or if it should print later. 

Eudora for the Macintosh will do the same in a less gracefull fashion.
It will warn you before hand and then if you run out, it will "save
the files" and then exit, I think.

I bet there are some Macintosh programming guidelines for dealing with
low-memory conditions gracefully.

In the worst case, what about trying something like the NeXT Session
Manager? I recall hearing that NeXT's Session Manager (or whatever it
is called) will warn you before going down (due to a severe errors)
and gives you a few seconds to save your files and quit important
applications. (This procedure can be applied in a multi-threaded
environment, I think, couldn't it?)

I agree that in Modula-3 things are more complicated, but I think most
mainstream Mac apps (with the exception of Microsoft ones probably ;-)
handle low-memory conditions pretty well.  There is also the question
of portability and operating system dependence. It'd be interesting to
see what the UNIX and Windows versions of Photoshop, or Eudora do in
low memory.

-- Farshad

--
Farshad Nayeri
nayeri@gte.com

  ``Obviously, in each of these cases design decisions have been made,
    but unfortunately they were wrong.'' --Victor Papanek, 
                                           Design for the Real World


======================================================================= 74 ===
Date:    8 Jun 1995 02:26:27 GMT
From:    kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

In article <1995Jun7.101538.26580@wavehh.hanse.de> cracauer@wavehh.hanse.de (Ma
rtin Cracauer) writes:
>>I doubt it, what possible FSF goal can be met by such a separation, it
>>would seem to promote exactly that which FSF tries hard to prevent, the
>>creation of proprietary technologies which make use of free software.
>
>I don't think so. IMHO, the only reason why the separation isn't done
>is that noone spent the time on it.

Robert is quite correct.  Richard Stallman has been adamantly opposed
to any attempt to split front ends into separate programs for
precisely the reason Robert gives.

>The GNU-Objective-C folks, for example, would be very happy to have
>their frontend mixed with the C++ frontent to allow Objctive-C++
>programs.

True, but what does this have to do with the separation issue?  It
seems instead that such mixture would be even *less* separated.

>From what I heared, the FSF would be happy to make the gcc backend an
>easier-to-use tool for language implementors.

Certainly true, but again this has nothing to do with separation of
the kind Robert was talking about.

>The backend has to be modified anyway to allow better optimization for the
>deeper pipelines of modern CPUs.

There are lots of optimizations that could be added to the backend to
produce better code; GCC does reasonably well now with pipeline
delays, so the above doesn't appear to be one of the more important.

However, again, what does this have to do with the separation issue?

>If the current way to implement m3 causes major overhead, maybe the
>time required for every m3-inside-gcc-backend release would be better
>invested in turning gcc into something that causes less overhead.

The experiences of the GNAT project show how valuable GCC has been to
language implementation since they were able to concentrate solely on
language issues and leave code generation, optimization, and
portability issues to GCC.

However, everything can be improved.  I welcome your suggestions for
making it easier to write front ends to GCC.


======================================================================= 75 ===
Date:    11 Jun 95 21:19:02 GMT
From:    amichail@cs.toronto.edu (Amir Michail)
Subject: modula 3 compiler for PC

Hi.

I was wondering how quickly the modula-3 compiler (by DEC) works
on a fast PC with 8 megs.  How long does it take to compile
and link a "hello world" program?

Thanks,

Amir


======================================================================= 76 ===
Date:    Mon, 12 Jun 95 06:46:24 GMT
From:    cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)

Folks, I admit that my previous posting to comp.lang.modula3 regarding
the seperation of the gcc front- and backend was uninformed in a
number of techincal and non-techincal ways.

Please ignore it.
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>. No NeXTMail, please.
 Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a 
 private address. At (netless) work programming in data analysis.


======================================================================= 77 ===
Date:    12 Jun 95 17:48:55 HKT
From:    clewis@ferret.ocunix.on.ca (Sylvia Wong)
Subject: Lonely Lily - Still Alive!



Rumors of Lily's demise are greatly exagerated.  

As I said before,  my friend Lily lives in Hong Kong,
like me.  She loves to receive phone calls from foreign
men. She does not have computer, so I am sending 
this message for her.

If you want to call her and you are in the United States 
the number is  011 852 1747 3094.  Callers 
from other countries need to put the international 
code then 852 1747 3094.

No e-mail please.

Sylvia Wong


PS.  Lily sends her love to all the boys at new@pobox.com



======================================================================= 78 ===
Date:    Mon, 12 Jun 1995 17:49:02 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: When NEW fails (summary)

>Blair MacIntyre wrote (summarised)
>
>At first glance, it would appear that the only effect on the libraries
>of raising new would be a plethora of "unhandled exception" warnings
....  While not exactly what we
>want, this would give no change in behaviour.
>
>I realize that it would take a fair amount of cleaning up ..., but
>it would seem to me to be worth it.  So much so that I would volunteer
>to help tidy things up.

>Be that as it may, I prefer the solution of registering routines to be
>called when memory runs out. ...
>
>As for the multithreaded issues, it would seem to me that if the
>allocator calls these routines inside a mutex, then tries again...
>

I guess we might be surprised at how many exceptions we'll see but I'm all
for doing it. Having an exception at least highlights the fact that an
operation might bring our world down, for example
     a := b & c;
I wonder how many operations there are that implicitly allocate memory?

I would like to see both approaches implemented. If we want to put up with
the possibility of running out of memory that should be our choice, not
forced upon us as currently is the case.

Even within a single system the use of both might be appropriate, perhaps
in concert.  Consider for example a database server with many clients. When
we run out of memory the first thing that might happen is that our
registered routine get's called. It will adjust some global information
which will tend to reduce the memory usage. It can then return indicating
either that the exception be raised or the allocation retried, whichever is
appropriate.

The problem I have with having no exception mechanism is, how do you inform
a thread that its attempted allocation just failed? The only way
implemented so far is the exception mechanism.




======================================================================= 79 ===
Date:    Thu, 15 Jun 1995 06:55:04 -0400
From:    Wayne Ward <wward@river.biddeford.com>
Subject: Calling process

Hi All,
I'am a COBOL programmer thinking of going to modula3. 
I would like to know how the calling process works.
If i have two programs, progA and progB, both being main.
Can progA call progB, have progB do somthing then return
to progA where the instruction to call progB was excuted?
I just finished taken a 'C' class and was suprise that this
can not be done in 'C', so my professor said.
Thanks Wayne,


======================================================================= 80 ===
Date:    Thu, 07 Jun 95 19:34:39 GMT
From:    ts4@iis.joanneum.ac.at
Subject: telematic sculptur 4 (T.S.4)

this mobile sculpture (length 21,8 meters, weight 1800 kg) by
r. kriesche is physically positioned in the austrian pavilion during
the biennale of venice.

T.S.4 is driven by the data flow in internet according to the relation
of the world wide computer newsgroups versus world wide art
newsgroups.  according to this relation T.S.4 will transcross the
austrian pavilion during the time of the biennale and might even break
through the wall of the pavilion.

you are invited to become part of T.S.4 by:

  o  visiting its www homepage
     http://iis.joanneum.ac.at/kriesche/biennale95.html
  o  discussion about T.S.4 on usenet news
  o  sending e-mail to T.S.4 (mailto:ts4@iis.joanneum.ac.at)

your participation will slow down the movement of T.S.4 and prevent it
crashing.


