======================================================================= 1 ===
Date:    2 Jan 93 05:21:38 GMT
From:    ark@alice.att.com (Andrew Koenig)
Subject: demo program crashes the window system?

I just tried installing DEC Modula3 2.07 on my Sparcstation.
It comes with three demo programs that play games.  Two of them
work fine.  The third, `solitaire' builds OK but instantly crashes
the window system (xnews) when I run it.

Has anyone else encountered this?  I'm running SunOS 4.1.1



PS: I know this isn't a language question, but this is the
only newsgroup this machine supports that's relevant at all.
-- 
				--Andrew Koenig
				  ark@europa.att.com


======================================================================= 2 ===
Date:    Mon, 4 Jan 1993 20:13:24 GMT
From:    ege@blitz.fiu.edu (Dr. Raimund K. Ege)
Subject: Call for Participation - TOOLS USA 93


                           TOOLS USA '93

         Technology of Object-Oriented Languages and Systems

          ELEVENTH INTERNATIONAL CONFERENCE AND EXHIBITION

             Santa Barbara, California, August 2-5, 1993

               FIRST ANNOUNCEMENT AND CALL FOR PAPERS

    Program Chair: Raimund Ege, Florida International University
           Panel and Workshop Chair: Madhu Singh, Bellcore
                Conference Chair: Bertrand Meyer, ISE


TOOLS  is  the  major  international  conference   devoted   to   the
applications  of  object-oriented technology.  TOOLS 11 will continue
the commitment to excellence  generated  by  earlier  conferences  in
Europe,  the Pacific and the US.  TOOLS is back for the third time in
Santa Barbara to continue the tradition of a high-level symposium  in
one of the most beautiful places in the world.

TOOLS will  continue  to  apply  the  standards  defined  by  earlier
conferences in the series:

     + Strong emphasis on the practice of object-oriented  technology
       and  its application in industrial environments, complementing
       the  more  academically-oriented  perspective  of  traditional
       conferences.

     + Solid technical program, based on a strict refereeing process.

     + Balanced coverage of the  wealth  of  approaches,  trends  and
       variants in the object-oriented community.

     + Combination of tutorials  by  recognized  experts,  up-to-date
       exhibitions   of  products  and  services,  invited  talks  by
       innovators in  the  field,  relevant  panel  discussions,  and
       technical papers targeted to industry practitioners.

As with previous  conferences,  the  TOOLS  11  Proceedings  will  be
published by Prentice-Hall and made available worldwide.

SUBMITTING A PAPER

TOOLS USA '93 is now soliciting papers  on  all  aspects  of  object-
oriented technology. All submitted papers will be refereed and judged
not only according to standards of  technical  quality  but  also  on
their  usefulness  to  practitioners  and applied researchers. A non-
exhaustive list of suggested topics includes:

     + Migration toward O-O Programming

     + O-O user interfaces

     + Management and training issues.

     + Reports of experiences with O-O technology.

     + Empirical and field studies.

     + Issues in the productions, distribution  and  applications  of
       reusable components of industrial quality.

TOOLS 11 will feature a special  track  on  issues  relating  to  the
migration  from  conventional  to  object-oriented  programming. This
track will include workshop(s),  tutorials,  panel  discussions,  and
featured  speakers.  Technical  papers  are  expressly sought in this
area.

Papers should be  in the  range of 8 to 15  single-spaced  pages. Six
copies  of each submission should be sent to:
     TOOLS USA '93, Attn: Dr. Raimund Ege
     School of Computer Science, Florida International University
     University Park, Miami, FL 33199 USA
     Phone: (305) 348-3381, Fax: (305) 348-3549
     E-mail: ege@scs.fiu.edu
General information  is available  by  e-mail from tools@scs.fiu.edu.
"Guidelines  for  Authors"  are  available  via  anonymous  ftp  from
tools.fiu.edu in file pub/tools-authors-guide.

Proposals for panels and workshops are also solicited and  should  be
sent to the Panel and Workshop Chair:
     Madhu S. Singh, Ph. D.
     Bellcore, RRC 1A 111, 444 Hoes Lane, Piscataway, NJ 08854-4182
     Phone: (908) 699-4366, Fax: (908) 336-2830
     E-mail: msingh@bcr.cc.bellcore.com

Tutorial  proposals  should  be  sent  to the conference organization
committee at the address listed below.

IMPORTANT DATES

All submissions must be received by March 20, 1993 to  be  considered
for  inclusion  in  the conference. Submissions should be in English.
Notification of acceptance will be mailed by April  30,  1993.  Final
manuscripts will be due June 1, 1993.

THE INTERNATIONAL OBJECT-ORIENTED WEEK

Friday, August 6 has  been  set  aside  for  independently  organized
events,  such  as  User Group meetings or standardization committees.
The TOOLS USA '93 organizers will help coordinate such events if they
fall within the scope of object-oriented techniques, and will include
the announcements in the final TOOLS program.  If you are  interested
in setting up such a meeting, please contact the conference chair for
details.

Conference Organization Committee:
     TOOLS USA '93
     P.O. Box 6863
     Santa Barbara, CA 93160
     Phone: (805) 685-1006, Fax: (805) 685-6869
     E-mail: tools@tools.com

For further information complete the coupon below  and send it to the
Conference Organization Committee.

Name,  address,  telephone, fax, E-mail:


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________


/    /  I intend to submit a paper with the following title:


_____________________________________________________________________


/ / Please send me the Guidelines for "Prospective TOOLS Authors".

/ / My company  is  interested  in  exhibiting.  Please  send  me  an
    exhibitor information kit


-- 
Raimund K. Ege                             School of Computer Science
                                             Florida Int'l University
ege@scs.fiu.edu           (305) 348-3381              University Park
ege@servax.bitnet     FAX (305) 348-3549              Miami, FL 33199


======================================================================= 3 ===
Date:    Tue, 5 Jan 1993 06:04:01 GMT
From:    suwandi@fraser.sfu.ca (Julian Suwandi)
Subject: faq?

Hi! I am interested to know more about M-3. Is there any FAQs for this group?
Thanx! :)
-- 
      Julian Suwandi        |  Quotes / Unquote of the week
         643-0827           |      Insanity is hereditary... 
      suwandi@sfu.ca        |      You get it from your kids.


======================================================================= 4 ===
Date:    6 Jan 93 04:50:34 GMT
From:    valery@ra.cs.umb.edu (Valery C)
Subject: Sorry, test

Sorry,  test


======================================================================= 5 ===
Date:    7 Jan 93 22:18:42 GMT
From:    mwalker@novell.com (Mel Walker)
Subject: Where can I get info on Modula-3?

The title says it all. FTP sites are preferable. Thank you.

----------------------------------------------------------------
Mel Walker                                    mwalker@novell.com
All opinions expressed are of the author.
Novell, Inc. is not responsible for the content of this article.


======================================================================= 6 ===
Date:    8 Jan 93 00:09:12 GMT
From:    lpratt@slate.mines.colorado.edu (Lorien Pratt)
Subject: Documentation for modula-3 libraries?

Hi,
  We've recently installed moedula-3 here at Mines and I'm using it in
data structures course.  I am using the Harbison book, which I had presumed
had full syntax, but now I notice that it seems to be missing information
on the various library routines.  I'm trying to put together my first
lecture, and to tell students what Wr.PutText takes as an argument list.
There is no description that I can find that indicates that the first
argument can be a file descriptor like Stdio.stdout.  I wonder if there's
some online documentation that might talk about the interfaces in a bit
more detail?  Or do I need to buy the big modula-3 reference book?
  Thanks for an answer ASAP!
    --Lori
-- 
L. Y. Pratt                           Dept. of Math and Computer Science
lpratt@franklinite.mines.colorado.edu Colorado School of Mines    
(303) 273-3878 (work)                 402 Stratton                
(303) 278-4552 (home)                 Golden, CO 80401, USA      


======================================================================= 7 ===
Date:    Thu, 7 Jan 1993 20:28:56 GMT
From:    papresco@lambert.uwaterloo.ca (Paul Prescod)
Subject: Modula 3&Linux

Has anyone successfully compiled Modula 3 on linux?  We are doing it in
school, so I would like to work at home.

Also: Are there any indepth docs (and/or FAQ) for Modula 3?  I can't
find a book on it to save my life (and couldn't afford it if I could).

Thanks.



======================================================================= 8 ===
Date:    Fri, 8 Jan 1993 10:53:29 GMT
From:    jlruiz@dit.upm.es (Jose Luis Ruiz Sanchez)
Subject: i386?

Hi, I'd like to have Modula 3 running on a 386 machine. Does anybody know if th
ere is any implementation available for SCO or BSD?. It seems that in gatekeepe
r the only 386 version is for AIX386. Could it be possible to port the AIX386 v
ersion to SCO or BSD? Has anybody done it?
Thanks,
Jose L Ruiz.

------------------------
jlruiz@dit.upm.es   


======================================================================= 9 ===
Date:    Fri, 8 Jan 1993 16:55:08 GMT
From:    cflatter@nrao.edu (Chris Flatters)
Subject: Re: i386?

In article 93Jan8115329@chinchon.dit.upm.es, jlruiz@dit.upm.es (Jose Luis Ruiz 
Sanchez) writes:
>Hi, I'd like to have Modula 3 running on a 386 machine. Does anybody
>know if there is any implementation available for SCO or BSD?. It seems
>that in gatekeeper the only 386 version is for AIX386. Could it be
>possible to port the AIX386 version to SCO or BSD? Has anybody done
>it?

It is possible to port SRC Modula 3 to new systems but you need a system that
it already runs on to perform a cross compilation down to C code.  The doc
file gives some sketchy instructions for generating a new port.

I'm still getting my 386BSD system in order after adding some disk space.
After I finish stuffing the new disk with X11 goodies I intend having a
go at Modula 3 (unless someone else does it first, GNU Modula 3 miraculously
appears or I run out of disk or get interested in something else).

	Chris Flatters
	cflatter@nrao.edu




======================================================================= 10 ===
Date:    8 Jan 93 16:33:40 GMT
From:    lpratt@slate.mines.colorado.edu (Lorien Pratt)
Subject: Proper use of interfaces/modules for top-down programming?

Hi,
  I wonder if somebody could answer some questions about, or give me a pointer
to a reference for, how to do proper top-down programming with
modula-3?  I'm teaching this language for a data structures course and
learning it at the same time, and I want to be sure I communicate
whatever is the usual philosophy for modular coding in modula-3.  I have
the Harbison book, but chapter 8 seems to present more legal syntax than
stylistic issues; and the programming conventions chapter doesn't get into
modularity.

  For example, what's the proper way to go about developing a program?
Do you write the Main module, then the interfaces, then try to compile to
check for type consistency, then fill in the modules for the interfaces?
Or do people typically write their interfaces and modules that export them,
before trying to incorporate them into the main procedure?  Is it a good
idea to have multiple procedures per module?  

  Thanks in advance for any help or pointers you can give!
			  --Lori Pratt


-- 
L. Y. Pratt                           Dept. of Math and Computer Science
lpratt@franklinite.mines.colorado.edu Colorado School of Mines    
(303) 273-3878 (work)                 402 Stratton                
(303) 278-4552 (home)                 Golden, CO 80401, USA      


======================================================================= 11 ===
Date:    10 Jan 93 03:15:56 GMT
From:    oliver@extro.ucc.su.OZ.AU (Oliver Bock)
Subject: Has Modula 3 been ported to MIPS Risc/OS?

I'd like to run Modula 3 on a MIPS R4000 running MIPS' RISC/OS with X.  
My porting skills are minimal so can someone tell me which of the ports 
on gatekeeper.dec.com (or elsewhere) is going to be closest to my system?


  Oliver


======================================================================= 12 ===
Date:    10 Jan 93 03:15:56 GMT
From:    oliver@extro.ucc.su.OZ.AU (Oliver Bock)
Subject: Has Modula 3 been ported to MIPS Risc/OS?

I'd like to run Modula 3 on a MIPS R4000 running MIPS' RISC/OS with X.  
My porting skills are minimal so can someone tell me which of the ports 
on gatekeeper.dec.com (or elsewhere) is going to be closest to my system?


  Oliver


======================================================================= 13 ===
Date:    Sun, 10 Jan 93 22:23:57 GMT
From:    cflatter@nrao.edu (Chris Flatters)
Subject: Re: Proper use of interfaces/modules for top-do

In article 12922@slate.mines.colorado.edu, lpratt@slate.mines.colorado.edu (Lor
ien Pratt) writes:
>  I wonder if somebody could answer some questions about, or give me a pointer
>to a reference for, how to do proper top-down programming with
>modula-3?  I'm teaching this language for a data structures course and
>learning it at the same time, and I want to be sure I communicate
>whatever is the usual philosophy for modular coding in modula-3.  I have
>the Harbison book, but chapter 8 seems to present more legal syntax than
>stylistic issues; and the programming conventions chapter doesn't get into
>modularity.
>
>  For example, what's the proper way to go about developing a program?
>Do you write the Main module, then the interfaces, then try to compile to
>check for type consistency, then fill in the modules for the interfaces?
>Or do people typically write their interfaces and modules that export them,
>before trying to incorporate them into the main procedure?  Is it a good
>idea to have multiple procedures per module?  

The common practice in developing a program using a language supporting
modules (be it Modula 3, Modula 2, Ada, Fortran 90 or whatever) is to
determine what data structures will be needed by the program and what
functions act on each data structure.  You then write a module for each
different data structure including the definition of that data structure
and the functions that act upon it: aspects of the data structure that
need not be known in order to use it should be made private to the module
(this minimizes the chances that changing the implementation of the
data structure will require changes in the program that uses it).  Hopefully
you will then have a data structure and its associated functions packaged
in such a way that they can be used in a number of different programs.

	Chris Flatters
	cflatter@nrao.edu


======================================================================= 14 ===
Date:    Mon, 11 Jan 93 21:18:34 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Proper use of interfaces/modules for top-down programming?

There is no single "proper" way to develop a system.  At this level of
detail, writing Modula-3 programs is not much different from writing
Modula-2 programs.  Both languages have separate interfaces and
implementations.

Often each person and project has a different style.  Some design
detailed specs, others jump in and write code.  I would say it's typical
to design the abstractions and interfaces from the top-down.  As soon
as an interface is specified, its implementation can begin.

The new question for Modula-3 programmers is whether an abstraction
should be implemented as a module with exactly one instantiation
or as an object type with multiple instantiations.  So far I don't have
any particularly insightful advice or religious position on the issue.

 - Bill Kalsow



======================================================================= 15 ===
Date:    Mon, 11 Jan 93 19:48:02 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Documentation for modula-3 libraries?


Unfortunately, there isn't a single coherent exposition of the
SRC Modula-3 libraries.  The actual interfaces are often the
best documentation.  There are a few other sources:

  "Systems Programming with Modula-3" edited by Greg Nelson
  describes the required interfaces (Text, Thread, Word, Fmt, and Pkl),
  the basic I/O streams (Rd, Wr, and Stdio), and gives a brief
  overview of the Trestle window system.

  SRC Report #68,  "Trestle Reference Manual" by Mark S. Manasse
  and Greg Nelson, provides a detailed description of the
  Trestle interfaces.  Send e-mail to "src-reports@src.dec.com"
  for a copy.

  The soon-to-be available "FormsVBT Reference Manual" by Marc H.
  Brown and James R. Meehan describes the higher-level FormsVBT
  UI toolkit.

  A small group of here at SRC are working to build a small, portable,
  core collection of interfaces.  Today that set includes sequences,
  atoms, tables, random numbers, times, dates, files, paths, directories
  command-line parameters, and environment variables.  The documentation
  should be available soon.

I hope this helps.

 - Bill Kalsow




======================================================================= 16 ===
Date:    Mon, 11 Jan 1993 18:00:39 GMT
From:    pyeatt@Texaco.com (Larry D. Pyeatt)
Subject: Re: Modula 3&Linux

In article <C0I3K9.5Jz@undergrad.math.waterloo.edu>, papresco@lambert.uwaterloo
.ca (Paul Prescod) writes:
|> Has anyone successfully compiled Modula 3 on linux?  We are doing it in
|> school, so I would like to work at home.

Don't know, but would be interested if anyone has.

|> Also: Are there any indepth docs (and/or FAQ) for Modula 3?  I can't
|> find a book on it to save my life (and couldn't afford it if I could).
|> 
|> Thanks.
|> 

I recommend that you get "Modula-3" by Samuel P. Harbison, 
published by Prentice Hall.  It is well worth the money.


-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.


======================================================================= 17 ===
Date:    Tue, 12 Jan 1993 14:27:36 GMT
From:    dagenais@vlsi (Michel Dagenais)
Subject: Re: Modula 3&Linux


>   Has anyone successfully compiled Modula 3 on linux?  We are doing it in
>   school, so I would like to work at home.

The question of Modula 3 on intel platforms has been discussed in the past.
With the freely available LINUX which can coexist with DOS, the problem
could be solved easily (as compared with trying a port to DOS). Is anyone
working on this by any chance?

>   Also: Are there any indepth docs (and/or FAQ) for Modula 3?  I can't
>   find a book on it to save my life (and couldn't afford it if I could).

On Modula 3 you have the excellent book "Modula-3" from Sam Harbison,
Prentice-Hall. There is a FAQ (gatekeeper.dec.com:pub/DEC/Modula-3/FAQ) and
some documentation bundled with the DEC SRC compiler... and a friendly
newsgroup too :-) .

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

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

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


======================================================================= 18 ===
Date:    Wed, 13 Jan 93 04:05:47 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Trouble with stdin on RS/6000

In article <1993Jan12.172641.40124@slate.mines.colorado.edu>, lpratt@slate.mine
s.colorado.edu (Lorien Pratt) writes:
|> Hi,
|>   I'm trying to write a simple modula-3 program that takes input from the
|> terminal.  Unfortunately, the program doesn't pause to wait for input from
|> stdin; instead it receives an end of file indication.  If I echo the input
|> to the program, however, it does work.  

There is nothing wrong with program and it works on a DECstation, so I would
suspect something is amiss in the RS6000 runtime system. Lets hope an
RS6000 M3 wizard can help.

|> I'd appreciate any pointers for how tell modula-3 to generate code to
|> expect stdin from the terminal.  Thanks!
|> 

For the record, the compiler knows nothing about the input/output system.
Stdio, Rd and Wr are just modules like any other. The Stdio module
arranges, as part of its initialisation code, to connect stdin/stdout/stderr
to the Unix file descriptors of the same name.

Two improvements I would suggest to the program:

1. Stdio.stdout is buffered and, perhaps to your suprise, the buffer is
   not flushed by the '\n' character. You need to call "Wr.Flush(Stdio.stdout)"
   either after each output or before any input requests.

2. I find the concatenation of text literals and text values rather unreadable.
   You can rewrite:

   Write("The sum of " & Fmt.Int(n1) & " And " & Fmt.Int(n2) & " is " &
         Fmt.Int (n1 + n2) & ".\n");

   as:

   Write(Fmt.F("The sum of %s and %s is %s.\n", Fmt.Int(n1), Fmt.Int(n2),
               Fmt.Int (n1 + n2)));

   which is about as close to "printf" as you can get without wiring
   input/output into the compiler.

Mick Jordan
             


======================================================================= 19 ===
Date:    12 Jan 93 17:26:41 GMT
From:    lpratt@slate.mines.colorado.edu (Lorien Pratt)
Subject: Trouble with stdin on RS/6000

Hi,
  I'm trying to write a simple modula-3 program that takes input from the
terminal.  Unfortunately, the program doesn't pause to wait for input from
stdin; instead it receives an end of file indication.  If I echo the input
to the program, however, it does work.  
  Specifically, I've typed in Example 1-8 in Harbison (page 12).  It looks
like this:
----
MODULE WriteSum EXPORTS Main;
IMPORT Wr, Rd, Fmt, Scan, Stdio;
 
PROCEDURE Read(): INTEGER =
  BEGIN
    RETURN Scan.Int( Rd.GetLine(Stdio.stdin));
  END Read;

PROCEDURE Write(t:TEXT) =
  BEGIN
    Wr.PutText(Stdio.stdout, t);
  END Write;

VAR n1, n2: INTEGER;
BEGIN
  Write("Please type two numbers on separate lines:\n");
  n1 := Read();
  n2 := Read();
  Write("The sum of " & Fmt.Int(n1) & " And " & Fmt.Int(n2) & " is " &
Fmt.Int (M^n1 + n2) & ".\n");
END WriteSum.

-----
Now, if I compile this and try to run it, I get the following error
message:
----
a.out
****************** EXCEPTION HANDLER STACK *********************
0x2ff7fa98 TRY-FINALLY  proc = 0x2006daac   frame = 0x2ff7fa8c
0x2ff7fb4c RAISES {}
****************************************************************


***
*** runtime error:
***    Exception "Rd.EndOfFile" not in RAISES list
***

Please type two numbers on separate lines:
Quit(coredump)
----
But if I echo the proper input to the program, it works:
----
echo "1
2" |a.out
Please type two numbers on separate lines:
The sum of 1 And 2 is 3.
----

I'd appreciate any pointers for how tell modula-3 to generate code to
expect stdin from the terminal.  Thanks!

  --Lori




-- 
L. Y. Pratt                           Dept. of Math and Computer Science
lpratt@franklinite.mines.colorado.edu Colorado School of Mines    
(303) 273-3878 (work)                 402 Stratton                
(303) 278-4552 (home)                 Golden, CO 80401, USA      


======================================================================= 20 ===
Date:    13 Jan 93 13:30:31 GMT
From:    buschman@slsvaat.sel.de (Andreas Buschmann US/ESI R.127 Tel.3841)
Subject: Re: Modula 3&Linux

Hello,

i would like to do the port to linux in my spare time, but have to add 
an extra harddisk first. When I used modula3 two years ago I did need 
about 40MBytes of disk space for a complete build (Sun4 version to Sun3, 
and we had to build a special gcc for it).

As I am a bit out of date with modula3 (my diploma thesis was finished 
one and a half year ago) I have some extra questions about it:

  - How much disk space does it need now? (Sun4 -> i368)

  - With which version of the compiler should I start?

  - Did anyone else start with it? experience?


					Tschuess
						Andreas
-- 
#include <stddisclaimer.h>

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

	buschman@us-es.sel.de


======================================================================= 21 ===
Date:    14 Jan 93 01:01:39 GMT
From:    patl@bodacia.Eng.Sun.COM (Pat Lashley)
Subject: Problems building 2.11 on SPARC

I'm trying to build the 2.11 SPARC release.  The bootstrap build
goes fine, and `m3 -\?' works ok, but when I attempt to compile
anything I get:

***
*** runtime error:
***    ASSERT failed
***    file "RTHeap.m3", line 2898
*** 

`pstat -s' reports about 25M availiable before the m3make, so I
don't think I'm running out of memory.

Do any of you have any ideas?



Thanks,
-Pat



---
PMLashley	plashley@Sun.COM    SunSoft:NeWS/TNT
"Those who do not understand NeWS are doomed to recreate it - badly"


======================================================================= 22 ===
Date:    13 Jan 93 17:32:26 GMT
From:    pyeatt@Texaco.com (Larry D. Pyeatt)
Subject: Type conversions

Given the following:

VAR
  a: CARDINAL := 10;
  x: LONGREAL := 10.0d0;
   
BEGIN
  x := x/a;
END;

Why does the compiler have a problem with the  
division, and how do I get around the fact that
a is a cardinal and x is a longreal.  I can't seem
to find an easy way to convert a into a longreal.
I`m sure I am just not seeing something that is
obvious to everyone else.

HELP!

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.


======================================================================= 23 ===
Date:    Thu, 14 Jan 1993 06:05:50 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Re: Type conversions

pyeatt@Texaco.com (Larry D. Pyeatt) writes:

>Given the following:

>VAR
>  a: CARDINAL := 10;
>  x: LONGREAL := 10.0d0;
>   
>BEGIN
>  x := x/a;
>END;

>Why does the compiler have a problem with the  
>division, and how do I get around the fact that
>a is a cardinal and x is a longreal.  I can't seem
>to find an easy way to convert a into a longreal.

It is a type collision. The Float operation "/" requires both its
operands to be of the same type. It also returns a value of that
type. Try this:

MODULE Main;

IMPORT Wr, Stdio, Fmt;

VAR
  a : CARDINAL := 2;
  x : LONGREAL := 10.0d0;

BEGIN
  x := x / FLOAT(a, LONGREAL);
  Wr.PutText(Stdio.stdout, Fmt.LongReal(x) & "\n");
END Main.

The function FLOAT(x, T) returns the value of floating-point type T
closest to value x, which can be both a floating-point or an integer
value.

I strongly recommend getting Sam Harbison's book "Modula-3". The answer
to this question could be found in Sec. 4.6 "Floating-Point Types",
page 81 in my copy.

Torsten
-- 
               kirschnt@informatik.{tu|uni}-muenchen.de


======================================================================= 24 ===
Date:    Thu, 14 Jan 93 17:56:24 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Generating def/use graphs for Modula-3 programs

In article <C0uJD4.MGF@babbage.ece.uc.edu>, dsims@don.ece.uc.edu (David Sims) w
rites:
|> I'm looking for source that builds a definition/use graph for Modula-3
|> programs.  Is anyone aware of such a tool?
|> 
|> Source to a tool that just builds a control flow graph would be helpful
|> too.

No, but you could use the Modula-3 AST toolkit as a starting point. In the
semantically attributed AST, all Modula-3 identifiers are bound to their
definitions. Any node can have additional attributes added easily, so 
you can build your own auxiliary data structures. The toolkit supports
the compilation of multiple interfaces and modules in the same run of
a tool so it is possible, for example, to work on the the set of ASTs
that represent an entire program (assuming that you have enough VM).

The system is available from gatekeeper in the directory:

  /pub/DEC/Modula-3/release/m3tk-2.11.tar.Z

The documentation on the AST itself is reasonable; more is on the way.
There are several example programs that can help you get started.


Mick Jordan


======================================================================= 25 ===
Date:    Thu, 14 Jan 1993 13:41:27 GMT
From:    dsims@don.ece.uc.edu (David Sims)
Subject: Generating def/use graphs for Modula-3 programs

I'm looking for source that builds a definition/use graph for Modula-3
programs.  Is anyone aware of such a tool?

Source to a tool that just builds a control flow graph would be helpful
too.

Thanks in advance.
-- 
David Sims                    Dept. of Electrical and Computer Engineering
david.sims@uc.edu             University of Cincinnati
(513) 556-2499                Cincinnati OH  45221-0030
RIPEM mail accepted.          USA


======================================================================= 26 ===
Date:    14 Jan 93 08:29:39 GMT
From:    vermeulen@rulwinw.LeidenUniv.nl (Hans Vermeulen)
Subject: Modula-3 on HP9000/720?

Hello,

Has Modula-3 been ported to the HP9000/7xx series?
Or is it easy to adapt the HP300 code available on
gatekeeper.dec.com?
Does anybody have a clue?

regards,

Hans Vermeulen
Dept. of Computer Science
Leiden University
P.O. Box 9512
2300 RA  Leiden
The Netherlands


======================================================================= 27 ===
Date:    14 Jan 93 13:22:47 GMT
From:    dsims@don.ece.uc.edu (David Sims)
Subject: Re: Problems building 2.11 on SPARC

A human named patl@bodacia.Eng.Sun.COM wrote:
>I'm trying to build the 2.11 SPARC release.  The bootstrap build
>goes fine, and `m3 -\?' works ok, but when I attempt to compile
>anything I get:
>
>***
>*** runtime error:
>***    ASSERT failed
>***    file "RTHeap.m3", line 2898
>*** 

Me too!  I get the identical error.  I'm running SunOS 4.1.2.

I *really* want to run m3 so any tips or suggestions are greatly
appreciated.
-- 
David Sims                    Dept. of Electrical and Computer Engineering
david.sims@uc.edu             University of Cincinnati
(513) 556-2499                Cincinnati OH  45221-0030
RIPEM mail accepted.          USA


======================================================================= 28 ===
Date:    Thu, 14 Jan 1993 17:13:30 GMT
From:    dsims@thor.ece.uc.edu (David Sims)
Subject: Re: Problems building 2.11 on SPARC

I wrote:
>A human named patl@bodacia.Eng.Sun.COM wrote:
>>I'm trying to build the 2.11 SPARC release.  The bootstrap build
>>goes fine, and `m3 -\?' works ok, but when I attempt to compile
>>anything I get:
>>
>>***
>>*** runtime error:
>>***    ASSERT failed
>>***    file "RTHeap.m3", line 2898
>>*** 
>
>Me too!

I changed the config file for m3make to use gcc instead of /bin/cc.  That
seems to have fixed the problem.
-- 
David Sims                    Dept. of Electrical and Computer Engineering
david.sims@uc.edu             University of Cincinnati
(513) 556-2499                Cincinnati OH  45221-0030
RIPEM mail accepted.          USA


======================================================================= 29 ===
Date:    Thu, 14 Jan 1993 22:46:06 GMT
From:    eduardo@porthos.cs.ua.edu (Eduardo Kortright)
Subject: Zeus/Mentor Problem


Hi there.  I am dabbling with the Zeus algorithm animation package
available from gatekeeper.dec.com.  If anyone out there has used this,
I would appreciate any e-mail that would point me in the right
direction.

Specifically, I have tried to look at the demos in the Mentor package.
Running m3zume on any of them generates the *.i3 and *.m3 files
described in the manpage, but all of them are empty save for the one
comment '(*SYNTAXERROR*)'.  Is there some mechanism in m3zume that at
least hints at what the problem might be?

I assume I'm doing something wrong, since all demos in Mentor give
similar results.  Also, the SRC m3 on my system is version 2.10 while
m3zume and mentor are version 2.11.  Is that a problem?  Our platform
is IBM RS/6000 running AIX 3.1.

If anyone else is interested, I would be willing to relay results
and/or post a summary.  Thanks,
-- 
     ._ 			    //  Eduardo Kortright (eduardo@cs.us.edu)
    /_  ._/ . .  ._   ._ ._/ ._	   //  Grad Student (i.e. Cheap Labor)
   /__ /_/ /_/_ /_/_ /  /_/ /_/   //  University of Alabama at Tuscaloosa


======================================================================= 30 ===
Date:    Fri, 15 Jan 1993 02:08:43 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Re: Modula-3 on HP9000/720?

vermeulen@rulwinw.LeidenUniv.nl (Hans Vermeulen) writes:

>Has Modula-3 been ported to the HP9000/7xx series?

Yes, get the file boot.HPPA-2.11.tar.Z from gatekeeper.dec.com:
/pub/DEC/Modula-3/release. It contains the boot archive for the
"HP Precision Architecture", the 700 series CPUs.

Torsten
-- 
               kirschnt@informatik.{tu|uni}-muenchen.de


======================================================================= 31 ===
Date:    Fri, 15 Jan 93 17:57:26 GMT
From:    jdd@src.dec.com (John DeTreville)
Subject: Re: Problems building 2.11 on SPARC

The first copy of 2.11 that made it to gatekeeper was buggy.  You
might want to re-retrieve and retry.

Cheers,
John



======================================================================= 32 ===
Date:    Sat, 16 Jan 93 00:36:40 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: m3tk-2.11 (Modula-3 AST Toolkit V2.2)

Although the "release" version numbering doesnt suggest it, this
version of the AST toolkit is considerably improved over the "last"
release (2.07). It covers two internal releases and contains
improvements suggested by external and internal users, plus the usual
bug fixes. You can find the details in the files CHANGES.2.1 and
CHANGES.2.2 in the m3tk directory. Here are some highlights:


m3check
-------
The m3check tool has been reworked quite a bit. A major performance
bug in the scanning of the file system for modified files has been
fixed, dramatically shortening the turnround time.  The <*FATAL*> and
<*OBSOLETE*> pragmas are now supported by the warning tool.

m3tk-chartool
-------------
I would like to draw your attention to this tool, substantially
written by Mike Spreitzer of XEROX PARC CSL, that checks code for
dependencies on the fact that CHAR has only 256 elements.  This tool
is included in m3check and m3fe.  Documentation can be found in
m3tk/m3tk-chartool.2.2/doc/CharWarn.{dvi,tex,ps}.


shell-compile
-------------
Although its use is not restricted to m3check, I have included
some gnuemacs lisp code to handle error messages in *shell*
buffers. The idea being that you run m3check under a gnuemacs shell
and process the errors in place. 

How to get m3tk
---------------

The system is in the archive file m3tk-2.11.tar.Z in the Modula-3
release directory on gatekeeper. If you picked it up prior to today
you may have noticed that m3check wouldnt build, owing to a
change in the garbage collector interface. This is now fixed.
The file m3tk-2.11.tar.p1.Z contains the files that changed over
the previous version.

Mick Jordan, January 15th 1993.


======================================================================= 33 ===
Date:    15 Jan 93 16:48:44
From:    d90phj@mamba.DoCS.UU.SE (Pierre T. Hj{lm)
Subject: Re: Modula-3 on HP9000/720?

>>Has Modula-3 been ported to the HP9000/7xx series?
>
>Yes, get the file boot.HPPA-2.11.tar.Z from gatekeeper.dec.com:
>/pub/DEC/Modula-3/release. It contains the boot archive for the
>"HP Precision Architecture", the 700 series CPUs.
>
>Torsten
>-- 
>               kirschnt@informatik.{tu|uni}-muenchen.de

Have you managed to get this to work as it's supposed to?
Especially the thread handling seems to be a bit erronous on the HP
version.
Try tests p005, p006 and p007. I sure didn't get them to work without one
error or another.
You might also try formsedit, which I also failed to get to work (at
all).

If it's just me, I would appreciate if someone could tell me I'm wrong
so I won't waste any effort in trying to solve the problem the hard way.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Pierre Hjalm, Uppsala University Sweden. Email: d90phj@csd.uu.se
 for(i=--k;a[a[k]<a[--i]?a[k]=a[i],i:k]=a[k],i||(i=k--);)f:;if(i)goto f;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


======================================================================= 34 ===
Date:    Sat, 16 Jan 1993 09:55:37 GMT
From:    gandalf@sabrina.dei.unipd.it (ROBERTO AVANZI)
Subject: Re: Sorry, test

The title says all
IS There a M3 compiler, a port of the m3 compiler, for the
macintosh ? I mean MacOS , not A/UX.
Thanks in advance

#  Cheers
#  Roberto Avanzi
#  <gandalf@sabrina.dei.unipd.it>    (ITALY !!!)
#  "Those from Italy send you their greetings" (Hebrews 13:24-NIV)
#           "Wer nicht liebt Wein, Weib und Gesang,
#            der Bleibt ein Narr sein Leben lang." (Martin Luther)
 



======================================================================= 35 ===
Date:    Sun, 17 Jan 93 00:19:03 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: m3tj-2.11.tar.Z corrupt

Owing to a boob on my part, the file on gatekeeper is currently corrrupted.
Please wait for an all clear message before grabbing it.

Mick Jordan


======================================================================= 36 ===
Date:    Sat, 16 Jan 1993 17:46:28 GMT
From:    papresco@cantor.math.uwaterloo.ca (Paul Prescod)
Subject: Modula-3

Thank you to everybody who responded to my questions about Modula-3 in
email and posts.  It's nice to have such a supportive user community.

I really like Modula-3.  It seems like the perfect mix of language
features.  

I've ordered the Harbison book, because I can't get it anywhere around
here.  I've been reading the Nelson book I borrowed from the library.

Just a tip to the designers of modula-3: The language is great, it's
simplicity is just as you planned.  It was a good idea to try and fit
the language definition in 40 pages.  OTOH, it does have a lot of
features, and perhaps a slightly less terse language spec would go a
long way towards making the language achieve the popularity it
deserves.  With only two (or theee) books on Modula-3, some people are
going to be forced to the language definition to learn the language.



======================================================================= 37 ===
Date:    18 Jan 93 06:56:44 GMT
From:    dcm@iris.mincom.oz.au (Doug Merrett)
Subject: Re: IP address

Andrew Wenn (awenn@matilda.vut.edu.au) wrote:
: Could someone please let me know the IP address of gatekeeper.dec.com,
: I had it written down somewhere but cant find it now.

: Thanks.
: Andrew.

The address is 16.1.0.2.

--

Doug Merrett
Internet: dcm@mincom.oz.au


======================================================================= 38 ===
Date:    Sun, 17 Jan 1993 23:43:20 GMT
From:    awenn@matilda.vut.edu.au (Andrew Wenn)
Subject: IP address

Could someone please let me know the IP address of gatekeeper.dec.com,
I had it written down somewhere but cant find it now.

Thanks.

Andrew.


---------------------------------------------------------------------------
Andrew Wenn          Victoria University of Technology
                     Footscray Campus.
                     awenn@matilda.vut.edu.au

                     phone 03 688 4342
                     fax   03 688 4804
---------------------------------------------------------------------------


======================================================================= 39 ===
Date:    Mon, 18 Jan 1993 05:05:47 GMT
From:    gallatin@cobb.cs.rpi.edu (Andrew Gallatin)
Subject: Problems making libm3 on a Sparc


I've been trying to build Modula-3 from the files in
/pub/DEC/Modula-3/release/ (dated Jan 13, 17:10) on gatekeeper.dec.com.
I'm working on a sun sparc, running SunOS 4.1.2

I have followed the instructions given in doc/README of the bootstrap
distribution.

Building boot.SPARC-2.11.tar.Z goes fine, and a call of 'm3 -\?' seems
to give acceptable results. 

The problem occurs when I build libm3-2.11.tar.Z, using
'm3make build_install.all'

The tar file is unpacked, but it dies with the message:
make: Fatal error: Don't know how to make target `/M3Config.m3'

I have tracked this down to libm3/SPARC/.makefile, line 992, where
there is a space in the path" ../config/src /M3Config.m3" I removed
this space, and ran the makefile by hand:

------------
<11:59pm>pleiades/gallatin:SPARC>make -f .makefile PACKAGE=SPARC M3MAKEFILE=../
src/m3makefile all
sed -e 's:PUB:/usr/local/modula3/include/m3:g' -e 's:LIB:/usr/local/modula3/lib
/m3:g'           < ../config/src/M3Config.m3 > M3Config.m3
/usr/local/modula3/bin/m3 -w1 -make -why -nostd -times -g    -a libm3.a -F.PGM_
SOURCES

 seconds  #times  operation
    0.15       2  garbage collection
    1.11          other
---------------------------------------------------
    1.26          TOTAL


Fatal Error: duplicate interface: Ctypes.i3
  ../C/src/SPARC/Ctypes.i3
  ../C/src/generic/Ctypes.i3

*** Error code 255
make: Fatal error: Command failed for target `libm3.a'
-----------

I figure there must be a corrupt sed or awk script somewhere.  Can
anyone give any advice?  Has anybody gotten this version to build on a sparc?

Thanks for any help!

Andrew Gallatin
-- 
   "Early to bed, early to rise, makes a man sleepy and bleary in the eyes"

        Andrew Gallatin                         gallatin@cs.rpi.edu


======================================================================= 40 ===
Date:    Mon, 18 Jan 93 17:12:22 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: m3tk-2.11.tar.Z corrupt

Problem fixed.


======================================================================= 41 ===
Date:    Tue, 19 Jan 93 01:54:48 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Re: WildJmp.i3

In article <1993Jan18.235813.14076@zia.aoc.nrao.edu>, cflatter@nrao.edu (Chris 
Flatters) writes:
|> Well, I'm about to start trying to get SRC Modula 3 up under 386BSD.
|> Looking through the release 2.11 sources, I notice that WildJmp.i3 no
|> longer seems to exist.  Is this correct?

Look in libm3/runtime/src/*/RTThread.i3 to find our infamous friends.

-- 
Eric.



======================================================================= 42 ===
Date:    Mon, 18 Jan 93 23:58:13 GMT
From:    cflatter@nrao.edu (Chris Flatters)
Subject: WildJmp.i3

Well, I'm about to start trying to get SRC Modula 3 up under 386BSD.
Looking through the release 2.11 sources, I notice that WildJmp.i3 no
longer seems to exist.  Is this correct?

	Chris Flatters
	cflatter@nrao.edu


======================================================================= 43 ===
Date:    18 Jan 93 22:14:48 GMT
From:    eduardo@porthos.cs.ua.edu (Eduardo Kortright)
Subject: Zeus on RS/6000


Is there anyone out there running the Zeus animation package on IBM
RS/6000's?  I figure SOMEBODY ported this thing to the RS/6000, so
there has to be at least one person out there . . .

If you exist, and you don't mind answering a few questions about
your installation, please e-mail me:

	eduardo@cs.ua.edu

Thanks.

-- 
     ._ 			    //  Eduardo Kortright (eduardo@cs.us.edu)
    /_  ._/ . .  ._   ._ ._/ ._	   //  Grad Student (i.e. Cheap Labor)
   /__ /_/ /_/_ /_/_ /  /_/ /_/   //  University of Alabama at Tuscaloosa


======================================================================= 44 ===
Date:    Tue, 19 Jan 1993 10:28:05 GMT
From:    viggo@nada.kth.se (Viggo Kann)
Subject: Typos in Harbinson's book

I am using Harbinson's book "Modula-3" in a course in Modula-3 at the Royal
Institute of Technology, Stockholm. I think the book is good, but it is full
of typos. Some of them are trivial but others are very dangerous, for example
the syntax of the REPEAT statement is wrong.

Here is the typos I have found. I would very much like to know if anyone has
found other typos in the book. And how do I communicate my list to the
author?

page and line   text to be replaced             replacement
p 7, l -12	as in the example on page 3	(not true!)
p 9, l  20	REPEAT Stmts UNTIL Expr END	REPEAT Stmts UNTIL Expr
p 20, l  3	Threethousand			3thousand
p 22, l 18	least_value:=MostNegativeNumber	MostNegativeNumber:=least_value
p 31, l -6	Fib				Fac
p 31, l -4	Fib				Fac
p 31, l -3	Fib				Fac
p 32, l  6	VAR n:=n;			VAR n:INTEGER:=n;
p 32, l 17	The type of a named constant is	The type of a named 
                                                constant is always
p 32, l 22	A, B, C, and D			A, B, C, D, and E
p 33, l  8	VAR x:Sub;			(wrong font)
p 33, l 15	b:=c;				b:INTEGER:=c;
p 33, l 16	c:=b;				c:INTEGER:=b;
p 33, l -5	OF REAL;			OF REAL);
p 33, l -4	OF REAL;			OF REAL);
p 40, l 11	Color are assignable		Color is assignable
p 40, l -10	Some the following		Some of the following
p 43, l -4	assignable of N			assignable of n
p 47, l -1	REPEAT Stmts UNTIL Expr END	REPEAT Stmts UNTIL Expr
p 57, l  8	If x is a field of record r	If x is a field of record r 
                                                and r is not READONLY
p 72, l  7	ORD, VALUE			ORD, VAL
p 84, l  7	NTERFACE RealFloat		INTERFACE RealFloat
p 124, l  6	END Sum;			END Add;
p 169, l 28	END IntegerElement.		BEGIN IntegerElement 
                                                END IntegerElement.
p 178, l 13	page 188			page 191
p 214, l 25	END InitPosition;		RETURN self;
                                                END InitPosition;
p 214, l 35	END InitRectangle;		RETURN self;
                                                END InitRectangle;
p 218, l 25	END InitPosition;		RETURN self;
                                                END InitPosition;
p 218, l 32	END InitRectangle;		RETURN self;
                                                END InitRectangle;
p 219, l 30	END InitCircle;			RETURN self;
                                                END InitCircle;
p 234, l  5	94861				94681
p 234, l  6	94863				94683
p 234, l  7	94864				94684
p 244, l 23	END;				RETURN self; END;
p 285, l  7	PROCEDURE Int			PROCEDURE Bool(b: BOOL):Text.T
                                                PROCEDURE Int
p 299, l  4	e. semantic			e. lexical or semantic
p 299, l  6	c. 3				c. 11
p 300, l  6	WITH T=Recs			WITH T=recs
p 300, l  8	a:=y;				b:=y;


Dr Viggo Kann                    E-mail: viggo@nada.kth.se
Theoretical CS                   Fax:    +46 8-790 09 30
NADA, Dept of Numerical Analysis and Computing Science
KTH, Royal Institute of Technology
S-100 44  Stockholm, SWEDEN


======================================================================= 45 ===
Date:    19 Jan 93 01:57:09 GMT
From:    worstell@sirr.eecs.ucdavis.edu (glen)
Subject: m3 on NeXT

The m3-2.11 compiler installed ok on my NeXT (3.0), but libm3 did not.
Anyone had success with this?


======================================================================= 46 ===
Date:    Tue, 19 Jan 1993 13:42:41 GMT
From:    cameron shelley <cpshelle@undergrad.math.uwaterloo.ca>
Subject: Forward: Typos in Harbinson's book

Newsgroups: comp.lang.modula3
Path: undergrad.math.waterloo.edu!watmath!watserv2.uwaterloo.ca!torn!spool.mu.e
du!uunet!mcsun!sunic!kth.se!nada.kth.se!viggo
From: viggo@nada.kth.se (Viggo Kann)
Subject: Typos in Harbinson's book
Message-ID: <1993Jan19.102805.5644@kth.se>
Originator: viggo@byse.nada.kth.se
Sender: usenet@kth.se (Usenet)
Nntp-Posting-Host: byse.nada.kth.se
Reply-To: viggo@nada.kth.se (Viggo Kann)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 19 Jan 1993 10:28:05 GMT
Lines: 65

I am using Harbinson's book "Modula-3" in a course in Modula-3 at the Royal
Institute of Technology, Stockholm. I think the book is good, but it is full
of typos. Some of them are trivial but others are very dangerous, for example
the syntax of the REPEAT statement is wrong.

Here is the typos I have found. I would very much like to know if anyone has
found other typos in the book. And how do I communicate my list to the
author?

page and line   text to be replaced             replacement
p 7, l -12	as in the example on page 3	(not true!)
p 9, l  20	REPEAT Stmts UNTIL Expr END	REPEAT Stmts UNTIL Expr
p 20, l  3	Threethousand			3thousand
p 22, l 18	least_value:=MostNegativeNumber	MostNegativeNumber:=least_value
p 31, l -6	Fib				Fac
p 31, l -4	Fib				Fac
p 31, l -3	Fib				Fac
p 32, l  6	VAR n:=n;			VAR n:INTEGER:=n;
p 32, l 17	The type of a named constant is	The type of a named 
                                                constant is always
p 32, l 22	A, B, C, and D			A, B, C, D, and E
p 33, l  8	VAR x:Sub;			(wrong font)
p 33, l 15	b:=c;				b:INTEGER:=c;
p 33, l 16	c:=b;				c:INTEGER:=b;
p 33, l -5	OF REAL;			OF REAL);
p 33, l -4	OF REAL;			OF REAL);
p 40, l 11	Color are assignable		Color is assignable
p 40, l -10	Some the following		Some of the following
p 43, l -4	assignable of N			assignable of n
p 47, l -1	REPEAT Stmts UNTIL Expr END	REPEAT Stmts UNTIL Expr
p 57, l  8	If x is a field of record r	If x is a field of record r 
                                                and r is not READONLY
p 72, l  7	ORD, VALUE			ORD, VAL
p 84, l  7	NTERFACE RealFloat		INTERFACE RealFloat
p 124, l  6	END Sum;			END Add;
p 169, l 28	END IntegerElement.		BEGIN IntegerElement 
                                                END IntegerElement.
p 178, l 13	page 188			page 191
p 214, l 25	END InitPosition;		RETURN self;
                                                END InitPosition;
p 214, l 35	END InitRectangle;		RETURN self;
                                                END InitRectangle;
p 218, l 25	END InitPosition;		RETURN self;
                                                END InitPosition;
p 218, l 32	END InitRectangle;		RETURN self;
                                                END InitRectangle;
p 219, l 30	END InitCircle;			RETURN self;
                                                END InitCircle;
p 234, l  5	94861				94681
p 234, l  6	94863				94683
p 234, l  7	94864				94684
p 244, l 23	END;				RETURN self; END;
p 285, l  7	PROCEDURE Int			PROCEDURE Bool(b: BOOL):Text.T
                                                PROCEDURE Int
p 299, l  4	e. semantic			e. lexical or semantic
p 299, l  6	c. 3				c. 11
p 300, l  6	WITH T=Recs			WITH T=recs
p 300, l  8	a:=y;				b:=y;


Dr Viggo Kann                    E-mail: viggo@nada.kth.se
Theoretical CS                   Fax:    +46 8-790 09 30
NADA, Dept of Numerical Analysis and Computing Science
KTH, Royal Institute of Technology
S-100 44  Stockholm, SWEDEN

</dev/cam
--
      Cameron Shelley        |"In the beginning, there was nothing.  Then
cpshelle@napier.uwaterloo.ca | God said `Let there be light', and there
   Math & Computer Rm 1014   | was still nothing, but youse could see it."
 Phone (519) 885-1211 x6827  | --Dave Thomas, SCTV:_Sunrise Semester_


======================================================================= 47 ===
Date:    Tue, 19 Jan 93 14:36:35 CST
From:    shri@sol.acs.unt.edu (Shrinand "shri" Desai)
Subject: Re: WildJmp.i3

Hi Eric,
I heard that someone had done a port of M3 on IBM-PC, do you
know about it?

Thanks.

--Shri
 
-- 
Shrinand Desai           | 
shri@sol.acs.unt.edu     | If I don't care where I am, I ain't lost.   
or shri@vaxb.acs.unt.edu |  





======================================================================= 48 ===
Date:    Tue, 19 Jan 1993 19:58:26 GMT
From:    rhoover@watson.ibm.com (Roger Hoover)
Subject: <*EXTERNAL*> Bug?


I have an external procedure that takes a record and returns a
record.  If I create a file Defs.i3:
INTERFACE Defs;

TYPE
  Rec = RECORD
    a : INTEGER;
    b : INTEGER;
  END;

<*EXTERNAL*>PROCEDURE foo(o : Rec) : Rec;

END Defs.

And another file otest.m3:
MODULE otest EXPORTS Main;

IMPORT Defs;

VAR x,y: Defs.Rec;

BEGIN
  x.a := 1; x.b := 2;
  y := Defs.foo(x)
END otest.

I get a generated file otest.mc that contains:
   foo (otest__x, &_z2);  otest__y = _z2;

Is this a bug?  Shouldn't the <*EXTERNAL*> declaration keep the
compiler from passing the return value as a VAR parameter?  (I'm
using 2.08 if it makes any difference.)

roger hoover
rhoover@watson.ibm.com


======================================================================= 49 ===
Date:    Tue, 19 Jan 1993 19:57:07 GMT
From:    rhoover@watson.ibm.com (Roger Hoover)
Subject: Re: Trouble with stdin on RS/6000

lpratt@slate.mines.colorado.edu writes:
>Hi,
>  I'm trying to write a simple modula-3 program that takes input from the
>terminal.  Unfortunately, the program doesn't pause to wait for input from
>stdin; instead it receives an end of file indication.  If I echo the input
>to the program, however, it does work.  

The problem with the RS/6000 is that its read() system call is
of the system V type, where O_NDELAY mode to a terminal with no data
is indistinguishable from EOF.  This is corrected (on the RS/6000)
by using the posix O_NONBLOCK mode, which has the desired
return code of -1 if no characters are available.

Thus, the fix is in the file libm3/rw/src/UFileRd.m3:

PROCEDURE TerminalSeek (rd: TerminalReader; dontBlock: BOOLEAN): RdClass.SeekRe
sult
   RAISES {Rd.Failure, Thread.Alerted} =

  VAR
    status: INTEGER;
    readFDSet, errorFDSet := Unix.FDSet {rd.targetFD};
    old_mode := Unix.fcntl (rd.targetFD, Unix.F_GETFL, 0);
    new_mode := Word.Or (old_mode, Unix.O_NONBLOCK);
                                   ^^^^^^^^^^^^^^^ 
                                   change from O_NDELAY

roger

ps to Bill and Eric:  This is supposed to be machine independent
code.  What is the best way to get this fix to work with the other
architectures?



======================================================================= 50 ===
Date:    19 Jan 93 12:13:42 +1000
From:    manning@cssun3.vassar.edu (Joseph Manning)
Subject: Re: Typos in Harbinson's book

In addition to Viggo Kann's list, here are some further typos which I found
in Sam Harbison's otherwise excellent book "Modula-3":

page and line  text to be replaced             replacement

p 142, l 4     Divsr                           divisor
p 195, l -7    fill with gas                   add gas
p 198, l -17   END SetBirthDate;               END New;
p 211, l 20    in a new variable a             in a new variable square
p 280, l 12    UnGetChar(rd: T; c: CHAR)       UnGetChar(rd: T)

Joseph Manning - Computer Science - Vassar College - manning@vassar.edu


======================================================================= 51 ===
Date:    20 Jan 93 02:44:07 GMT
From:    aobrodsk@undergrad.math.waterloo.edu (Alex Brodsky)
Subject: The C version of the source for modula-3

Does anyone know where I can get the C source code to a modula-3 compiler and/
or converter (Mod3 to C).  I have acquired the modula-3 source code to a modula
-3 compiler, however that is slightly useless since I cannot compile it.

ttyl
Alex


======================================================================= 52 ===
Date:    Thu, 21 Jan 1993 06:52:17 GMT
From:    awenn@matilda.vut.edu.au (Andrew Wenn)
Subject: Modula3 and DOS

Dear modula3 users,

Can anyone tell me if there is a DOS version of modula3 available? Prefer
a PD one but any would do.

Andrew Wenn.


---------------------------------------------------------------------------
Andrew Wenn          Victoria University of Technology
                     Footscray Campus.
                     awenn@matilda.vut.edu.au

                     phone 03 688 4342
                     fax   03 688 4804
---------------------------------------------------------------------------


======================================================================= 53 ===
Date:    Fri, 22 Jan 1993 08:57:02 GMT
From:    babraham@unpcs1.cs.unp.ac.za (Bobby Abraham)
Subject: 1st Southern African Computer Programming Competition

 #####                           #####
#     #   ####   #    #  #####  #     #   ####   #    #  #####
#        #    #  ##  ##  #    # #        #    #  ##  ##  #    #
#        #    #  # ## #  #    # #        #    #  # ## #  #    #
#        #    #  #    #  #####  #        #    #  #    #  #####
#     #  #    #  #    #  #      #     #  #    #  #    #  #
 #####    ####   #    #  #       #####    ####   #    #  #

                 ###    #####   #####
                 ###   #     # #     #
                  #    #     #       #
                 #      ######  #####
                             #       #
                       #     # #     #
                        #####   #####

This is an updated preliminary announcement for the upcoming computer
programming competition on the 18 March 1993.  This competition is
organised by the Computer Science Department, University of Natal in
Pietermaritzburg.

Who may Enter?

Teams from any Southern African university composed of four students,
provided that each team may contain at most one student studying at higher
than Honours level.  We expect most teams to consist of 3rd year and honours
students.  It is also a requirement that each team has internet access as
questions are sent and solutions received via email.

The Nature of the Competition.

It is hoped that this competition will attract computer science and
business computing students.  For this reason there is no restriction
on the tools used during the competition.  For assesment purposes all
solutions will be required to be executable files for a PC running
MSDOS.  Should some sort of environment be required for running
submitted programs, contact the organisers as we may be prepared to
make some sort of arrangement.  The questions will cover a wide area
with some favouring business computer science students and others
favouring the computer science students.  It is not expected that all
questions will be answered during the allocated six hours.

As soon as a team has solved any of the questions, they will submit
their solution either via email or ftp.  Points will be awarded for
each solution according to the time of submission.  Programs will be
required to match specification exactly.  Any program which does not
will not count.  It will start at 16h00 and no solution will be
accepted after 22h00.

The SIGCSE bulletin, vol 24 No. 2 1992 contains the questions asked
during the 1991 ACM Scholastic Programming Contest Finals.
Participants can expect questions of a similar standard.

What can one win?

Prizes will not be substantial.  We are hoping to be able to
offer a R400 prize to the winning team as an incentive.  However,
we believe that going down in history as participants (let alone
winners) of the first ever CompComp competition should be enough
to get the adrenaline pumping and those programming brains into
gear!

How does one enter?

It is required that each participating university nominate a staff
member to act as coordinator.  Multiple teams may be entered.  Entry
forms or requests for further information can be obtained from the
following email address.

        compcomp@unpcs1.cs.unp.ac.za
-------------------------------------------------------------------
Bobby Abraham
Dept. of Computer Science
University of Natal, Pietermaritzburg
email - babraham@unpcs1.cs.unp.ac.za
        abraham@unpsun1.cc.unp.ac.za
-------------------------------------------------------------------


======================================================================= 54 ===
Date:    Sat, 23 Jan 1993 21:20:41 GMT
From:    papresco@napier.uwaterloo.ca (Paul Prescod)
Subject: references, objects & m3

I'm using modula-3, and I like it.  I've found one thing I can't seem
to get around.

I've got an _Insert_Bin_Tree function, which inserts "Sortable" objects
into a binary tree.

I've got "Sortable_Sub" which is a subtype of the sortable object.

The problem is, _Insert_Bin_Tree only takes REFERENCES to Sortable
objects.  It seems like the REFERENCE to a Sortable_Sub is not a
subtype of the reference to Sortable.  Therefore, I can't use narrow.

How can I call _Insert_Bin_Tree then?  I've modified _Insert_Bin_Tree,
but I won't always be able to do that in the future.

Is the only way around it to declare the module unsafe and use the ADR
operator?

Thanks in advance for any help.



======================================================================= 55 ===
Date:    Sun, 24 Jan 1993 18:43:58 GMT
From:    gallatin@dimaggio.cs.rpi.edu (Andrew Gallatin)
Subject: cpp / fisheye


A while back I posted with a problem I was having building libm3 on a
sparc.  The make would die with the message:
 make: Fatal error: Don't know how to make target `/M3Config.m3'

The problem turned out to be caused by setting CPP to gnu's cpp in the
initial config file.  (Which I did because people were recommending
building with gcc, so I figured I would use gnu cpp as well)  Changing
this to Sun cpp solved this problem, and I was able to build the package.

I was wondering if anybody knew the status of the fisheye package?
(Ie, if/when it will be fixed to run with the current version of m3?) Its
the real reason that I started to build modula-3.  Does anybody know
of any working sparc binaries that I could obtain?  Unfortunately, I
don't have access to a mips machine..

Thanks for any help!

Andrew
-- 
   "Early to bed, early to rise, makes a man sleepy and bleary in the eyes"

        Andrew Gallatin                         gallatin@cs.rpi.edu


======================================================================= 56 ===
Date:    24 Jan 93 16:52:42 GMT
From:    sullivan@teal.csn.org (Steve Sullivan)
Subject: structural equivalence ==> no referential transparency


In Modula 3, arrays lose all index info when passed to a subprocedure.
For example, an array dimensioned [1:10] becomes [0:9] in a called proc.

This is a real lack of referential transparency:
vec[1] means different things, depending on which proc it appears in.
If a caller passed an array and an index value of some element
to a subproc, the index value would be invalid in the subproc.
For example:

Main proc:
 avec: ARRAY {1..100} OF LONGREAL;
 ...
 x = subproc( avec, k);

subproc( avec, k):
  v = avec[k]         (* will access element k+1 *) 

Although Modula 3 does have FIRST and LAST functions, they
seem more like afterthoughts than features:  even if the
above subproc were coded   v = avec[FIRST(avec)-1+k],
the subproc must still know the base of avec (hardcoded as "1").
And in any event "avec[FIRST(avec)-1+k]"
is far less clear to the reader than  "avec[k]".

I don't know, but I assume the designers did this:
  1. To further the "structural equivalence" concept:
     that all arrays of reals are identical, whether the indices
     of the arrays ints, or an enumerated set.
  2. To avoid headaches in dealing with enumerated index sets.

However, for me their decision
not only invalidates all use of enumerated index sets (they
can't be used in subprocs), but destroys the usefulness of
subprocs for handling arrays of any sort.

A better approach, in my mind,
would have been to store a pointer to the definition
of the enumeration with each array whose index set is drawn from it.
That way they would main referential transparency.

Does anyone know why the Modula 3 designers created such
an unwieldy definition for array handling?  Is there any
thought of changing it?

Steve Sullivan
Grad Student, Dept Computer Science, Univ Colorado Boulder
sullivan@csn.org


======================================================================= 57 ===
Date:    24 Jan 93 21:41:46 GMT
From:    moss@cs.cmu.edu (Eliot Moss)
Subject: Re: references, objects & m3

I don't understand why you're using REF OBJECT ... END instead of just OBJECT
... END. The latter is implementation essentially as REF RECORD ... END, but
with the additional semantics of OBJECT method invocation, subtyping, etc. You
should probably just delete the level of REF in your binary tree stuff. Maybe
you want somehting like this:

	TYPE Node = RECORD
	              This       : Sortable;
		      Left, Right: REF Node;
		    END;

You are quite right in noting that REF S is not a subtype of REF T, even when
S is a subtype of T. Adding such subtyping rules to the language has various
undesirable consequences, mainly in complexity, though one may be able to come
up with type systems in which such subtyping judgements would be sound. See
the section of the Nelson book "How the Language Got Its Spots" for further
discussion of rationale for the subtyping rules.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu


======================================================================= 58 ===
Date:    Sun, 24 Jan 93 16:46:52 -0800
From:    heydon@src.dec.com
Subject: Re: structural equivalence ==> no referential transparency

Steve Sullivan (sullivan@teal.csn.org) writes:

> Main proc:
>  avec: ARRAY {1..100} OF LONGREAL;
>  ...
>  x = subproc( avec, k);
>
> subproc( avec, k):
>   v = avec[k]         (* will access element k+1 *) 
>
> Although Modula 3 does have FIRST and LAST functions, they
> seem more like afterthoughts than features:  even if the
> above subproc were coded   v = avec[FIRST(avec)-1+k],
> the subproc must still know the base of avec (hardcoded as "1").
> And in any event "avec[FIRST(avec)-1+k]"
> is far less clear to the reader than  "avec[k]".

Modula-3 makes a distinction between *fixed* an *open* arrays. A 
fixed array declaration includes an index type, while an open array 
declaration does not. The index type of an open array is [0..n-1], 
where "n" is the run-time length of the array, so the first element 
has index 0. You left out the type declarations for the "avec" and 
"k" formal parameters to the "subproc" procedure in your example, 
but I'm guessing that you meant for "avec" to be declared as an open 
array like this (I've changed the names of the variables in "subproc" 
to avoid confusion): 

  VAR
    avec: ARRAY [1..100] OF LONGREAL;
    k: [1..100];
    x: LONGREAL;

  PROCEDURE subproc(avec2: ARRAY OF LONGREAL; j: CARDINAL): LONGREAL =
    VAR v: LONGREAL; BEGIN
      v := avec2[j];
      RETURN v
    END subproc;

  BEGIN
    x := subproc(avec, k)
  END Main.

As Steve points out, this code will assign "x" the value "avec[k+1]". 
The problem is that he has not given a specification for "subproc". 
If he did, it would state that "subproc" returns the value of "avec2" 
at zero-based index "j". Therefore, to use the procedure correctly, 
we must convert the actual argument "k" to a zero-based index in 
the main body, like this: 

  BEGIN
    x := subproc(avec, k - FIRST(avec))
  END Main.

There is no way we can get around forcing such a conversion, since 
the actual parameter "avec" and the formal parameter "avec2" have 
different types. 

> However, for me their decision
> not only invalidates all use of enumerated index sets (they
> can't be used in subprocs), but destroys the usefulness of
> subprocs for handling arrays of any sort.

Formal array arguments may certainly be fixed. For example, if we 
had instead given the following signature to "subproc", in which 
the array argument is a fixed array: 

  PROCEDURE subproc(avec2: ARRAY [1..100] OF LONGREAL; j: CARDINAL):
      LONGREAL =
    VAR v: LONGREAL; BEGIN
      v := avec2[j];
      RETURN v
    END subproc;

then the arrays "avec" and "avec2" would have the same type, and 
so we would not need to convert the index argument "k" in the call 
to "subproc" by subtracting "FIRST(avec)". The limitation to using 
fixed arrays as formal procedure arguments is that such procedures 
can only be called with arrays of the specified length (or shape, 
for multi-dimensional fixed arrays). 

See pgs 14-15 of Systems Programming with Modula-3 (SPwM3) for definitions 
of fixed and open arrays; pg 24 for a definition of when one array 
type is a subtype of another; and pg 26 for when one array type is 
assignable to another. It is interesting to note that two one-dimensional 
fixed arrays are subtypes of each other if they have the same base 
type and the *number* of elements in their respective index types 
are the same.

Allan Heydon					heydon@src.dec.com
DEC Systems Research Center			(415) 853-2142
130 Lytton Ave.
Palo Alto, CA 94301


======================================================================= 59 ===
Date:    Mon, 25 Jan 1993 03:00:07 GMT
From:    papresco@undergrad.math.waterloo.edu (Paul Prescod)
Subject: Re: references, objects & m3

In article <MOSS.93Jan24164146@CRAFTY.cs.cmu.edu> moss@cs.cmu.edu writes:
>I don't understand why you're using REF OBJECT ... END instead of just OBJECT
>... END. The latter is implementation essentially as REF RECORD ... END, but
>with the additional semantics of OBJECT method invocation, subtyping, etc. You
>should probably just delete the level of REF in your binary tree stuff. Maybe
>you want somehting like this:

Thanks for your help.  Someone else pointed out to me that objects ARE
references.

I'm not sure if I like that.  For instance, how do I copy an object?
The copy will point to the same data fields, right?  

Also is there anyway to auto-initialize/auto-destroy objects as in C++
with constructors and destructors?



======================================================================= 60 ===
Date:    25 Jan 93 14:28:56 GMT
From:    rhoover@watson.ibm.com (Roger Hoover)
Subject: generics that use generics


I'd like to write a generic that extends another generic.  For
example, consider the generic List:

--
GENERIC INTERFACE List(El);

TYPE T <: REFANY;

PROCEDURE RemoveFirst(VAR l: T): El.T;
PROCEDURE InsertFirst(VAR l: T, x: El.T);

END List.

--
GENERIC MODULE List(El);

REVEAL
  T = BRANDED OBJECT
    el: El.T;
    next: T := NIL;
  END;

PROCEDURE RemoveFirst(VAR l: T): El.T =
VAR r: El.T;
BEGIN
  <*ASSERT l # NIL*>
  r := l.el
  l := l.next;
  RETURN r
END RemoveFirst;

PROCEDURE InsertFirst(VAR l: T, x: El.T) =
BEGIN
  l := NEW(T, el := x, next := l)
END InsertFirst;

END List.

--
I'd like to create a generic Stack that uses List:
GENERIC INTERFACE Stack(El);

TYPE T <: REFANY;

PROCEDURE Pop(VAR l: T): El.T;
PROCEDURE Push(VAR l: T, x: El.T);

END Stack.

Is there any way to write GENERIC MODULE Stack(El) using the
List.RemoveFirst procedure for Pop and ListInsertFirst for
Push?

roger
rhoover@watson.ibm.com


======================================================================= 61 ===
Date:    25 Jan 93 12:42:45 GMT
From:    grlw1@cus.cam.ac.uk (G.R.L. Walker)
Subject: Symbolic Expressions

In the 2.11 Modula-3 libraries, the Sx.i3 file refers to (section 3.1)
'SxSyntax.DefineCurly' for adding functionality to Sx things.
But there seems to be no such thing any more.
What happened to it? Is there any easy way to replace it's functionality?

-- Rich!
If not voting could change anything,
would it still be legal?


======================================================================= 62 ===
Date:    25 Jan 93 13:56:01 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: references, objects & m3

In article <C1E30F.vx@undergrad.math.waterloo.edu> papresco@undergrad.math.wate
rloo.edu (Paul Prescod) writes:

   In article <MOSS.93Jan24164146@CRAFTY.cs.cmu.edu> moss@cs.cmu.edu writes:

   >I don't understand why you're using REF OBJECT ... END instead of
   >just OBJECT ... END. The latter is implementation essentially as
   >REF RECORD ... END, but with the additional semantics of OBJECT
   >method invocation, subtyping, etc. You should probably just delete
   >the level of REF in your binary tree stuff. Maybe you want
   >somehting like this:

   Thanks for your help.  Someone else pointed out to me that objects ARE
   references.

   I'm not sure if I like that.  For instance, how do I copy an object?
   The copy will point to the same data fields, right?  

I wonder why do you need to copy objects. I know that copying objects
is pretty usual in C++ programming: since there is no garbage
collection, programmers copy object _contents_ (and not object
_references_) to reduce sharing within the "object graph". This way
the source pointer can be disposed without worrying about who else
references the object. Modula-3 has grabage collection, so you seldom
have to copy objects.

   Also is there anyway to auto-initialize/auto-destroy objects as in C++
   with constructors and destructors?

Not really (except for static initializations).  This is a matter of
religeous war among Modula-3 purists and people with C++ orientation.
I hope that I won't be starting a war-thread on this subject, when I
say that:

- Because of garbage collection, destructors are not as crucial in
  Modula-3 programming. (What do you usually do in a destructor in
  C++?)

- Constructor-like procedures can be created by doing:

  MODULE Foo;

  TYPE T = OBJECT val: INTEGER := -1 END;

  PROCEDURE New (val: INTEGER): T =
  BEGIN
    RETURN NEW (T, val := val);
  END New;
  
  BEGIN
  END Foo.

The "New" procedure can be exported to other modules.

Another way to achieve the same thing is to have:

  MODULE Foo;

  TYPE T = OBJECT val: INTEGER; METHODS init (val:INTEGER): T := Init; END;

  PROCEDURE Init (self: T; val: INTEGER): T =
  BEGIN
    self.val := val;
    RETURN self;
  END Init;

  BEGIN
  END Foo.


Now you can do something like:
   
  VAR t := NEW (Foo.T).init(20);

or if you want to subclass T, you can do

  TYPE 
    S = Foo.T OBJECT 
      name: TEXT; 
    OVERRIDES 
      init (val: INTEGER; name: TEXT) := Init;
    END;

  PROCEDURE Init (self: S; val: INTEGER; name: TEXT) = 
  BEGIN
    Foo.T.init (self);   (* call init of the superclass *)
    self.name := name;
  END Init;

    
Yes, this is not exactly a constructor, and no, there are no public
plans to add constructors and destructors (or anything else for that
matter ;-) to Modula-3.

Hope this helps.

--farshad

Disclaimer: enclosed code has not been compiled.

--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 63 ===
Date:    Mon, 25 Jan 1993 19:17:26 GMT
From:    jredford@shearson.com (John Redford)
Subject: Re: references, objects & m3

In article <FN00.93Jan25085601@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) wri
tes:

   In article <C1E30F.vx@undergrad.math.waterloo.edu> papresco@undergrad.math.w
aterloo.edu (Paul Prescod) writes:

[STUFF DELETED]


      Also is there anyway to auto-initialize/auto-destroy objects as in C++
      with constructors and destructors?

   Not really (except for static initializations).  This is a matter of
   religeous war among Modula-3 purists and people with C++ orientation.

I have been looking at the WeakRef interface. It would appear at first
reading that this would provide a destructor-like functionality. I
cant tell for sure if it would work with objects, but it would seem
likely.

--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford@shearson.com     | 5 cans of Scotchguard.


======================================================================= 64 ===
Date:    25 Jan 93 19:35:20 GMT
From:    ark@alice.att.com (Andrew Koenig)
Subject: Re: references, objects & m3

In article <FN00.93Jan25085601@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) wri
tes:

> - Because of garbage collection, destructors are not as crucial in
>   Modula-3 programming. (What do you usually do in a destructor in
>   C++?)

If C++ had garbage collection, destructors would sometimes still be
useful.  For example, if I have an object that represents a window in
my window system, I really do want the window to go away as soon as
the object is no longer in use, rather than waiting around for the
next garbage collection.  A similar argument applies to flushing the
buffer of an I/O library structure as soon as possible.
-- 
				--Andrew Koenig
				  ark@europa.att.com


======================================================================= 65 ===
Date:    Mon, 25 Jan 1993 22:57:33 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Harbison errata list

A formatted list of all the errors I know about as of this posting
in Harbison's ``MODULA-3'' text is available via anonymous ftp from 
beethoven.cs.colostate.edu (129.82.102.83), in the file 

  ~ftp/pub/M3/harbison-errs.ps.Z.

The list currently has 96 entries ranging from changing typeface
to the replacement of most of page 75.

I'd appreciate contributions of additional errors to keep this list
up-to-date.  Thanks for your help.


|--------------------------------------------------------------|
| Rod Oldehoeft                    Email: rro@cs.colostate.edu |
| Computer Science Department      Voice: 303/491-5792         |
| Colorado State University        Fax:   303/491-6639         |
| Fort Collins, CO  80523                                      |
|--------------------------------------------------------------|
| I pay the price, but do not count the cost.                  |
|                            John Barth, "The Tidewater Tales" |
|--------------------------------------------------------------|


======================================================================= 66 ===
Date:    25 Jan 93 22:00:41 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: references, objects & m3

>>>>> On 25 Jan 93 19:35:20 GMT, ark@alice.att.com (Andrew Koenig) said:
AK> Article-I.D.: alice.24699

AK> In article <FN00.93Jan25085601@tahoe.gte.com> fn00@gte.com (Farshad Nayeri)
 writes:

> - Because of garbage collection, destructors are not as crucial in
>   Modula-3 programming. (What do you usually do in a destructor in
>   C++?)

AK> If C++ had garbage collection, destructors would sometimes still be
AK> useful.  For example, if I have an object that represents a window in
AK> my window system, I really do want the window to go away as soon as
AK> the object is no longer in use, rather than waiting around for the
AK> next garbage collection.  A similar argument applies to flushing the
AK> buffer of an I/O library structure as soon as possible.

True, see Barry Hayes's survey paper "Finalization ion the Collector
Interface" in the last International Workshop on Memory Management (Springer
Verlag LNCS 637) for a discussion of the issues.

One advantage M3 has over some of the other languages that have GC and want
finalization is that M3 has threads. This means that once the semantics of
what should be finalized is worked out the semantics of when are simple.  I
suspect that registering objects for finalization might be the easiest
semantic for determining what objects should be finalized. This could be
accomplished by passing the object to some system REGISTER_TO_FINALIZE
routine. When the GC discovers such a registered object is no longer
accessible, it passes the object to the finalization thread for finalization
sometime in the future.  Notice that finalization doesn't actually DISPOSE of
the memory used by the object it just performs actions like flushing buffers
and closing files. The GC will dispose of the memory. This solves the problem
of whether a finalization routine can resurrect an object, it can and it could
even register the object to be finalized again.

This leaves only one issue to wrap up and that is the order that linked
objects are finalized. One would not like to close a file prior to flushing
the IO buffer for example. I once thought that objects should be finalized in
reverse order of creation since this seems to follow C++ and Ada 9X
conventions. Recently, I have come to believe that this will put undo
restrictions on some GC schemes. Someone (Greg Nelson??) suggested that
one way around these restrictions is to not finalize objects that are linked.
Data structures that hold information needed for finalization would have to be
hung off of any objects that form a circularity. In other words there could be
no path from one finalizable object to another finalizable object. This seemed
like a very simple solution that would require very little rethinking of data
structures on the programmers part.

--

       Richard L. Hudson  -  Hudson@cs.umass.edu; (413) 545-1220; 
       Advanced Languages Project - University Computing Services
       Lederle Graduate Research Center
       University of Massachusetts             Amherst, MA  01003
       "Unix and C are the ultimate computer viruses." - R. Gabriel


======================================================================= 67 ===
Date:    Mon, 25 Jan 93 22:16:43 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: m3tk update (missing chartool doc)

Regrettably I had omitted to include the advertised "doc" subdirectory
in the CHAR analysis tool. I have now updated the archive to include it,
plus a couple of late breaking bug fixes.  The updated files alone
can be acquired by getting the update archive "m3tk-2.11.tar.p2.Z".

Mick Jordan


======================================================================= 68 ===
Date:    25 Jan 93 23:02:39 GMT
From:    grenzelm@slate.mines.colorado.edu (RENZELMAN GREGORY DO)
Subject: What is the representation of Text?

I am taking a computer course at the Colorado School of Mines, which is using
modula3 as the programming language.  I'm interested in how the computer
represents the data type TEXT.  Is it similar to C where there is a null
terminator?  This information would be helpful because I will have to write 
code that parses TEXT.  Thankyou for your time.

Greg Renzelman


======================================================================= 69 ===
Date:    26 Jan 93 12:21:03 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: What is the representation of Text?


In article <1993Jan25.230239.45587@slate.mines.colorado.edu> grenzelm@slate.min
es.colorado.edu (RENZELMAN GREGORY DO) writes:

   I am taking a computer course at the Colorado School of Mines,
   which is using modula3 as the programming language.  I'm interested
   in how the computer represents the data type TEXT.  Is it similar
   to C where there is a null terminator?  This information would be
   helpful because I will have to write code that parses TEXT.
   Thankyou for your time.

I think the whole point is that you *shouldn't* need to know how
Modula represents TEXT. Commmon operations on texts are in the "Text"
interface. If you _really_ want to know what the representation is,
try the "TextF" interface.

You may want to take a look at "Modula-3" by Sam Harbison; I am sure
he explains how to work with TEXTs.

--farshad

--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 70 ===
Date:    Tue, 26 Jan 93 00:13:52 GMT
From:    cflatter@nrao.edu (Chris Flatters)
Subject: m3make relies on obsolete shell feature

Make files (.makefile) constructed by m3make from the SRC Modula 3 distribution
contain rules like the following.

c.o:
	IFS=' $(SEP)'; $(PASS1) -c $(BOOTOPT) $<
s.o:
	IFS=' $(SEP)'; $(PASS1) -c $(BOOTOPT) $<


These cause commands similar to the following to be passed to the shell

IFS=' @'; @cc@ -c .... $<

This will not work unless IFS is used for splitting all fields.  This
is traditionally the case for the Bourne shell but is not the case for
the POSIX.2 shell:  the POSIX.2 shell only performs splitting on fields
that result from tilde expansion, parameter expansion, command
substitution and arithmetic expansion (section 3.6).  The splitting of
other fields causes a number of problems (including some security
holes) and has been removed from some Bourne shells (eg. 386BSD --- and
probably other NET-2 derivatives) that do not fully conform to
POSIX.2.  m3make will not, therefore, work in its current form on
systems that comply with POSIX.2 or have a corrected Bourne shell.

Which part of the system relies on the use of a non-whitespace separator
in the definitions of the compiler passes?  Can the seperators be elided
when creating the .makefile(s) without causing any side effects?

	Chris Flatters
	cflatter@nrao.edu


======================================================================= 71 ===
Date:    Mon, 25 Jan 1993 23:51:56 GMT
From:    papresco@undergrad.math.waterloo.edu (Paul Prescod)
Subject: Re: references, objects & m3

>I wonder why do you need to copy objects.

You are right, it's not that often.  But occasionally you may want to
have permission to edit an object without changing the original.

Besides: Isn't the idea of object oriented programming that you
shouldn't have to understand the implementation of the "primitives."
If I didn't understand how M3 objects worked, I could very easily edit
the original.  

Once you understand it, I guess it's just another convention.

>Not really (except for static initializations).  This is a matter of
>religeous war among Modula-3 purists and people with C++ orientation.
>I hope that I won't be starting a war-thread on this subject, when I
>say that:
>
>- Because of garbage collection, destructors are not as crucial in
>  Modula-3 programming. (What do you usually do in a destructor in
>  C++?)

Agreed.  But what about say, sending a message to a window that has
just been destroyed to remove itself from the screen.  Is there a
one line call-destructor and destroy object similar to your one line
constructor?

>- Constructor-like procedures can be created by doing:

>  VAR t := NEW (Foo.T).init(20);

>Hope this helps.

Immensely, thanks for the explanation.



======================================================================= 72 ===
Date:    Mon, 25 Jan 1993 21:30:38 GMT
From:    rhoover@watson.ibm.com (Roger Hoover)
Subject: changes to 2.11 for IBMR2 and SPARC

The following changes fix a problem with IBMR2 terminal input and
allow SPARC and IBMR2 implementations of 2.11 to compile using shared
libraries.

The files changed are:
./m3make/model-configs/IBMR2              Shared library support.
./m3make/model-configs/SPARC

./libm3/rw/src/UFileRd.m3                 Terminal input problem fix for
./libm3/unix/src/aix-3-2/Unix.i3          POSIX machines.
./libm3/unix/src/ultrix-3-1.SPARC/Unix.i3

./trestle/src/m3makefile                  Library use problem fixed for
                                          shared libraries.

Still known problems:

tools/pp and tools/gnuemacs fixes for IBMR2 (posted in November 1992) have
    not been installed.

formsedit fails on IBMR2:
	% formsedit
	Illegal size(13.5)

fisheye fails on SPARC:
	% fisheye
	***
	*** runtime error:
	***    Segmentation violation - possible attempt to dereference NIL
	***    pc = 0x1d3830 = Fisheye.Attach + 0x1add04
	***
	Quit (core dumped)
  and on IBMR2:
	% fisheye
	****************** EXCEPTION HANDLER STACK *********************
	0x2ff7f6f4 TRY-FINALLY  proc = 0x201b697c   frame = 0x2ff7f6e4
	****************************************************************
	***
	*** runtime error:
	***    Unhandled exception "FormsVBT.Error"
	***
	(core dumped)


Context diffs of changed files follow.  A uuencoded version of
m3make/model-configs/IBMR2 follows the diffs (since there is a
line with embedded tabs and spaces that is easy to get wrong).

--------
*** orig_m3-2.11/./m3make/model-configs/IBMR2	Thu Dec 10 14:04:39 1992
--- m3-2.11/./m3make/model-configs/IBMR2	Mon Jan 25 15:42:47 1993
***************
*** 80,85 ****
--- 80,86 ----
     the installation will fail, but can be restarted after you have 
     fixed the permissions. */
  
+ M3VERSION = 2.11
  PREFIX = /usr/local
  INSTALL_PREFIX = $(PREFIX)
  
***************
*** 153,158 ****
--- 154,186 ----
  
  /* When m3(1) receives the -O option, it really does this */
  CC_O = @-O@
+ 
+ /* These macros are used instead of the ones in the template, so that we
+    can have shared libraries */
+ 
+ #define library(name)                                                       @
@\
+ all:: lib##name.a                                                           @
@\
+ clean:: ; rm -f lib##name.a lib##name.ax                                    @
@\
+ lib##name.a: FRC                                                            @
@\
+ 	$(DO_M3) -a lib##name.a $(PGM_SOURCES) $(IMPORT_LIBS) \             @@\
+ 	   -Y4@/bin/touch@.newlib@                                          @@\
+ 	if [ -f .newlib ]; then \                                           @@\
+ 	  /bin/dump -g lib##name.a | sed -n -e \                            @@\
+ 	    's/^[ 	]*[0-9][0-9]*[ 	]*\([^ 	.][^ 	]*\)$$/\1/p' \      @@\
+ 	    > .expnames; \                                                  @@\
+           deflibs="-lm3 -lm"; \                                             @
@\
+ 	  if [ ##name = m3 ]; then deflibs="-lm"; fi; \                     @@\
+ 	  /bin/bsdcc -bE\:.expnames -bM\:SRE -o _shar lib##name.a \         @@\
+             -L$(LIB_USE) $(IMPORT_LIBS) $$deflibs -e _nostart; \            @
@\
+ 	  mv _shar lib##name.a; \                                           @@\
+ 	  rm -f .expnames .newlib; \                                        @@\
+ 	fi
+ 
+ #define Library(name)                                                       @
@\
+ install::                                                                   @
@\
+ 	INSTALL (lib##name.a, $(LIB_INSTALL), 644)                          @@\
+ 	INSTALL (lib##name.ax, $(LIB_INSTALL), 644)                         @@\
+ library(name)
  
  /* Give the value 0 if you want the m3 driver to pass -L/-l arguments to 
     LD for libraries; otherwise (value = 1), the m3 driver will pass 
*** orig_m3-2.11/./m3make/model-configs/SPARC	Thu Dec 10 14:32:37 1992
--- m3-2.11/./m3make/model-configs/SPARC	Mon Jan 25 15:43:13 1993
***************
*** 35,40 ****
--- 35,41 ----
     the installation will fail, but can be restarted after you have 
     fixed the permissions. */
  
+ M3VERSION = 2.11
  PREFIX = /usr/local
  INSTALL_PREFIX = $(PREFIX)
  
***************
*** 110,115 ****
--- 111,144 ----
  /* When m3(1) receives the -O option, it really does this */
  CC_O = @-O@
   
+ /* These macros are used instead of the ones in the template, so that we
+    can have shared libraries */
+ 
+ LIBEXT = so.$(M3VERSION) /* this is the extension of the library name.  Note
+                             that we build a dummy lib##name.a and keep the
+                             name lib##name.ax so that the m3 linker
+                             does not become confused */
+ 
+ #define library(name)                                                       @
@\
+ all:: lib##name.a                                                           @
@\
+ clean:: ; rm -f lib##name.$(LIBEXT) lib##name.a lib##name.ax                @
@\
+ lib##name.a: FRC                                                            @
@\
+ 	$(DO_M3) -a lib##name.a -X1@-PIC@ \                                 @@\
+ 	  -Y3@/bin/ld@-assert@pure-text@-o@ -Y4@/bin/touch@.newlib@ \       @@\
+ 	  $(PGM_SOURCES) $(IMPORT_LIBS)                                     @@\
+         if [ -f .newlib ]; then \                                           @
@\
+           mv lib##name.a lib##name.$(LIBEXT); \                             @
@\
+           /bin/ar cru lib##name.a; \                                        @
@\
+           rm .newlib; \                                                     @
@\
+         fi
+ 
+ #define Library(name)                                                       @
@\
+ install::                                                                   @
@\
+ 	INSTALL (lib##name.a, $(LIB_INSTALL), 644)                          @@\
+ 	INSTALL (lib##name.$(LIBEXT), $(LIB_INSTALL), 644)                  @@\
+ 	INSTALL (lib##name.ax, $(LIB_INSTALL), 644)                         @@\
+ library(name)
+ 
  /* Give the value 0 if you want the m3 driver to pass -L/-l arguments to 
     LD for libraries; otherwise (value = 1), the m3 driver will pass 
     the full path name of the librairies it located */
*** orig_m3-2.11/./libm3/rw/src/UFileRd.m3	Tue Oct 13 18:45:11 1992
--- m3-2.11/./libm3/rw/src/UFileRd.m3	Mon Jan 25 15:37:29 1993
***************
*** 160,166 ****
      status: INTEGER;
      readFDSet, errorFDSet := Unix.FDSet {rd.targetFD};
      old_mode := Unix.fcntl (rd.targetFD, Unix.F_GETFL, 0);
!     new_mode := Word.Or (old_mode, Unix.O_NDELAY);
    BEGIN
      LOOP
        (* make the read call non-blocking; we cannot set/reset the mode at
--- 160,166 ----
      status: INTEGER;
      readFDSet, errorFDSet := Unix.FDSet {rd.targetFD};
      old_mode := Unix.fcntl (rd.targetFD, Unix.F_GETFL, 0);
!     new_mode := Word.Or (old_mode, Unix.TTY_DO_NOT_BLOCK);
    BEGIN
      LOOP
        (* make the read call non-blocking; we cannot set/reset the mode at
*** orig_m3-2.11/./libm3/unix/src/aix-3-2/Unix.i3	Thu Nov 12 14:46:07 199
2
--- m3-2.11/./libm3/unix/src/aix-3-2/Unix.i3	Thu Jan 21 14:26:01 1993
***************
*** 756,761 ****
--- 756,762 ----
    O_TRUNC  =    FTRUNC;         (* open with truncation *)
    O_EXCL =      FEXCL;          (* error on create if file exists *)
    O_FYNC =      FSYNCRON;       (* syncronous write *)
+   TTY_DO_NOT_BLOCK = O_NONBLOCK;(* puts tty in nonblocking mode *)
  
  <*EXTERNAL*> PROCEDURE open (name: char_star; flags, mode: int): int;
  
*** orig_m3-2.11/./libm3/unix/src/ultrix-3-1.SPARC/Unix.i3	Mon Jan 11 17:2
6:35 1993
--- m3-2.11/./libm3/unix/src/ultrix-3-1.SPARC/Unix.i3	Thu Jan 21 14:25:58 199
3
***************
*** 827,832 ****
--- 827,833 ----
    O_EXCL =      FEXCL;          (* error on create if file exists *)
    O_BLKINUSE =  FBLKINUSE;      (* block if "in use" *)
    O_FSYNC =     FSYNCRON;       (* syncronous write *)
+   TTY_DO_NOT_BLOCK = O_NDELAY;  (* puts tty in nonblocking mode *)
  
  <*EXTERNAL*> PROCEDURE open (name: char_star; flags, mode: int): int;
  
*** orig_m3-2.11/./trestle/src/m3makefile	Sun Jan 17 23:10:22 1993
--- m3-2.11/./trestle/src/m3makefile	Thu Jan 21 13:46:37 1993
***************
*** 12,16 ****
--- 12,17 ----
  source_dir (../src/trestle)
  
  import_lib (m3X11R4)
+ import_lib (X11)
  
  Library (m3ui)

--------
begin 644 IBMR2
M+RH@0V]P>7)I9VAT("A#*2`Q.3@Y+"`Q.3DR($1I9VET86P@17%U:7!M96YT
M($-O<G!O<F%T:6]N("`@("`@("`@("`@("`@("`@("`J+PHO*B!!;&P@<FEG
M:'1S(')E<V5R=F5D+B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("HO"B\J(%-E92!T:&4@9FEL92!#3U!9
M4DE'2%0@9F]R(&$@9G5L;"!D97-C<FEP=&EO;BX@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@*B\*"B\J($QA<W0@36]D:69I960@3VX@5'5E($]C="`R
M-R`Q,3HR-3HT,B!04U0@,3DY,B!">2!M=6QL97(@("`@("`@("`@("`@("`@
M("`@*B\*+RH@("`@("!-;V1I9FEE9"!/;B!&<FD@1F5B(#(X(#$T.C$P.C`P
M(%!35"`Q.3DR($)Y(&MA;'-O=R`@("`@("`@("`@("`@("`@("`J+PHO*@E-
M;V1I9FEE9"!/;B!4=64@36%Y("`X(#$Y.3`@0GD@;W)G87-S0&EB;2YC;VT@
M("`@("`@("`@("`@("`@("`@("`@("`J+PH*+RH@4W1A;F1A<F0@8V]N9FEG
M=7)A=&EO;B!F:6QE(&9O<B!)0DU2,B`J+PH*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*B\*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\*+RH)"4E-4$]25$%.5`D)"0D@("`@
M("`@*B\*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*B\*"B\J(%1H:7,@8V]N9FEG=7)A=&EO;B!A<W-U;65S('1H870@>6]U(&AA
M=F4@:6YS=&%L;&5D(&)S9&-C(&%S"B`@(&1E<V-R:6)E9"!I;B`B4&]R=&EN
M9R`T+C,@0E-$(%!R;V=R86US('1O($%)6"!697)S:6]N(#,N,2X*("`@5&AE
M(&9O;&QO=VEN9R!I<R!A('-I;7!L92!F;W)M(&]F('1H97-E(&EN<W1R=6-T
M:6]N<RX*"B`@("@Q*2!!9&0@=&AE(&9O;&QO=VEN9R!S=&%N>F$@=&\@+V5T
M8R]X;&,N8V9G.@H**B!S=&%N9&%R9"!C(&-O;7!I;&5R(&%L:6%S960@87,@
M8G-D8V,*8G-D8V,Z("!U<V4@("`@("`@(#T@1$5&3%0*("`@("`@("!C<G0@
M("`@("`@(#T@+VQI8B]C<G0P+F\*("`@("`@("!M8W)T("`@("`@(#T@+VQI
M8B]M8W)T,"YO"B`@("`@("`@9V-R="`@("`@("`]("]L:6(O9V-R=#`N;PH@
M("`@("`@(&QI8G)A<FEE<R`@/2`M;&)S9"P@+6QC"B`@("`@("`@<')O9FQI
M8G,@("`]("U,+VQI8B]P<F]F:6QE9"PM3"]U<W(O;&EB+W!R;V9I;&5D"B`@
M("`@("`@;W!T:6]N<R`@("`]("U(-3$R+"U4-3$R+"`M<6QA;F=L=FP]97AT
M96YD960L("UQ;F]R;RP@+41?0E-$+`HM1%].3TY35$1?5%E015,L("U$7TY/
M7U!23U1/+"`M1%]"4T1?24Y#3%5$15,L("UB;F]D96QC<V5C="P@+55?7U-4
M4E]?+`HM55]?34%42%]?"@H@("`@3F]T92!T:&%T('1H92!O<'1I;VYS(&%R
M92!A('-I;F=L92!L:6YE+@H*("`@*#(I($%S(')O;W0L(&5X96-U=&4@=&AE
M(&9O;&QO=VEN9R!S=&%T96UE;G1S.@H*("`@"6-D("]B:6X*"6QN("US('AL
M8R!B<V1C8PH*("`@5&AE(')E<W5L="!I<R!T;R!M86ME(&)S9&-C(&$@0R!C
M;VUP:6QE<B!T:&%T(&ES(&%S(&-L;W-E;'D*("`@8V]M<&%T:6)L92!W:71H
M(#0N,R!"4T0@87,@<&]S<VEB;&4N("!4:&4@<&]R=&EN9R!G=6ED90H@("!D
M:7-C=7-S97,@=&AE(')E;6%I;FEN9R!I;F-O;7!A=&EB:6QI=&EE<RX@(%1H
M92!T<F]F9B!S;W5R8V4*("`@9F]R(&$@=F5R<VEO;B!O9B!T:&4@<&]R=&EN
M9R!D;V-U;65N="!I<R!I;B!F:6QE"B`@("]U<W(O;'!P+V)O<R]B<V1P;W)T
M+G1R+@H*04Q33R!.3U1%.B`@5&AE<F4@:7,@82!B=6<@:6X@96%R;&EE<B!V
M97)S:6]N<R!O9B!T:&4@,RXR('AL8R!C;VUP:6QE<@IT:&%T('=I;&P@9VEV
M92!Y;W4@8V]M<&EL871I;VX@97)R;W)S+B`@5&AE(&5A<FQI97-T('9E<G-I
M;VX@:VYO=VX@=&\*8V]M<&EL92!M,R`R+C$P*&%N9"!A8F]V92D@:7,@,2XR
M+C`N-RX@(#$N,BXP+C`@9&]E<R!N;W0@=V]R:RX@(%1O('-E90IW:&EC:"!V
M97)S:6]N('EO=2!H879E+"!T>7!E("(O=7-R+W5C8B]W:&%T("]U<W(O;'!P
M+WAL8R]B:6XO>&QC96YT<GDB+@HJ+PH*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*B\*"B\J($EN(&UO<W0@8V%S97,L(&-H86YG:6YG('1H92!F;VQL;W=I
M;F<@<&%R86UE=&5R<R!I<R!E;F]U9V@Z"@H@("`@("!04D5&25@L($E.4U1!
M3$Q?4%)%1DE8+"`@.B`@=VAE<F4@>6]U('=A;G0@36]D=6QA+3,@:6YS=&%L
M;&5D"B`@("`@($)524Q$7U@Q,5(T+"!83$E"4$%42"`@("`Z("!D;R!Y;W4@
M:&%V92!8,3%2-"`_(`H@("`@("!(059%7U1E6"P@1%9)4%,@("`@("`@("`@
M.B`@9&\@>6]U(&AA=F4@5&58(#\*"B`@(%1H92!O=&AE<B!C;VYF:6=U<F%T
M:6]N('!A<F%M971E<G,@:&%V92!V86QU97,@=&AA="!S:&]U;&0@8F4@;VLN
M"BHO"@HC:68@(61E9FEN960@*%1!4D=%5"D*(V1E9FEN92!405)'151?24)-
M4C(*(V1E9FEN92!405)'150*0U!57U194$4@/2!)0DU2,@HC96YD:68*"B\J
M(%!A=&@@;F%M97,@9&5F:6YE9"!I;B!T:&4@<F5S="!O9B!T:&ES(&9I;&4@
M=VEL;"!B92!P<F5F:7AE9"!B>2!04D5&25@*("`@;W(@24Y35$%,3%]04D5&
M25@L(&1E<&5N9&EN9R!O;B!T:&4@8V]N=&5X="X@5VAE;B!A('!A=&@@:7,@
M=7-E9"`*("`@:6X@=&AE(&1O8W5M96YT871I;VX@;W(@:6X@=&AE($UO9'5L
M82TS(&1R:79E<BP@4%)%1DE8(&ES('5S960N(`H@("!7:&5N(&$@9FEL92!I
M<R!I;G-T86QL960L($E.4U1!3$Q?4%)%1DE8(&ES('5S960N(%1H870@:7,L
M(&EF(%!2149)6`H@("!I<R`G82<L($E.4U1!3$Q?4%)%1DE8(&ES("=B)R!A
M;F0@3$E"(&ES("=C)RP@=&AE($UO9'5L82TS(&1R:79E<@H@("!W:6QL(&QO
M;VL@9F]R('1H92!-;V1U;&$M,R!R=6YT:6UE(&EN("=A+V,G+"!B=70@)VUA
M:V4@:6YS=&%L;"<@=VEL;`H@("!A='1E;7!T('1O('!U="!I="!I;B`G8B]C
M)RX*"B`@($1U<FEN9R!T:&4@:6YS=&%L;&%T:6]N+"!D97-T:6YA=&EO;B!D
M:7)E8W1O<FEE<R!T:&%T(&1O(&YO="!E>&ES=',@"B`@('=I;&P@8F4@8W)E
M871E9"X@66]U(&YE960@=&AE(&YE8V5S<V%R>2!P97)M:7-S:6]N<R!T;R!D
M;SL@;W1H97)W:7-E+`H@("!T:&4@:6YS=&%L;&%T:6]N('=I;&P@9F%I;"P@
M8G5T(&-A;B!B92!R97-T87)T960@869T97(@>6]U(&AA=F4@"B`@(&9I>&5D
M('1H92!P97)M:7-S:6]N<RX@*B\*"DTS5D524TE/3B`](#(N,3$*4%)%1DE8
M(#T@+W5S<B]L;V-A;`I)3E-404Q,7U!2149)6"`]("0H4%)%1DE8*0H*+RH@
M5&AE('5S97(M86-C97-S:6)L92!E>&5C=71A8FQE<R!G;R!T:&5R92X@*B\*
M0DE.(#T@8FEN"D))3E]54T4@("`@(#T@)"A04D5&25@I+R0H0DE.*0I"24Y?
M24Y35$%,3"`]("0H24Y35$%,3%]04D5&25@I+R0H0DE.*0H*+RH@5&AE('!U
M8FQI8R!I;G1E<F9A8V5S(&=O('1H97)E+B`J+PI054(@/2!I;F-L=61E+VTS
M"E!50E]54T4@("`@(#T@)"A04D5&25@I+R0H4%5"*0I054)?24Y35$%,3"`]
M("0H24Y35$%,3%]04D5&25@I+R0H4%5"*0H*+RH@5&AE(&]T:&5R(&9I;&5S
M(&YE8V5S<V%R>2!T;R!R=6X@36]D=6QA+3,@9V\@=&AE<F4N("HO"DQ)0B`]
M(&QI8B]M,PI,24)?55-%("`@("`]("0H4%)%1DE8*2\D*$Q)0BD*3$E"7TE.
M4U1!3$P@/2`D*$E.4U1!3$Q?4%)%1DE8*2\D*$Q)0BD*"B\J(%1H92!G;G5E
M;6%C<R!L:7-P(&-O9&4@9V]E<R!T:&5R92X@*B\*1TY514U!0U-?24Y35$%,
M3"`]("0H24Y35$%,3%]04D5&25@I+VQI8B]E;&ES<`H*+RH@5&AE(&UA;G5A
M;"!P86=E<R!N;W)M86QL>2!G;R!I;B!S=6)D:7)S(&UA;GLQ+"XN+CA](&]F
M($U!3BX*("`@268@>6]U('!R969E<B!T;R!H879E('1H96T@:6X@82!G:79E
M;B!S96-T:6]N+"!S87D@;"P*("`@9&5F:6YE($U!3E]314-424].("HO"DU!
M3B`](&UA;@I-04Y?55-%("`]("0H4%)%1DE8*2\D*$U!3BD*34%.7TE.4U1!
M3$P@/2`D*$E.4U1!3$Q?4%)%1DE8*2\D*$U!3BD*+RHC9&5F:6YE($U!3E]3
M14-424].(&PJ+PH*+RH@268@>6]U(&AA=F4@6#$Q4C0@:6YS=&%L;&5D(&%N
M9"!W;W5L9"!L:6ME('1H92!8,3%2-"!B:6YD:6YG(&EN=&5R9F%C97,*("`@
M=&\@8F4@8G5I;'0L(&1E9FEN92!"54E,1%]8,3%2-"P@<V5T(%A,24)0051(
M('1O(&)E('1H92!C;VQO;@H@("!S97!A<F%T960@;&ES="!O9B!D:7)E8W1O
M<FEE<R!I;B!W:&EC:"!T;R!F:6YD('1H92!8(&QI8G)A<FEE<RP@86YD"B`@
M('-E="!83$E"('1O(&)E('1H92!L:7-T(&]F(&QI8G)A<FEE<R!T;R!L:6YK
M('=I=&@Z(&EF('EO=2!U<V4@=&AE(`H@("!-250@<V5R=F5R('=I=&@@1$5#
M;F5T('-U<'!O<G0L('EO=2!N965D(%@Q,2!A;F0@9&YE="P@;W1H97)W:7-E
M"B`@(%@Q,2!S:&]U;&0@8F4@96YO=6=H+@H@("`*("`@4VEN8V4@6#$Q4C4@
M:7,@86X@97AT96YS:6]N(&]F(%@Q,5(T+"!Y;W4@8V%N('5S92!T:&4@6#$Q
M4C4@;&EB<F%R:65S"B`@(&EN<W1E860@;V8@6#$Q4C0N("!(;W=E=F5R+"!T
M:&4@36]D=6QA+3,@8FEN9&EN9R!I;G1E<F9A8V5S(&AA=F4@;F]T"B`@('EE
M="!B965N('5P9W)A9&5D('1O(%@Q,5(U+B`J+PHC9&5F:6YE($)524Q$7U@Q
M,5(T"@HC:68@9&5F:6YE9"A"54E,1%]8,3%2-"D*6$Q)0E!!5$@@/2`O=7-R
M+VQO8V%L+VQI8@I83$E"("`@("`]("UL6#$Q"B-E;F1I9@H*+RH@268@>6]U
M(&AA=F4@5&58+"!D969I;F4@2$%615]495@@86YD(&1E9FEN92!$5DE04R!T
M;R!C;VYV97)T($1622!F:6QE<PH@("!T;R!0;W-T4V-R:7!T("AO<B!W:&%T
M979E<B!Y;W5R('!R:6YT97(@86-C97!T<RDN(%1H:7,@=VEL;"!A;&QO=R`*
M("`@<')O8V5S<VEN9R!O9B!T:&4@:6UP;&5M96YT871I;VX@;F]T97,N("HO
M"B-D969I;F4@2$%615]495@*"B-I9B!D969I;F5D("A(059%7U1E6"D*(V1E
M9FEN92!$5DE04RAF*2!D=FEP<R`M;R!F+G!S(&8N9'9I"B-E;F1I9@H*+RH@
M0T,@:7,@=&AE(&-O;7!I;&5R('1H870@=VEL;"!B92!U<V5D('1O(&-O;7!I
M;&4@0R!C;V1E('1H870*("`@:7,@<&%R="!O9B!T:&4@9&ES=')I8G5T:6]N
M+@H*("`@3F]T93H@=&AE('9A;'5E(&]F('1H:7,@<WEM8F]L(&UU<W0@;F]T
M('5S92!T:&4@=F%L=65S(&]F"B`@(&]T:&5R('-Y;6)O;',N("HO"D-#(#T@
M+V)I;B]B<V1C8PH@"B\J(%-E="!#0U]705).4U]&3U)?54Y+3D]73E]&24Q%
M4R!T;R`Q(&EF($-#(&ES<W5E<R!A('=A<FYI;F<@:68*("`@>6]U('1R>2!T
M;R!L:6YK(&9I;&5N86UE<R!W:71H(&%N(&5X=&5N<VEO;B`N:6\@;W(@+FUO
M.PH@("!I;B!T:&%T(&-A<V4L('1H92!M,R!D<FEV97(@=VEL;"!C:&%N9V4@
M=&AE(&YA;65S(&]F('1H;W-E(&9I;&5S+@H@("!/=&AE<G=I<V4L('-E="!T
M:&ES('-Y;6)O;"!T;R`P(&%N9"!M,R!W:6QL(')U;B!F87-T97(N("HO"D-#
M7U=!4DY37T9/4E]53DM.3U=.7T9)3$53(#T@,0H*+RH@5VAE;B!M,R@Q*2!R
M96-E:79E<R!T:&4@+6<@;W!T:6]N+"!I="!R96%L;'D@9&]E<R!T:&ES("HO
M"D-#7T<@/2!`+6=`"@HO*B!7:&5N(&TS*#$I(')E8V5I=F5S('1H92`M3R!O
M<'1I;VXL(&ET(')E86QL>2!D;V5S('1H:7,@*B\*0T-?3R`]($`M3T`*"B\J
M(%1H97-E(&UA8W)O<R!A<F4@=7-E9"!I;G-T96%D(&]F('1H92!O;F5S(&EN
M('1H92!T96UP;&%T92P@<V\@=&AA="!W90H@("!C86X@:&%V92!S:&%R960@
M;&EB<F%R:65S("HO"@HC9&5F:6YE(&QI8G)A<GDH;F%M92D@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M0$!<"F%L;#HZ(&QI8B,C;F%M92YA("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!`0%P*8VQE86XZ
M.B`[(')M("UF(&QI8B,C;F%M92YA(&QI8B,C;F%M92YA>"`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@($!`7`IL:6(C(VYA;64N83H@1E)#
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@0$!<"@DD*$1/7TTS*2`M82!L:6(C(VYA;64N82`D
M*%!'35]33U520T53*2`D*$E-4$]25%],24)3*2!<("`@("`@("`@("`@($!`
M7`H)("`@+5DT0"]B:6XO=&]U8VA`+FYE=VQI8D`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("!`0%P*"6EF(%L@+68@+FYE=VQI
M8B!=.R!T:&5N(%P@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@0$!<"@D@("]B:6XO9'5M<"`M9R!L:6(C(VYA;64N82!\('-E
M9"`M;B`M92!<("`@("`@("`@("`@("`@("`@("`@("`@("`@($!`7`H)("`@
M("=S+UY;(`E=*ELP+3E=6S`M.5TJ6R`)72I<*%M>(`DN75M>(`E=*EPI)"0O
M7#$O<"<@7"`@("`@($!`7`H)("`@(#X@+F5X<&YA;65S.R!<("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!`0%P*
M("`@("`@("`@(&1E9FQI8G,](BUL;3,@+6QM(CL@7"`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@($!`7`H)("!I9B!;(",C
M;F%M92`](&TS(%T[('1H96X@9&5F;&EB<STB+6QM(CL@9FD[(%P@("`@("`@
M("`@("`@("`@("`@("!`0%P*"2`@+V)I;B]B<V1C8R`M8D5<.BYE>'!N86UE
M<R`M8DU<.E-212`M;R!?<VAA<B!L:6(C(VYA;64N82!<("`@("`@("`@0$!<
M"B`@("`@("`@("`@("U,)"A,24)?55-%*2`D*$E-4$]25%],24)3*2`D)&1E
M9FQI8G,@+64@7VYO<W1A<G0[(%P@("`@("`@("`@("!`0%P*"2`@;78@7W-H
M87(@;&EB(R-N86UE+F$[(%P@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@0$!<"@D@(')M("UF("YE>'!N86UE<R`N;F5W;&EB
M.R!<("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@($!`
M7`H)9FD*"B-D969I;F4@3&EB<F%R>2AN86UE*2`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!`0%P*:6YS
M=&%L;#HZ("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@($!`7`H)24Y35$%,3"`H;&EB
M(R-N86UE+F$L("0H3$E"7TE.4U1!3$PI+"`V-#0I("`@("`@("`@("`@("`@
M("`@("`@("`@("!`0%P*"4E.4U1!3$P@*&QI8B,C;F%M92YA>"P@)"A,24)?
M24Y35$%,3"DL(#8T-"D@("`@("`@("`@("`@("`@("`@("`@("`@0$!<"FQI
M8G)A<GDH;F%M92D*"B\J($=I=F4@=&AE('9A;'5E(#`@:68@>6]U('=A;G0@
M=&AE(&TS(&1R:79E<B!T;R!P87-S("U,+RUL(&%R9W5M96YT<R!T;R`*("`@
M3$0@9F]R(&QI8G)A<FEE<SL@;W1H97)W:7-E("AV86QU92`](#$I+"!T:&4@
M;3,@9')I=F5R('=I;&P@<&%S<R`*("`@=&AE(&9U;&P@<&%T:"!N86UE(&]F
M('1H92!L:6)R86ER:65S(&ET(&QO8V%T960@*B\*2T5%4%],24)205))15-?
M4D533TQ6140@/2`P("\J('=E(&YE960@+4PO+6P@9F]R('-H87)E9"!L:6)R
M87)I97,@*B\*"B\J(%=E(&1O;B=T('=A;G0@=&\@=7-E('1H92!P<F5D969I
M;F5D($-&3$%'4R`J+PI#1DQ!1U,@/2`*(`HO*B!$969A=6QT(&]P=&EM:7IA
M=&EO;B!F;W(@36]D=6QA+3,@<')O9W)A;7,@*'5S:6YG(&TS;6%K969I;&5S
M*2`J+PI-,T]05"`]("UG"@HO*B!$969A=6QT(&]P=&EM:7IA=&EO;B!F;W(@
M=&AE(&)O;W-T<F%P(&-O;7!I;&5R(&%N9"!D<FEV97(@*B\*0D]/5$]05"`]
M("UG"@HO*B!);6%K92!M87D@;F5E9"!T;R!B92!C;VYF:6=U<F5D"@H@("!.
M;W1E.B!T:&4@=F%L=64@;V8@=&AI<R!S>6UB;VP@;75S="!N;W0@=7-E('1H
M92!V86QU97,@;V8@;W1H97(@<WEM8F]L<RX@*B\*24U!2T5&3$%'4R`]("U$
M4D5$54-%1%]43U]!4T-)25]34$%#10H*+RH@4V]M92!V97)S:6]N<R!O9B!M
M86ME*#$I(&QE="!U<R!S<&5C:69Y('1H92!S:&5L;"!T;R!U<V4N($EN(&%N
M>0H@("!C87-E+"!W92!W86YT('-H("HO"E-(14Q,(#T@+V)I;B]S:`H*+RH@
M5VAA="!A8F]U="!#4%`@/PH*("`@3F]T93H@=&AE('9A;'5E(&]F('1H:7,@
M<WEM8F]L(&UU<W0@;F]T('5S92!T:&4@=F%L=65S(&]F(&]T:&5R('-Y;6)O
M;',N("HO"D-04"`]("]U<W(O;'!P+U@Q,2]886UP;&5S+W5T:6PO8W!P+V-P
M<`H*+RH@5VAA="!A8F]U="!-04M%(#\*"B`@($YO=&4Z('1H92!V86QU92!O
M9B!T:&ES('-Y;6)O;"!M=7-T(&YO="!U<V4@=&AE('9A;'5E<R!O9B!O=&AE
M<B!S>6UB;VQS+B`J+PI-04M%(#T@+W5S<B]B:6XO;6%K90H@("`*+RH@06YD
M(&EN<W1A;&P@*B\*(V1E9FEN92!)3E-404Q,*&8L9"QP*2`O=7-R+W5C8B]I
M;G-T86QL("UC("UM('`@9B!D"@HO*B!(97)E(&%R92!T:&4@<&EE8V5S('1H
M870@=&AE($UO9'5L82TS(&1R:79E<B!N965D<RX*("`@(%!!4U,P.B!T:&4@
M36]D=6QA+3,@=&\@0R!C;VUP:6QE<@H@("`@4$%34S$Z('1H92!#(&-O;7!I
M;&5R+"!W:71H(&]P=&EO;G,@=&\@8V]M<&EL92!-;V1U;&$M,R!C;V1E"B`@
M("!005-3,CH@=&AE($,@8V]M<&EL97(L('=I=&@@;W!T:6]N<R!T;R!C;VUP
M:6QE($UO9'5L82TS(&-O9&4*("`@(%!!4U,S.B!A<BP@=&\@8G5I;&0@87)C
M:&EV97,*("`@(%!!4U,T.B!R86YL:6(L('1O(&-R96%T92!T:&4@=&%B;&4@
M;V8@8V]N=&5N=',@:6X@87)C:&EV97,*("`@(%!!4U,U.B!T:&4@;&EN:V5R
M+"!W:71H(&]P=&EO;G,@=&\@8W)E871E(&%N(&]V97)L87D*"B`@(%1H92!S
M>6YT87@@9F]R(&5A8V@@<&EE8V4@:7,@0'!G;4!A<F<Q0"XN+D!A<F=N0"X@
M(%EO=2!C86X@=7-E"B`@(&%N;W1H97(@8VAA<F%C=&5R('1H86X@0"!A<R!A
M('-E<&%R871O<BP@8G5T('EO=2!N965D('1O(&-H86YG92!315`N"@H@("!7
M:&5N(&$@(F)A<V4B('!R;V=R86T@:7,@8G5I;'0@0D%315]!4D=3(&%R92!A
M9&1E9"!T;R!T:&4@4$%34S(@87)G=6UE;G1S+@H*("`@5VAE;B!A;B!O=F5R
M;&%Y(&ES(&)U:6QT('1H92!F;VQL;W=I;F<@8V]M;6UA;F0@:7,@8V]N<W1R
M=6-T960Z"B`@("`@("!005-3-2`@8F%S92YB("!/5D523$%97S`@("UO(&]V
M97)L87DN;W8@(&]B:F5C=',N+BX@($]615),05DQ"B`@('=H97)E(")B87-E
M+F(B(&ES('1H92!B87-E('!R;V=R86T@=&AA="!W:6QL(&QO860@=&AE(&]V
M97)L87DL"B`@(")O=F5R;&%Y+F]V(B!I<R!T:&4@;F%M92!O9B!T:&4@;F5W
M(&]V97)L87D@86YD(")O8FIE8W1S+BXN(B!I<PH@("!T:&4@;&ES="!O9B!O
M8FIE8W0@;6]D=6QE<R!T;R!I;F-L=61E(&EN('1H92!O=F5R;&%Y+@H*("`@
M3F]T93H@=&AE(&1R:79E<B!O;FQY(&-R96%T97,@<&QA:6X@87)C:&EV97,N
M("!4:&4@=&5M<&QA=&5S"B`@('1A:V4@8V%R92!O9B!B=6EL9&EN9R!T:&4@
M<VAA<F5D(&QI8G)A<FEE<RX@*B\*4T50("`@/2!`"E!!4U,P(#T@0"0H3$E"
M7U5312DO;3-C;VUP:6QE<D`*4$%34S$@/2!`)"A#0RE`+7=`"E!!4U,R(#T@
M0"0H0T,I0"UW0`I005-3,R`]($`O8FEN+V%R0&-R=4`*4$%34S0@/2!`<F%N
M;&EB0`I005-3-2`]($`O8FEN+VQD0"U!0`I/5D523$%97S`@/2!`+6=`"D]6
M15),05E?,2`]($`M;&-`"D)!4T5?05)'4R`]($`M3D`*"B\J(%1H92!M87AI
M;75M('-I>F4@*&EN(&UE9V%B>71E<RD@=&AA="!087-S,"!I<R!A;&QO=V5D
M('1O(')E86-H(&%S"B`@(&$@<&5R<VES=&5N="!S97)V97(@8F5F;W)E('1H
M92!D<FEV97(@:VEL;',@:70N("!3971T:6YG(%-%4E9%4E],24U)5`H@("!T
M;R!Z97)O(&1I<V%B;&5S('1H92!S97)V97(@;6]D92X@*B\*4T525D527TQ)
M34E4(#T@,`HO*B!.3U1%.B!T:&4@8V]M<&EL97(@:7,@8G5G9WDL(&QE879E
M(%-%4E9%4E],24U)5"!A;&]N92$@*B\*"B\J(%1H92!D969A=6QT('!A=&@@
M=&\@<V5A<F-H(&9O<B!-;V1U;&$M,R!I;G1E<F9A8V5S+B`@5&AE('-T86YD
M87)D"B`@(&EN=&5R9F%C97,@87)E(&EN<W1A;&QE9"!I;B!054(N("HO"D1%
M1E!!5$@@/2`N.B0H4%5"7U5312D*"B\J(%1H92!D969A=6QT('!A=&@@=&\@
M<V5A<F-H(&9O<B!L:6)R87)I97,N("!4:&4@<W1A;F1A<F0*("`@36]D=6QA
M+3,@;&EB<F%R:65S(&%R92!I;G-T86QL960@:6X@3$E"+B`@5&AI<R!P871H
M(&1O97,@;F]T"B`@(&YE960@=&\@:6YC;'5D92!D:7)E8W1O<FEE<R!S96%R
M8VAE9"!B>2!D969A=6QT(&)Y(&-C*#$I(&EF"B`@('1H97D@9&]N)W0@8V]N
M=&%I;B!L:6)R87)I97,@=VET:"!-;V1U;&$M,R!C;V1E+B`J+PHC:68@9&5F
M:6YE9"`H0E5)3$1?6#$Q4C0I"DQ)0E!!5$@@/2`N.B0H3$E"7U5312DZ)"A8
M3$E"4$%42"D*(V5L<V4*3$E"4$%42"`]("XZ)"A,24)?55-%*0HC96YD:68*
M"B\J(%1H97-E(&9I;&5S(&%R92!S>7-T96UA=&EC86QL>2!L:6YK960@=VET
M:"!-;V1U;&$M,R!P<F]G<F%M<RX@5&AE"B`@(&9I<G-T('-Y;6)O;"!I<R!U
M<V5D(&9O<B!B;V]T<W1R87`@<')O9W)A;7,N("HO"DQ)3DM"1DE,15,@/2!`
M+6QM0`I,24Y+1DE,15,@/2!`+6QM,T`M;&U`"@HO*B!4:&5S92!F:6QE<R!A
M<F4@;&EN:V5D('=I=&@@36]D=6QA+3,@<')O9W)A;7,@=VAE;B`M6B!I<R!S
M<&5C:69I960N("HO"DQ)3DM#3U9%4B`]("0H3$E"7U5312DO<F5P;W)T7V-O
M=F5R86=E+F\*"B\J(%1H92!#(&-O9&4@9V5N97)A=&5D(&)Y('1H92!-;V1U
M;&$M,R!T;R!#('1R86YS;&%T;W(@(VEN8VQU9&4G<R!S;VUE"B`@(&)A<VEC
M(&9I;&5S+"!T;R!B92!F;W5N9"!I;B!T:&ES(&1I<F5C=&]R>2X@*B\*24Y#
M3"`]("0H3$E"7U5312D*"B\J(%1H92!T96UP;&%T92!T;R!U<V4@9F]R(&TS
D;6%K92@Q*2`J+PI414U03$%412`]('1O<&QE=F5L+G1M<&P*
`
end


======================================================================= 73 ===
Date:    25 Jan 93 23:22:49 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: references, objects & m3

In article <24699@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

   In article <FN00.93Jan25085601@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) 
writes:

   > - Because of garbage collection, destructors are not as crucial in
   >   Modula-3 programming. (What do you usually do in a destructor in
   >   C++?)

   If C++ had garbage collection, destructors would sometimes still be
   useful.  For example, if I have an object that represents a window in
   my window system, I really do want the window to go away as soon as
   the object is no longer in use, rather than waiting around for the
   next garbage collection.  A similar argument applies to flushing the
   buffer of an I/O library structure as soon as possible.

That's why I said "not as crucial" and "usually". Much like other
things in Modula-3, I think of it as an application of 80%-20% rule.
Personally, I wouldn't mind trading in constructors and destructors in
return of a good garbage collector.

--farshad
--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 74 ===
Date:    Tue, 26 Jan 1993 14:13:36 GMT
From:    marc@ecrc.de (Marc Bourgois)
Subject: debugger?

with the release come tools like replayheap and showthread.  From their
names I suppose they are debugging tools, is there any doc on how to
use them?  Are they graphical?

Any info on how you debug multithreaded m3 programs is useful -- thanks

---
Marc Bourgois
European Computer-Industry Research Centre      Tel. + (49) 89-92699-179
Arabellastr 17, 8000 Muenchen 81. Germany.
Internet: marc@ecrc.de
UUCP: ..unido!ecrc!marc




======================================================================= 75 ===
Date:    Tue, 26 Jan 93 22:12:22 GMT
From:    norman@flash.bellcore.com (Norman Ramsey)
Subject: Interface for establishing internet connections


I enclose an interface that makes it easy to write networked
applications.  A server calls Network.Serve to establish a port on the
local machine to which clients can connect.  Each call to
Network.Accept blocks until a client connects, then returns the new
connection.  Clients connect to a server at a known host and port by
calling Network.Connect.  The implementation uses the standard BSD IPC
tricks.

Norman


# To unbundle, "sed '1,/^# To unbundle/d' < thisfile | sh"
# To unbundle, make sure both lines appear in the file
# Tue Jan 26 17:10:37 EST 1993
echo Network.i3 1>&2
sed 's/^-//' >'Network.i3' <<'End of Network.i3'
-(* \section{Network interface}                                              *)
-(* A [[Network.T]] is a (reader, writer) pair used for talking to another   *)
-(* process.  A [[Network.Server]] is a server that can accept connections   *)
-(* from client processes, which call [[Network.Connect]].  The server       *)
-(* process should have a thread that loops and calls [[Network.Accept]]     *)
-(* over and over again.  Typical servers will fork a new thread for each    *)
-(* client connection returned by [[Network.Accept]].  Connections are       *)
-(* specified by Internet host name and port number.                         *)
-(*                                                                          *)
-(* The writer in a [[Network.T]] must be flushed explicitly to ensure       *)
-(* that the pending bits are actually sent over the network.                *)
-(*                                                                          *)
-(* <interface>=                                                             *)
-INTERFACE Network;
-IMPORT UnixError, Rd, Thread, Wr;
-
-TYPE T = RECORD rd: Rd.T; wr: Wr.T; END;
-
-PROCEDURE Connect(hostname:TEXT; port:INTEGER):T RAISES {UnixError.E};
-  (* connect over the network *)
-
-TYPE 
-  Server <: REFANY;
-
-PROCEDURE Serve(port := 0):Server RAISES {UnixError.E};
-  (* serve named port, default any port *)
-
-PROCEDURE Accept(server: Server):T RAISES {UnixError.E, Thread.Alerted};
-  (* accept a connection on the server (blocks, serialized internally) *)
-
-PROCEDURE Host(server: Server):TEXT;
-  (* return name of host served by server *)
-
-PROCEDURE Port(server: Server):INTEGER;
-  (* return port number served by server *)
-
-END Network.
End of Network.i3
echo Network.m3 1>&2
sed 's/^-//' >'Network.m3' <<'End of Network.m3'
-(* The implementation of the [[Network]] interface is based on the C code   *)
-(* in the BSD 4.3 IPC tutorial.                                             *)
-(*                                                                          *)
-(* <*>=                                                                     *)
-UNSAFE MODULE Network;
-IMPORT Fmt, M3toC, Rd, RTScheduler, Text, Thread,
-       UFileRdWr, Uin, Unetdb, Unix, UnixError, Usocket, Wr;
-(* <toplevel>=                                                              *)
-PROCEDURE Connect(host:TEXT; port:INTEGER):T RAISES {UnixError.E} =
-VAR hp    := Unetdb.gethostbyname(M3toC.TtoS(host));
-    sock  := Usocket.socket(Usocket.AF_INET, Usocket.SOCK_STREAM, 0);
-    server:  Uin.struct_sockaddr_in;
-BEGIN
-  IF hp = NIL THEN UnixError.Fail("unknown host: " & host) END;
-  IF sock < 0 THEN UnixError.Fail("can't create socket") END;
-  server.sin_family := Usocket.AF_INET;
-  bcopy(hp.h_addr_list^, ADR(server.sin_addr), hp.h_length);
-  server.sin_port := Uin.htons(port);
-  IF Usocket.connect(sock, ADR(server), BYTESIZE(server)) < 0 THEN
-    UnixError.Fail(Fmt.F("Can't connect to server at %s %s", host, Fmt.Int(por
t)));
-  END;
-  RETURN FromFD(sock);
-END Connect;
-(* When creating a (reader, writer) pair from a socket, I duplicate the     *)
-(* socket, which makes it possible to close both the reader and writer      *)
-(* without barfing.  If such wasteful use of open file descriptors          *)
-(* offends, the solution is to implement new reader and writer classes      *)
-(* such that the underlying file descriptor is not closed until both the    *)
-(* reader and writer are closed.                                            *)
-(*                                                                          *)
-(* <toplevel>=                                                              *)
-PROCEDURE FromFD(sock:INTEGER):T =
-VAR 
-  input  := UFileRdWr.CreateFileReader(sock);
-  output := UFileRdWr.CreateFileWriter(Unix.dup(sock), buffered := TRUE);
-  <*FATAL Rd.Failure, Wr.Failure*>
-BEGIN
-  RETURN T {input, output};
-END FromFD;
-(* This implementation of [[bcopy]] is slightly embarrassing, but I         *)
-(* find address arithmetic too painful to contemplate.                      *)
-(*                                                                          *)
-(* <toplevel>=                                                              *)
-PROCEDURE bcopy(src:ADDRESS; dest:ADDRESS; n:INTEGER) =
-VAR s, d : UNTRACED REF ARRAY [0..1023] OF CHAR;
-BEGIN
-  IF n <= 0 THEN RETURN END;
-  s := src;
-  d := dest;
-  SUBARRAY(d^, 0, n) := SUBARRAY(s^, 0, n);
-END bcopy;
-(* To serialize acceptance of new connections, a [[Network.Server]]         *)
-(* is also a mutex.                                                         *)
-(*                                                                          *)
-(* <toplevel>=                                                              *)
-REVEAL
-  Server = MUTEX BRANDED "Network.Private" OBJECT
-              server : Uin.struct_sockaddr_in;
-              sock: INTEGER;
-              hostname : TEXT;
-              port : INTEGER;
-            END;
-
-PROCEDURE Host(server: Server):TEXT    = BEGIN RETURN server.hostname END Host
;
-PROCEDURE Port(server: Server):INTEGER = BEGIN RETURN server.port     END Port
;
-(* The code to create an accepting socket within the server                 *)
-(* is from the IPC tutorial.  I've added the call to [[gethostname]]        *)
-(* as a convenience.  I call [[Usocket.listen]] with the maximum backlog,   *)
-(* 5, because there seems no reason to make the potential backlog any       *)
-(* smaller than the maximum.                                                *)
-(*                                                                          *)
-(* <toplevel>=                                                              *)
-PROCEDURE Serve(port := 0):Server RAISES {UnixError.E} =
-VAR server := NEW(Server);
-    hostbuf : ARRAY[0..1023] OF CHAR;
-BEGIN
-  server.sock := Usocket.socket(Usocket.AF_INET, Usocket.SOCK_STREAM, 0);
-  IF server.sock < 0 THEN UnixError.Fail("creating socket") END;
-  IF Unix.gethostname(ADR(hostbuf[0]), BYTESIZE(hostbuf)) < 0 THEN
-    UnixError.Fail("gethostname");
-  END;
-  (* It's not safe to use [[M3toC.StoT]] here because the storage holding     
*)
-  (* the host name may be re-used.                                            
*)
-  (*                                                                          
*)
-  (* <set [[server.hostname]] from [[hostbuf]]>=                              
*)
-  VAR i := 0;
-  BEGIN
-    WHILE i < NUMBER(hostbuf) AND hostbuf[i] # '\000' DO INC(i) END;
-    server.hostname := Text.FromChars(SUBARRAY(hostbuf, 0, i));
-  END;
-  server.server.sin_family := Usocket.AF_INET;
-  server.server.sin_addr.s_addr := Uin.INADDR_ANY;
-  server.server.sin_port := Uin.htons(port);
-  IF Usocket.bind(server.sock, ADR(server.server), BYTESIZE(server.server)) # 
0 THEN 
-    UnixError.Fail("binding socket");
-  END;
-  VAR length := BYTESIZE(server.server);
-  BEGIN
-    IF Usocket.getsockname(server.sock, ADR(server.server), ADR(length)) # 0 T
HEN
-      UnixError.Fail("getsockname");
-    END;
-  END;
-  server.port := Uin.ntohs(server.server.sin_port);
-  IF Usocket.listen(server.sock, 5) # 0 THEN UnixError.Fail("listen") END;
-  RETURN server;
-END Serve;
-(* To avoid blocking the entire address space on the [[accept]] system      *)
-(* call, [[Accept]] calls [[select]] first.  Because the socket is hidden   *)
-(* within the [[Network.Server]], and because this code is protected by     *)
-(* the mutex, other code can't get in and accept the connection between     *)
-(* the time [[select]] returns and the connection is accepted.              *)
-(*                                                                          *)
-(* Normal usage is to fork a thread that loops and calls [[Accept]]         *)
-(* continually.  The thread can be stopped by alerting it.                  *)
-(*                                                                          *)
-(* <toplevel>=                                                              *)
-PROCEDURE Accept(server: Server):T RAISES {UnixError.E, Thread.Alerted} =
-VAR sock : INTEGER;
-    reads := Unix.FDSet { server.sock };
-BEGIN
-  LOCK server DO
-    IF RTScheduler.IOAlertSelect(server.sock + 1, ADR(reads), NIL, NIL) < 0 TH
EN
-      UnixError.Fail("select");
-    END;
-    sock := Usocket.accept(server.sock, NIL, NIL);
-    IF sock < 0 THEN UnixError.Fail("accepting socket connection") END;
-    RETURN FromFD(sock);
-  END;
-END Accept;
-BEGIN
-END Network.
End of Network.m3
echo UnixError.i3 1>&2
sed 's/^-//' >'UnixError.i3' <<'End of UnixError.i3'
-(* [[UnixError.Fail]] encapsulates the normal action taken when             *)
-(* a Unix system call fails.                                                *)
-(*                                                                          *)
-(* <interface>=                                                             *)
-INTERFACE UnixError;
-
-TYPE
-  Erec = RECORD msg: TEXT := NIL; errno : INTEGER END;
-
-EXCEPTION E(Erec);
-
-PROCEDURE Fail(msg : TEXT := NIL; errno := 0) RAISES {E};
-  (* check the real errno, add an appropriate message, and RAISE E *)
-
-END UnixError.
End of UnixError.i3
echo UnixError.m3 1>&2
sed 's/^-//' >'UnixError.m3' <<'End of UnixError.m3'
-(* <*>=                                                                     *)
-UNSAFE MODULE UnixError;
-IMPORT M3toC, Uerror;
-
-PROCEDURE Fail(msg : TEXT := NIL; en := 0) RAISES {E} =
-BEGIN
-  IF en = 0 THEN en := Uerror.errno END;
-  WITH syserr = M3toC.StoT(Uerror.GetFrom_sys_errlist(en)) DO
-    IF msg = NIL THEN msg := syserr ELSE msg := msg & ": " & syserr END;
-  END;
-  RAISE E(Erec{msg, en});
-END Fail;
-
-BEGIN
-END UnixError.
End of UnixError.m3


======================================================================= 76 ===
Date:    26 Jan 93 19:41:54 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: debugger?

In article <1993Jan26.141336.13273@ecrc.de> marc@ecrc.de (Marc Bourgois) 
  writes:

   with the release come tools like replayheap and showthread.  From their
   names I suppose they are debugging tools, is there any doc on how to
   use them?  Are they graphical?

   Any info on how you debug multithreaded m3 programs is useful -- thanks

If you've installed the tools distribution, you can get man pages on
showthread(1) and showheap(1) for some information.

I would say that they are "somewhat" graphical. They don't have much
of a GUI, but they do show the information about your running program
graphically.  The "showheap" tool may be great, for example, if you
have a lot (10+) of threads running and you want to see if any of them
is blocking. I have never used "showthread" and "showheap" for
debugging myself, but they are great for showing off to other people
(the average programmer-types get pretty amazed when you show them
that you have 20 threads running in a little program.  ;-)

A neat experiment to try is to run a VBT-intensive modula-3 program
and use showthread to show all the threads running.

Try displaying the tools on color screens. It is kind of hard to
figure out things on black and white screens.

I use gdb for debugging multi-threaded programs. It is not great (you
can't switch from one thread to another), but it works. In case you
missed it, there is a little section about debugging in the SRC
Modula-3 documentation.

I remember hearing people talk about a multi-threaded Modula-3
debugger this past summer. Anyone has any "vaporware" info to report?

--farshad

--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 77 ===
Date:    Wed, 27 Jan 1993 01:50:08 GMT
From:    dsims@don.ece.uc.edu (David Sims)
Subject: Why are M3 executables so big?

Why does the following hello-world program create a 400K stripped
executable on my Sparc box?  The .mo file is a mere 399 bytes, but the
executable balloons to 400K.  Are the Wr, Stdio, and other run-time
libraries really that large?

Or maybe I installed M3 wrong?

MODULE Main;

IMPORT Wr,Stdio;

BEGIN
  Wr.PutText(Stdio.stdout,"Hello, world.\n");
END Main.

-- 
David Sims                    Dept. of Electrical and Computer Engineering
david.sims@uc.edu             University of Cincinnati
(513) 556-2499                Cincinnati OH  45221-0030
RIPEM mail accepted.          USA


======================================================================= 78 ===
Date:    Wed, 27 Jan 1993 03:40:45 GMT
From:    moss@cs.cmu.edu (Eliot Moss)
Subject: Re: What is the representation of Text?

Farshad is entirely right that the implementation is hidden so that programs
cannot bypass it and depend on it in that way. Still, it can be useful to
understand the relative costs of various operations, which tends to vary
depending on the implementation. I believe that SRC uses C-like strings
(probably even null terminated), and I am sure that GNU Modula-3 will.
However, we can always go to something more sophisticated, such as the
Modula-2+ implementation, which uses a tree of string fragments, which may
tend to reduce the allocation overhead and the cost of certain operations.

Cheers --							Eliot
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu


======================================================================= 79 ===
Date:    Wed, 27 Jan 93 03:07:07 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Why are M3 executables so big?

In article <C1Hp3L.3z7@babbage.ece.uc.edu>, dsims@don.ece.uc.edu (David Sims) w
rites:
|> Why does the following hello-world program create a 400K stripped
|> executable on my Sparc box?  The .mo file is a mere 399 bytes, but the
|> executable balloons to 400K.  Are the Wr, Stdio, and other run-time
|> libraries really that large?
|> 

This is an old chestnut that many new users find astonishing, but we ought to
put it in a little perspective. First, all programs include a relatively
sophisticated storage manager and garbage collector, a lightweight process
package (Thread), and a run-time type system. These artefacts, that in other
languages would count as user libraries, cost quite a bit in code and data
size. There is also some overhead that arises from generating C code instead
of native machine code.

In addition, there is substantially more functionality in the libraries,
than hello-world actually needs. We have not tried very hard to structure
the library into small components. I have a prototype tool that optimises
whole M3 programs and, when applied to hello-world, generates an
executable that is 220K in size, as opposed to 417K, on a DECstation 5000.
If this is then optimised with the C compiler, it reduces to 177K.

Of course, since you are running on a Sparc, you can use shared libraries
to mitigate the size of executables. 

Mick Jordan






======================================================================= 80 ===
Date:    26 Jan 93 23:39:27 GMT
From:    awenn@matilda.vut.edu.au (Andrew Wenn)
Subject: Help installing m3 on ARM

Can anyone help me please?

I am installing m3 on an ACORN machine using the ARM architecture and RISCiX.

Most of the installation appears to go O.K. until we get to step 6.

i.e. m3make -f m3makefile.boot all install 

then I get an error:

LongReal_i.c: 15: Error: small floating point value converted to 0.0
LongReal_i.c: 0warnings 1 error 0 serious errors
Error code 1.
Stop.
Error code 1.
Stop.

Can someone please tell me what to fix as I cannot find any obvious errors
in the files (there are two of them as far as I can see.

Thanks.
Andrew Wenn.



---------------------------------------------------------------------------
Andrew Wenn          Victoria University of Technology
                     Footscray Campus.
                     awenn@matilda.vut.edu.au

                     phone 03 688 4342
                     fax   03 688 4804
---------------------------------------------------------------------------


======================================================================= 81 ===
Date:    Wed, 27 Jan 1993 16:08:43 GMT
From:    mgrice@athena.mit.edu (Matthew Grice)
Subject: Modula 3 with OS/2 API

Programming is kind of my hobby, but I to make more of it.
I like what I see of Modula-3, and want to use it to develop
os/2 programs with the Presentation Manager interface.

I wondered if there is an M3 comiler (pref share or free) that I
could get that would support the os/2 api.

I'm not quite sure how these things work, because I am used to dealing
with much less complex operating systems when programming.

If there is a person reading this that could kind of guide me to 
a compiler or solution, could you send me mail?

One more thing.  I have the GNU emx 0.8 c/c++ development system.
Do I just need a m3->c translator?

Thanks,
Matt





======================================================================= 82 ===
Date:    27 Jan 93 17:12:22 GMT
From:    C.R.Snow@newcastle.ac.uk (Dick Snow)
Subject: UMAX build problem with 2.11

I am trying to build the 2.11 distribution for the Multimax running UMAX4.3.
The compiler has been successfully built, and I am now trying to create the new
library. The modules compile ok (which presumably tests the compiler quite
adequately), but when it tries to build the archive, it fails with the error
message below. Can anybody suggest a cure?

Thanks,
	... Dick Snow.

-------------------------------------- libm3/UMAX
/usr/local/m3-2.11/bin/m3 -w1 -make -why -nostd -times -O    -a libm3.a
-F.PGM_S
OURCES
new objects -> archiving libm3.a
ar: bad option `3'

 seconds  #times  operation
    1.24       1  flattening search path
    3.80     351  checking object timestamps
   33.26     348  checking old link info
   11.08       1  compiling C -> object
    0.72       1  checking global consistency
    3.60       1  generating _m3lib.c
    0.72       1  building library link info
   19.81       1  exhaling new link info
    0.17       1  building library archive
    0.21       2  removing temporary files
   29.49      10  garbage collection
    1.98          other
---------------------------------------------------
  106.08          TOTAL


Fatal Error: program "/bin/ar" failed (exit status 2)

gmake: *** [libm3.a] Error 255
*** Error code 1

Stop.


======================================================================= 83 ===
Date:    27 Jan 93 16:59:29 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: What is the representation of Text?


In article <MOSS.93Jan26224045@CRAFTY.cs.cmu.edu> moss@cs.cmu.edu (Eliot Moss) 
writes:

   I believe that SRC uses C-like strings (probably even null
   terminated), and I am sure that GNU Modula-3 will. However, we can
   always go to something more sophisticated, such as the Modula-2+
   implementation, which uses a tree of string fragments, which may
   tend to reduce the allocation overhead and the cost of certain
   operations.

Eliot's comment brought up some questions in my mind. I have always
been assuming that Texts in Modula-3 are not null-terminated (you can
certainly insert '\000' in the middle of a "TEXT" without a problem.

Looking at the libm3 source, I can see that "Text"s _are_
null-terminated, but I can't find any part of the code that _uses_ the
null-termination (instead, a combination of memcpy and NUMBER is used).

So, _why_ are "Text"s null-terminated?

I can think of two possiblities: 

a) it makes debugging easier in a c-oriented debugger.
b) some of the lower layers of the code (like the compiler) uses this
   assumption. These layers are hidden from the user, so the user
   never needs to worry about the null characters.  [I assume that
   libm3 code for "Text" is not really the code that the compiler
   executes, and "Text"s are probably embedded in the compiler.]

Unfortunately I don't have the source release, so I can't examine the
source for the compiler.

--farshad
--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 84 ===
Date:    27 Jan 93 14:44:21 GMT
From:    dagenais@vlsi (Michel Dagenais)
Subject: Re: references, objects & m3


>   I have been looking at the WeakRef interface. It would appear at first
>   reading that this would provide a destructor-like functionality. I
>   cant tell for sure if it would work with objects, but it would seem
>   likely.

Indeed, these guys at DEC SRC are incredible. From version 2.07 to version
2.11, besides a lot of interesting applications like Zeus/Mentor, they
solved probably the two most noteworthy problems that i had with Modula 3 
(and that most other popular languages are not close to address for some
time). (Note that i have not tried much these new features yet).

For highly interactive applications, long garbage collections can be a
nuisance. The incremental garbage collector just appeared to solve this!

The other difficulty was "finalization/destructors" as discussed in this
thread. The weakref library is very simple yet solves elegantly the
problem. It handles correctly finalization order and resurected objects. We
needed this for cleaning up windows, communication channels, telling remote
objects that their proxy was not used anymore, removing collected
character bitmaps from the character cache... Many thanks!

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

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

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


======================================================================= 85 ===
Date:    27 Jan 93 14:59:24 GMT
From:    dagenais@vlsi (Michel Dagenais)
Subject: Re: debugger?


>>      Any info on how you debug multithreaded m3 programs is useful -- thanks
...
>   I remember hearing people talk about a multi-threaded Modula-3
>   debugger this past summer. Anyone has any "vaporware" info to report?

The goodies i remember from last summer were:

- Zeus/mentor
- native compiler
- Modula 3 aware debugger with thread support
- network objects
- incremental garbage collector

Zeus/Mentor and the incremental collector are there. The weakref are
somewhat a bonus although they are strongly related to network objects
which are probably close to ready (they are mentioned in the weakref
interface). Let see when the compiler/debugger appear... probably in a few
months. I suppose it is better not to ask because these things are usually
ready when they are ready. Moreover, DEC SRC has done an excellent job of
sparing us from buggy releases. Admittedly though it is more difficult to
write buggy programs in Modula 3 :-).

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

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

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


======================================================================= 86 ===
Date:    Thu, 28 Jan 1993 15:33:11 GMT
From:    pbh@sbcs.sunysb.edu (Peter B. Henderson)
Subject: Courses using Modula-3

I would be interested in hearing from anyone who has experience using
Modula-3 for instructional purposes.  This semester I plan to use Modula-3
for our CS-II (Data Structures and Algorithms) course on a network of
Hewlet-Packard workstations.  Am using "Modula-3" by Harbison, and
we have Modula-3 installed/running, currently with minimal library
support and tools.  My first experience using Modula-3 for teaching.

Specifically I am seeking helpful hints, features/tools you have found
useful for instruction, and material for students (brief user manuals or
guidelines, useful scripts, examples, sample assignments, etc.).  Anything
you wish to share, including ideas for improving instruction using 
Modula-3 which we may be able to work on as a group.

Thank you.

Peter B. Henderson
spbh@sbcs.sunysb.edu

Dept of Computer Science
SUNY at Stony Brook
Stony Brook, N.Y.  11794
516 - 632 - 8463



======================================================================= 87 ===
Date:    28 Jan 93 16:43:22 GMT
From:    emery@goldfinger.mitre.org (David Emery)
Subject: Re: What is the representation of Text?

Farshad points out a danger in implementing Mod-3 strings using the
standard C technique/hack.  If you have a string with a null '\000' in
it, this string will be 'ill-behaved' with respect to those parts of
the system that depend on null-termination.

We had the same issue when working on the POSIX/Ada binding.  We
originally wanted to make the effect of passing 
	"STR" & ASCII.NUL & "MORE_STR" 
to POSIX as undefined, but our balloters persuaded us that it was much
better to forbid the null in a string altogether.

In languages with subtypes, perhaps string should be defined as
follows (using Ada syntax now):
	subtype STRING_CHARACTER is CHARACTER 
		range CHARACTER'VAL(1) .. CHARACTER'LAST;
	type STRING is array (positive range <>) of STRING_CHARACTER;
This definition prohibits the null character (CHARACTER'VAL(0)) from
(user definable) strings.

				dave


======================================================================= 88 ===
Date:    Thu, 28 Jan 93 18:09:05 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Re: What is the representation of Text?

In article <FN00.93Jan27115929@tahoe.gte.com>, fn00@gte.com (Farshad Nayeri) wr
ites:

|> Looking at the libm3 source, I can see that "Text"s _are_
|> null-terminated, but I can't find any part of the code that _uses_ the
|> null-termination (instead, a combination of memcpy and NUMBER is used).
|> 
|> So, _why_ are "Text"s null-terminated?
|> 
|> I can think of two possiblities: 
|> 
|> a) it makes debugging easier in a c-oriented debugger.

That's the correct answer.

|> b) some of the lower layers of the code (like the compiler) uses this
|>    assumption.

M3toC.TtoS uses it.  It breaks when you try to convert a Text.T with a
'\000' in it, but you cannot represent such a string anyway.

-- 
Eric.



======================================================================= 89 ===
Date:    28 Jan 93 23:29:38 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Keeping up with SRC Modula-3 advances (was Re: debugger?)


In article <DAGENAIS.93Jan27095924@pollux.vlsi> dagenais@vlsi (Michel Dagenais)
 writes:
   >>      Any info on how you debug multithreaded m3 programs is useful -- tha
nks
   ...
   >   I remember hearing people talk about a multi-threaded Modula-3
   >   debugger this past summer. Anyone has any "vaporware" info to report?

   The goodies i remember from last summer were:

   - Zeus/mentor
   - native compiler
   - Modula 3 aware debugger with thread support
   - network objects
   - incremental garbage collector

And FormsVBT, right?

   Zeus/Mentor and the incremental collector are there. The weakref are
   somewhat a bonus although they are strongly related to network objects
   which are probably close to ready (they are mentioned in the weakref
   interface). Let see when the compiler/debugger appear... probably in a few
   months. 

   I suppose it is better not to ask because these things are usually
   ready when they are ready. 

Is it better not to ask? I have never figured out what the exact
etiquette is on this topic. I usually ask in order to have a feel of
when things are coming out to help with planning.

We have experienced nothing but pleasure (and amazement) from using
Modula-3 (both language _and_ libraries), talking to folks at SRC,
witnessing instantaneous bug fixes. 

   Moreover, DEC SRC has done an excellent job of sparing us from
   buggy releases.

It is great that folks at SRC are taking their time to make sure
everything is in a good shape before a "real" release. They have also
been very open and accommodating in discussing their future development
plans (as well as doing a lot of test releases for the eager.) If they
released software any faster, we wouldn't be able to keep up with
downloading and installing everything ;-)

   Admittedly though it is more difficult to write buggy programs in
   Modula 3 :-).

Once again to SRC's credit.

--farshad
--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery


======================================================================= 90 ===
Date:    28 Jan 93 15:44:35 GMT
From:    hootons@p4.cs.man.ac.uk (Stephen Hooton)
Subject: Inheritance and opaque types.

I am just starting to use Modula-3 at the University of 
Manchester, England. Everything was fine until I started
to use inheritance with opaque objects. As far as I can
work out; if I have 'hidden' the datafields of an object
inside an opaque type, even a class that inherits that
object can not access it's datafields. Surely the idea
of hiding datafields is so clients of the object cannot
directly access them, not an objects subclasses.

As far as I can see the only options are :-

1) Leave my datafields public to everyone,
   not what I want to do.

or
2) Write for every field in an object, 2 methods
   one to read the field and one to write it,
   though not only does this sound tedious and
   inefficient, but it removes the protection.
   Any clients of the object can use these methods
   to set the fields directly.


Any help much appreciated!

Thanks Steve.

Stephen Hooton.


======================================================================= 91 ===
Date:    Fri, 29 Jan 93 20:00:50 GMT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Inheritance and opaque types.

In article <hootons.728235875@p4.cs.man.ac.uk>, hootons@p4.cs.man.ac.uk (Stephe
n Hooton) writes:
|> I am just starting to use Modula-3 at the University of 
|> Manchester, England. Everything was fine until I started
|> to use inheritance with opaque objects. As far as I can
|> work out; if I have 'hidden' the datafields of an object
|> inside an opaque type, even a class that inherits that
|> object can not access it's datafields. Surely the idea
|> of hiding datafields is so clients of the object cannot
|> directly access them, not an objects subclasses.
|> 
|> As far as I can see the only options are :-
|> 
|> 1) Leave my datafields public to everyone,
|>    not what I want to do.
|> 

There is no language-level support for allowing a subtype
accces to hidden fields, but denying other clients access.
The convention is to place the half-hidden fields in a separate
interface, and publicise that this is intended for subtype
clients only. You can use partial revelations to arrange this,
e.g.

INTERFACE Foo;

TYPE T <: Public;
  Public = OBJECT
  METHODS
   ..
  END;
END Foo;

INTERFACE FooRep;

  TYPE T = Public OBJECT
     (* fields seen by subtypes *)
  END;

  REVEAL Foo.T <: T;
END FooRep;

MODULE Foo;
IMPORT FooRep;

REVEAL T = FooRep.T OBJECT
   (* really private fields *)
   OVERRIDES
     (* method implementations *)
  END;
BEGIN
END Foo.

One could imagine some programming environment level support for
denying access to "FooRep" except by certain clients.

Mick Jordan



======================================================================= 92 ===
Date:    Sun, 31 Jan 1993 09:45:03 GMT
From:    emclean@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Seek M3 executable for the VAX


I am requesting that anyone working on a VAX/UNIX machine
send me a uuencoded executable version of DIGITAL's Modula-3
running on their machine.

Since this is public domain software we wouldn't be breaking
any copyrights and you'd be saving me the troble of trying
to figure out the installation instructions and working out
any bugs.

Most user's here will be programming from a vt100 so there
is no worry about having special user interface under X.

Thanks,

Emmett


