======================================================================= 1 ===
Date:    02 Feb 1994 15:31:50 GMT
From:    sims@gehrig.ucr.edu (david sims)
Subject: A more recent Alpha release for M3?

I've noticed that the Alpha release of version 3.0 of the DEC SRC
Modula-3 compiler dates back to September 27, 1993.  How about a more
recent snapshot of the 3.0 system?  Could someone install the latest
release on gatekeeper in the alpha-3.0 directory?

I'm specifically interested in the Linux port.  I'd really like to
give it a shot on my Linux box, but I'd rather start with the latest
release rather than the September 27, 1993 release.

Thanks for the help!
--
David L. Sims                              Department of Computer Science
sims@cs.ucr.edu                            University of California
+1 (909) 787-6437                          Riverside CA  92521-0304
PGP encryption key available on request.   USA
--
David L. Sims                              Department of Computer Science
sims@cs.ucr.edu                            University of California
+1 (909) 787-6437                          Riverside CA  92521-0304
PGP encryption key available on request.   USA


======================================================================= 2 ===
Date:    3 Feb 1994 12:52:10 GMT
From:    vogler@rzddec2.informatik.uni-hamburg.de (Jens Vogler)
Subject: Re: New version of Modula-3/PC

Carsten WEICH (carsten@post.ifi.uni-klu.ac.at) wrote:

> NEW VERSION OF M3-PC 
> --------------------

.....

>The necessary files are available at "gatekeeper.dec.com" in
>/pub/DEC/Modula-3/contrib/m3pc:

>	Install.txt	please read this first!
>	djgpp.tar	the DJGPP-gnu-C-compiler
>	m3.tar		compiler binaries
>	m3src.tar	sources of the compiler (optional)
>	tar.exe		program to unpack these files

 Hello,
  is it possible to cut the archieves into smaller pieces?
 I have only a disk quota of 3 Megs here ...
                                Yours
                                 ABert
--

/* ************************************************************* */
/* Wir waren zusammen, den Rest habe ich vergessen.              */
/* We were together, I have forgotten the rest.			 */
/* Eravamo insieme, tutto il resto del tempo l'ho scordato.	 */
/* Nous etions eusemble, le reste je l'ai oublie.		 */
/* Estabamos juntos, el otro lo he olvidado.                     */
/*				(Walt Whitman)			 */
/* 								 */
/*              \\\|||///					 */
/*                o   o   Yours ...				 */
/*	    	    |           Jens Vogler			 */
/*		   \_/		vogler@informatik.uni-hamburg.de */
/*		Amiga Gruppe - Virus Test Center - Uni Hamburg	 */
/* ************************************************************* */




======================================================================= 3 ===
Date:    Fri, 04 Feb 1994 08:47:06 +0100
From:    a.vermeulen@ECN.NL (Vermeulen A.T.)
Subject: m3pc distribution

In <2iqs1q$3b9@rzsun02.rrz.uni-hamburg.de>, vogler@rzddec2.informatik.uni-hambu
rg.de (Jens Vogler) writes:
>Carsten WEICH (carsten@post.ifi.uni-klu.ac.at) wrote:
>
>> NEW VERSION OF M3-PC 
>> --------------------
>
>......
>
>>The necessary files are available at "gatekeeper.dec.com" in
>>/pub/DEC/Modula-3/contrib/m3pc:
>
>>	Install.txt	please read this first!
>>	djgpp.tar	the DJGPP-gnu-C-compiler
>>	m3.tar		compiler binaries
>>	m3src.tar	sources of the compiler (optional)
>>	tar.exe		program to unpack these files
>
> Hello,
>  is it possible to cut the archieves into smaller pieces?
> I have only a disk quota of 3 Megs here ...
>                                Yours
>                                 ABert
>--

Compressing the files would be nice using compress, gzip or zip.
It would reduce the src-file to 25% of its current size! Getting
the files compressed automatically doesn't work on gatekeeper!

======================================================================
A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194)
Energy Research Foundation, PO Box 1, 1755 ZG  Petten, The Netherlands


======================================================================= 4 ===
Date:    4 Feb 1994 18:48:37 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Modula-3 Frequently Asked Questions (FAQ)

Archive-name: Modula-3-faq
Last-modified: Feb 3 1994


		 Modula-3 Frequently Asked Questions
		 ===================================


1. The language
	1.1 What is Modula-3?
	1.2 Is Modula-3 a superset of Modula-2?
2. The documentation
	2.1 Where can I get a description of Modula-3? 
	2.2 Where can I get other information on Modula-3?
3. The implementations
	3.1 Where can I get an implementation?
	3.2 What is SRC Modula-3?
	3.3 What is m3pc?
	3.4 What is GNU Modula-3?
4. Some specific questions
        4.1 Why is "Hello World" so large?
        4.2 Why objects and interfaces?
	4.3 What is the story with Trestle and OpenWindows?
        4.4 When is the next release of SRC Modula-3 ?
5. FTP
	5.1 What if I don't have ftp access?
6. Contributing
	6.1 Can I contribute Modula-3 software?




1.1. What is Modula-3?

   Modula-3 is a systems programming language that descends from Mesa,
   Modula-2, Cedar, and Modula-2+.  It also resembles its cousins
   Object Pascal, Oberon, and Euclid.

   The goal of Modula-3 is to be as simple and safe as it can be while
   meeting the needs of modern systems programmers.  Instead of
   exploring new features, we studied the features of the Modula
   family of languages that have proven themselves in practice and
   tried to simplify them into a harmonious language.  We found that
   most of the successful features were aimed at one of two main
   goals: greater robustness, and a simpler, more systematic type
   system.

   Modula-3 retains one of Modula-2's most successful features, the
   provision for explicit interfaces between modules.  It adds objects
   and classes, exception handling, garbage collection, lightweight
   processes (or threads), and the isolation of unsafe features.


1.2. Is Modula-3 a superset of Modula-2?

   No; valid Modula-2 programs are not valid Modula-3 programs.  However,
   there is a tool to help convert Modula-2 programs to Modula-3.


2.1. Where can I get a description of Modula-3? 
   
   The definition of Modula-3 is contained in:

        System Programming with Modula-3
        Edited by Greg Nelson
        Prentice Hall Series in Innovative Technology
        ISBN 0-13-590464-1
        L.C. QA76.66.S87 1991

   also known as SPwM3.  Here is the table of contents:

        1. Introduction
        2. Language Definition
        3. Standard Interfaces
        4. An Introduction to Programming with Threads
        5. Thread Synchronization: A Formal Specification
        6. I/O Streams: Abstract Types, Real Programs
        7. Trestle Window System Tutorial
        8. How the Language Got its Spots

   Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27,
   Number 8, August 1992, pp 15-42.

   Sam Harbison has written a more tutorial book about Modula3:

        Modula-3
        Samuel P. Harbison
        Prentice Hall, 1992
        ISBN 0-13-596396-6

   The errata sheet is available via anonymous ftp from gatekeeper.dec.com 
   in pub/DEC/Modula-3/errata.


2.2. Where can I get other information on Modula-3?

   There is a Usenet newsgroup, comp.lang.modula3.  The archives of
   that group are available via anonymous ftp from gatekeeper.dec.com
   in pub/DEC/Modula-3/comp.lang.modula3.  If you do not have
   access to Usenet, there is a relay mailing list; send a message to
   m3-request@src.dec.com to be added to it.

   There are a couple high-level overview articles available:

        "Modula-3", Sam Harbison, Byte, Vol. 15, No. 12, November 1990,
        pp 385+.

        "Safe Programming with Modula-3", Sam Harbison, Dr. Dobb's Journal,
        Vol. 17, No. 10, October 1992, pp 88+.

   A description of the Modula-3 type system is in

        "The Modula-3 Type System", Luca Cardelli, Jim Donahue, Mick Jordan,
        Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual
        ACM Symposium on Principles of Programming Languages (POPL), Austin
        Texas, January 11-13 1989, pp 202-212.

   The Trestle window system toolkit, higher-level FormsVBT toolkit, and
   Zeus animation system available with Modula-3, are documented in the
   following reports:

        "Trestle Reference Manual", Mark S. Manasse and Greg Nelson,
        SRC Research Report 68, December 1991.

        "Trestle Tutorial", Mark S. Manasse and Greg Nelson, SRC Research
        Report 69, May 1, 1992.

        "VBTkit Reference Manual: A toolkit for Trestle", edited by
        Marc H. Brown and James R. Meehan.  (soon to be a SRC Research
        Report)  A draft version is available via anonymous FTP from
        gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z.

        "The FormsVBT Reference Manual", Marc H. Brown and James R. Meehan,
        (soon to be a SRC Research Report).  A draft version is available
        via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and
        pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z.

        "Zeus: A System for Algorithm Animation and Multi-View Editing",
        Marc H. Brown, SRC Research Report 75, February 28, 1992.
        Available via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/SRC/research-reports/SRC-075*.ps.Z.

        "Color and Sound in Algorithm Animation", Marc H. Brown and
        John Hershberger, SRC Research Report 76a, August 30, 1991.
        Available via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/SRC/research-reports/SRC-076a*.ps.Z.

        "The 1992 SRC Algorithm Animation Festival", Marc H. Brown, 
	SRC Research Report 98, March 27, 1993.  Available via anonymous ftp
        from gatekeeper.dec.com in 
        pub/DEC/SRC/research-reports/SRC-098*.ps.Z.

   Hardcopy versions of these reports can be ordered by e-mail; send your
   request including a postal mail address to src-reports@src.dec.com.

   Sedgewick's classic text on computer algorithms is presented
   in Modula-3 in:

        Alogorithms in Modula-3
        Robert Sedgewick
        Addison-Wesley, 1993
        ISBN 0-201-53351-0

3.1. Where can I get an implementation?

   Two implementations are available, SRC Modula-3 and a
   PC version of it (m3pc).  Work is also progressing on GNU Modula-3.

   As far as we know, implementations are not available for VMS, Macintosh,
   or Alpha AXP/OSF.


3.2. What is SRC Modula-3?

   SRC Modula-3 was built by the DEC Systems Reseach Center
   and is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/release.

   The current version, 2.11, implements the language defined in SPwM3.
   There are versions for the following machines:

        AIX386  IBM PC running AIX/PS2,
        AP3000  Apollo DN4500 running Domain/OS
        ARM     Acorn R260 running RISC iX 1.21
        DS3100  DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
        HP300   HP 9000/300 running HP-UX 8.0
	HPPA    HP 700/800 running HP-UX 8.0
        IBMR2   IBM R6000 running AIX 3.1, 
        IBMRT   IBM RT running IBM/4.3, 
        NEXT    NeXT running ??
	OKI     Okidata 7300 (i860) running AT&T SVR4.0
        SPARC   SPARCstation running SunOS 4.1.x
        SUN3    SUN3 running SunOS
	SUN386  Sun 386i  running SunOS 4.0.1
        UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)
        VAX     VAX running Ultrix 3.1

   SRC Modula-3 includes a user manual, compiler, runtime library,
   some libraries and a few other goodies (see below).

   The compiler generates C as an intermediate language and should be
   fairly easy to port.  Except for the very lowest levels of the
   thread implementation, the entire system is written in Modula-3.

3.3. What is m3pc?

   m3pc is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/contrib/m3pc.


   From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI)
   Subject: M3 pn PC

   The Modula-3 system ported by us on the PC and available on the
   gatekeeper, runs with MSDOS, gnu c compiler and djgpp memory
   manager (detailed description in the read me file).

   The first version was ported by Klaus Preschern. Carsten Weich rewrote
   the handling of long filenames for the second version.

   You may compile, link and run Modula-3 programs, without threads.
   From the library modules only those are tested which are used by
   the compiler.  We are using the actual version for our beginners-course
   and we are working on "student-friendly" programming environmnents and
   a simple windowing graphic-library.


   From: carsten@post.ifi.uni-klu.ac.at (Carsten WEICH)
   Subject: New version of Modula-3/PC
   Date: 28 Jan 1994 13:25:28 GMT

   We have built a new version of Modula-3 running on a PC.
   You will need a PC:
     *  80486 or 80386 with floatingpoint-coprocessor,
     *  at least 4 but preferable 8 MByte of RAM,
     *  20 MByte discspace free at least.

   You can run a modified Modula-3 version 2.09 without thread-
   support. Our version features:
     *  support for Unix-like long filenames
     *  automatic compilation (to substitute the lack of m3make)
     *  library to access DOS-files and directories.

   We have built a little shell which translates the long filenames you
   type in into DOS-filenames. It has a unix-lookalike "ls"-command.
   There are commands to teach the system new long filenames.
   You can savely move such files around through DOS-directories
   (which was not possible with the first version).

   This version accesses DOS-files significantly faster than the first
   version. Especially linking large Modula-3 programs is much faster
   now. On a 50 MHz 80486 with 16 MByte of RAM we measured
   a turn-around time of 2 minutes for a 5 module, 500 lines program.
   If you want to compile only one module you will have to wait
   about one minute.

   The necessary files are available at "gatekeeper.dec.com" in
   /pub/DEC/Modula-3/contrib/m3pc:

	Install.txt	please read this first!
	djgpp.tar	the DJGPP-gnu-C-compiler
	m3.tar		compiler binaries
	m3src.tar	sources of the compiler (optional)
	tar.exe		program to unpack these files


3.4. What is GNU Modula-3?

   From: moss@cs.cmu.edu (Eliot Moss)
   Subject: GNU Modula-3 alpha release status
   Date: 25 Mar 93 17:53:12 GMT

   We said we'd try to get the initial (alpha) release of GNU
   Modula-3 out some time this month (March), and we're in the
   process of figuring out what to release and how to package it
   up. We expect to have something in roughly two weeks (watch
   this space for a notice).

   What would this be? First, it is a compiler for the VAX (only)
   under Ultrix (only), definitely without threads, and probably
   still failing a small number of the tests in the SRC test
   suite (which implies that not all of libm3 is likely to work
   either). The actual release information will detail more about
   what's working and what's not at that time. We DO currently
   pass all the compiler tests that the SRC compiler did when it
   was first released (i.e., the ones we fail are more obscure
   things that users uncovered over time).

   Second, the release itself will be a compressed tar file
   including sources and executables. The executables will
   probably work only if you put libraries, etc., in the expected
   places (otherwise, you'll need to rebuild from sources).The
   compiler is written in C and should be compiled with a recent
   version of gcc (so you'll need gcc installed). The system also
   uses gld (the GNU linker).

   This release should be most useful to people undertaking ports
   to other machines and operating systems, since it will give
   them a head start on understanding the compiler and getting
   the full system ready. It may be of some use for ordinary
   programming, but it really depends on whether you tend to use
   features that tickle the remaining bugs. We are indeed
   interested in alpha test reports, but only if they tell us
   something new (i.e., we'll provide a list of known
   deficiencies).

   When the release is made, we'll also start email discussions
   with the various parties who have indicated they might
   undertake ports, to help sort out who will do what.

   Regards, and thanks for your continued interest and
   encouragement -- EM

   From: moss@cs.cmu.edu (Eliot Moss)
   Subject: GNU Modula-3 pre-release
   Date: Wed, 5 May 1993 23:49:33 GMT

   At long last, the GNU Modula-3 project has a pre-release ready, for
   the VAX/Ultrix platform ONLY. Various folks had notified us of
   their interest in doing ports or alpha testing, and they have
   already been sent email with particulars on how to obtain the tar
   file, etc. There are a number of known bugs; I'll see about making
   a list available by ftp or something, for interested parties.

   It is our opinion that the prerelease is not mature enough for
   general use, but we wished to give a head start to those folks
   attempting ports, and we will make periodic patches available. If
   you want to use this compiler for serious program development or
   need something solid with debugging support for classroom use, you
   should wait until we've fixed more of the problems. (But to give a
   sense of what we HAVE accomplished, as I recall, all but 3 of the
   SRC compiler tests compile (there are 137 of them).) We hope to do
   a more general release, and support more platforms, in the summer.

   If you're interested in helping and have not previously contacted
   us, please send email to me and/or Rick Hudson
   (hudson@cs.umass.edu).

   Thanks to Digital and SRC for supporting us, and to Rick Hudson, Amer Diwan,
   and Norm Walsh, the guys who do all the hard work!


4.1. Why is "Hello World" so large?

   Modula-3 programs are larger than C programs for the following reasons:

     1) The fixed runtime is substantially larger.  It contains a
        garbage collector, a thread runtime, and exception support.
        Note that "Hello World" is virtually all runtime.  For
        larger programs the runtime is not an issue.

     2) The generated code includes runtime checks for out-of-bound
        array references and NIL pointer.  Many of these checks could
        be removed by a better compiler.  The current compiler is
        only a research prototype.

     3) The compiler generates C code as its intermediate language
        consequently the final machine code suffers.  For example,
        the compiler is constantly storing single-precision floating
        point values into memory to get around C's predisposition
        for double precision.

4.2. Why objects and interfaces?

   Allan Heydon on comp.lang.modula3,  May 4th 1993:

   Modula-3 provides two separate mechanisms for data-hiding: one for 
   hiding details about how interfaces are implemented, and the other 
   for hiding details about how objects are implemented.

   The first data-hiding mechanism is realized by the distinction between 
   interfaces and modules. Clients can only import interfaces, so the 
   names declared in the modules implementing those interfaces are hidden 
   from clients. Note that this mechanism has only two levels; a name 
   is either declared in an interface, or it isn't. If a name is only 
   declared in a module, it can't be used by a client. 

   The second data-hiding mechanism is realized by opaque types and 
   revelations. A Modula-3 interface may declare an object type to be 
   opaque, in which case only a subset of the fields and methods of 
   that object are revealed to clients importing the interface. Furthermore, 
   the Modula-3 revelation mechanism allows a designer to reveal successively 
   more fields and methods of an object in a series of interfaces. The 
   fields and methods visible to a client then depends on which interfaces 
   the client imports. 

   The latter mechanism is quite flexible. As opposed to the interface/module 
   data-hiding mechanism, opaque types allow you to define an arbitrary 
   number of levels at which more and more information about the implementation
 
   of your object is revealed. 

   See Sections 2.2.10, 2.4.6, and 2.4.7 of "Systems Programming with 
   Modula-3" for more information about opaque types and about partial 
   and complete revelations. 

4.3. What is the story with Trestle and OpenWindows?

   Mark Manasse says: 

   I think that the OpenWindows release should be enough (no need to 
   get the MIT X release], although there are a few things in Trestle
   that trigger devastating bugs in OpenWindows. But the only library
   we depend on is Xlib, R4 or later.

   The main thing I know that crashes OW 2.0 is the code where we call 
   GrabKey specifying AnyKey.  You can either loop over all of the 
   keys, or you can just comment out the call; programs won't run exactly 
   the same, but you probably won't notice the difference.


4.4 When is the next release of SRC Modula-3 ?

  The next release will be 3.1.  Here are some of the new things you will
  find in it:
  
  1. the compiler has a new internal interface between the front-end and
     the back-end, M3CG.  This interface is supposed to be easy to
     implement.
  
  2. the front-end can compute in the target arithmetic system; in particular
     it is possible to cross-compile to machines with larger integers than
     the host.
  
  3. one back-end has been implemented on top of gcc.  The implementation of
     M3CG interface generates the tree representation used internally in gcc.
     From the gcc point of view, this back-end looks like a new front-end.
     Using this back-end, we have cross-compiled solitaire for mips, alpha and
     386 processors; there is no reason to believe that there would be a
     problem for the other architectures supported by gcc.
  
  4. Dave Hanson wrote another implementation of the M3CG that is
     self-contained. He is currently working on the 386 code generation (he
     has done the mips code generation already).
  
  5. gdb has been modified to understand Modula-3 debugging information
     produced by the back-ends.  gdb can now parse Modula-3 expressions, print
     Modula-3 values and evaluate some of the Modula-3 built-in operations.
     There is also a little bit of support for multi-threaded programs (you
     can look at the stacks of other threads).
  
  6. there is a replacement for m3make, m3build, that does not rely on
     cpp/awk/sed/make and what not, and removes some of the limitations of
     m3make.  m3makefiles are very similar.
  
  7. libm3 has been significantly changed by the Interface Police, mostly in
     the area of OS interfaces and data structures.
  
  8. for the OS interfaces, we still have the U* interfaces, but applications
     are not supposed to use those.  Instead they should use a new set of
     interfaces that are os-independent; for example, there is a Pathname
     interface that manipulates file names; there is a Process interface that
     manipulate child processes.  These interfaces enabled a prototype port
     of the C based version to Windows NT machines.
  
  9. for the data structures, generics have been introduced and the various
     data structures are more consistent.
  
  10. because of 6 and 8, we can think about going to different os than Unix.
      In particular a Windows NT port will be available at some point (may not
      be in 3.0).
  
  11. the runtime has been improved quite a bit.
  
  12. new platforms: Alpha running OSF/1, 386 running Linux.  We will pay
      more attention to the porting instructions and support.
  
  13. I am not sure about all the changes in the libraries other than
      libm3.  I suspect that there will be few changes in trestle, but that
      mentor changed quite a bit. 
  
  14. The Windows NT port uses native threads.  This should be a good model
      for other implementations of Thread using native threads.

  The current status is:
  . the front-end is very stable
  . the gcc-based back-end has been stable for 4 months
  . the gdb extensions are brand new and need some test
  . the interface police work is very stable
  . we are working on bringing the system up on the machines we have in the
    building, and building the export machinery.
  
  We don't have a date for the 3.1 release.  Given the amount of changes
  introduced by 3.1, I suspect that the first few releases will not work out
  of the box for any machine but the ones for which we can test (decstations
  [mips and alpha], linux).  Consequently, I expect a high rate of releases
  for a while.  We will try to post accurate information about the status of
  each machine, but we can only rely what you tell us.
  
  At this point, I would not encourage anybody to start a new port.  If you
  have a new port, or are close to complete one, you can send us your bits,
  we will try to put them in 3.1.
  
  
5.1. What if I don't have ftp access?
  
   Unfortunately, we cannot deliver Modula-3 other than by 
   anonymous ftp.  

   Fortunately, Prime Time Freeware (PTF) includes Modula-3.  PTF is
   a set of two ISO-9660 CDroms filled with 3GB of freeware, issued
   semi-annually.  The latest issue, Volume 1, Number 2, July 1992,
   contains SRC Modula-3 2.07.  PTF is distributed via bookstores and
   mail.  You can reach PTF using:

	Email:  ptf@cfcl.com
        Fax:    [1] (408) 738 2050
        Voice:  [1] (408) 738 4832
        Mail:   Prime Time Freeware
 	        415-112 N. Mary Ave., Suite 50
		Sunnyvale, CA 94086
	        USA

6.1. Can I contribute Modula-3 software?

   Certainly.  Send us what you are willing to share, be it programs,
   libraries or other things.  We'll put them in the distribution.

   Right now, the pub/DEC/Modula-3/contrib directory contains:

      m3rpc   an rpc system from Xerox Parc
      M2toM3  a translator from Modula-2 to Modula-3
      m3pc    an implementation of Modula-3 for PCs.
   
----
Eric.





-- 
Eric.



======================================================================= 5 ===
Date:    Fri, 4 Feb 1994 18:35:28 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Reading Integer


In article <2itrke$eh5@nic.lth.se> dat93lma@ludat.lth.se (Lars Malmborg) writes
:

   I have a problem I can't figure out how to solve. It should be
   quite easy, but I am quite fresh on the language...  The problem is
   that I want to read from an ASCII-file containing numbers, possibly
   many on each row, and place them in an array of integers.

   -Lars

I am not sure if there is an interface that supports specifically what
you are asking, but two interfaces come to mind that may help:

INTERFACE FieldList;

(* Breaks text lines into fields that can be processed individually as
   text or numbers. *)

or 

INTERFACE Lex;
(* Sifting through a reader for booleans, integers, reals, and text strings. *)

You can take a peek at the implementation of Lex to see how it works.

--farshad
--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 6 ===
Date:    4 Feb 1994 16:03:26 GMT
From:    dat93lma@ludat.lth.se (Lars Malmborg)
Subject: Reading Integer

I have a problem I can't figure out how to solve. It should be quite easy, but 
I am quite fresh on the language...
The problem is that I want to read from an ASCII-file containing numbers, possi
bly many on each row, and place them in an array of integers.

-Lars





======================================================================= 7 ===
Date:    Fri, 4 Feb 1994 19:28:32 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Re: Reading Integer

dat93lma@ludat.lth.se (Lars Malmborg) writes:

>I have a problem I can't figure out how to solve. It should be quite easy, but
 I am quite fresh on the language...
>The problem is that I want to read from an ASCII-file containing numbers, poss
ibly many on each row, and place them in an array of integers.

Hey Lars,

here's one quick and dirty way using the FieldList interface to approach 
your problem:

MODULE Main;

IMPORT Stdio, Wr, FieldList, Fmt;

VAR
  fl                                := NEW(FieldList.T).init();
  MyLine: TEXT;
  Ints  : ARRAY [1 .. 4] OF INTEGER;
  Char  : CHAR;

BEGIN
  fl.getLine(Stdio.stdin);
  FOR i := FIRST(Ints) TO LAST(Ints) DO
    Ints[i] := fl.integer(i - 1);
  END;
  Char := fl.char(4, 0);         
  MyLine := fl.line();
  Wr.PutText(Stdio.stdout, Fmt.F("%s\n", MyLine)); (* print original line
                                                      as is *)
  Wr.PutText(
    Stdio.stdout, Fmt.F("%2s   %2s  %2s  %2s    %s\n", Fmt.Int(Ints[1]),
                        Fmt.Int(Ints[2]), Fmt.Int(Ints[3]),
                        Fmt.Int(Ints[4]), Fmt.Char(Char))); (* print what
                                                               the
                                                               Fieldlist
                                                               Reader
                                                               found *)
END Main.

It can be fed with lines like these, that are also trailed by a char.:
12   54  88   5    A
33   10   9   4    Q

The FieldList package can handle a variable number of elements in each
line, etc. etc.

The FieldList interface documentation ca also be found on the WorldWideWeb
as http://file01.mpipf-muenchen.mpg.de:8001/~torki/FieldList.ps
as well as on gatekeeper.dec.com, but in a directory I do not remember.
Moreover, the FieldList.i3 file gives sufficient information on how to
use the interface. Look for /usr/local/include/m3/FieldList.i3, or
wherever your public interfaces are stored.

You do not need the source code for the FieldList package, it has been
incorporated into the standard libm3.

I hope this helps you,
Torsten
-- 
Torsten R. Kirschner             Torsten.R.Kirschner@Informatik.TU-Muenchen.DE
[PGP 2.1 1024-bit key, Key ID 8A3F97, created 1993/11/14 available via finger]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>


======================================================================= 8 ===
Date:    Fri, 4 Feb 1994 21:22:42 GMT
From:    bnfb@scs.carleton.ca (Bjorn Freeman-Benson)
Subject: OOPSLA'94 Paper Deadline is NOT flexible!

J. Eliot B. Moss, Program Chair for OOPSLA'94, asked me to remind potential
OOPSLA'94 authors that the deadline for submitting papers really is the
15th of February -- there is no hidden later deadline...  An abstract of
how to submit papers is:

  Authors should send six copies of the full paper, in English, to the
  program chair (address below), to be received no later than 15 FEBRUARY
  1994. Papers must not exceed 18 PAGES, double-spaced, exclusive of figures
  and bibliographic references.  Electronic submissions will not be accepted.
  Each copy must contain CONTACT INFORMATION (contact name, postal address,
  telephone number, fax number, and electronic mail address), a 100 word
  ABSTRACT, indication of the CATEGORY (research or experience), and TOPIC
  AREA(S) as follows: language design and implementation, tools and
  environments, components and frameworks, user interfaces, principles and
  theory, databases and persistence, reflection and meta-level architectures,
  concurrent and distributed systems, design methods and software engineering
  practices. If none of the topic areas seem to apply, please contact the
  Program Chair for advice, preferably by electronic mail. The submission
  deadline is rigid; late submissions will NOT be processed.
  
  Program Chair
  J. Eliot B. Moss
  Computer Science Department, University of Massachusetts
  Box 34610, Amherst MA  01003-4610 USA
  (phone) +1-413-545-4206 (fax) +1-413-545-1249   
  (email) moss@cs.umass.edu

For more complete details, feel free to use the OOPSLA'94 Electronic Hotline:

    	    OOPSLA'94 ELECTRONIC INFORMATION HOTLINE

              Ninth Annual ACM Conference on
Object-Oriented Programming Systems, Languages and Applications
 
CONFERENCE CHAIR  JEFF McKENNA			23-27 October 1994
PROGRAM CHAIR	  J. ELIOT B. MOSS		Portland, OR, USA

The Ninth Annual ACM-SIGPLAN Conference on Object- Oriented Systems,
Languages, and Applications is returning to the site of its birth,
Portland, Oregon. Much has changed since that first meeting! The success of
OOPSLA is due to the quality and variety of offerings in the conference
programs.  In the spirit of all prior OOPSLA conferences, we invite you,
the researcher or practitioner, to participate.

________________ WHAT INFORMATION IS AVAILABLE ____________________

The CALL FOR PARTICIPATION is available, as well as some general
information about the conference and some advice and guidelines on how to
submit a winning paper/panel/workshop/tutorial/etc.  In the months to come,
other information will become available including: the technical program, 
the full conference schedule, registration forms, paper abstracts, how to
enjoy your trip to Portland, ... just about anything that you might want to
know about OOPSLA'94!

__________ HOW TO RECEIVE MORE INFORMATION ELECTRONICALLY _________

There are five mechanisms for receiving further information electronically:
WWW, gopher, WAIS, anonymous ftp, and e-mail list server.  

                            W W W

http://ursamajor.uvic.ca/oopsla94.html
    -or-
http://128.189.88.151/oopsla94.html

                         G O P H E R

gopher ursamajor.uvic.ca
    -or-
gopher 128.189.88.151

                           W A I S

(:source
 :version 3
 :ip-name "ursamajor.uvic.ca"
 :tcp-port 210
 :database-name "oopsla94"
 :cost 0.00
 :cost-unit :free
 :maintainer "bnfb@cs.uvic.ca"
 :description "Registration and attendance information for the 1994 ACM SIGPLAN
Conference on Object-Oriented Programming Systems, Languages,
and Applications (OOPSLA'94).  This server will be maintained
through October 1994.

Created with xwais by bnfb@ursamajor on May 31 16:57:27 1993."
)

        	    A N O N Y M O U S   F T P

Host name:     godot.uvic.ca
Host id:       128.189.88.101
FTP directory: pub/oopsla-94

    	    	E - M A I L   L I S T   S E R V E R

E-mail address:  listserv@csr.uvic.ca

In the BODY of the message (not in the subject line), include keyword
such as:
    help
or:
    index oopsla-94
or:
    get oopsla-94 call.for.participation.text

Our list server is very fragile, so please treat it kindly.  Specifically,
please do not include ANY extra text in the body of your message (no
pleasantries, no signatures, etc.) -- just the keywords.  Also, the
keywords must be in the *body* of the message not the subject line.  Please
note that due to internet mail delays, the file may take a day or so to
reach you.

Example (using the very simple Unix mail program):
	% mail listserv@csr.uvic.ca      <-- you type the command
	Subject:                         <-- you type return for "no subject"
	help                             <-- you type "help"
	^D                               <-- you send the message
Another example:
	% mail listserv@csr.uvic.ca      <-- you type the command
	Subject:                         <-- you type return for "no subject"
	get oopsla-94 call.for.participation.text <-- you type
	^D                               <-- you send the message

____________________ CONTACT WITH A PERSON ________________________

This Hotline is automatic - your e-mail has been processed by auto-answer
program.  No human has read your message.  If you are having trouble with
the Hotline, or need to communicate with an OOPSLA'94 representative about
some issue that the Hotline does not provide an answer for, you can contact
bnfb@ursamajor.uvic.ca (for Hotline Problems), oopsla94@applelink.apple.com
(for OOPSLA'94 Administration).

    	    	    	>>> PLEASE <<< 

Please do not contact the administration or registration people if your
problem can be answered by files on the Hotline.  OOPSLA is a big
conference and it is staffed by unpaid volunteers - we give our time to
make it happen.  This Hotline has been set up to provide answers to
Frequently Asked Questions and to reduce the administrative load on us...
Thank you.  (Also, the Hotline is automatic and thus available 24 hours a
day, whereas the administration is a 9am-5pm West Coast time operation.)


======================================================================= 9 ===
Date:    Sun, 6 Feb 1994 00:41:42 GMT
From:    torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner)
Subject: Q: M3 3.0 alpha and libm3 installation

Hello folks,

fortunately I just got M3 3.0 alpha to install on my DECstation. Now I
want to install libm3, but I get this error message that leaves me without
a clou what to do:
file01:/tmp/torki/boot-DS3100/libm3 > m3build
--- building in DS3100 ---
m3 -w1 -why -g -times -a libm3.a -F/usr/tmp/aaaa15954 
Fatal Error: missing link info file: ./src/runtime/32BITS/RTBuiltin.ix: errno=2
seconds  #times  operation    0.07       
1  inhaling library link info    0.01       
1  merging new link info    0.20       
2  garbage collection    0.09          
other---------------------------------------------------    
0.37          TOTAL
*** error code 1 (ignored)
file01:/tmp/torki/boot-DS3100/libm3 > ls -l ./src/runtime/32BITS/RTBuiltin.ix
-rw-r--r--   1 torki    system       3232 Jun  9  1993 ./src/runtime/32BITS/RTB
uiltin.ix

Can anybody help me, please? 

Thanks in advance,
Torsten
--
Torsten R. Kirschner  (EDV)           torki@mpipf-muenchen.mpg.de
MPI f. Psychologische Forschung       tel: ++49 89 38602258
Leopoldstr. 24                        fax: ++49 89 342473
80802 Muenchen
Germany          X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki"
[PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner <torki@mpipf-muenchen.mpg.de>]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>
-- 
Torsten R. Kirschner  (EDV)           torki@mpipf-muenchen.mpg.de
MPI f. Psychologische Forschung       tel: ++49 89 38602258
Leopoldstr. 24                        fax: ++49 89 342473
80802 Muenchen
Germany          X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki"
[PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner <torki@mpipf-muenchen.mpg.de>]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>


======================================================================= 10 ===
Date:    Sun, 6 Feb 1994 02:46:14 GMT
From:    torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner)
Subject: Q: libm3 3.0 alpha on ALPHA_OSF version stamp mismatch

Hello,

I got a little further with my attempts to get Modula-3.0 alpha running
on an ALPHA_OSF machine. The compiler seems to work as far as I can tell,
but when I try to compile libm3, I get this:

axposf.pa.dec.com:/scratch/kirschnt/boot-ALPHA_OSF/libm3 > m3build
--- building in ALPHA_OSF ---
m3 -w1 -why -g -times -a libm3.a -F/tmp/aaa011756 
new source -> compiling ../src/float/Common/LongFloat.i3
new source -> compiling ../src/float/Common/ExtendedFloat.i3
new source -> compiling ../src/float/IEEE/LongReal.i3
new source -> compiling ../src/float/IEEE/Extended.i3
missing version stamps -> compiling ../src/text/TextF.i3
version stamp mismatch: M3_BUILTIN.TEXT
  <036d35197f13b642> => TextF.i3
  <3a93efbb9d13c2d0> => M3_BUILTIN.i3  

Fatal Error: bad version stamps: TextF


 seconds  #times  operation
    0.35     126  checking object timestamps
    2.96     116  checking old link info
    0.07       2  merging new link info
    9.08       5  compiling Modula-3 -> IL
    0.27       1  compiling IL -> assembly
    0.63       1  compiling assembly -> object
    0.24      14  removing temporary files
    1.29       6  garbage collection
    0.09          other
---------------------------------------------------
   14.99          TOTAL

*** error code 1 (ignored)
axposf.pa.dec.com:/scratch/kirschnt/boot-ALPHA_OSF/libm3 > 

Since I am not familiar with how the new compiler works (the M3_BUILTIN.i3
interface seems to be generated at compile time, as I cannot find it anywhere
in the source tree), I am asking for some advice on how to correct this
version stamp mismatch.

Any help is appreciated. Thanks in advance!

Torsten
ps. The axposf.pa.dec.com:/scratch/kirschnt tree is world readable/executable.
It contains the status quo of what I have accomplished so far with M3 3.0
alpha. It's not much, but maybe more than what works on other platforms.
I'd be more than happy to find other users who are also eager to see a
working port. As far as I can tell, the new compiler is a lot faster than
the old one, especially on such a machine.
-- 
Torsten R. Kirschner  (EDV)           torki@mpipf-muenchen.mpg.de
MPI f. Psychologische Forschung       tel: ++49 89 38602258
Leopoldstr. 24                        fax: ++49 89 342473
80802 Muenchen
Germany          X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki"
[PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner <torki@mpipf-muenchen.mpg.de>]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>


======================================================================= 11 ===
Date:    6 Feb 1994 20:22:42 GMT
From:    mako@FNALA.FNAL.GOV
Subject: Re: Modula-3 Frequently Asked Questions (FAQ)

> 4.4 When is the next release of SRC Modula-3 ?
>
>   The next release will be 3.1.

So the alpha-3.0 is the 3.0 we will ever get... Perhaps, we could have an
alpha-3.1 sometime before you increment the version number again?

						mako


======================================================================= 12 ===
Date:    Sun, 6 Feb 1994 19:44:14 GMT
From:    890930g@dragon.acadiau.ca (D. Aaron Gallagher)
Subject: Trestle: VBT default sizes

Hi,
	I'm just starting out in Mod3 and I seem to have run into a
brick wall in Trestle. I'm trying to open a VBT and when it appears
on the screen it is always the minimum size, which is as small as it
can make the menu bar. I then have to manually increase the window size.
I've been going through .i3 libraries for a few days now, and I've seen
lots of references to getting the min, pref and max values, and what to
do after you change them, but I can't find any way of actually changing
these values. I don't know if I'm looking in the wrong places or just
not reading something correctly. Any help would be greatly appreciated.
	BTW, are there any reference guide type things out there for
Trestle? The books I have on Mod-3 don't really do more than touch on
the subject.

	
-- 
-------------------------------------------------------------------------------
                  Aaron Gallagher, aka 890930g@dragon.acadiau.ca 
                Go ahead and flame. Just remember, I'm on a Dragon.
+++++++++++++++++++++++++E-mail at 890930g@acadiau.ca++++++++++++++++++++++++++


======================================================================= 13 ===
Date:    Tue, 08 Feb 94 10:28:53 -0800
From:    msm@src.dec.com
Subject: Re: Trestle: VBT default sizes


You can get copies of the Trestle Reference Manual (report #68) and 
the Trestle tutorial (report #69) by sending mail to src-report@src.dec.com.

You change the window size for a top-level window by having that 
top-level window report a preference in its shape method.  The standard 
methods for splits often do the wrong thing for a top-level window, 
so you'll need to override the method, or wrap your top-level window 
in a filter that does the right thing.  Be sure to call VBT.NewShape 
whenever you change your mind, to prevent old cached results from 
being used.

Mark


======================================================================= 14 ===
Date:    7 Feb 1994 22:14:17 GMT
From:    salomon@silver.cs.umanitoba.ca (Daniel J. Salomon)
Subject: Question for Modula-3 Designers: Why no null stmts?


While experimenting with a grammar for Modula-3 we found that the
YACC's error recovery mechanism works much better if we change the
grammar to allow empty statements.  So according to our grammar a
sequence of semicolons would be accepted.  We then issue a warning
about empty statements as part of semantic analysis instead of
syntactic analysis.

My question is: Is there some deep philosophical reason why Modula-3
disallows empty statements?  In other words, should I really bother
to issue warnings for empty statements?

Perhaps the Modula-3 grammar should be changed to explicitly allow
empty statements.  In addition to improving YACC error recovery, it
might also make it easier for programs that generate Modula-3 code
automatically.

In the same vein, perhaps Modula-3 should allow constructor lists to
end with a comma.  C allows this in order to make automatic code
generation easier.  Just as the SRC Modula-3 compiler now translates to
C, Modula-3 may become a common target language in the future.  Why not
facilitate that task?

-- 
Daniel J. Salomon -- salomon@cs.UManitoba.CA
       Dept. of Computer Science / University of Manitoba
       Winnipeg, Manitoba, Canada  R3T 2N2 / (204) 474-8687


======================================================================= 15 ===
Date:    Tue, 8 Feb 1994 23:16:31 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Question for Modula-3 Designers: Why no null stmts?


A generalization of Daniel's a null statement question is whether the
language designer should sacrifice "human interface" issues to make
the "programming interface" for the language easier to use (either for
the program that implements a language or a program that generates a
language.)

In the case of C, it seems to me that more care was spent on
making things easier for the language designers, compiler writers, and
so on than improving the human interface. Decisions like = vs. ==,
empty statements, or type declarations reflect this point of view.
Though this policy works for the minority of programmers (today) who
are dilligent enough to not make mistakes, "the average programmer"
suffers from this. For an example, let's take a look at a C fragment:

        len = read_number (fp);
        returnval = MakeVector (len);
        for ( i=0; i < len; i++ );
          SetElement (returnval, i, ReadObject (fp));
        printf ("%d\n", i);

My impression of Modula is that it came from a different perspective.
There is more emphasis on how the "the average programmer" -- or even
a beginner -- is going to use the language. Modula-3 has retained most
of its predecessor's philosophy about syntax (though I would not want
to teach partially opaque types to someone who just started
prorgamming).  As a consequence, I think it is possible to teach
programming to early programmers with (a subset of) Modula-3, while it
is much harder to do the same with C.

Other than the fact that it is portable and lightweight, I can't
imagine why C is a particularly good target language _these days_,
especially since it lacks things such as memory management, good
namespace management, nested procedures, and overflow detection. I
seem to recall some gripes about C as a target language in some
documentation relating to SRC Modula-3.  Maybe some of the
implementors can elaborate. Modula-3 on the other hand, makes a pretty
nice target language for the most part, if you are willing to live
with the "little" extra overhead.

So my guess is that there is a philosophical difference between the
way the Modula-3 language designers work from the C language
designers. This not only affects the null statement, but also things
such as the MOD and DIV operators, etc. 

As to how one can support both the "beginners" and the "advanced"
progammers and/or other tools generating code, I can think of a couple
of ways:

One possible direction is to use "open implementation" techniques
which allow the programmer to change the language implementation (in
both syntactic and semantic ways) using things such as Metaobject
Protocols (MOPs). This way, the language designers don't have to guess
"what the user may wish for" ahead of time. You, as a programmer, can
change it to allow empty statements and comma-ended constructors.
However, this would probably go against the design goal of Modula-3's
which was to put together safe and proven set of features. (MOPs and
open implementations are not yet considered "safe" or "proven".)

Another alternative may be to provide a toolkit that allows you to
create abstract syntax trees for the language and manipulate them
instead of generating text. (I think the Modula-3 Toolkit allows you
to do all this.)  If the compiler is available "as a library" then,
you should be able to use it to compile your valid ASTs using its
backend.  Maybe at that level, the AST definition in the compiler
implementation can be relaxed to allow for empty statements, since the
"human" interface is not an issue at that level.

[I am hoping that this would spark a religious programming language
design debate that will keep this group busy while we await the 3.1
release. But previous such attempts have not been too successful,
except when it had to do with uppercase/lowercase issues.  We'll see.]

--farshad

...Disclaimer: I am not a language designer, but I play one at work...
--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 16 ===
Date:    Wed, 9 Feb 94 16:55:31 GMT
From:    rjohnson@titan.rdd.lmsc.lockheed.com (Ray Johnson)
Subject: Re: Question for Modula-3 Designers: Why no null stmts?

In article <FN00.94Feb8181631@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) writ
es:
>
>A generalization of Daniel's a null statement question is whether the
>language designer should sacrifice "human interface" issues to make
>the "programming interface" for the language easier to use (either for
>the program that implements a language or a program that generates a
>language.)
>
>In the case of C, it seems to me that more care was spent on
>making things easier for the language designers, compiler writers, and
>so on than improving the human interface. Decisions like = vs. ==,
...

>My impression of Modula is that it came from a different perspective.
>There is more emphasis on how the "the average programmer" -- or even
>a beginner -- is going to use the language. Modula-3 has retained most
>of its predecessor's philosophy about syntax (though I would not want
>to teach partially opaque types to someone who just started
>prorgamming).  As a consequence, I think it is possible to teach
>programming to early programmers with (a subset of) Modula-3, while it
>is much harder to do the same with C.

I agree with this last point.  However, that doesn't mean you should
ignore implementation issues or how the language design effects a code
generator etc.  Designing a language ONLY from the programers point of
view can be a mistake if for example you desing a language that is
so difficult to write a compilier for that no one can pass a standard
test suite.  Rather, proposed changes for implementational purposes
should be weighed against the impact on the user interface.  As for
null statements, what harm is there?  In fact, from a user interface
perspective I think it would be BETTER if an extra semicolon was
treated as a semantical warning rather than a syntactically error.

>Other than the fact that it is portable and lightweight, I can't
>imagine why C is a particularly good target language _these days_,
>especially since it lacks things such as memory management, good
>namespace management, nested procedures, and overflow detection. I
>seem to recall some gripes about C as a target language in some
>documentation relating to SRC Modula-3.  Maybe some of the
>implementors can elaborate. Modula-3 on the other hand, makes a pretty
>nice target language for the most part, if you are willing to live
>with the "little" extra overhead.

I thought the reason C was often used as a target language was 
because thier compiliers were common and highly optimized.

Ray




-- 
_____________________________________
Ray Johnson
Lockheed Artifical Intelligence Center


======================================================================= 17 ===
Date:    9 Feb 1994 19:58:18 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: comp.lang.modula3 archive

I have update the archive on gatekeeper.  It now includes all the
messages sent through January 94 (one file per month), together with 
a kwic index of the subject lines.

-- 
Eric.



======================================================================= 18 ===
Date:    Wed, 9 Feb 1994 12:31:18 +0100 (MET)
From:    thomas.tensi@fi.sdm.de (Dr. Thomas Tensi)
Subject: Did anybody do a M3-Spiderweb?

Hello M3 community,

I would like to know if anybody did a description of MODULA-3 for the
spiderweb literate programming system of Norman Ramsey.

(For those not familiar with this concept: Literate programming is method for
combining programs and their documentation into one document. This document is
filtered. Result of this filtering process is a prettyprinted documentation
(normally in TeX) and a source file for a programming language compiler.)

So: Has anyone done a m3.spider?

					Thanks



-------------------------------------------------------------------------
Dr. Thomas Tensi     |s  |d &|m  |  software design & management GmbH
                     |   |   |   |  Thomas-Dehler-Str. 18
thomas.tensi@sdm.de  |   |   |   |  81737 M"unchen, Germany.


======================================================================= 19 ===
Date:    Thu, 10 Feb 1994 11:24:11 GMT
From:    hws@csis.dit.csiro.au (Heinz Schmidt)
Subject: New OO benchmark TR


The following technical report can now be obtained by anon ftp from
csis.dit.csiro.au /pub/sather/papers.

We describe initial benchmark results obtained for some basic runtime
system primitives including array accesses, attribute accesses and
dynamic dispatch for Sather and C++ with a variety of different
approaches to object layout and dispatch implementation.  Our schemes
are a marriage of C++ virtual function tables and Sather dispatch
mechanisms, including a new technique based on custom dispatch tables
containing assembler instructions. The schemes are described in detail
and partly make Sather faster, in raw execution speed of these
primitives, tham current C++ implementations.  While we have written
the benchmarks in C and Sather, there is no reason why some of these
schemes could not be used in other OO languages.  

It is interesting to note that we have not yet optimized the
underlying C code sequence produced by Sather and/or used in part of
the runtime system.  Nevertheless Sather can obtain a speed very close
and partly faster to that of C++.  While many believe that typesafe
and higher-level OO languages such as Modula-3, Eiffel or Sather have
other advantages over C++, our benchmarks indicate that there is still
room for efficiency improvements at the runtimes level and further
optimization may be possible beyond that.

We are submitting an improved version of the TR including refined
benchmarks and additional architectures and would be most happy to
collect critique, feedback etc.

File: TR-CS-94-02.ps.Z

@techreport{Milton-Schmidt-94,
  author        = {S. Milton and H.W. Schmidt},
  institution   = {Department of Computer Science, The Australian National Univ
ersity},
  month         = jan,
  number        = {TR-CS-94-02},
  title         = {Dynamic Dispatch in Object-Oriented Languages}
  year          = {1994}
}


\begin{abstract}

Dynamic binding in object-oriented languages is perhaps the most
important semantic aspect of these languages. At the same time it can
contribute to inefficiency and lack of robustness because it incurs
lookup overheads on function calls and hinders the compiler
determining the exact type of objects held in variables or returned by
functions. This may, for instance, preclude inlining of small
functions or attribute offset computation at compile time. Yet
attribute accesses are the most frequently executed operations.  As a
result, to regain lost performance, OO programmers are tempted to
break the encapsulation of classes or want explicit control over
dynamic dispatch, trading off extensibility.

In the implementation of parallel object-oriented languages the
additional complication arises that object accesses may require more
expensive remote memory accesses.  Lookup at the call may be
inappropriate if the code has to be executed on a different processor
and there perhaps has a different address.

This paper summarizes dispatching as addressed in several modern
object-oriented languages. We then describe and benchmark fast and
flexible dispatch schemes that we are currently implementing on SPARC
based workstations and multi-processors. These involve elements of
\cplusplus\ virtual function tables and Eiffel's and Sather's ability
to redefine abstract functions as attributes.  Initial benchmarks seem
to promise improved efficiency on a range of modern RISC based
architectures.

\end{abstract}


         ,-------------------------------------------------------------------.
 ,--_|\  |Heinz.Schmidt@csis.dit.csiro.au  | CSIRO Div Information Technology|
/      \ |CSIRO DIT, POBox 664             | ANU Dept Computer Science       |
\_,--_*/ |Canberra ACT 2601, Australia     | include STD_DISCLAIMER{CSIRO};  |
      v  |Tel: +61-6-275-0974 Fax: 257-1052| include STD_DISCLAIMER{ANU};    |
         `-------------------------------------------------------------------'




======================================================================= 20 ===
Date:    10 Feb 94 12:56:20
From:    mday@note.lcs.mit.edu (Mark Day)
Subject: Re: Question for Modula-3 Designers: Why no null stmts?

   rjohnson@titan.rdd.lmsc.lockheed.com (Ray Johnson) writes:

   In fact, from a user interface
   perspective I think it would be BETTER if an extra semicolon was
   treated as a semantical warning rather than a syntactically error.

Actually, from a user interface perspective *all* semicolons are
annoying and should be exterminated.

Especially because you can write nice quasi-Modula-3 programs without
the semicolons, upper case keywords, and other syntactic glitches
marring an otherwise very nice language.

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).

--Mark Day

mday@lcs.mit.edu


======================================================================= 21 ===
Date:    10 Feb 94 16:22:32 GMT
From:    tj@lamar.ColoState.EDU (Tamera Joice)
Subject: Modula-3 Compiler for PC


		Does anyone know if there is a Modula-3 compiler for the
		PC that does not use djgpp? Are there any planned in the
		future? Are there any currently available? (Besides the 
		one currently available from gatekeeper)

			Email tj@lamar.ColoState.edu




======================================================================= 22 ===
Date:    10 Feb 1994 23:07:22 GMT
From:    salomon@silver.cs.umanitoba.ca (Daniel J. Salomon)
Subject: Re: Question for Modula-3 Designers: Why no null stmts?

In article <FN00.94Feb8181631@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) writ
es:
> 
> A generalization of Daniel's a null statement question is whether the
> language designer should sacrifice "human interface" issues to make
> the "programming interface" for the language easier to use (either for
> the program that implements a language or a program that generates a
> language.)

Orienting a language toward the user rather than the implementor is a
good philosophy in general, but I believe that Modula-3 has already
made compromises along this line.  For instance, I believe that the
reason that GOTO statements were left out of BLISS, Modula-2, and
Modula-3 was not due entirely to programming fashion alone.  An
additional consideration was that the absence of GOTOs permitted
improved code optimization since a code block cannot be interrupted by
random jumps in or out.  After all, if one is against GOTOs, one can
leave them out of programs, but if they impede optimization, or
complicate compilation, then one is forced to ban them from the
language instead.

Once you have made compromises for the implementor, the question becomes
where to stop compromising.
-- 
Daniel J. Salomon -- salomon@cs.UManitoba.CA
       Dept. of Computer Science / University of Manitoba
       Winnipeg, Manitoba, Canada  R3T 2N2 / (204) 474-8687


======================================================================= 23 ===
Date:    10 Feb 1994 23:10:38 GMT
From:    spreitze@parc.xerox.com (Mike Spreitzer)
Subject: C header file to language-X transliterator?

Does anybody know of any programs that will transliterate ANSI C header files
(ie, ".h" files that declare --- but not define --- things) into other language
s?
In order to invoke C procedures, and reference C variables, from another langua
ge
one typically needs to write some sort of "external declaration" to describe
those procedures and variables in the other language (assuming they can be
described at all in that language).  I'm looking for programs that take a
C header file as input and produce the required external declarations in any of
 a
variety of languages.  Note that I'm not asking for something that will
generate glue code that will transform the representations into something
more natural for the language in question; that's a harder problem.  Note
also that I'm not being picky about the language in which the transliterator
itself is written.

Please reply by mail to me; I don't follow all of these newsgroups.
I'll post a summary of the responses.

Thanks,
Mike Spreitzer
spreitze@parc.xerox.com


======================================================================= 24 ===
Date:    Thu, 10 Feb 1994 15:39:43 GMT
From:    tgt@lanl.gov (Thierry G. Thelliez)
Subject: Re: OOPSLA'94 Paper Deadline is NOT flexible!

In article <CKpy1v.2uL@cunews.carleton.ca>
bnfb@scs.carleton.ca (Bjorn Freeman-Benson) writes:

> 
>   Authors should send six copies of the full paper, in English, to the
>   program chair (address below), to be received no later than 15 FEBRUARY
>   1994. Papers must not exceed 18 PAGES, double-spaced, exclusive of figures
>   and bibliographic references.

Not very clear.  Can we send a camera-ready paper ?
18 Pages and double-spaced are the only constraints ?

Thierry



======================================================================= 25 ===
Date:    Sun, 13 Feb 94 21:41:25 EST
From:    vidya!mohan@vigyan.ernet.in
Subject: Hello

Friends,
 Is there a more detailed documentation on the internals of  the
Modula-3 compiler and runtime system than that in the DEC SRC Document
on Modula-3 (Chapter 6 details a little, I wish it was more ). This
is the document present in the modula-3 distribution in
 gatekeeper.pa.dec.com


Thanks in advance

Mohan

-------------------------------------------------------------------------
Mohan T S
Supercomputer Education and Research Centre
Indian Institute of Science			 mohan@vidya.iisc.ernet.in
Bangalore 560 012
INDIA						 mohan@vigyan.ernet.in 
-------------------------------------------------------------------------


======================================================================= 26 ===
Date:    16 Feb 1994 18:08:21 GMT
From:    kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS)
Subject: Why no 'use of unset value' run-time error in M-3?

M-3 is defined so that it is not a run-time error to use an unset
variable; an uninitialized variable assumes an arbitrary value of its
type.  I don't think this is ideal.  At CenterLine (Saber) we found that
'use of unset variable' is a common run-time error, and that it's very
nice to have a language implementation that catches it.

I realize that there are tradeoffs here between safety, language
complexity, and run-time cost.  Does anyone remember what alternatives
the language design committee considered?  Release 3 doesn't have any
unset variable run-time checking, does it?

----
Sam Kendall
Sun Microsystems Labs BOS


======================================================================= 27 ===
Date:    Wed, 16 Feb 1994 15:47:53 +0000
From:    conference@rtal.demon.co.uk ("S.T.Q. Conference")
Subject: CONFERENCE:'Safety Through Quality' (June 94, UK)

*******************************************************************************
*
*                     'SAFETY THROUGH QUALITY' conference                      
*
*******************************************************************************
*
                      Monday 6th and Tuesday 7th June 1994
              Beaumont Conference Centre, Old Windsor, Berks., UK

*******************************************************************************
*
***********************  PROSPECTUS AND CALL FOR PAPERS  **********************
*
*******************************************************************************
*

Real Time Associates Ltd., in conjunction with the British Computer Society 
Modular Languages SIG announce a major 2 day International Conference - `Safety
 
Through Quality'.

With the increasing use of modular programming languages for safety critical 
applications, the event is organised to embrace these, and the wider issues of 
designing and building safe systems through attention to quality.

The conference has been carefully arranged to contrast and encourage debate 
through comparing practical approaches that have been adopted - or are being 
contemplated - by the speakers for real world applications.

Although this prospectus constitutes an outline of the agenda, we are pleased 
to say that all companies and organisations mentioned in the provisional progr-
amme have confirmed that they will be presenting their papers and we thank them
 
for their support and encouragement.

The call for papers is designed to solicit further contributions in the theme o
f 
the conference. 

The organisers acknowledge the co-operation of the `Safety-Critical Systems Clu
b' 
(UK).

*******************************************************************************
*
***********************************  THEME  ***********************************
*
*******************************************************************************
*

Approaches ...                          

  *  Language design & compiler verification                            
  *  The place and importance of Formal Methods                               
  *  Automated testing of application code
  *  Weak links - the software / hardware interface.
  *  Neural networks - a different approach to the same goal

Implementation ...

  *  Case tools for safe design
  *  The place of reverse engineering
  *  The safety & quality of modern OOPs languages
  *  Parallel processing - too complex to be safe?
  *  The role of basic support tools - debuggers etc.

Psychological Issues...

  *  Are system designers and programmers trained in quality and safety issues?
  *  Quality assurance in project management - bargaining for safety testing
  *  The burgeoning of 'FATWARE' operating systems, compilers and utilities to 
     achieve safe results - is this possible?

Legal Issues ...

  *  The need for accountability
  *  Standards
  *  Current Legislation
  *  Civil Liabilities

*******************************************************************************
*
***************************  PROVISIONAL PROGRAMME  ***************************
*
*******************************************************************************
*

Computer based systems effect all aspects of our lives, and so they should be 
safe. But are they? 

The presentations are designed to contrast and encourage debate in the quality 
approach and safety considerations adopted by different companies and organis-
ations involved in areas such as those shown below. We hope that by comparing 
alternative approaches, the conference and debate will be synergetic to safer 
systems development.

  *  Military & Aerospace
     Speakers from Russian Military, NASA

  *  Nuclear Reactor Control
     Speakers from LDRA Ltd. (UK), Atomic Energy of Canada Ltd (AECL)

  *  Accounting & Finance (integrity in accounting systems)
     Speakers from Coopers&Lybrand, KPMG.

  *  Neural Networks (The Alternative Approach)
     Speakers from CalTech(USA) - hybrid neural network / expert system for
     telephone network management. University of Exeter - new theories and
     practices

  *  Virtual Reality (As an aid to Fire Fighting)
     Speakers from Human Engineering Technologies Ltd.

  *  Automobile Control Systems
     Ford Motor Co, Rover Group Ltd.

  *  Railway Control
     HM Railway Inspectorate (UK), Matra Transport (France)

  *  Quality Control Mechanisms & Law 
     Lloyds Register, Exxel consultants - R.J. McQuaker (Vice President of BCS)

 ** KEYNOTE PAPER
    Brian Wichmann of National Physical Laboratory (UK)
    Modularisation for Assurance (and how we gauge safety & quality).

*******************************************************************************
*
******************************  CALL FOR PAPERS  ******************************
*
*******************************************************************************
*

Papers in accordance with the Conference theme are invited from any source. 
Please send max. 500 word  abstract to the programme committee not later  than 
March 14th 1994. Notification of accepted papers will be given to the authors 
before April 15th 1994,where upon full papers will be expected by May 6th 1994.
Both abstracts and full papers should be submitted in machine readable form - 
either by disk (pref. 3.5", IBM PC format or Unix TAR) or by email - in ASCII 
or any popular word or desk top publishing format. All submissions must be 
accompanied by a hard copy as an aid to setting the proceedings. 

Submissions to :

      The Programme Committee 
      c/o Real Time Associates Ltd.
      Canning House
      59 Canning Road               Tel       : (+44)(0)81 656 7333/4/5
      Croydon                       Fax       : (+44)(0)81 655 0401
      Surrey
      CRO 6QF                       Internet  : conference@rtal.demon.co.uk
      UK                            CompuServe: 71333,2346


The working language of the conference is English, and will be used for all 
presentations and printed material.

The proceedings are likely to be post published by Oxford University Press and
we hope that selected papers will be published in the new, peer reviewed, 
international journal `High Integrity Systems' also published by Oxford 
University Press. The Programme Committee will hold copyright on the Proceeding
s 
material for this and the duration of the Conference. Any exceptions to this 
copyright scheme should be clearly indicated at the time of the submission.

The programme committee will not unreasonably withhold transfer of copyright, 
which, after this period, will reside with the authors or their organisations.

*******************************************************************************
*
*******************************  THE CONFERENCE  ******************************
*
*******************************************************************************
*

Beaumont Conference Centre at Old Windsor is situated close to the River Thames
 
and is adjacent to both Runnymede (Magna Carta & Kennedy Memorial) and Windsor 
Castle. Heathrow airport is just 10 miles away and Central London a 30 minute 
train journey.

A short walk over Windsor Bridge to Eton allows you to browse antique shops, ar
t
galleries and soak up the atmosphere of this historic town. 

The Eighteenth Century Georgian house is set within fifty acres of gardens and 
park lands and overall provides a combination of traditional elegance and moder
n
comforts. 

Recreational facilities include heated swimming pool, squash & tennis courts, a
nine hole pitch & putt golf course and croquet on the garden lawn. For those 
that prefer the less physical sports, snooker, pool, darts and various board 
games are also available.

Residential accommodation will be split between Beaumont itself and the adjacen
t 
Heathrow Marriott Hotel. All rooms are equipped with en-suite bathrooms, 
telephone, TV, etc. and are charged at the same rate. A courtesy coach service 
is provided between Beaumont and the Marriott Hotel, and from all four Heathrow
 
Airport terminals to/from the Marriott.

The larger Marriott accommodation is more suitable should you wish to bring a 
partner. Depending upon uptake, the organising committee will arrange a social 
programme for partners, to be run in parallel with the conference.

*******************************************************************************
*
*********************************  REGISTRATION  ******************************
*
*******************************************************************************
*

The residential fee for the two day Conference is GBP#420 to include conference
 
attendance, proceedings, two nights accommodation at Beaumont (Sunday 5th, 
Monday 6th June) and all meals (breakfast, lunch & dinner) and usual coffee 
& tea refreshments.

The non-residential fee is GBP#220 to include conference attendance, proceed-
ings, lunch and coffee & tea refreshments. Tickets for the Conference banquet 
on the evening of Monday 6th June are available for residential delegates at 
GBP#35 and for non-residential at GBP#45. After dinner speech by the entertain-
ing Mr Michael Bailey - 'Quality is No Illusion'.

Arrangements have been made to book supplementary accommodation for residential
 
delegates at a concessionary rate prior to, and after the Conference. This will
 
be charged at the special rate of 80 per day for dinner bed and breakfast. 
Partners sharing a delegates room will be charged a supplement of GBP#20 /day 
for bed and breakfast accomodation.

Members of the BCS Modular Languages SIG may attend the conference at a 10% 
discount on the conference fee (residential or non-residential). This discount 
will not apply to supplementary or partner rates.

The above rates are subject to the addition of UK VAT at 17.5%. A full VAT 
invoice will be issued. Monies are accepted in USD.

The conference is limited to a maximum of 100 attendees, so please book early t
o 
secure your place. Pre-payment is required before attendance is possible.

*******************************************************************************
*
*****************************  BOOKING DETAILS  *******************************
*
*******************************************************************************
*

To Book, please contact Real Time Associates Ltd (See 'Call For Papers' above f
or
details), stating address. You will be sent details and a booking form by retur
n 
post.

*******************************************************************************
*
********************************** CALENDAR ***********************************
*
*******************************************************************************
*

           +----------------------------+-----------------+
           | Abstracts by               | March 14th 1994 |
           +----------------------------+-----------------+
           | Acceptance Notification    | April 15th 1994 |
           +----------------------------+-----------------+
           | Full Papers by             | May 6th 1994    |
           +----------------------------+-----------------+
           | Final Conference Programme | May 16th 1994   |
           +----------------------------+-----------------+
           | Registration Deadline      | May 27th 1994   |
           +----------------------------+-----------------+
           | Conference                 | 6-7th June 1994 |
           +----------------------------+-----------------+

-- 
----------------------------------------------------------------------------
 'Safety Through Quality' Conference    conference@rtal.demon.co.uk
----------------------------------------------------------------------------
 c/o  Real Time Associates Ltd
      Canning House                    Tel: (+44)(0)81 656 7333/4/5
      59 Canning Road                  Fax: (+44)(0)81 655 0401
      Croydon, Surrey
      CR0 6QF, UK
-----------------------------------------------------------------------------


======================================================================= 28 ===
Date:    16 Feb 1994 14:34:17 -0500
From:    smiale@copper.ucs.indiana.edu (Steven Miale)
Subject: 2nd RFD: comp.lang.python

Second Request For Discussion: comp.lang.python

Purpose
-------

The newsgroup will be for discussion on the Python computer language.
Possible topics include requests for information, general programming,
development, and bug reports. The group will be unmoderated.


What is Python?
---------------

Python is a relatively new very-high-level language developed in
Amsterdam.  Python is a simple, object-oriented procedural language,
with features taken from ABC, Icon, Modula-3, and C/C++.

Its central goal is to provide the best of both worlds: the dynamic
nature of scripting languages like Perl/TCL/REXX, but also support for
general programming found in the more traditional languages like Icon,
C, Modula,...

Python may be FTP'd from the following sites:

	ftp.cwi.nl in directory /pub/python (its "home site", also has a FAQ)
	ftp.uu.net in directory /languages/python
	gatekeeper.dec.com in directory /pub/plan/python/cwi


Rationale
---------

Currently there is a mailing list with over 130 subscribers.
The activity of this list is high, and to make handling the
traffic more reasonable, a newsgroup is being proposed. We
also feel that comp.lang.misc would not be a suitable forum
for this volume of discussion on a particular language.


Charter
-------

Comp.lang.python is an unmoderated newsgroup which will serve
as a forum for discussing the Python computer language. The
group will serve both those who just program in Python and
those who work on developing the language. Topics that
may be discussed include:

	- announcements of new versions of the language and
	  applications written in Python.

	- discussion on the internals of the Python language.

	- general information about the language.

	- discussion on programming in Python.


Discussion
----------

Any objections to this RFD will be considered and, if determined
to be appropriate, will be incorporated. The discussion period
will be for a period of 21 days after which the first CFV will be
issued.


======================================================================= 29 ===
Date:    Wed, 16 Feb 94 12:27:14 PST
From:    frode@toaster.SFSU.EDU (Frode Odegard)
Subject: uninitialized variables and looseness

Yeah, it would seem reasonable - from a formal specification point of
view (read: VDM) - that the result of an expression f(x) is undefined
if x is undefined.  But would that not require some special value
representing 'undefined' ?  This might be expensive and complicated.

The M-3 approach is such that

   VAR x: T;
   BEGIN
      f(x)
   END

corresponds to the VDM-SL

   let x in set T in
      f(x)

In VDM-SL this is called "looseness", x is said to be some T but can
be *any* T.  A demand is laid upon f(x) such that it is defined for
any value of x as long as it is a member of T.  The above Modula-3
construct allows "looseness" in a formal specification to be echoed
to some degree in the implementation.

The looseness in Modula-3 is not as general as in VDM-SL, however.
As an example, look at the following VDM-SL function to find the
largest element in a set:

   S = set of Element;

   max-element: S --> Element

   max-element (s: S) r: Element
   pre s <> {}
   post r in set s and not exists x in set s . x > r

   max-element (s: S) ==
      let q in set s in
         if exists x in set s . x > q then
            max-element (s - {q})
         else
            q

The Modula-3 type system restrictions (types and sets are not generalized)
reflect the fact that the language is an implementation language.  While
VDM-SL makes it easy to write non-executable specifications, this would
not make sense in a programming language.

But at least Modula-3 lets us express "some T, any T."


Frode Odegard



======================================================================= 30 ===
Date:    Thu, 17 Feb 94 02:04:59 -0600
From:    demo.next.com!ggf@jsoft.com (Gary Frederick)
Subject: VDM tools (Was: Re: uninitialized variables and looseness)

frode@toaster.SFSU.EDU (Frode Odegard) gave some interesting info that mentione
d VDM:

Frode, I remember someone telling me there were some tools for VDM coming out.

Do you know anything about such tools?

Gary


======================================================================= 31 ===
Date:    Thu, 17 Feb 94 07:51:18 PST
From:    frode@toaster.SFSU.EDU (Frode Odegard)
Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness)

> Do you know anything about such tools?

Um, yes, I am a NAFTA-area distributor for one of them, the IFAD
VDM-SL Toolbox.  It contains an interpreter, a type-checker, a
LaTeX pretty-printer and a test coverage analyzer.  Presently
runs on SPARC machines only.  The system is fully integrated
with emacs, which is wonderful if you're already an emacs user.
(If not there's also a stand-alone mode.)  There's a new release
coming out any day now, watch comp.specification for the
announcement.  A demo version is available by ftp.

There's also a product called SpecBox from Adelaide in the UK;
IFAD is based in Denmark.

Frode Odegard
(frode@odegard.com)

PS: I hope this isn't too blatant an advertisement, but somebody
    did ask..


======================================================================= 32 ===
Date:    Thu, 17 Feb 94 10:13:52 -0800
From:    gnelson@src.dec.com
Subject: Re: Why no 'use of unset value' run-time error in M-3?


We didn't want to require a runtime check for using
an uninitialized variable, since this seemed like
it could be too slow.

We considered ways to change the language that would 
make it a static error to use an uninitialized variable,
but we couldn't find one that was simple enough.  (Consider
arrays that are initialized by passing them as a VAR OUT to
a procedure.)

Many of us concluded that the best approach was to build a 
lint-like tool to catch and statically warn the programmer about the
use of uninitialized variables.  Indeed, we are working
on an extended static checker at the moment, one of whose
checks will be for use of uninitialized variables.  But
the checker is Research with a capital R, so for the moment,
you just have to program carefully.

Greg Nelson


======================================================================= 33 ===
Date:    Thu, 17 Feb 1994 17:29:37 GMT
From:    jbpn1@hermes.cam.ac.uk (J.B.P. Naylon)
Subject: Errors in m3pp?

Recently I attempted to pretty-print a Modula-3 program, outputting to
PostScript in portrait orientation, and on one occasion received the message:

	***
	*** runtime error:
	***    ASSERT failed
	***    file "FBEPostScript.m3", line 225
	***

On trying again, I was rewarded with:

	***
	*** runtime error:
	***    NARROW failed
	***    file "NewFormatter.m3", line 860
	***

In both cases the command line was:

	m3pp -ps -portrait SubMaster.m3 >../../ps/SM.ps

Any suggestions as to why this happened?  Incidentally, SubMaster.m3 is not
even that large:

	wc SubMaster.m3

     	358    1682   15633 SubMaster.m3

I believe that this m3pp is the version distributed with version 2.11 of
the compiler.

-- 
John Naylon


======================================================================= 34 ===
Date:    Fri, 18 Feb 1994 13:24:07 GMT
From:    marcel@dutcu15.tudelft.nl (Marcel Verhoef)
Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness)

This is what I wrote to the comp.compilers group a while ago:

The institute of applied computer science IFAD at Odense, Denmark has
a toolset (compiler, interpreter, debugger) for the development of
VDM-SL specifications. All the tools used, are formally defined in VDM-SL
itself (syntax, abstract syntax, operational and static semantics) and 
implemented in C++. I have worked on part of the toolset for my MSc 
thesis and the general development approach taken was as follows:

1) specify the tool in a VDM-SL, beginning at a high level of abstraction
   and lowering the level of abstraction until you have a fully explicit
   formal definition of your program
2) test the specification with the debugger, develop a test-suite
   (the debugger can be used in on-line and batch mode)
3) implement the program (e.g. in C++)
4) re-use the test-suite to "validate" the program.

Of course, this is not a single-in-line operation, the power of this
approach is that you can re-iterate ideas by trying out specification
styles in an early stage with the debugging environment and taking
design decisions along the way.

Second advantage is that the coding in (e.g.) C++ is quite easy and the
time used on actually writing code is reduced *dramatically*. Actually,
much of this work could be automated (and what I hear is that IFAD is
going to built such a code-generator). I wrote a 2500 line specification
of a prototype staic semantics analysis tool (which took me 3 months to
complete, including testing) and I coded 7500 lines of C++ code in
less than one month, implementing the specification. This is including
the "learning"-curve (I had reasonable knowledge of VDM, but never
programmed anything big in C++). Although it was a price-to-win
approach (ever tried to complete your MSc in time?) comparable results
from industry are there. So, I would urge everyone interested in
implementing formal specifications to have a very close look at
what is going on in the Formal Methods world. There are several
companies with industry-proof toolsets available. Apart from IFAD
I can think of Adelard and BP research in GB and CRI in DK.  You can 
get info about the IFAD VDM toolbox by emailing toolbox@ifad.dk,
I don't know about the others.

Good entry-points are the proceedings of the VDM and FME conferences
which are published as lecture notes in computer science by Springer.

Greetings,
Marcel 


======================================================================= 35 ===
Date:    Fri, 18 Feb 1994 17:09:47 GMT
From:    pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma)
Subject: Acos ??


Hello,


My question is probably not so hard, at least that's what I hope:

I need to switch between the carthesian and polar coordinates of a
2D-vector. Which in itself isn't a problem since I can use the rule:

a.b = |a| |b| cos(c) --> angle = acos (a.b / |a| |b|)

Although I still have to make sure that the angle  will be between
0-360 degrees and not 0-180 all in all it's not so hard.

But I'm using Oberon which doesn't have an acos, asin funtion.
Basically my question is:

1] If I can't use acos or asin how do get polar coordinates
2] How can I define my own acos function easily

3] This is more of a general question:
Oberon, but also the original Modula-2 (see Wirth Report) have a Math
librarie which is very simple, things like acos, asin etc are
'missing'. Obviously this was done with a purpose but why??

Thanks in advance


Paul

                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
                            DELPHI PROJECT
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       tel:   (44) (0)223-333416 fax:   (44) (0)223-334871 
                    email: pgs1002@esc.cam.ac.uk
---------------------------------------------------------------------

Clinton Ft. Bragg Soviet Nazi Rule Psix supercomputer colonel NSA
AK-47 Semtex smuggle fissionable Noriega assassination domestic
disruption
--
                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       fax:   (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk
---------------------------------------------------------------------





======================================================================= 36 ===
Date:    Fri, 18 Feb 1994 13:16:21 GMT
From:    c2car@dmu.ac.uk (CA Randall)
Subject: Shareware

Does anyone know if a modula 3 system exists in the shareware for a pc. if so w
here can i get it ftp sites etc..


thanks in advance

chris.



======================================================================= 37 ===
Date:    Fri, 18 Feb 1994 15:42:39 GMT
From:    Darren New <dnew@thumper.bellcore.com>
Subject: Re: Why no 'use of unset value' run-time error in M-3?

> We considered ways to change the language that would 
> make it a static error to use an uninitialized variable, 
> but we couldn't find one that was simple enough. 

The Hermes language does this. 

>  (Consider 
> arrays that are initialized by passing them as a VAR OUT to 
> a procedure.) 

All you need to do is to have keywords or whatever that say "this
parameter can be passed uninitialized and is returned initialized". 
Course, this has to be checked when compiling the implementation, but
that isn't any harder than checking that you don't use uninitialized
variables.      -- Darren 
 



======================================================================= 38 ===
Date:    Fri, 18 Feb 94 01:58:27 -0600
From:    demo.next.com!ggf@jsoft.com (Gary Frederick)
Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness)

>PS: I hope this isn't too blatant an advertisement, but somebody
    did ask..

I did not find it blatant, then again, I am the person that asked (-:

Are you using VDM on any projects that also use M3?

Is anyone using M3 commercially?

Gary


======================================================================= 39 ===
Date:    Sun, 20 Feb 1994 02:44:39 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: 3.1


I downloaded the Linux version of Modula-3 v3.1 from gatekeeper.
It seems to install smoothly, but when I run m3build (as in the
tiny example at the front of DOC.dvi) m3c cannot find the standard
interfaces.  They ARE there, and seemingly in the right place.
Has anyone gotten this to work?  Do I have to change the templates?
Is there some DIRECT way to get m3c to look in some particular
place for interfaces?

-mike


======================================================================= 40 ===
Date:    Mon, 21 Feb 1994 00:20:52 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: 3.1

In article <CLI4yG.2yJ@watserv2.uwaterloo.ca> mhcoffin@tolstoy.uwaterloo.ca (Mi
chael Coffin) writes:

   I downloaded the Linux version of Modula-3 v3.1 from gatekeeper.
   It seems to install smoothly, but when I run m3build (as in the
   tiny example at the front of DOC.dvi) m3c cannot find the standard
   interfaces.  They ARE there, and seemingly in the right place.
   Has anyone gotten this to work?  Do I have to change the templates?
   Is there some DIRECT way to get m3c to look in some particular
   place for interfaces?

I run into a similar situation (with testing 3.1 on the SPARCs) which
I got rid of by adding the statement "import(libm3)" in the
m3makefile. I am not sure why libm3 is not imported automatically as
it used to be. I figured out that I need to do this by looking at
other m3makefiles in the distribution.

Hope this helps...

--farshad
--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 41 ===
Date:    21 Feb 94 20:42:04 GMT
From:    kazmier@CS.ColoState.EDU (michael kazmier)
Subject: Modula-3 and NeXT computers

Hey, just a quick question for all of you modula buffs, I am currently running
on NeXTStep 3.2 for Intel, does anyone know if there is a release of the lang
for my system and where I could find it.  If there is not one, does anyone
know of any planned release (such as the GNU release)

Feel free to e-mail me at kazmier@cs.colostate.edu

Thanks in advance...Mike Kazmier (kaz)



======================================================================= 42 ===
Date:    21 Feb 1994 14:55:20 -0600
From:    johnh@wheaton (John C. Hayward)
Subject: Missing Version Stamps for TEXT, MUTEX while making a boot-able

I am trying to make a bootstrap distribution of Modula-3-2.11 for NetBSD.
I have a working environment.  I have been having my students do some trestle
and formsVBT programming under NetBSD, XFree2.0 and Modula-3-2.11.

I have forgotten the steps I used to port it (its a long story but I originally
ported from Sun to 386BSD and then to NetBSD with the help of DecStation).

I have Modula-3-2.11 under a DecStation and attempting to create a
bootstrap_driver produces the following script.

scr> csh> m3make -f m3makefile.compiler bootstrap_driver NEW=NETBSD
scr> mkdir driver/boot-NETBSD
scr> Mon Feb 21 13:23:14 CST 1994 ===================== bootstrap driver for NE
TBSD
scr> cp ../src/m3.1 .
scr> /usr/local/bin/m3 -w1 -make -why -boot -times -g  -Y0@../../compiler/cross
-NETBSD/m3compiler@  -o m3 -F.PGM_SOURCES
scr> new source -> recreating ../../libm3/Csupport/src/generic/M3Runtime.h
scr> ... lots of new source -> recreating ...
scr> new source -> recreating ../../libm3/unix/src/ultrix-3-1.NETBSD/Uin.m3
scr> new objects -> linking m3
scr> undefined version stamp: TEXT  <b7a92447326386f5>
scr>      TextF.i3
scr> undefined version stamp: MUTEX  <1f9d4e89391ab815>
scr>      Thread.m3
scr>
scr>  seconds  #times  operation
scr>     1.34       1  flattening search path
scr>     3.66     271  checking object timestamps
scr>  1231.16     261  compiling Modula-3 -> C
scr>    14.91     261  merging new link info
scr>     0.94       1  checking global consistency
scr>     0.12      11  removing temporary files
scr>     3.50      10  copying files
scr>     6.76      10  garbage collection
scr>     1.09          other
scr> ---------------------------------------------------
scr>  1263.48          TOTAL
scr>
scr>
scr> Fatal Error: incomplete program
scr>
scr> *** Error code 255
scr>
scr> Stop.
scr> *** Error code 1
scr>
scr> Stop.
scr> csh> exit
scr> csh>
scr> script done on Mon Feb 21 14:09:17 1994

The resultant directory has almost everything it needs except
m3makefile.objs and _m3main.c.

There are comments in both Thread.m3 and TextF.i3 which indicate that
MUTEX and THREAD are special in that they are declared REFANY while these
modules define them as something else.

Any suggestions would be appreciated.
I think our postmailer is broken so pleas reply to
johnh@wheaton.edu

Thanks in advance.


======================================================================= 43 ===
Date:    Tue, 22 Feb 94 04:55:34 -0600
From:    demo.next.com!ggf@jsoft.com (Gary Frederick)
Subject: Re: Modula-3 and NeXT computers

I did the version of M3 for the 68K.  I may have both time and resources to get
 a "fat" (Motorola and  
Intel) version up soon.  I have not heard of anyone getting an Intel version up
.  The notes with the  
Motorola version at the ftp site in Oregon would be helpful.

E-mail me if you do the Intel version.

Good luck

Gary


======================================================================= 44 ===
Date:    22 Feb 1994 17:50:44 +1100
From:    ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Subject: Re: Acos ??

pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) writes:
>My question is probably not so hard, at least that's what I hope:

>I need to switch between the carthesian and polar coordinates of a
>2D-vector. Which in itself isn't a problem since I can use the rule:

>a.b = |a| |b| cos(c) --> angle = acos (a.b / |a| |b|)

This is a very odd way to do it.  That conversion is precisely what the
very common two-argument arctangent function is supposed to do.
Diagram:
		.
	       /|
	      / |		r >= 0 is length of hypotenuse
	    r/  |y		0 <= a < 2pi is the angle
	    /a  |		x is horizontal, could have either sign
	   /____.		y is vertical, could have either sign
	      x

In the UNIX C environment, we have
	x = r*cos(a)		r = hypot(y, x)
	y = r*sin(a)		a = atan2(y, x)

>But I'm using Oberon which doesn't have an acos, asin funtion.

Does Oberon have an atan function?  If it has a two-argument arctangent,
then the conversion is as easy as I have shown, and will give you the
right answers for all four quadrants (all angles 0 <= a < 2pi, all values
of x and y).  If it has a one-argument arctangent, you will have to look
at the angle yourself to find out which quadrant (sign of x, y) you want.

*Mathematically*, hypot(y, x) = sqrt(y*y + x*x).
A good *mplementation* will avoid overflow and underflow, typically by
doing something like
	ax <- abs(x)
	ay <- abs(y)
	if ax > ay then
	    p <- ax
	    t <- ay/ax
	else
	    p <- ay
	    t <- ax/ay
	end if
	if t > EPS then		# precalculated so that EPS*EPS+1.0 == 1.0
	    return sqrt(t*t+1.0) * p
	else
	    return p
	end if

Something you want to watch out for is that (x=0.0,y=0.0) is a perfectly good
point in Cartesian coordinates, but atan2(0.0, 0.0) is not well defined (when
the radius r = 0.0, the angle is genuinely undefined).  So you want

	if abs(x) = 0 and abs(y) = 0 then
	    r <- 0
	    a <- 0 # or anything else you fancy
	else
	    r <- hypot(y, x)	# computed as above
	    a <- atan2(y, x)
	end if



======================================================================= 45 ===
Date:    22 Feb 1994 18:05:16 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Q: netobj/stubgen on DS3100?

In article <torki.761929785@MPIPF-Muenchen.MPG.DE>, torki@mpipf-muenchen.mpg.de
 (Torsten R. Kirschner) writes:

> My only problem is occurs during
> the stubgen build phase:
> 
> ***
> *** runtime error:
> ***    checked runtime error: range fault, value too small
> ***    pc = 0x4aff78 = EmitArg + 0x240 in ../src/values/Formal.m3
> ***

The compiler chokes when it's generating code to pass an
open array by value.  In this case the easiest workaround
is to modify stubgen/src/CodeForType.AugmentImportList to take
a READONLY ARRAY OF Atom.T.

  - Bill Kalsow




======================================================================= 46 ===
Date:    22 Feb 94 16:44:54 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Redefined procedures from generic module

In working up to generics, I have a generic interface/module
implementing a list type and associated operations.  There are
8 procedures here.

I have two data types, INTEGER and TEXT, defined by two more
pairs of interface/module.

I have two instantiations (two more pairs) of the generic list,
defining integer lists and text lists.

I have a main module that imports both instantiations, and declares
some variables of each list type.

The m3 compiler complains to me that 4 of the 8 procedures in the
generic module are redefined.

Any instant help out there?  I can be lots more specific, but I
hoped there was a "Hey, dummy ... " response.

Thanks in advance.


======================================================================= 47 ===
Date:    Tue, 22 Feb 1994 15:09:45 GMT
From:    torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner)
Subject: Q: netobj/stubgen on DS3100?

Hello,

I just successfully compiled and installed Modula-3 3.1 out of the box.
It works fine as a DS3100 port. Of course I would like to play with DO,
so I tried to compile the netobj package. My only problem is occurs during
the stubgen build phase:

--- building in DS3100 ---
rm -f stubgenv1
ln -s stubgen stubgenv1
m3 -w1 -why -g -o stubgen -F/usr/tmp/aaaa23402 
new source -> compiling ../src/StubCode.m3


***
*** runtime error:
***    checked runtime error: range fault, value too small
***    pc = 0x4aff78 = EmitArg + 0x240 in ../src/values/Formal.m3
***

------------------------- STACK DUMP ---------------------------
----PC----  ----SP----  
  0x4d4268  0x7fffb2f0  Crash + 0x9c
  0x4d93c8  0x7fffb310  EndError + 0x44
   [0x4d90ac..0x4d929c]  RAISES {}
  0x4d9298  0x7fffb328  FatalErrorPC + 0x218
  0x504ee0  0x7fffb358  CRE + 0x40
   [0x504c10..0x504e88]  RAISES {}
  0x504d04  0x7fffb370  BusError + 0x114
  0x533580  0x7fffb390  [sigvec]
  0x4aff74  0x7fffb4e8  EmitArg + 0x240
   [0x4a3c44..0x4a4564]  RAISES {}
  0x4a41ac  0x7fffb530  Prep + 0x594
  0x424c20  0x7fffb5b0  Prep + 0x40
   [0x41bc94..0x41bd24]  RAISES {}
  0x41bd20  0x7fffb5d0  Prep + 0xa8
  0x4795d0  0x7fffb5f0  Compile + 0x38
  0x475aa0  0x7fffb610  Compile + 0xb4
  0x4792c8  0x7fffb648  Compile + 0x134
  0x475aa0  0x7fffb678  Compile + 0xb4
  0x4ba284  0x7fffb6b0  GenBody + 0x1c8
  0x4ba0a0  0x7fffb6f0  EmitBody + 0x68
   [0x462db8..0x462f28]  RAISES {}
  0x462e50  0x7fffb710  EmitBody + 0xb4
   [0x46208c..0x462bd0]  RAISES {}
  0x462124  0x7fffb740  EmitAll + 0xd4
  0x4b64a0  0x7fffb7f8  CompileModule + 0x150
   [0x4b5e04..0x4b60dc]  RAISES {}
  0x4b6014  0x7fffb830  Compile + 0x234
  0x44c7e0  0x7fffb870  DoCompile + 0x1f0
   [0x44c0f0..0x44c278]  LOCK  mutex = 0x1007b4c0
  0x44c264  0x7fffb8b8  Compile + 0x1c8
  0x4c6850  0x7fffb8e0  DoCompile + 0x3d8
  0x4c644c  0x7fffb930  DoIt + 0x30
  0x4c78e0  0x7fffb950  _INITM_Main + 0x16c
   [0x4d436c..0x4d4444]  RAISES {}
  0x4d4404  0x7fffb970  RunInitPhase + 0xb8
  0x4d4630  0x7fffb9a0  _INITM_RTLinker + 0x1cc
  0x40042c  0x7fffb9c0  [main]
  0x400334  0x7fffb9e8  [__start]
----------------------------------------------------------------
"../src/StubCode.m3", line 118: warning: potentially unhandled exception (OSErr
or.E)
"../src/StubCode.m3", line 119: warning: potentially unhandled exception (OSErr
or.E)
compilation failed => not building program "stubgen"
*** error code 1 (ignored)

I apologize for the long quote, but maybe someone can interpret it.
Unfortunately, I cannot. However, stubgen is essential for building DO
applications.

Has anyone got a quick hint for me how I can fix this? Thanks in advance!

Torsten
ps. I would like to add that I ftp'd th release-3.1 from the very well
sorted ftp.informatik.tu-muenchen.de:/pub/comp/programming/languages/Modula-3.
That's a German site and might be a little faster for most European fellows
than gatekeeper.dec.com directly.
-- 
Torsten R. Kirschner  (EDV)           torki@mpipf-muenchen.mpg.de
MPI f. Psychologische Forschung       tel: ++49 89 38602258
Leopoldstr. 24                        fax: ++49 89 342473
80802 Muenchen
Germany          X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki"
[PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner <torki@mpipf-muenchen.mpg.de>]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>


======================================================================= 48 ===
Date:    22 Feb 1994 23:23:09 -0600
From:    johnh@wheaton (John C. Hayward)
Subject: troubles with 3.1 with libm3 imports

I have installed 3.1 on a decstation and have tried to build the simple
hello program.  I did change the default directories for bin, lib
(/usr/local/new/bin and /usr/local/new/lib) so installing 3.1 would not
clobber the current 2.11 version.

There seems to be a file in topdir/libm3/DS3100/.M3IMPTAB with all of
the information for the compiler(driver) to locate the include files
for libm3.  When I do a m3ship for the library I do not see that file
being installed.

I think the compiler(driver) does not see this file when I attempt to m3build
the hello program and as a result cannot find the include files from
the library.

Where is the proper place for the .M3IMPTAB describing libm3 when it is
installed and do I have to do anything special to get the driver(compiler)
to see it?

Below is a script of my unsuccessful attempt:

>Script started on Tue Feb 22 23:02:23 1994
>csh> m3build
>--- building in DS3100 ---
>m3 -w2 -why -g -o foo -T.M3IMPTAB ../src/Main.m3 ../src/A.i3 ../src/A.m3
>new source -> compiling ../src/A.i3
>"../src/A.i3", line 1: unable to find interface (RT0)
>"../src/A.i3", line 1: imported object is not an interface (RT0)
>"../src/A.i3", line 1: unable to find interface (RTHooks)
>"../src/A.i3", line 1: imported object is not an interface (RTHooks)
>4 errors encountered
>... other errors for A.m3 and Main.m3
>compilation failed => not building program "foo"
>*** error code 1 (ignored)
>csh> ^D
>script done on Tue Feb 22 23:02:40 1994

Thanks in advance for any help.
Our news poster may be broken please e-mail to:

johnh@wheaton.edu

johnh...


======================================================================= 49 ===
Date:    Wed, 23 Feb 1994 18:04:52 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Modula-3 3.1 on a SPARC


Quentin asked me for hints to bring up Modula-3 3.1 on the SPARCs, so
I am releasing a log of bug reports and fixes that I know of.  You can
find these as a tar file:

   ftp.gte.com:/pub/m3/m3-3.1-on-a-SPARC.tar

and its expanded version, the directory:

   ftp.gte.com:/pub/m3/m3-3.1-on-a-SPARC

This includes fixes to formsvbt, netobj, and obliq.  (All but the last
one are working fine for me; obliq still gives me a weird run-time
crash.)

Many thanks to m3-request (whoever you are), Bill Kalsow, Geoff Wyant,
Marc H. Brown, and Luca Cardelli for their input.

Let me know if you find other fixes that I should include in this
directory until the next release comes out. (I haven't gotten Michel's
post about the binary archive, but I think some of these patches here
are complementary to his patches.)

--farshad
--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 50 ===
Date:    Wed, 23 Feb 1994 14:30:22 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Release 3.1 compiled for SPARC available


I have successfully compiled most of the release 3.1 for SPARC. This includes
the compiler, libm3, m3gdb, trestle, vbtkit, formsvbt/formsedit, m3tk.
Zeus, netobj and obliq are missing. New binaries will be generated with
better optimization, dynamic librairies and the missing parts whenever
things settle down a bit.

This is available from:

ftp.vlsi.polymtl.ca:pub/lude/modula3-3.1/run/poly/sun4.1_sparc

To use it you simply have to put this in 

/usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc and make links from 
/usr/local/bin/* to /usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc/bin/*

A first set of LINUX binaries will be available shortly in 

pub/lude/modula3-3.1/run/linux.tar.Z

and must be put in /usr/local/soft/modula3-3.1. Then, links should be made
from /usr/local/bin/* to /usr/local/soft/modula3-3.1/run/bin/*

Enjoy!
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 51 ===
Date:    Wed, 23 Feb 1994 14:18:46 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: troubles with 3.1 with libm3 imports


   Below is a script of my unsuccessful attempt:

   >Script started on Tue Feb 22 23:02:23 1994
   >csh> m3build
   >--- building in DS3100 ---
   >m3 -w2 -why -g -o foo -T.M3IMPTAB ../src/Main.m3 ../src/A.i3 ../src/A.m3
   >new source -> compiling ../src/A.i3
   >"../src/A.i3", line 1: unable to find interface (RT0)
   >"../src/A.i3", line 1: imported object is not an interface (RT0)

You can put "import(libm3)" in your m3makefile. It fixed my problem.
However, i agree that normally the driver/compiler should not need it.
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 52 ===
Date:    24 Feb 1994 17:06:06 GMT
From:    sims@ucrengr.ucr.edu (david sims)
Subject: Re: 3.1

mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:

Michael> I downloaded the Linux version of Modula-3 v3.1 from
Michael> gatekeeper.  It seems to install smoothly, but when I run
Michael> m3build (as in the tiny example at the front of DOC.dvi) m3c
Michael> cannot find the standard interfaces.

I just did the same thing and got the same problem.  Argh!

I tried putting "import(libm3)" in the m3makefile, but that didn't
help a bit.  Has anyone been able to get it working with Linux?  If
so, what did you do?  Please help!

thanks,
dave sims
-- 
David L. Sims                              Department of Computer Science
sims@cs.ucr.edu                            University of California
+1 (909) 787-6437                          Riverside CA  92521-0304
PGP encryption key available on request.   USA


======================================================================= 53 ===
Date:    Thu, 24 Feb 1994 16:33:48 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 3.1 on a SPARC


   Let me know if you find other fixes that I should include in this
   directory until the next release comes out. (I haven't gotten Michel's
   post about the binary archive, but I think some of these patches here
   are complementary to his patches.)

In ftp.vlsi.polymtl.ca:lude/modula3-3.1 (my previous post said pub/lude
by mistake) you will not only find the SPARC and LINUX binaries under run
but also the unmodified source code under src/orig and the local modifs
under src/poly. Indeed, i use a translucent mount when modifying and
compiling packages. Thus, all my patches are readily available by
looking at src/poly.
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 54 ===
Date:    Fri, 25 Feb 1994 00:09:18 GMT
From:    aselkirk@leibniz.uwaterloo.ca (Andrew Selkirk)
Subject: v3.1 libm3

G'Day....

I've been able to successfully install v3.1 on my Linux system...  On top
of having to include the "import (libm3)" in your m3makefile, I also
installed the libm3.tar.gz package (which installs into ../m3/pkg/libm3)
which seemed to do the trick. But sure was tedious having to recompile the
libm3 library which was originally done to create the m3 executables...Argh!

NOTE:  The debugging option "-g" (M3OPTIONS in ../m3build/templates/LINUX) is
       set and well... the difference between a 4M and 2M library.
       (I just copied the libm3.a from the initial install after installing
       libm3 package...There's probably a better solution but it worked)

Hope this helps....

---------------------------
Andrew Selkirk
University of Waterloo
2A Honours Computer Science


======================================================================= 55 ===
Date:    25 Feb 1994 05:46:40 GMT
From:    sims@ucrengr.ucr.edu (david sims)
Subject: Re: 3.1 [problem fixed]

I wrote> mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:

Michael> I downloaded the Linux version of Modula-3 v3.1 from
Michael> gatekeeper.  It seems to install smoothly, but when I run
Michael> m3build (as in the tiny example at the front of DOC.dvi) m3c
Michael> cannot find the standard interfaces.

I wrote> I just did the same thing and got the same problem.  Argh!

Well, in case y'all were sitting on the edge of your seats, my
problem's been fixed.  Seems I neglected to build and install libm3.
I was fooled into thinking I didn't need it since m3boot had already
built it.

Thanks to everyone for helping me out.

Cheers,
dave
-- 
David L. Sims                              Department of Computer Science
sims@cs.ucr.edu                            University of California
+1 (909) 787-6437                          Riverside CA  92521-0304
PGP encryption key available on request.   USA


======================================================================= 56 ===
Date:    Sat, 26 Feb 1994 12:51:21 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Trestle problems under Linux 0.99pl15

 Hello everyone :-). I'm having a bit of trouble with Trestle (and hence
FormsVBT) under Linux 0.99pl15. Trestle and FormsVBT compile without
errors, and so do programs which use them (I've tried 'Cards', 
'Hello Trestle', 'Calculator' and 'Cube'). 

 When I try to run these programs, however, they run successfully for
 anything from a few to 20 or more seconds, and then crash with a 'Virtual 
time alarm' error. This (or so gdb and the kernel source tell me) is due 
to their being sent signal 26 (Virtual time alarm). If I insert a signal 
handler for SIGVTALRM, Cards and Hello Trestle work fine - I haven't tried 
with Calculator and Cube because they take ages to build on my platform.

 I assume that what's happening is that Trestle is setting a timeout, 
expecting to recieve SIGALRM or something, and is instead recieving what
it expects, is getting SIGVTALRM. This is fixable by inserting a null 
SIGVTALRM handler in whatever package under Trestle (ui, X11R4 or tcp)
sets the alarm, but since the alarm is probably supposed to be doing
something, that sounds like a silly thing to do.

 I'd be grateful if someone could tell me what incredibly obvious and
stupid thing I'm doing wrong, or provide some sort of bug fix ?


 Thanks in advance,



Richard.



======================================================================= 57 ===
Date:    Mon, 28 Feb 1994 18:30:32 GMT
From:    mms@dcs.glasgow.ac.uk (Miguel Mira da Silva)
Subject: FAQ ?

Is there a FAQ for this newsgroup?

Thanks, Miguel.
-- 
Miguel Mira da Silva
mms@dcs.glasgow.ac.uk


======================================================================= 58 ===
Date:    Mon, 28 Feb 1994 18:22:53 GMT
From:    890930g@dragon.acadiau.ca (D. Aaron Gallagher)
Subject: a couple of formsVBT/Trestle questions

First I'd like to thank everyone who mailed me about the last post.
I ended up using a RigidVBT with the FromHV command. (I'd never have
found it if I'd been looking by my self)

I now have two rather major problems which are stumping me :-(
The first seems to be a font problem or something similar.
I'm using a JoinVBT to display on several displays and the fonts, menubars
and FormsVBT buttons won't show up on the other displays. The buttons
are there, because they work when clicked on, but they appear as just
a block of the background. Anyone have any ideas ?

The other problem has to do with TextEdit windows from FormsVBT. I want
to have one come up on just one screen while the JoinVBT window is 
displayed on several. It installs fine if The JoinVBT window is
displayed on only the originating display, but when I try to open
more than one display for the JoinVBT, I get the following runtime
error message:
***
*** runtime error:
***    ASSERT failed
***    file "Thread.m3", line 575
***
. Again, I'm stumped. I'm specifying the trsl and everything, and it works
for and FormsVBT type I've tried except the TextEdit, and TypeIn (and
probably the Typescript too). 

Any help is greatly appreciated!




-- 
-------------------------------------------------------------------------------
                  Aaron Gallagher, aka 890930g@dragon.acadiau.ca 
                Go ahead and flame. Just remember, I'm on a Dragon.
+++++++++++++++++++++++++E-mail at 890930g@acadiau.ca++++++++++++++++++++++++++


======================================================================= 59 ===
Date:    Mon, 28 Feb 1994 14:14:02 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Trestle problems under Linux 0.99pl15

I have built Trestle on Linux but have not run it yet so i cannot say if
it works (my regular machine is at the repair shop and a 4MB 386 does not
run well under X11). The SIGVTALARM signal is used for thread scheduling
so disabling it will cause you problem eventually. It is not enabled for 
programs without threads but Trestle uses multiple threads internally
(at least that was true for 2.11).
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 60 ===
Date:    28 Feb 94 18:28:15 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: Where to start

    Ok, I got the DOS port of Modula-3, I got the Book, I got a computer<g>,
where to start?  What is a good begining for learning M3?  Any suggestions? 
Tips?  Pitfalls?

Thanks,
Joe


