======================================================================= 1 ===
Date:    Tue, 1 Mar 1994 02:35:12 GMT
From:    zmbenhal@netcom.com (Zeyd M. Ben-Halim)
Subject: Re: Trestle problems under Linux 0.99pl15

In article <1994Feb26.125121.8435@infodev.cam.ac.uk> rrw1000@cus.cam.ac.uk (Ric
hard Watts) writes:
> Hello everyone :-). I'm having a bit of trouble with Trestle (and hence
>FormsVBT) under Linux 0.99pl15. Trestle and FormsVBT compile without
>errors, and so do programs which use them (I've tried 'Cards', 
>'Hello Trestle', 'Calculator' and 'Cube'). 
>
> When I try to run these programs, however, they run successfully for
> anything from a few to 20 or more seconds, and then crash with a 'Virtual 
>time alarm' error. This (or so gdb and the kernel source tell me) is due 
>to their being sent signal 26 (Virtual time alarm). If I insert a signal 
>handler for SIGVTALRM, Cards and Hello Trestle work fine - I haven't tried 
>with Calculator and Cube because they take ages to build on my platform.
>
> I assume that what's happening is that Trestle is setting a timeout, 
>expecting to recieve SIGALRM or something, and is instead recieving what
>it expects, is getting SIGVTALRM. This is fixable by inserting a null 
>SIGVTALRM handler in whatever package under Trestle (ui, X11R4 or tcp)
>sets the alarm, but since the alarm is probably supposed to be doing
>something, that sounds like a silly thing to do.
>
> I'd be grateful if someone could tell me what incredibly obvious and
>stupid thing I'm doing wrong, or provide some sort of bug fix ?

Are you sure that there is no SIGVTALRM handlers in Trestle or M3
itself? The most common problem with uncaught signals under Linux
is that signal() has SYSV semantics and NOT the BSD semantics most
people expect. This reulst in the signal handler being reset to the
default after it's first occurance.

I've yet to see an offical release of M3 for Linux, so the chances are
that problems like that may still appear.

>
> Thanks in advance,
>
>
>
>Richard.
>


-- 
---
Zeyd M. Ben-Halim	zmbenhal@netcom.com
10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281


======================================================================= 2 ===
Date:    Tue, 1 Mar 1994 08:49:30 GMT
From:    qs101@pelican.cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: M3 3.1 on SPARCs - Questions


I now have most of 3.1 up and running on my SPARC - many thanks to all
who made it possible. Overall the system looks like a considerable
improvement, though I have a few gripes (What happened to ParseParams?
List.Push()? ).  m3build is wonderful.

* Is there a document anywhere that describes the changes to the
  interfaces? Or an index to them?

* Was it a policy decision that you should have to explicitly import
  libm3 in m3makefiles?  There can't really be many cases where you
  don't need it.

Many thanks,
Quentin

--

 ----------------------------------------------------------------------
                       Quentin Stafford-Fraser
            
 Cambridge University Computer Lab        Rank Xerox Cambridge EuroPARC
 qs101@cl.cam.ac.uk                           fraser@europarc.xerox.com
 Tel: +44 223 334411                                Tel: +44 223 341521
 Fax: +44 223 334679                                Fax: +44 223 341510

           http://pelican.cl.cam.ac.uk/people/qs101/me.html
 ----------------------------------------------------------------------



======================================================================= 3 ===
Date:    Tue, 1 Mar 1994 15:05:18 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: M3 3.1 on SPARCs - Questions

   Overall the system looks like a considerable
   improvement, though I have a few gripes (What happened to ParseParams?
   List.Push()? ).

The interfaces in libm3 have been cleaned up. IMHO the interface police
has done a good job. Data structures (lists...) were converted to generic
modules, OS neutral interfaces were provided to manipulate files and
a few things have been made more coherent. List.Push is an example, this
function destructively alters a list received as argument. It is
easily replaced: List.Push(\([^,]*\),\([^,]*\)) by: \1 := List.Cons(\2,\1) .
(i.e. List.Push(list,item) -> list := List.Cons(item,list) ).

   * Is there a document anywhere that describes the changes to the
     interfaces? Or an index to them?

I have seen the draft of a nicely organized document. I presume it will
come out fairly soon. The info is already stored in the interfaces and
can be extracted with m3totex although you may be missing the glue that
ties all this info together.

   * Was it a policy decision that you should have to explicitly import
     libm3 in m3makefiles?  There can't really be many cases where you
     don't need it.

I was under the impression that it is not intentional and would be fixed
with some "quake goo", as they say, in the next release.


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

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

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


======================================================================= 4 ===
Date:    Tue, 1 Mar 1994 16:43:55 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: M3 3.1 on SPARCs - Questions

In article <QS101.94Mar1084930@pelican.cl.cam.ac.uk> qs101@pelican.cl.cam.ac.uk
 (Quentin Stafford-Fraser) writes:

   I now have most of 3.1 up and running on my SPARC - many thanks to all
   who made it possible. Overall the system looks like a considerable
   improvement, though I have a few gripes (What happened to ParseParams?
   List.Push()? ).  m3build is wonderful.

We also had some existing code that heavily used the old List
interface and a lot of its features. One thing to note is that you can
recompile the old List interface with the new compiler since it only
counts on Text and Thread. Sx has also changed a lot.

I believe many of changes were due to SRC's interface police
inspecting the libm3 libraries. 

I agree that m3build is really nice to use. 

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


======================================================================= 5 ===
Date:    1 Mar 94 21:05:04 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Re: Where to start


In article <f2c_9402281953@blkcat.fidonet.org>, Joe.Klemmer@f370.n109.z1.fidone
t.org (Joe Klemmer) writes:
|>     Ok, I got the DOS port of Modula-3, I got the Book, I got a computer<g>,
|> where to start?  What is a good begining for learning M3?  Any suggestions? 
|> Tips?  Pitfalls?
|> 
|> Thanks,
|> Joe

If by the book you mean Harbison's, I have these observations:

1.  The text approaches language features like a Swiss army knife
    demo.  This is OK for people experienced at learning new languages,
    but it is confusing for my data structures class.  Every esoteric
    option of a language feature is explained right up front, instead
    of showing the commonly used options first, and saving the juicy
    bits for later.

2.  The book is extremely loaded with errors of every kind.  For quite
    awhile I've been collecting errata and maintaining a sheet for
    people who want to spend a couple of hours getting the book more
    nearly correct.  You can get this via anonymous ftp from
    beethoven:~ftp/pub/M3/{harbison-errs.ps.Z,harbison-errs.tex}.
    Machine beethoven is also known as 129.82.102.183.

    If, after looking over my errata sheet, you have more, please send
    them to me (rro@cs.colostate.edu).

Another book is Nelson's "Systems Programming in Modula-3."  I haven't
spent a lot of time in it, but it assumes you pretty much know M3 and
want to know how to do system-like things.

Now to the software.  The PC version from DEC hasn't received very much
good press as far as I can tell, and I'm anxiously awaiting the GNU
version.  Can anyone provide an update on the state of this project?




======================================================================= 6 ===
Date:    Tue, 1 Mar 1994 23:24:49 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Trestle problems under Linux 0.99pl15

In article <zmbenhalCLysIq.Jw@netcom.com>, zmbenhal@netcom.com (Zeyd M. Ben-Hal
im) writes:
|> In article <1994Feb26.125121.8435@infodev.cam.ac.uk> rrw1000@cus.cam.ac.uk (
Richard Watts) writes:
|> [things deleted]
|> Are you sure that there is no SIGVTALRM handlers in Trestle or M3
|> itself? The most common problem with uncaught signals under Linux
|> is that signal() has SYSV semantics and NOT the BSD semantics most
|> people expect. This reulst in the signal handler being reset to the
|> default after it's first occurance.
|> 
|> I've yet to see an offical release of M3 for Linux, so the chances are
|> that problems like that may still appear.
|> 

 Yup. Spot on - SIGVTALRM is used by the thread scheduler to, um,
schedule threads. The problem stems from src/unix/linux/Usignal.i3 - the 
sigaction structure members are defined in the wrong order (actually,
the wrong members for Linux are defined too, but this doesn't make any
difference in practice). The Modula-3 definition for the sigaction structure
for 0.99pl15 should be something along the lines of :

 struct_sigaction = RECORD
    sa_handler : SignalActionHandler;
    sa_mask    : sigset_t;
    sa_flags   : int;                  (* signal action flags *) 
    (* sa_resv    : ARRAY [0..1] OF int; *)
    sa_restorer : SignalRestoreHandler;
  END;

 After which the scheduler kicks in very nicely, thank you :-).
 Unfortunately, even with this fix applied, my threaded programs die nastily
when they try to reschedule threads - the program :

MODULE Hello EXPORTS Main;

IMPORT Wr, Stdio, Thread, Fmt, Rd;

TYPE
 ch = Thread.Closure OBJECT ms : TEXT; OVERRIDES apply := SayCheese; END;

PROCEDURE SayCheese(self : ch ): REFANY RAISES {}  =
 VAR 
  a: TEXT;
BEGIN
Wr.PutText(Stdio.stdout, self.ms );
Wr.Flush(Stdio.stdout);
LOOP
 (*  Wr.PutText(Stdio.stdout, self.ms); *)
 END;
  RETURN self;
END SayCheese;

VAR
 i : INTEGER;

BEGIN
 Wr.PutText(Stdio.stdout," Type a line : \n");
 Wr.Flush(Stdio.stdout);
 EVAL Rd.GetLine(Stdio.stdin);
  FOR i := 1 TO 23 DO 
     EVAL Thread.Fork(NEW(ch, ms := "Cheese " & Fmt.Int(i)));
  END;
  LOOP
  END;
END Hello.

 Falls over in the following rather nasty way :

$ LINUX/thread
Type a line : 
gfreg
Cheese 4Cheese 3Cheese 2Cheese 1Cheese 9Cheese 8Cheese 7Cheese 6Cheese 5Cheese 
14
Cheese 13Cheese 12Cheese 11Cheese 10Cheese 19Cheese 18Cheese 17Cheese 16Cheese 
15
Cheese 23Cheese 22Cheese 21Cheese 20Illegal instruction
$

[line breaks inserted for clarity]
[If I uncomment the second Wr.PutText, it segfaults instead - the default
 handler does kick in properly ]

 On having a look at the Linux-specific thread scheduling code, I can't find
anything at all wrong with the context switching itself, so my current
suspect is the thread stacks. I've replied to Marc Brown at DEC (who very
kindly emailed me about it), so I presume some knowledgable person who
actually knows how it all works will toddle along and sort it out. Meanwhile,
I'd be interested to hear from anyone who can get my program past the 
'Illegal instruction' stage under Linux... there's a chance it's just my
setup (though I don't really see how it could be), and I'll carry on trying
to hack at it in my (by now fairly limited - things have been piling up !)
spare time.


 Thanks for all the help !


Richard.


|> [things deleted]


======================================================================= 7 ===
Date:    Wed, 2 Mar 1994 08:28:33 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Re: Where to start

rro@CS.ColoState.EDU (Rod Oldehoeft) writes:
[...]
>Another book is Nelson's "Systems Programming in Modula-3."  I haven't
>spent a lot of time in it, but it assumes you pretty much know M3 and
>want to know how to do system-like things.

SPwM3 is, I think, a very good introduction to what you can do with SRC M3
and how to do it. It also contains good chapters about Thread programming
and how Trestle, a window system for SRC M3, can be used. As far as I can tell,
the "System Programming" part refers to the design of software systems
implemented in SRC M3 rather than to something like "UNIX system programming".
SPwM3 doesn't tell about kernel structures or something like that, and 
that's good so, I think.
Harbison's book is still the only language reference except for the (reveised)
M3 Report, SRC-52 technical report, if I remember correctly.

>Now to the software.  The PC version from DEC hasn't received very much
>good press as far as I can tell, and I'm anxiously awaiting the GNU
>version.  Can anyone provide an update on the state of this project?

As far as I remember, neither the SRC nor DEC as such has ever put out a/the
PC version of M3. What's stored on gatekeeper.dec.com as m3pc is merely a
port of the M3 language, done by someone outside SRC. As far as its quality 
is concerned, I have no personal experience. 
However, one should take into account that (a) It's a language port, not a 
complete implementation of the SRC M3 package.
It (b) does not have thread support since that would be an interesting task in
itself, I guess. After all, it's (c) free, and if you have enough DOS disk
space but cannot get a UNIX for some reason it might just be your only
chance to work with the M3 language on a PC. So, lacking competition, it's 
per se "the best there is" on PC-DOS.

As far as the original question - where to start with M3 (on PC) - is
concerned, one might also consider Robert Sedgewick's "Algorithms
in Modula-3", Addison-Wesley. Although all the traditional algorithms
are merely re-written in Modula-3 and there are no algorithms or data
structures that make inventive use of M3-specific features, it is all in
all a good book. 

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


======================================================================= 8 ===
Date:    02 Mar 94 07:25:32 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: Where to start

rro@CS.ColoState.EDU wrote in a message to All:

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

rCE> If by the book you mean Harbison's, I have these
rCE> observations:

That's the book.

rCE> 1.  The text approaches language features like a Swiss army
rCE> knife     demo.  This is OK for people experienced at
rCE> learning new languages,     but it is confusing for my data
rCE> structures class.  Every esoteric     option of a language
rCE> feature is explained right up front, instead     of showing
rCE> the commonly used options first, and saving the juicy
rCE> bits for later.

This could be confusing, thanks for pointing it out.

rCE> 2.  The book is extremely loaded with errors of every kind.
rCE> For quite     awhile I've been collecting errata and
rCE> maintaining a sheet for     people who want to spend a
rCE> couple of hours getting the book more     nearly correct.
rCE> You can get this via anonymous ftp from
rCE> beethoven:~ftp/pub/M3/{harbison-errs.ps.Z,harbison-errs.te
rCE> }.     Machine beethoven is also known as 129.82.102.183.

I'll definitely go and get this.  Couldn't hurt, huh?

rCE>     If, after looking over my errata sheet, you have more,
rCE> please send     them to me (rro@cs.colostate.edu).

Will do.

rCE> Another book is Nelson's "Systems Programming in Modula-3."
rCE> I haven't spent a lot of time in it, but it assumes you
rCE> pretty much know M3 and want to know how to do system-like
rCE> things.

I saw it when I picked up the Harbison book.  There was those two and one
about algorithms in Modula-3.  I figured I'd get the "basic" book and maybe
work my way up from therem.

rCE> Now to the software.  The PC version from DEC hasn't
rCE> received very much good press as far as I can tell, and I'm
rCE> anxiously awaiting the GNU version.  Can anyone provide an
rCE> update on the state of this project?

Ditto.

Later,
Joe


======================================================================= 9 ===
Date:    Wed, 2 Mar 1994 15:06:24 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Where to start

In article <kirschnt.762596913@news.informatik.uni-muenchen.de> kirschnt@inform
atik.uni-muenchen.de (Torsten R. Kirschner) writes:

   rro@CS.ColoState.EDU (Rod Oldehoeft) writes:
   [...]
   >Another book is Nelson's "Systems Programming in Modula-3."  I haven't
   >spent a lot of time in it, but it assumes you pretty much know M3 and
   >want to know how to do system-like things.

   SPwM3 is, I think, a very good introduction to what you can do with
   SRC M3 and how to do it. It also contains good chapters about
   Thread programming and how Trestle, a window system for SRC M3, can
   be used. As far as I can tell, the "System Programming" part refers
   to the design of software systems implemented in SRC M3 rather than
   to something like "UNIX system programming".  SPwM3 doesn't tell
   about kernel structures or something like that, and that's good so,
   I think.  Harbison's book is still the only language reference
   except for the (reveised) M3 Report, SRC-52 technical report, if I
   remember correctly.

I love SPwM3, but I think it is not a good book for people who are
looking for a tutorial that gets them started with Modula-3. You have
had to have some exposure both to Modula-3 and system implementation
to appeciate it, I think. Someone annouced a textbook for Modula-3
here a while ago, but I think it will be a while before it gets
published. Any chance we can get pre-released copies for review?
(Though I can't read German.) 

I never liked "Modula-3" that much (though some of the language
comparisons are nice to someone who knows those languages), but I have
seen people who like it better than SPwM3 and also use it as a
reference. I think it is not a good reference (possibly due to its
errors) and I hate its typesetting. (Sorry, I can't cover my
prejudices. Typesetting Modula in Helvetica is a _big_ mistake. Too
many uppercase characters. Follow ups to comp.fonts.) The SRC
references are now outdated. I think the book needs a second revision,
but I am not sure if Sam is doing Modula-3 related stuff anymore. Sam,
are you out there?

   >Now to the software.  The PC version from DEC hasn't received very much
   >good press as far as I can tell, and I'm anxiously awaiting the GNU
   >version.  Can anyone provide an update on the state of this project?

I think your best bet right now is to run Linux on your PC. I know
this is not a good option for the people with _really_ tight space or
ones that don't want to deal with running UNIX, but I think this way,
you can use the full-fledged Modula-3 system including FormsVBT,
Obliq, Network Objects. By the way the first two of these systems are
very well-introduced as SRC TRs by Marc H. Brown and Luca Cardelli.

Also, don't hesitate to ask questions if you have any. This is one of
the best comp.lang newsgroups because of its load and the readership,
I think.

(Disclaimer: I haven't run Linux myself, but those who have say it is
great. I am awaiting a port to the Mac...)

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


======================================================================= 10 ===
Date:    2 Mar 1994 17:46:18 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Modula-3 Frequently Asked Questions (FAQ)

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


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


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




1.1. What is Modula-3?

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

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

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


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

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


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

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

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

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

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

   Sam Harbison has written a more tutorial book about Modula3:

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

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


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

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

   There are a couple high-level overview articles available:

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

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

   A description of the Modula-3 type system is in

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

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

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

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

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

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

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

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

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

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

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

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

3.1. Where can I get an implementation?

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

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


3.2. What is SRC Modula-3?

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

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

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

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

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

3.3. What is m3pc?

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


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

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

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

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


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

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

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

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

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

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

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


3.4. What is GNU Modula-3?

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

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

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

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

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

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

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

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

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

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

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

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


4.1. Why is "Hello World" so large?

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

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

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

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

4.2. Why objects and interfaces?

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

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

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

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

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

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

4.3. What is the story with Trestle and OpenWindows?

   Mark Manasse says: 

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

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


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

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

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

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

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

6.1. Can I contribute Modula-3 software?

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

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

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






======================================================================= 11 ===
Date:    02 Mar 1994 20:53:10 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: Where to start - GNU M3 status.

>>>>> "Rod" == Rod Oldehoeft <rro@CS.ColoState.EDU> writes:
 > I'm anxiously awaiting the GNU
 > version.  Can anyone provide an update on the state of this project?

I put in as much time as anyone on the GM3 project and have it wired up and
sort of running on my desk well enough to do run experiments. Unfortunately,
it is in no shape for prime time. No threads and 20% of the SRC libraries
don't even compile. Work slowed in July due to me switching projects and
pretty much halted when it became obvious that SRC was doing such a good job
on their compiler.

We are porting pieces of our backend and runtime into the SRC stuff but it is
just for internal research use since that is all we really have time for.
Cheers,

--

       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


======================================================================= 12 ===
Date:    Thu, 03 Mar 94 08:21:28 -0800
From:    mcjones@src.dec.com
Subject: Re: Document on M3 3.1 interface changes

Quentin Stafford-Fraser asks:

    Is there a document anywhere that describes the changes to the
    interfaces? Or an index to them?

Michel comments:

    I have seen the draft of a nicely organized document. I presume it will
    come out fairly soon.

It is in fact now available, as: 

     Some Useful Modula-3 Interfaces
     Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson
     SRC Research Report 113

You can retrieve a PostScript version via anonymous FTP from  
gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-113.ps.Z 

The document includes an index.

Please send any feedback on the document to me:


Paul McJones
mcjones@src.dec.com


======================================================================= 13 ===
Date:    Thu, 3 Mar 1994 21:14:12 GMT
From:    murphy@sbu.edu (Michael Murphy)
Subject: SRC Modula-3 FTP sites

***************************************************************
*                                                             *
*	Saint Bonaventure University                          *
* 	Department of Computer Science                        *
*                                                             *
***************************************************************
*							      *
* 	Michael Josephy Murphy III			      *
*                                                             *
***************************************************************

I WAS UNABLE TO FTP THE SRC MODULA-3 FROM GATEKEEPER.DEC.COM
BECAUSE I COULD NOT MATCH THE DIRECTORIES I FOUND IN A FAQLIST
WITH XARCHIE OR MANUAL FTP.

DOES ANYBODY KNOW HOW I CAN REALLY GET IT...

I AM RUNNING DeskTop SPARC w/X11 olwm mounted on SunOS 4.1.x

***************************************************************
*			*				      *
*  mmurphy@sbu.edu      * NO LIBERTY WITHOUT DISCRETION WHILE *
*                       *  LAWS OF CAUSE & EFFECT STILL APPLY *
*			*                                     *
***************************************************************
-- 
*****************************************************
*                                                   *
* Michael Murphy                mmurphy@sbu.edu     *
*                                                   *


======================================================================= 14 ===
Date:    Thu, 3 Mar 1994 20:34:43 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Annoucement: Modula-3 on a SPARC Mailing List


I have created the mailing list "m3-sparc@gte.com" for the people
running Modula-3 on SPARCs. If you would like to be on this mailing
list, please send me e-mail at "nayeri@gte.com".

The purpose of this mailing list is to keep everybody who runs
Modula-3 on SPARCs updated on the changes to new releases to Modula-3
or anything that is specific to running Modula-3 on SPARCs, SunOS or
Solaris.

I will keep an archive of messages in this in:

         ftp.gte.com:/pub/m3/m3-sparc.tar

To post to the mailing list, send your messages to "m3-sparc@gte.com".

Please let me know if you have any ideas or suggestions about the
operations, as this is the first time I have made a public mailing
list.

--farshad

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


======================================================================= 15 ===
Date:    02 Mar 94 23:11:59 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: Where to start

Torsten R. Kirschner wrote in a message to All:

>Now to the software.  The PC version from DEC hasn't received very much
>good press as far as I can tell, and I'm anxiously awaiting the GNU
>version.  Can anyone provide an update on the state of this project?

TRK> As far as I remember, neither the SRC nor DEC as such has
TRK> ever put out a/the PC version of M3. What's stored on
TRK> gatekeeper.dec.com as m3pc is merely a port of the M3
TRK> language, done by someone outside SRC. As far as its quality
TRK>  is concerned, I have no personal experience.
TRK> However, one should take into account that (a) It's a
TRK> language port, not a  complete implementation of the SRC M3
TRK> package.
TRK> It (b) does not have thread support since that would be an
TRK> interesting task in itself, I guess. After all, it's (c)
TRK> free, and if you have enough DOS disk space but cannot get a
TRK> UNIX for some reason it might just be your only chance to
TRK> work with the M3 language on a PC. So, lacking competition,
TRK> it's  per se "the best there is" on PC-DOS.

Well, since that is the situation I'm in it definitely looks like the "best
there is" all right.  I know enough programming in other languages to get by,
I think.  I'm interested in picking up some different points-of-view.  M3
looks like a bet to learn some new things.

TRK> As far as the original question - where to start with M3 (on
TRK> PC) - is concerned, one might also consider Robert
TRK> Sedgewick's "Algorithms in Modula-3", Addison-Wesley.
TRK> Although all the traditional algorithms are merely
TRK> re-written in Modula-3 and there are no algorithms or data
TRK> structures that make inventive use of M3-specific features,
TRK> it is all in all a good book.

I saw that book when I picked up the Harrison one.  Nothing like spending
$109 on programming books in one shot.  Guess I could go back and get the
Algorithms book, too.

Thanks,
Joe


======================================================================= 16 ===
Date:    04 Mar 94 05:51:44 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: Where to start

fn00@gte.com wrote in a message to All:

fc> I think your best bet right now is to run Linux on your PC.
fc> I know this is not a good option for the people with
fc> _really_ tight space or ones that don't want to deal with
fc> running UNIX, but I think this way, you can use the
fc> full-fledged Modula-3 system including FormsVBT, Obliq,
fc> Network Objects. By the way the first two of these systems
fc> are very well-introduced as SRC TRs by Marc H. Brown and
fc> Luca Cardelli.

I'd be ecstatic if I could run Linux.  But to do so would bean my purchasing
another PC.  All my systems are currently tied up running my BBS.  I have to
share one for all the stuff I want to do.  Thus I'm limited to DOS only.  :-(

Later,
Joe


======================================================================= 17 ===
Date:    4 Mar 94 16:45:37 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Revised Harbison errata sheet available

Peter Klein has supplied me with many new errata for Harbison's book.
The following are available from beethoven.cs.colostate.edu via
anonymous ftp, in ~ftp/pub/M3/*:

harbison-errs.ps.Z		Newest errata sheet
harbison-errs.tex		LaTeX form of above
previous-version.ps.Z	The previous errata sheet
latest-errs			Just the info I got from Peter

I provide the previous sheet, and the new errata, in case your book
has the previous updates, and you want to conveniently apply the
new changes without going through the whole new thing.


======================================================================= 18 ===
Date:    Mon, 7 Mar 94 13:58:59 EST
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: problems using netobj rule in m3makefile


I have a directory that looks like:

  pkgname/SPARC
  pkgname/src/
  pkgname/src/interfaces

where the pkgname/interfaces directory contains some
network object interfaces. The src directory makefile
contains the line:

	include_dir(interfaces)

and the interfaces directory m3makefile contains

    	import(netobj)
	netobj(Coordinator,T)

When I try to build this, I get the following error:

   % m3build
   --- building in SPARC ---
   stubgen -sno Coordinator.T   -T.M3IMPTAB
   m3cfe: (Error) failed to find source for interface 'Coordinator'
   stubgen: NetObj.T not known in this scope.
   *** error code 1

It is executing it in the SPARC subdirectory, and it seems 
unable to find the Coordinator.i3 source file in the 
interfaces directory (../src/interfaces). Can anyone sshed
any clues as to what is going on with 'stubgen' or how to 
track this farther ?

thanks !

--geoff



======================================================================= 19 ===
Date:    7 Mar 1994 15:41:03 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Where to start

A new version of M3-PC has been avaiable for a few weeks.
(By the way: the port wasn't made by DEC,
 rather by Klaus Preschern und Carsten Weich at the University of Klagenfurt.)
Next enhancements (e.g. adding graphics) are to be hoped still before summer.

An introduction into programming with Modula-3
is also written by us.
It should appear in autumn in German and
not too much later in English (at Springer).

Best regards
Laszlo Boszormenyi

*********************************
* Prof. Laszlo Boeszoermenyi	*
* Institut fuer Informatik	*
*                              	*
* Universitaet Klagenfurt	*
* Universitaetsstr. 65-67  	*
* A-9022  Klagenfurt / Austria	*
*                              	*
* e-mail:			*
* laszlo@ifi.uni-klu.ac.at	*
* Tel.: 			*	
* 00-43-463-2700-509 		*
* 00-43-463-2700-506 (secr.)	*
* Fax.:		 		*
* 00-43-463-2700-505 		*
*********************************


======================================================================= 20 ===
Date:    7 Mar 1994 19:35:31 GMT
From:    patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng])
Subject: :? SRC m3-3.1 on SPARC/Solaris2

Has anyone successfully built SRC Modula-3 v3.1 on a SPARC
running Solaris2?  I'm trying to build on Solaris 2.3 using
the SC2.0.1 SPARCware compilers.

To build quake, I had to replace random() with rand() in
boot-SOL2/quake/src/hash.c, add an explicit -D__sparc to
the DEFINES macro in boot-SOL2/quake/src/makefile, and
modify a conditional in boot-SOL2/quake/src/parser.c. (The
test for whether to include <alloca.h> was failing; apparently
because of the check for ANSI c.)  I've included a context
diff below, along with a change to the SOL2 config file to
correct the location of as and ar.

With these changes, everything proceeds smoothly until it
attempts to link the complier.  At this point a few undefined
symbols are found - all BSD routines that aren't supported in
Solaris2 native mode.  I suspect that either the bootstrap
libm3 wasn't built with the USG flag set, or that a few more
tests for it need to be inserted...

Undefined                       first referenced
 symbol                             in file
getwd                               ../../libm3/SOL2/libm3.a(ProcessPosix_m.o)
getdtablesize                       ../../libm3/SOL2/libm3.a(ProcessPosix_m.o)
sigsetmask                          ../../libm3/SOL2/libm3.a(FloatMode_m.o)
_longjmp                            ../../libm3/SOL2/libm3.a(RTThreadC.o)
_setjmp                             Host_m.o
ld: fatal: Symbol referencing errors. No output written to m3c


-Pat

*** boot-SOL2/m3build/templates/SOL2    Mon Feb 14 10:43:41 1994
--- boot-SOL2-local/m3build/templates/SOL2      Fri Mar  4 14:03:17 1994
***************
*** 174,181 ****
  
  if defined("_bootstrap")
    BOOT_CC   = "/opt/SUNWspro/bin/cc"
!   BOOT_ASM  = "/bin/as"
!   BOOT_AR   = "ar cru"
    BOOT_RAN  = "touch"
    BOOT_LINK = "/opt/SUNWspro/bin/cc"
    include("COMMON.BOOT")
--- 174,181 ----
  
  if defined("_bootstrap")
    BOOT_CC   = "/opt/SUNWspro/bin/cc"
!   BOOT_ASM  = "/usr/ccs/bin/as"
!   BOOT_AR   = "/usr/ccs/bin/ar cru"
    BOOT_RAN  = "touch"
    BOOT_LINK = "/opt/SUNWspro/bin/cc"
    include("COMMON.BOOT")


*** boot-SOL2/quake/src/parser.c        Tue Jan 25 16:46:22 1994
--- boot-SOL2-local/quake/src/parser.c  Fri Mar  4 13:53:27 1994
***************
*** 317,328 ****
     along with this program; if not, write to the Free Software
     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
  
- 
  #ifndef alloca
  #ifdef __GNUC__
  #define alloca __builtin_alloca
  #else /* not GNU C.  */
! #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || define
d (__sparc) || defined (__sgi)
  #include <alloca.h>
  #else /* not sparc */
  #if defined (MSDOS) && !defined (__TURBOC__)
--- 317,328 ----
     along with this program; if not, write to the Free Software
     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
  
  #ifndef alloca
  #ifdef __GNUC__
  #define alloca __builtin_alloca
  #else /* not GNU C.  */
! /*#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defi
ned (__sparc) || defined (__sgi)*/
! #if (defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined 
(__sgi)
  #include <alloca.h>
  #else /* not sparc */
  #if defined (MSDOS) && !defined (__TURBOC__)


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



======================================================================= 21 ===
Date:    Tue, 8 Mar 94 13:27:24 EST
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: debugging m3build files/quake scripts ?


Is there any way to get quake to print out the 
actions/procedures it is executing when it executes
an 'm3makefile' ?

In general, what is a good way of debugging m3makefiles
and quake scripts ?

thanks !

--geoff


======================================================================= 22 ===
Date:    8 Mar 1994 16:02:23 GMT
From:    will@marvin.or.uni-bonn.de (Hans-Martin Will)
Subject: Installation of M3 3.1 on AIX 3.2.5

Hi,
has anybody out there succeeded in installing boot-IBMR2... from
gatekeeper.dec.com upon an IBM AIX 3.2.5 system? On my system
m3boot and m3ship seem to terminate successfully, but the created
executable m3c loops endlessly in sbrk(). [That's what dbx is
telling after ^C]
Does anybody have working executables?

Thank you very much,

Martin Will		email: will@marvin.or.uni-bonn.de


======================================================================= 23 ===
Date:    8 Mar 1994 12:43:54 -0800
From:    omalley@porte-de-st-ouen.ics.uci.edu (T. Owen O'Malley)
Subject: Comparing the types of object

I would like to compare the types of two objects. For example, I would
like to be able to do something along these lines:

PROCEDURE Subtype(Left,Right : ROOT) : boolean =
BEGIN
  TYPECASE Left OF
    Right(Something) => RETURN TRUE;
  ELSE
    RETURN FALSE;
  END;
END Subtype;
      
This _is_not_ legal because the selectors of a typecase must be types.
Alternately, if I used:

BEGIN
  RETURN TYPECODE(Left) = TYPECODE(Right);
END Subtype;

I'll only see if the types are equal and not subtypes. Is there a way
to do this?

Thanks,
  Owen O'Malley

Department of ICS  | omalley@ics.uci.edu                 (ARPA)
UC Irvine          | "http://www.ics.uci.edu/~omalley/"  (WWW)
Irvine, CA 92717   | ucbvax!ucivax!omalley               (UUCP)


======================================================================= 24 ===
Date:    Wed, 9 Mar 1994 00:10:59 GMT
From:    fandrich@malibu.sfu.ca (Daniel Theodore Fandrich)
Subject: Class library for standard I/O?

Has anyone written a class library for doing standard I/O in M-3 in a better
fashion than the default libraries?  There must be an easier way than Rd,
Wr, Fmt and Scan!

>>> Dan


======================================================================= 25 ===
Date:    9 Mar 1994 05:31:04 GMT
From:    lucee@ryoohki.its.rpi.edu (Scanner)
Subject: Re: M3 3.1 on SPARCs - Questions

fn00@gte.com (Farshad Nayeri) writes:
>We also had some existing code that heavily used the old List
>interface and a lot of its features. One thing to note is that you can
>recompile the old List interface with the new compiler since it only
>counts on Text and Thread. Sx has also changed a lot.

Oh no! I just wrote about 10,000 lines of an imbeddable scheme interpreter
that used Sx... oh well.. 
-- 
- You ever have one of those days where you just want to teleport in
- somewhere, destroy a couple of monsters, do some property damage,
- then teleport out?
** internet: scanner@rpi.edu	** bitnet:   userf0f3@rpitsmts.bitnet


======================================================================= 26 ===
Date:    9 Mar 1994 12:12:32 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Class library for standard I/O?


> Has anyone written a class library for doing standard I/O in M-3 in a better
> fashion than the default libraries?  There must be an easier way than Rd,
> Wr, Fmt and Scan!

> >>> Dan

SRC has an "IO" interface for simple IO.

We have made another, a bit more powerful standard I/O.
(Modules SIO and SF.)
If some people are interested, we can send the sources,
resp. to put the whole stuff on the gatekeeper.

I append the interfaces.
You don't need SF if you don't use disk files, just standard i/o.
SF is used to open files, naming is quite flexible.

Usage of SIO is quite simple, such as
SIO.PutInt(i); SIO.PutChar(ch),
i:= SIO.GetInt(); ch:= SIO.GetChar() etc.
With "Gets" you can read a stream of typed data.
The interfaces are intended mainly for use in education. 

Greetings
Laszlo Boszormenyi

*********************************
* Prof. Laszlo Boeszoermenyi	*
* Institut fuer Informatik	*
*                              	*
* Universitaet Klagenfurt	*
* Universitaetsstr. 65-67  	*
* A-9022 Klagenfurt / Austria	*
*                              	*
* e-mail:			*
* laszlo@ifi.uni-klu.ac.at	*
* Tel.: 			*	
* 00-43-463-2700-509 		*
* 00-43-463-2700-506 (secr.)	*
* Fax.:		 		*
* 00-43-463-2700-505 		*
*********************************

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

INTERFACE SIO;	(*Simple Input/Output 12.01.94. LB*)

(*SIO provides a Reader and a Writer type.
  A reader or a writer is a stream of typed data.
  Data can be read from a reader by "Get" procedures,
  and can be written by "Put" procedures onto a writer.
  The "Get" and "Put" procedures advance a (hidden) position
  over the reader resp. writer stream.
  The procedure "LookAhead" returns the next character,
  without advancing the reader position.

  All "Put" procedures flush automtically on stdout.
  GetText terminates with new line (other white space characters may occur insi
de).
  GetInt, GetReal, GetBool terminate with any white space character,
  leading whitespaces are ignored. 
  (White spaces are: new line, tab, space, form feed and carriage return.)
  "Error" exception is raised only for readers, not connected to Stdio.stdin.
  For Stdio.stdin, the user is prompted to type in a new value.

  SIO provides some additional functions,
  such as positioning (seeking) in readers,
  length and end of readers, flushing of writers etc.
  Writers are strictly sequential, positioning is not supported.
  The default value of the reader or writer parameter is always NIL,
  with the effect, selecting the appropriate standard device.
  Standard reader is Stdio.stdin, which is normally the keyboard.
  Standard writer is Stdio.stdout, which is normally the screen.*)

  IMPORT Rd, Wr;

  EXCEPTION Error;

  TYPE
    Reader = Rd.T;
    Writer = Wr.T;

  (*--------  Basic procedures  --------*)  

  PROCEDURE GetChar(rd: Reader := NIL): CHAR
    RAISES {Error};
  (*Returns the next char.*)

  PROCEDURE PutChar(ch: CHAR; wr: Writer := NIL);
  (*Outputs a single character.*)

  PROCEDURE GetText(rd: Reader := NIL): TEXT
    RAISES {Error};
  (*Reads a text. The terminating character is not appended.*)

  PROCEDURE PutText(t: TEXT; wr: Writer := NIL);
  (*Outputs all characters in t.*)

  PROCEDURE GetInt(rd: Reader := NIL): INTEGER
    RAISES {Error};
  (*Reads a decimal integer.*)

  PROCEDURE PutInt(i: INTEGER; length := 3; wr: Writer := NIL);
  (*Outputs an integer number. *)

  PROCEDURE GetReal(rd: Reader := NIL): REAL
    RAISES {Error};
  (*Reads a real number.*)

  PROCEDURE PutReal(r: REAL; wr: Writer := NIL);
  (*Outputs a real number. *)

  PROCEDURE GetBool(rd: Reader := NIL): BOOLEAN
    RAISES {Error};
  (*Reads a Boolean constant, terminated by any character in "terminate".
    Legal values are: TRUE, True, true, T, t resp. FALSE, False, false, F, f.*)
  (*!!! Currently works only with T, t, F, f due to an error in "Lex"*)

  PROCEDURE PutBool(b: BOOLEAN; wr: Writer := NIL);
  (*Outputs a Boolean value.*)

  (*--------  Additional procedures  --------*)  

  PROCEDURE LookAhead(rd: Reader := NIL): CHAR
    RAISES {Error};
  (*Returns the next character, without removing it from the reader.*)

  PROCEDURE Nl(wr: Writer := NIL);
  (*Outputs a new line character*)

  PROCEDURE PutUnsigned(i: INTEGER; length := 6; base: [2..16] := 16;
                        wr: Writer := NIL);
  (*Outputs an unsigned number with given base.*)

  PROCEDURE End(rd: Reader := NIL; skip:= TRUE): BOOLEAN;
  (*Returns TRUE iff end of reader reached.
    On the keyborad CTRL-Z on the PC, and CTRL-D in Unix.
    Skips whitespaces if "skip" is true.*)

  PROCEDURE Flush(wr: Writer := NIL);
  (*Flushes the writer on the file. Not necessary for Stdio.stdout.*)

  PROCEDURE Available(rd: Reader := NIL): BOOLEAN;
  (*Returns TRUE iff some characters are available.*)
  (*!!! Currently doesn't work on the PC !!! - it blocks*)

  PROCEDURE Length(rd: Reader := NIL): CARDINAL;
  (*Returns the length of the reader.
    Returns 0 if the length cannot be computed.*)
  (*!!! Currently doesn't work on the PC !!!*)

  PROCEDURE Seek(rd: Reader := NIL; position: CARDINAL := 0);
  (*Sets the reader on "position" if it is seekable.
    Default corresponds to reset a reader.*)
  (*!!! Currently doesn't work on the PC !!!*)

END SIO.

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

INTERFACE SF;	(*SimpleFiles 7.01.94. LB*)

(*SimpleFiles provides simple procedures
  to connect readers and writers with files ("Open" procedures),
  and to decouple them ("Close" procedures).
  "OpenRead" connects a reader to an existing file,
  "OpenWrite" connects a writer to a new file.
  If the file with the given name already exists,
  the user may type in a new name or let it overwrite.
  "OpenAppend" positions the writer at the end of a file.
  The text in parameter "prompt" is displayed on standardout (screen).
  The file connected to a writer is made permanent by a "CloseWrite".

  SimpleFiles provides a flexible mechanism for file name specification.
  If the "name" parameter is omitted (or NIL) at opening, then
  the opening procedures ask the user for a file name.
  If the user enters an empty line, the file defaults to standard i/o,
  i.e. normally to keyboard (standardin) and screen (standardout).
  "GetFileName" provides more explicit control over file name specification. *)

  IMPORT Rd, Wr;

  CONST
    PromptStart = "Type file name ";    
    PromptEnd   = " or NL for standard = ";
    InPrompt    = PromptStart & "for  input" & PromptEnd;
    OutPrompt   = PromptStart & "for output" & PromptEnd;
    AppPrompt   = PromptStart & "for append" & PromptEnd;

  TYPE
    Reader = Rd.T;
    Writer = Wr.T;

    
  PROCEDURE OpenRead(name: TEXT := NIL; prompt:= InPrompt): Reader;
  (*Connects the file, called "name" to a reader.
    If "name" is NIL, or the file does not exists,
    it asks the user for a file name until the file can be opened.
    It returns Stdio.stdin if the user enters "return".*)

  PROCEDURE OpenWrite(name: TEXT := NIL; prompt:= OutPrompt;
                      overwrite:= FALSE): Writer;
  (*Connects a writer to the file, called "name".
    If "name" is NIL it asks the user for a file name.
    It returns Stdio.stdout if the user enters "return".
    If the file (given in "name" or typed in by the user) already exists,
    and "overwrite" is false, it prompts the user to give another file name 
    or to type "End" (CTRL-Z on PC, CTRL-D in Unix) for overwriting.
    If parameter "overwrite" is true, an existing file with same name
    will be overwritten, without asking the interactive user!*)

  PROCEDURE OpenAppend(name: TEXT := NIL; prompt:= AppPrompt): Writer;
  (*Connects a writer to the file, called "name".
    If "name" is NIL it asks the user for a file name.
    It returns Stdio.stdout if the user enters "return".
    Creates a new file, if the specifeid file doesn't exists yet.
    If the file already exists, it positions the writer to the end of it.*)
  (*!!! Currently doesn't work on the PC !!! - it doesn't append*)

  PROCEDURE FileExists(name: TEXT): BOOLEAN;
  (*Returns TRUE iff the file exists.*)

  PROCEDURE CloseRead(VAR rd: Reader);
  (*Closes the file. Assigns NIL to rd - except rd is stdin.*)

  PROCEDURE CloseWrite(VAR wr: Writer);
  (*Flushes the writer and closes the file. 
    Assigns NIL to wr - except wr is stdout.
    Close MUST be called if the content of the writer
    should be made permanent!*)

  PROCEDURE GetFileName(prompt:= PromptStart & PromptEnd): TEXT;
  (*Asks the user for a file name - actually a simple text.
    It is the very same procedure used by OpenRead and OpenWrite.
    Returns NIL if the user enters "return".*)

END SF.



======================================================================= 27 ===
Date:    Wed, 9 Mar 1994 03:27:24 GMT
From:    890930g@dragon.acadiau.ca (D. Aaron Gallagher)
Subject: installation problems on a SPARC

Hi,

I'm trying to install release 3.1, and it keeps hanging, or appearing to
hang.  It makes it through the basic installation ok, although it appears
to be using cc sometimes, although gcc is specified, and it doesn't
seem to be putting in debugging code, even with the ccflag set in the
build file in m3cc.  But the real problem seems to occur when it try to
compile the libm3 package.  I run m3build and it builds all the files,
then hits:
m3 @M3novm -w1 -why -g -times -a libm3.a -F/usr/tmp/aaaa10336 

and stays there.  I've let this go for atleast half an hour.  
I guess what I'm asking is, is this getting stuck there, or am I just
being impatient?


		Any help is gratly appreciated,

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


======================================================================= 28 ===
Date:    Wed, 9 Mar 1994 17:25:23 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: M3 3.1 on SPARCs - Questions

In article <2ljmuo$2ja@usenet.rpi.edu> lucee@ryoohki.its.rpi.edu (Scanner) writ
es:

   fn00@gte.com (Farshad Nayeri) writes:
   >We also had some existing code that heavily used the old List
   >interface and a lot of its features. One thing to note is that you can
   >recompile the old List interface with the new compiler since it only
   >counts on Text and Thread. Sx has also changed a lot.

   Oh no! I just wrote about 10,000 lines of an imbeddable scheme interpreter
   that used Sx... oh well.. 

That's pretty much what we had as well. And the new Sx is pickier
about identifiers (only alphanumeric characters) since it is now using
Atom.T instead of Sx.Symbol. Though they did add ";" as a comment
character. :-) You can hack the new Sx to allow for other identifiers,
but it sure ain't a pretty hack.

How complete is your Scheme implementation? Is it R4Rs? What Scheme
datatypes do you support? Is your system going to be available for
public use?

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


======================================================================= 29 ===
Date:    Wed, 9 Mar 1994 17:16:09 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: installation problems on a SPARC

In article <1994Mar9.032724.8342@relay.acadiau.ca> 890930g@dragon.acadiau.ca (D
. Aaron Gallagher) writes:

   [...]

   I run m3build and it builds all the files, then hits: m3 @M3novm
   -w1 -why -g -times -a libm3.a -F/usr/tmp/aaaa10336

   and stays there.  I've let this go for atleast half an hour.  

Release 3.1 included infinite loops in place of some SPARC
dependencies. Checkout early messages in:

ftp.gte.com:/pub/m3/m3-sparc

directory to solve some of these problems as well as some others that
you may face if you continue working on the port to SPARC. 

--farshad

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


======================================================================= 30 ===
Date:    Wed, 9 Mar 94 08:53:17 EST
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: using stubgen


'Stubgen' seems to have some magic knowledge about the
way packages are structured. In particular, it seems to
work only when the interfaces to be processed are located
directly in the 'src' subdirectory of the package. If they
are located in a subdirectory of 'src', it fails to find them.
This can be manually worked around by invoking 'stubgen' manually
and passing it the '-D' flag to give indicate the directory 
in which they live. There doesn't seem to be anyway to do this 
through th 'netobj' quake template, though. Is there anyway of
specifying additional flags for 'stubgen' through the 'netobj' quake
templates ? 

--geoff



======================================================================= 31 ===
Date:    Wed, 9 Mar 94 10:20:16 EST
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: disregard posting on stubgen and flags


I recently posted a question about 'stubgen' not finding
the source for interfaces. My problem turned out to be
an incomplete 'm3makefile'. It turns out the the 
 
	netobj(Foo, T)

rule in an 'm3makefile' needs to really have the form

	interface(Foo)
	netobj(Foo, T)

and then stubgen can find the interface source.

--geoff

Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories, Inc.

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 32 ===
Date:    9 Mar 1994 19:40:03 GMT
From:    jbpn1@hermes.cam.ac.uk (J.B.P. Naylon)
Subject: Documentation for netobjs in 3.1?

Is there any documentation for the new NetObj library in release 3.1
available anywhere?  I'm writing a distributed system using Modula-3 and
the ANSA system at the moment, but I'd like to evaluate the netobj library
just for fun.  I downloaded the netobj.tar from gatekeeper but there did
not seem to be any documentation in there, nor in DOC.ps from the same
source.  Any pointers?

Thanks.
-- 
John Naylon


======================================================================= 33 ===
Date:    09 Mar 94 06:02:59 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: Revised Harbison errata sheet available

rro@CS.ColoState.EDU wrote in a message to All:

rCE> Peter Klein has supplied me with many new errata for
rCE> Harbison's book. The following are available from
rCE> beethoven.cs.colostate.edu via anonymous ftp, in
rCE> ~ftp/pub/M3/*:

rCE> harbison-errs.ps.Z        Newest errata sheet
rCE> harbison-errs.tex        LaTeX form of above
rCE> previous-version.ps.Z    The previous errata sheet
rCE> latest-errs            Just the info I got from Peter

rCE> I provide the previous sheet, and the new errata, in case
rCE> your book has the previous updates, and you want to
rCE> conveniently apply the new changes without going through the
rCE> whole new thing.

Any chance of getting this in plane ascii format for those of us who can't to
tex or ps?  Thanks.

Later,
Joe


======================================================================= 34 ===
Date:    Wed, 9 Mar 1994 18:31:23 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: m3build

I think that m3build, quake, etc. are quite nice.  However, from the
standpoint of education, it represents a problem.  First, it covers up
quite a bit of complexity because it is so automatic.  Second, part of
my mandate is to teach university students how to use standard tools
such as "make".  There seems to be no easy way to use modula3 version
3 with make.

Would it be possible to provide a more "Unix-like" wrapper for m3?
Something that acts roughly like the m3 of version 2?

Michael Coffin				mhcoffin@tolstoy.uwaterloo.ca
Dept. of Computer Science		office: (519) 888-4820
University of Waterloo			home:   (519) 884-6877
Waterloo, Ontario, Canada N2L 3G1


======================================================================= 35 ===
Date:    9 Mar 1994 20:19:36 GMT
From:    sims@gehrig.ucr.edu (david sims)
Subject: Re: Documentation for netobjs in 3.1?

jbpn1@hermes.cam.ac.uk writes:

john> Is there any documentation for the new NetObj library in release
john> 3.1 available anywhere?

It's not documentation, but there's a paper in the proceedings of the
December 93 SOSP (acm symposium on operating system principles) about
network objects.  I don't have mine here, but I do know that the
proceedings were mailed out to members of the ACM SIG on operating
systems.

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


======================================================================= 36 ===
Date:    9 Mar 1994 23:15:13 GMT
From:    lucee@ryoohki.its.rpi.edu (Scanner)
Subject: Re: M3 3.1 on SPARCs - Questions

fn00@gte.com (Farshad Nayeri) writes:

>In article <2ljmuo$2ja@usenet.rpi.edu> lucee@ryoohki.its.rpi.edu (Scanner) wri
tes:
>   Oh no! I just wrote about 10,000 lines of an imbeddable scheme interpreter
>   that used Sx... oh well.. 

>That's pretty much what we had as well. And the new Sx is pickier
>about identifiers (only alphanumeric characters) since it is now using
>Atom.T instead of Sx.Symbol. Though they did add ";" as a comment
>character. :-) You can hack the new Sx to allow for other identifiers,
>but it sure ain't a pretty hack.

Hm. Well, one has to do what one has to do.. but these modules I am
making are getting larger as time goes on! (I was in the middle
of dumping List.T because I need full cons cells to be more compliant)

Maybe I should just ditch using Sx, and write my own stuff.

>How complete is your Scheme implementation? Is it R4Rs? What Scheme
>datatypes do you support?

It is R4R. I support integers, reals, strings, Time.T, Boolean, 
Char, Array, SxSymbol.T, List.T, Address (Uin.struct_sockaddr_in),
NetAuth.AuthEnt, MyUID.T (their UID.T was not unique enough), and
Glom.T

I didn't have plans for rationals and imaginaries, but if I were
to be motivated that would be easy to add.  All of those
other weird types are needed by the 'greater' system that this
is being written for.  The Glom is an associative table the
supports the above types as keys and values. The Glom has a self-like
inheritance model. (It is what I use to define regions inside the
scheme interpreter.)

> Is your system going to be available for public use?

Yes.  I had not said anything yet because I hate promising something
without having a more or less completed working module.

The scheme interpreter is used as the interest language for a
mildly distributed database I am writing called Scatter.

Scatter uses a networking library called NetJack that provides
authenticated network connections (using bsd sockets & TCP),
with the ability to have a NetJack connection declared "stale"
after some idle time, which causes the network layer to be
dismantled.  It would be reconnected transparently whenever more data
is pushed across the NetJack.T.

Basically, I was going to release all of these when they
were finished. They are (were) quite near being done.  Now
it will take a little longer since I have to regroup with 3.1
and see how that affects what I have.
-- 
- You ever have one of those days where you just want to teleport in
- somewhere, destroy a couple of monsters, do some property damage,
- then teleport out?
** internet: scanner@rpi.edu	** bitnet:   userf0f3@rpitsmts.bitnet


======================================================================= 37 ===
Date:    10 Mar 94 03:27:21 GMT
From:    jeffo@uiuc.edu (J.B. Nicholson-Owens)
Subject: Re: Revised Harbison errata sheet available

Joe Klemmer writes:

>Any chance of getting this in plane ascii format for those of us who can't to
>tex or ps?  Thanks.

Or for those of us who can't read the PS file generated by TeX because
the font used in the output is so incredibly illegible?
--
*NO* NeXTmail please


======================================================================= 38 ===
Date:    Thu, 10 Mar 1994 13:55:33 GMT
From:    rroupski@borg.bell.ca (Roumen Roupski NTMS )
Subject: Modula-3 on Solaris


>> Has anyone successfully built SRC Modula-3 v3.1 on a SPARC
>> running Solaris2?  I'm trying to build on Solaris 2.3 using
>> the SC2.0.1 SPARCware compilers.

Hi Pat.

I am trying to install SRC Modula-3 on Solaris 2.3 as well. I had the
same problems as you have now. Here is what I have done so far:

1. I used /usr/ucb/cc C compiler insted of the SC2.0.1 SPARCware
compilers.I was able to build quake as it is, and to compile m3 and m3c.

If you use /usr/ucb/cc, you will not have these undefined symbols:
  
getwd                               ../../libm3/SOL2/libm3.a(ProcessPosix_m.o)
getdtablesize                       ../../libm3/SOL2/libm3.a(ProcessPosix_m.o)
sigsetmask                          ../../libm3/SOL2/libm3.a(FloatMode_m.o)
_longjmp                            ../../libm3/SOL2/libm3.a(RTThreadC.o)
_setjmp                             Host_m.o


BUT, you will probably have the following undefined symbol:
__cg92_used in /opt/SUNWspro/SC2.0.1/cg92/libm.a

2. In order to solve this I linked m3 and m3c with:
/opt/SUNWspro/SC2.0.1/cg89/libm.a


So far, so good. Everything compiles and links just fine. Then I ran
m3ship and I thought that I have got working Modula-3 compiler. But I
was wrong. Both m3 and m3c are not working. When I run either one them
consumes a lot CPU time, but does nothing. It seems to be hanging somewhere. 

I used gdb to find out what happend, and here is where I am now:

gdb m3

GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.11 (sparc-sun-solaris2.3), 
Copyright 1993 Free Software Foundation, Inc...(no debugging symbols found)...

(gdb) run 
Starting program: /ntms/users/rroupski/modula3/SOL2/m3 
warning: stopped at unknown breakpoint while handling shared libraries
 
Program received signal SIGTRAP (5), Trace/breakpoint trap
0xef6a9040 in _alloc_cnts ()

(gdb) where
#0  0xef6a9040 in _alloc_cnts ()
#1  0xef6ae948 in _alloc_cnts ()
#2  0xef6ae88c in _alloc_cnts ()
#3  0x55160 in Scan__Int ()
#4  0x54d6c in TextList ()
#5  0x57ff8 in IntRefTbl__Iterate ()
#6  0x44654 in FloatMode__BuildConversionArrays ()
#7  0x24ee4 in RTHeapMap__Walk ()
#8  0x2507c in RTHeapMap__Walk ()
#9  0x24d10 in RTHeapMap__BuildGlobalMap ()

(gdb) 

That's all.

Roumen


======================================================================= 39 ===
Date:    11 Mar 1994 09:35:19 GMT
From:    will@unitas.or.uni-bonn.de (Hans-Martin Will)
Subject: Re: Modula-3 on Solaris/AIX 3.2.5


This hang-up seems to be independent (more or less) of the
underlying architecture as it ressembles the problems I encountered
when installing on AIX 3.2.5 on RS/6000 systems. (Dbx tells me m3c
the program is frickling around with sbrk ()).

Martin			will@marvin.or.uni-bonn.de


======================================================================= 40 ===
Date:    Fri, 11 Mar 94 09:45:17 -0800
From:    heydon@src.dec.com
Subject: Re: Comparing the types of object


In message <2lio2a$ajh@porte-de-st-ouen.ics.uci.edu>, Owen O'Malley asks if
there is a way to dynamically decide if one object "a" is a subtype of another
object "b". Of course, if "b"'s type is known statically to be of some type
"T", then you can use the built-in "ISTYPE" operation:

  ISTYPE(a, T)

which is true iff the object "a" is a member of the object or traced reference
type "T". If "b"'s type is not static, then you can test the subtype relation
at run-time using the "IsSubtype" procedure in the "RTType" interface:

  RTType.IsSubtype(TYPECODE(a), TYPECODE(b))

This expression is true iff the dynamic type corresponding to "a" is a subtype
of the dynamic type corresponding to "b".

- Allan Heydon

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



======================================================================= 41 ===
Date:    Fri, 11 Mar 94 10:09:23 -0800
From:    heydon@src.dec.com
Subject: Re: Documentation for netobjs in 3.1?

jbpn1@hermes.cam.ac.uk writes:

> Is there any documentation for the new NetObj library in release 3.1
> available anywhere?

Documentation on network objects is now available in the following SRC
Research Report:

  SRC Research Report 115
  "Network Objects"
  Andrew Birrell, Greg Nelson, Susan Owicki, Edward Wobber

The network objects GC algorithm is described in:

  SRC Research Report 116
  "Distributed Garbage Collection for Network Objects"
  Andrew Birrell, David Evers, Greg Nelson, Susan Owicki, Edward Wobber

These reports are available for anonymous FTP from gatekeeper.dec.com in the
directory "pub/DEC/SRC/research-reports"; they are named "SRC-115.ps.Z" and
"SRC-116.ps.Z", respectively. Hardcopy versions of SRC Research Reports can
also be ordered by e-mail; send your request including a postal mail address
to "src-reports@src.dec.com". SRC 115 is still being printed, so there may be
a slight delay in processing requests for it.

- Allan Heydon

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


======================================================================= 42 ===
Date:    Sat, 12 Mar 94 12:15:12 EST
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: shared libraries on SUN

David Goldberg got all the answers for shared libraries on SUN:

   From: David Goldberg <goldberg@parc.xerox.com>

   I got shared libraries to work.  Just add

     m3_option("-X1@-PIC@")
     m3_option("-X6@-fPIC@")
     m3_option("-Y3@/tmp/ld-so@")
     m3_option("-Y4@touch@")
     m3_option("-X7@-k@")

   to libm3/src/m3makefile.  The results for the Hello World test program 
   compiled with shared vs non-shared libraries are

   text	data	bss	dec	hex
    32768	24576	   0	 57344	 e000	SPARC/foo.shared
   286720	81920	7816	376456	5be88	SPARC/foo.nonshared

   The /tmp/ld-so file should contain:

   #!/bin/csh -f
   # ld-so : based on version from Olly Stephens (os102@cl.cam.ac.uk) - 20/7/92
 
   set argv[1]=$1:r.so.1.1          # change <lib>.a to <lib>.so.1.1
   /bin/ld -assert pure-text -o $*

	-david

   P.S.  This is with libraries compiled -g.  Compiling -O will perhaps
   result in even better size savings.


======================================================================= 43 ===
Date:    Sat, 12 Mar 94 11:52:43 EST
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: shared libraries

Farshad Nayeri asked about shared libraries:

I was finally able to find the relevant documentation on shared libraries
under LINUX. It looks a bit painful to build but the resulting executables
should link very fast, be tiny and startup rapidly as well.

Basically you fix a priori the address of the libraries in virtual space.
Someone on the internet must ensure that libraries that may be linked together
in a program use different addresses. When you link, you get your own copy
of global variables and a jump table that points to the functions in the
library (this is much smaller than the library). When the program starts,
the dynamic loader insures that the needed libraries are in core and simply
maps then in the process virtual space at the predefined addresses; no
symbol linking is needed per see.

When 3.2 comes out i will build the full LINUX distribution with shared
libraries.


======================================================================= 44 ===
Date:    Sat, 12 Mar 1994 16:57:19 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 on Solaris/AIX 3.2.5


   This hang-up seems to be independent (more or less) of the
   underlying architecture as it ressembles the problems I encountered
   when installing on AIX 3.2.5 on RS/6000 systems. (Dbx tells me m3c
   the program is frickling around with sbrk ()).

This is probably the big/small endian problem encountered on SPARC as well.
Check on ftp.gte.com:pub/m3 for a fix.
--
---------------------------------------------------------------------

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

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


======================================================================= 45 ===
Date:    14 Mar 1994 08:23:38 GMT
From:    serrano@savigny.inria.fr (Manuel Serrano)
Subject: compilation ?

I'm wondering (excuse me if it is a FAQ) if their have been some thesis
about the modula3 compilation. In fact, i'm looking for any references on this
subject. 

Thanks to anyone who could help me.

 -----------------------------------------------------------------------------
 Manuel SERRANO (equipe ICSLA, Bat 8)           _/_/   _/_/           _/_/_/_/
 INRIA-Rocquencourt, BP 105, 78153             _/ _/ _/ _/          _/
 Le Chesnay CEDEX, FRANCE                     _/   _/  _/            _/_/_/
 tel: (work) 39-63-57-32                     _/       _/                  _/
 email: Manuel.Serrano@inria.fr             _/       _/     _/   _/_/_/_/
 -----------------------------------------------------------------------------
 


======================================================================= 46 ===
Date:    Mon, 14 Mar 1994 12:27:24 GMT
From:    klaus@tfl.dk (Klaus Elmquist Nielsen)
Subject: Re: Documentation for netobjs in 3.1?

jbpn1@hermes.cam.ac.uk (J.B.P. Naylon) writes:

>Is there any documentation for the new NetObj library in release 3.1
>available anywhere?

gatekeeper.dec.com:/pub/DEC/SRC/research-reports/SRC-115.ps.Z

Cheers!

	Klaus
--
Klaus Elmquist Nielsen                                  | Big blues:
Tele Danmark Research                                   | Q: Am I uniX?
Email: klaus@tdr.dk                                     | A: No!
``Mass production means chemestry, not cookery'', The Chocolate Book (Penguin)
           ``Hvis Fakta er fakta, s{\aa} er Brugsen fup!''


======================================================================= 47 ===
Date:    15 Mar 1994 08:40:25 -0800
From:    omalley@porte-de-st-ouen.ics.uci.edu (T. Owen O'Malley)
Subject: Trestle question

Hi,
  I've been working on a Trestle application under 2.11 and I've hit a
problem that I can't see how to fix (and I've tried). The layout is a
ZSplit with a RigidVBT over a TextureVBT as background. Above the
background is a leaf painted with PaintOp.TransparentFg. When I
originally draw the leaf, it looks fine but when I iconify the window
(or strech it) it picks up the pixels underneath the window as the
background. So if I've got an xterm where the application's window
will uniconify, I'll pickup text in the background of the Leaf. I've
tried forcing a repaint of the background (including trying to
overridding the ZSplits repaint method), but nothing seems to help.
Is this a known bug or is there a fix?

Thanks,
  Owen O'Malley

Department of ICS  | omalley@ics.uci.edu                 (ARPA)
UC Irvine          | "http://www.ics.uci.edu/~omalley/"  (WWW)
Irvine, CA 92717   | ucbvax!ucivax!omalley               (UUCP)


======================================================================= 48 ===
Date:    15 Mar 1994 21:53:46 GMT
From:    jsmith@red-branch.MIT.EDU ()
Subject: Questions, suggestions on porting Mod3 to linux

Does anyone out there have a list of reasonable referances to look at, for
who is intersted in getting modula3 running on a pc(486)under linux or one of 
freebsd's?.  And or, is anyone out there willing to help with such a project?


Jonathan Smith


======================================================================= 49 ===
Date:    15 Mar 1994 23:29:36 GMT
From:    jgoldst@jaguar.cs.wisc.edu (Jonathan Goldstein)
Subject: Can't compile Modula-3

I am trying to compile Modula-3 on a DEC 3100 running Ultrix
I follow the instructions exactly, and after I produce the make
for Modula-3, and I try to actually compile Modula-3, I get stuck.
(that is, I jump out of the make with Error Code 1). I think it has
something to do with all the @ symbols. What are these things supposed
to do anyway?

						  Thanks for the help,
						  Jonathan Goldstein
						  (jgoldst@cs.wisc.edu)    


======================================================================= 50 ===
Date:    Tue, 15 Mar 94 16:04:38 -0800
From:    msm@src.dec.com
Subject: Re: Trestle question


Not a bug.  A ZSplit isn't like a canvas widget; it implements overlapping 
windows with full clipping.  Once you've installed the leaf VBT, 
it's the only VBT that's allowed to paint anywhere inside its domain.  
Painting with TransparentFg doesn't make the VBT transparent in the 
spots where you paint, it just doesn't change what's displayed on 
the screen at those points where the transparent operation is used.

I've been considering implementing a new split which would be more 
like a canvas, but haven't done so yet.  The hard part is that you 
have to live with the flicker you get from originally painting everything 
from back-to-front, and that you have to implement a paintbatch method 
that causes VBTs that might obscure you to repaint themselves when 
you paint.  If you're willing to have a painting model where you 
don't worry about defining which VBTs paint wins when multiple VBTs 
paint, it's a lot easier, and you could probably write that yourself 
in an hour or two.

Mark


======================================================================= 51 ===
Date:    17 Mar 1994 07:02:13 GMT
From:    jcm@octavia (James McPherson)
Subject: Macintosh Port

Hi all. I'm really hankering after a Mac port of M3, so I can get some
real work done on my machine at home. I've got Symantec C++ 6.0.1, and
a fair bit of free space on my hd, but no idea about how to get
started. Is __anyone__ working on a mac port? Is there a place where I
can get some reasonably idiot-proof instructions/pointers/tips on
where/how to start otherwise?

ta muchly,
jcm
--
		jcm@octavia.anu.edu.au
The Mathematician beats the Chemist and Engineer hands down - 
"I started with the assumption that all the cans were open, and got
the desired result by imbibing."
--
other email addresses:
		jcm@cairo.anu.edu.au
		ht325689@dingo.cc.uq.oz.au
		j.mcpherson@mailbox.uq.oz.au
-- 
		jcm@octavia.anu.edu.au
The Mathematician beats the Chemist and Engineer hands down - 
"I started with the assumption that all the cans were open, and got
the desired result by imbibing."


======================================================================= 52 ===
Date:    Thu, 17 Mar 1994 08:29:24 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: FOR SRC: can we have OS2 please?

For the attention of the SRC Modula-3 team:

	Can we have an OS2 version please, released with WIN32?

I am using the Linux version of the 3.1 compiler now and it is great, I have
had copies of SPwM3 and the Harbison book for ages and have read them over 
and over, this is the language for me. I have converted a good few people
here onto M3, but our major platform is IBM OS2 2.1, a 32bit OS which is 
(IMHO) better than the WIN32 offerings (specifically NT). GCC exists for
OS2 as a port (GCC 2.5.7 called GCC/2) and as a more specific OS2/DOS 
version (called EMX based on 2.5.7). Along with a complete set of GNU tools, 
shells etc OS2 can look very Unix like if you want. 

Another thing is rather distasteful, can we have, or look at the posibility
of *commercial* versions of M3. Our design authorities here like the language
and concede that for the work we are doing it would be ideal. However they
cannot commit large scale, long term development (on OS2) to a freeware 
compiler. Any ideas ??

Sorry if all this sounds petty, its just that the language is good, and I 
want to see it prosper.

Thanks.


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer              |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk      |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476084|United Kingdom     |
|Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.


======================================================================= 53 ===
Date:    Thu, 17 Mar 1994 14:13:15 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Macintosh Port


In article <2m8v9l$lq6@manuel.anu.edu.au> jcm@octavia (James McPherson) writes:

   Hi all. I'm really hankering after a Mac port of M3, so I can get some
   real work done on my machine at home. I've got Symantec C++ 6.0.1, and
   a fair bit of free space on my hd, but no idea about how to get
   started. Is __anyone__ working on a mac port? Is there a place where I
   can get some reasonably idiot-proof instructions/pointers/tips on
   where/how to start otherwise?

   ta muchly,
   jcm

I have thought about a Mac port for a long time, and I will consider
helping others who want to try. (I have a Sym. C++ 6.0 as well and a
Centris 650 sitting idle at home.) I remember someone else (from UK?)
said that they had a partial port of 2.11 working, but I can't seem to
find the message. Maybe that someone could post a progress report.

Some of the challenges of the Mac port may be:

- Threads. Mac's thread support is very picky about preemptive
  threads. 

- Changing the "batch-oriented" model or modifying it in someway to
  work on the Mac. 

- Mac's IO is very slow. Modula-3 compiling is IO intensive.

- Window interaction. 

- Toolbox calls. A while ago someone posted an article about the need
  for a tool that takes C headers and maps them to Modula interfaces
  (partially of course). Such a tool will be very useful for the Mac
  port. And I think it will help with popularizing Modula-3 since it
  will make it easier to link with C code quickly.

Any other things that I am leaving off?

However, one of the greatest things about the Mac port may be that
Modula-3 programs will be highly portable between PowerPC and 68k
systems. 

The main question is that is it a good idea to port the current
implementation or wait until someone does an implementation that was
meant for lower-level, more popular systems.

In contrast, and relating to an earlier port, I think an OS/2 port is
not nearly as hard.

Boy, Modula-3 seems to be taking off a little bit. Two posts to port
on two popular platforms... This makes my day.

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


======================================================================= 54 ===
Date:    Thu, 17 Mar 1994 15:38:02 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Questions, suggestions on porting Mod3 to linux


Well, there are already binaries for LINUX on ftp.vlsi.polymtl.ca
lude/modula3-3.1/run/linux.tar.Z; however, not much else than the
compiler and libm3 is there. The next release (soon :-) should contain
all the libraries and come with Linux shared libraries.
--
---------------------------------------------------------------------

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

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


======================================================================= 55 ===
Date:    Thu, 17 Mar 1994 15:55:43 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: FOR SRC: can we have OS2 please?


   I am using the Linux version of the 3.1 compiler now and it is great, I have
   had copies of SPwM3 and the Harbison book for ages and have read them over 
   and over, this is the language for me. I have converted a good few people

I agree, and once you get to use network objects and the "very cool"
Obliq embedded OO language (you can call it from m3 and you can call 
pretty much all the m3 libraries from it), Modula-3 becomes irresistible!

   here onto M3, but our major platform is IBM OS2 2.1, a 32bit OS which is 
   (IMHO) better than the WIN32 offerings (specifically NT). GCC exists for
   OS2 as a port (GCC 2.5.7 called GCC/2) and as a more specific OS2/DOS 
   version (called EMX based on 2.5.7). Along with a complete set of GNU tools,
   shells etc OS2 can look very Unix like if you want. 

If you have all of this available, the port should be fairly simple.

   Another thing is rather distasteful, can we have, or look at the posibility
   of *commercial* versions of M3. Our design authorities here like the languag
e
   and concede that for the work we are doing it would be ideal. However they
   cannot commit large scale, long term development (on OS2) to a freeware 
   compiler. Any ideas ??

This is a good point. Frode Odegard (you should be able to find his e-mail in 
the comp.lang.modula3 archives) was offering commercial support for Modula-3
at some point. Some of the companies specialized in "freeware" support
may be willing to offer support contracts.
--
---------------------------------------------------------------------

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

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


======================================================================= 56 ===
Date:    Thu, 17 Mar 1994 14:31:57 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: FOR SRC: can we have OS2 please?

In article <CMsvL1.HHw@oasis.icl.co.uk> skj@oasis.icl.co.uk (Simon Johnston) wr
ites:

   For the attention of the SRC Modula-3 team:

           Can we have an OS2 version please, released with WIN32?

   I am using the Linux version of the 3.1 compiler now and it is
   great, I have had copies of SPwM3 and the Harbison book for ages
   and have read them over and over, this is the language for me. I
   have converted a good few people here onto M3, but our major
   platform is IBM OS2 2.1, a 32bit OS which is (IMHO) better than the
   WIN32 offerings (specifically NT). GCC exists for OS2 as a port
   (GCC 2.5.7 called GCC/2) and as a more specific OS2/DOS version
   (called EMX based on 2.5.7). Along with a complete set of GNU
   tools, shells etc OS2 can look very Unix like if you want.

It is probably not that hard since OS/2 is 32 bits and I believe it
has thread support, etc. (On thing that will be great and interesting
is to see SRC Modula-3 working on top of IBM System Object Model!)
Unfortunately, I don't have a PC, so I can't be of much help here.

I am not sure if SRC itself needs to do a port, or just someone out
there who knows OS/2 well should try do this. I have heard people
talking about an OS/2 port before. So far, most of the ports of the
2.11 version have been made by people outside SRC. Would you be able
to do such a port? The m3-request folks are very good in helping
people with porting and other problems. With release 3.1 it is even
easier to port because most/all of the UNIX/Make dependencies have
been removed.

   Another thing is rather distasteful, can we have, or look at the
   posibility of *commercial* versions of M3. Our design authorities
   here like the language and concede that for the work we are doing
   it would be ideal. However they cannot commit large scale, long
   term development (on OS2) to a freeware compiler. Any ideas ??

Although I've found that the level of quality and support of SRC
Modula-3 is better than most commercial packages I've ever used, I
agree with you that a second commercial source will be excellent for
popularizing Modula-3.  The question is that who's going to do it...
People have talked about it, but I've never seen one.  I even talked
with a vendor who was doing an Object Modula-2 on the Macintosh who
did not feel that they want to get into doing Modula-3. Even if
someone is willing to do an implementation of Modula-3 (though the
market share does not seem large) how would they be able to compete
with SRC's system? Would you be willing to pay $1000+ for a system
that you can get for free.

Then again, if there is enough demand, a cygnus-like system may work.
They can just use SRC's code, but sell support for it. I heard that
SRC is revising their commercial licesnsing agreement for Modula-3 to
allow more flexibility. Can someone from SRC elaborate on the intent
behind the changes?

   Sorry if all this sounds petty, its just that the language is good, and I 
   want to see it prosper.

I think you are making a good point; I think much of the readership
here would want to make Modula prosper. 

--farshad

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


======================================================================= 57 ===
Date:    17 Mar 1994 21:47:22 GMT
From:    dstengle@max (Renata Wentzcovitch)
Subject: Re: Questions, suggestions on porting Mod3 to linux

jsmith@red-branch.MIT.EDU wrote:
: Does anyone out there have a list of reasonable referances to look at, for
: who is intersted in getting modula3 running on a pc(486)under linux or one of
 
: freebsd's?.  And or, is anyone out there willing to help with such a project?


: Jonathan Smith
	Look on gatekeeper.dec.com for the new version (3.1).  This is a native
code compiler.  Linux was one of the first three platforms to be ported to and 
has fewer bugs than some others at the moment, having been one of the first.
For anyone where they have decided to use Modula-3 for teaching, this is a 
definite boon, as compared to using sometimes (or always)  overloaded facilitie
s.
			David Stenglein


======================================================================= 58 ===
Date:    17 Mar 1994 21:58:22 GMT
From:    dstengle@max (Renata Wentzcovitch)
Subject: installing 3.1 on IBM RS/6000

Simply put, bas anyone acomplished this?  There are a few errors, including
looking for a lib file that isn't there.  The make process hangs and says it
doesn't know how to make m3.o.  It would be great just to that it was possible
to do.
			David Stenglein


======================================================================= 59 ===
Date:    Thu, 17 Mar 94 13:57:38 PST
From:    frode@toaster.SFSU.EDU (Frode Odegard)
Subject: commercial support

Michel Dagenais <dagenais@froh.vlsi.polymtl.ca> writes:

> This is a good point. Frode Odegard (you should be able to find his e-mail
> in the comp.lang.modula3 archives) was offering commercial support for
> Modula-3 at some point.

Heh, okay, it's frode@odegard.com. :)

Odegard Labs is still in contract negotiations with DEC SRC.  If things
work out you should be able to buy a commercially supported version
from us for SPARC later this year (there is no set release date yet.).
Various PC OS'es are being looked at also, since we have two clients
that have massive amounts of Modula-2 code and want to move to Modula-3
(one is under OS/2, the other under DOS.)

A problem with this is that if you support some platform FOO and only
two people are interested, you're not going to make any money.  So
the plan was to get a solid legal arrangement with DEC SRC (this has
taken months and months because the DEC SRC legal staff was laid off)
and then see how the "Modula-3 marketplace" had developed at that
point. (SPARC is the easiest platform for us initially because that's
the hardware we and lots of other people have. :->)

Now that I'm writing this note anyway, perhaps those who are interested
in some form of commercial support can send a note to me at the above-
mentioned address with the subject line "M-3 Poll" and give me an idea
of what they're interested in (platform, features, bin vs src, pricing,
levels of support, porting, etc.).  I'll then summarize and post the
result here.

If nobody's interested then I hope we won't see any more "whining" about
how Modula-3 doesn't have any commercial backing. :-)


Frode Odegard



======================================================================= 60 ===
Date:    Fri, 18 Mar 1994 04:10:34 GMT
From:    torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner)
Subject: Q: M3 3.1 formsvbt package / videovbt?

Hello,

when I tried to install the formsvbt package from the M3 3.1 release,
I ran into this problem. Here are some lines from the "m3makefile.formsvbt":

import (ui)		
import (videovbt) 
import (vbtkit)
import (formsvbtpixmaps)

What is videovbt and where do I get this library from? Either I have over-
looked it in the distribution or it is just not there. I have all the other
libs installed.

TIA for any help,
Torsten
-- 
Torsten R. Kirschner  (EDV)           torki@mpipf-muenchen.mpg.de
MPI f. Psychologische Forschung       tel: ++49 89 38602258
Leopoldstr. 24                        fax: ++49 89 342473
80802 Muenchen
Germany          X.400: no longer available
[PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner <torki@mpipf-muenchen.mpg.de>]
<A HREF="http://file01.mpipf-muenchen.mpg.de:8001/~torki/index.html">Torsten</A
>


======================================================================= 61 ===
Date:    Fri, 18 Mar 1994 13:14:25 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Q: M3 3.1 formsvbt package / videovbt?

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

   Hello,

   when I tried to install the formsvbt package from the M3 3.1 release,
   I ran into this problem. Here are some lines from the "m3makefile.formsvbt":

   import (ui)		
>  import (videovbt) 
   import (vbtkit)
   import (formsvbtpixmaps)

   What is videovbt and where do I get this library from? Either I have over-
   looked it in the distribution or it is just not there. I have all the other
   libs installed.

VideoVBT is an extension for multimedia VBTs. Since it relies on SRC
hardware, it was not included in the release. I have created a "fake"
version which you can find ftp.gte.com:/pub/m3/m3-sparc/19. I believe
version 3.2 will fix the dependencies so that you can compile without
problems.

Note that if you use my "fake" videovbt and you (mistakenly) access a
videovbt you will raise either either a nil dereference or a
NonImplemented execption.

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


======================================================================= 62 ===
Date:    18 Mar 1994 11:45:57 -0600
From:    0006378709@mcimail.com (Ward Harold)
Subject: NT version?

An NT version of Modula-3 was rumored to be under development by
the SRC people. Does anyone care to confirm or deny? For what it's
worth I'd be happy to beta test.

Thanks ... WkH

Ward K. Harold		wkh@ACM.org
MCI Consumer Markets	(512) 416-4356
4115 Freidrich Lane
Austin, TX  78744



======================================================================= 63 ===
Date:    Fri, 18 Mar 1994 13:15:29 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Q: M3 3.1 formsvbt package / videovbt?


[sorry if this was posted twice.]

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

   Hello,

   when I tried to install the formsvbt package from the M3 3.1 release,
   I ran into this problem. Here are some lines from the "m3makefile.formsvbt":

   import (ui)		
>  import (videovbt) 
   import (vbtkit)
   import (formsvbtpixmaps)

   What is videovbt and where do I get this library from? Either I have over-
   looked it in the distribution or it is just not there. I have all the other
   libs installed.

VideoVBT is an extension for multimedia VBTs. Since it relies on SRC
hardware, it was not included in the release. I have created a "fake"
version which you can find ftp.gte.com:/pub/m3/m3-sparc/19. I believe
version 3.2 will fix the dependencies so that you can compile without
problems.

Note that if you use my "fake" videovbt and you (mistakenly) access a
videovbt you will raise either either a nil dereference or a
NotImplemented exception.

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


======================================================================= 64 ===
Date:    18 Mar 1994 15:14:12 GMT
From:    hendrik@CAM.ORG (Hendrik Boom)
Subject: Re: FOR SRC: can we have OS2 please?

Farshad Nayeri (fn00@gte.com) wrote:
: In article <CMsvL1.HHw@oasis.icl.co.uk>
 skj@oasis.icl.co.uk (Simon Johnston) writes:

:    For the attention of the SRC Modula-3 team:

:            Can we have an OS2 version please, released with WIN32?

I'm not on the SRC team, but have been planning to start an OS/2 port 
for a while now.  I managed to get a version 2.somethine port for DOS,
and its source, and was getting ready to port from that, using C as
cross-platform bootstrapping tool and thereby avoiding much of the
hassle with object file formats, etc.

Now that 3.1 is out, it's not as clear what I should be doing.  Probably
downloading the lot and thinking a bit longer before I start.

One question I'd like to have answered:

	Will the 3.1 code compile using any of the released 2.xx compilers?
	(my guess: it will almost compile, and is probably patchable)
Well, two questions:
	Is there a configuration of 3.1 that will generate C code?
	(my guess: no)

I will be setting up an OS/2 modula 3 porters' mailing list as soon as
my home site's net feed is regularized. I currently use
	hendrik@cam.org
and potential porters should write me here.  I'l post any relevant
mail on the mailing list when it is ready unless you ask me not to.

:    I am using the Linux version of the 3.1 compiler now and 
it is
:    great, I have had copies of SPwM3 and the Harbison book for ages
:    and have read them over and over, this is the language for me. I

The Linux-to-os/2 route seems to be the way to go, but I do not
have Linix installed.  Does anyone have any suggestions where the best
place is to get the parts of Linux I need for a Modula 3 port wiht the
minimum of installation effort?

:    have converted a good few people here onto M3, but our major
:    platform is IBM OS2 2.1, a 32bit OS which is (IMHO) better than the
:    WIN32 offerings (specifically NT). GCC exists for OS2 as a port
:    (GCC 2.5.7 called GCC/2) and as a more specific OS2/DOS version
:    (called EMX based on 2.5.7). Along with a complete set of GNU
:    tools, shells etc OS2 can look very Unix like if you want.

: It is probably not that hard since OS/2 is 32 bits and I believe it
: has thread support, etc. (On thing that will be great and interesting
: is to see SRC Modula-3 working on top of IBM System Object Model!)
: Unfortunately, I don't have a PC, so I can't be of much help here.

: I am not sure if SRC itself needs to do a port, or just someone out
: there who knows OS/2 well should try do this. I have heard people

Well I'm a someone out there.

: talking about an OS/2 port before. So far, most of the ports of the
: 2.11 version have been made by people outside SRC. Would you be able
: to do such a port? The m3-request folks are very good in helping
: people with porting and other problems. With release 3.1 it is even
: easier to port because most/all of the UNIX/Make dependencies have
: been removed.

:    Another thing is rather distasteful, can we have, or look at the
:    posibility of *commercial* versions of M3. Our design authorities
:    here like the language and concede that for the work we are doing
:    it would be ideal. However they cannot commit large scale, long
:    term development (on OS2) to a freeware compiler. Any ideas ??

: Although I've found that the level of quality and support of SRC
: Modula-3 is better than most commercial packages I've ever used, I
: agree with you that a second commercial source will be excellent for
: popularizing Modula-3.  The question is that who's going to do it...
: People have talked about it, but I've never seen one.  I even talked
: with a vendor who was doing an Object Modula-2 on the Macintosh who
: did not feel that they want to get into doing Modula-3. Even if
: someone is willing to do an implementation of Modula-3 (though the
: market share does not seem large) how would they be able to compete
: with SRC's system? Would you be willing to pay $1000+ for a system
: that you can get for free.

Ah! but is it *really* the same system?  I've found the CSET++
to be much better than gcc++, and well worth the introductory price.
I could see doing a p.d.port just to make the language available,
and then elaborately doing a non-p.d. port to pay the bills.
The p.d. port would sell the language, and the non-p.d. port would
sell quality-of-implentation and OS integration.

: Then again, if there is enough demand, a cygnus-like system may work.
: They can just use SRC's code, but sell support for it. I heard that
: SRC is revising their commercial licesnsing agreement for Modula-3 to
: allow more flexibility. Can someone from SRC elaborate on the intent
: behind the changes?

:    Sorry if all this sounds petty, its just that the language is good, 
:    and I want to see it prosper.

: I think you are making a good point; I think much of the readership
: here would want to make Modula prosper. 

: --farshad

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


======================================================================= 65 ===
Date:    19 Mar 1994 00:32:27 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Questions, suggestions on porting Mod3 to linux

  Does the version on vlsi.polymtl.ca have working threads ? I've just 
tried to get it to check, but the network transfer speed from here to vlsi
is fairly low, and I didn't want to clog up the net all night. 
 
  If anyone's got threads working properly (if the program appended below
doesn't segfault, that is), could they please email me ? I've been trying
to get the thread support working under Linux for a while now. 

  It's also probably worth mentioning that the unix interfaces for Linux
disagree with the Linux header files - I'm reworking them for Linux 1.0.

  Is anyone out there also doing either of these ? It'd be nice to get
together and pool our efforts. 



Richard.

 (test program :


MODULE Hello EXPORTS Main;

IMPORT Wr, Stdio, Thread, Fmt, Rd;

TYPE
 ch = Thread.Closure OBJECT ms : TEXT; OVERRIDES apply := SayCheese; END;

PROCEDURE SayCheese(self : ch ): REFANY RAISES {}  =
 VAR 
  a: TEXT;
BEGIN
Wr.PutText(Stdio.stdout, self.ms );
Wr.Flush(Stdio.stdout); 
LOOP
(*  Wr.PutText(Stdio.stdout, self.ms);  *)
 END;
  RETURN self;
END SayCheese;

VAR
 i : INTEGER;


BEGIN
(* Wr.PutText(Stdio.stdout," Type a line : \n");
Wr.Flush(Stdio.stdout);
 EVAL Rd.GetLine(Stdio.stdin); *)
 Wr.PutText(Stdio.stdout, " Integer byte size is " & Fmt.Int(BYTESIZE(INTEGER))
 
&"\n");
 Wr.Flush(Stdio.stdout);
FOR i := 1 TO 23 DO 
     EVAL Thread.Fork(NEW(ch, ms := "Cheese " & Fmt.Int(i)));
     Wr.PutText(Stdio.stdout, "Just forked " & Fmt.Int(i) & "\n");
     Wr.Flush(Stdio.stdout);
  END;
  LOOP
  END;
END Hello.


)


======================================================================= 66 ===
Date:    19 Mar 1994 03:11:08 GMT
From:    mako@FNALF.FNAL.GOV
Subject: Re: FOR SRC: can we have OS2 please?

>                  I managed to get a version 2.somethine port for DOS,
> and its source, and was getting ready to port from that, using C as
> cross-platform bootstrapping tool and thereby avoiding much of the
> hassle with object file formats, etc.
>
> Now that 3.1 is out, it's not as clear what I should be doing.  Probably
> downloading the lot and thinking a bit longer before I start.
>
> One question I'd like to have answered:
>
> 	Will the 3.1 code compile using any of the released 2.xx compilers?
> 	(my guess: it will almost compile, and is probably patchable)
> Well, two questions:
> 	Is there a configuration of 3.1 that will generate C code?
>	(my guess: no)

Wouldn't it be easier to use IL (those generated in .ic/.mc files) + m3cg
(the gcc backend) rather than trying to use 2.xx + a C compiler as a cross-
platform bootstrapping tool? You can keep these files by uncommenting the
line m3_option("-keep") in the make file (m3makefile).

						mako


======================================================================= 67 ===
Date:    Sat, 19 Mar 1994 05:54:09 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Q: M3 3.1 formsvbt package / videovbt? (uuencode, 98 lines)


Due to popular demand, here is a fake videovbt package for those of
you who can't wait for 3.2 (for good reasons, I am sure. :-)

This and other patches to bring up version 3.1 can be found in
ftp.gte.com:/pub/m3/m3-sparc. Some patches are sparc-specific while
others should be made in other configurations as well.

--farshad

begin 644 videovbt.tar.gz
M'XL( *H3:BT  ^U;67/;R!%6\I+2)(]YR$,>.EZ[EE2)$$'PL*EUBA )RK1Y
MA:1D.>LM%@2.1,0XN#AT;*7V5^W/R,_(C\AC>@8GJ3N1:"?&E$1BNGMZCNYO
M9GH&/--GU#X[]G8VGBX!0*U2 ?8-4 R_Q? [)$*E(I7*HHA_P#.U#7C")F4I
M3&>1_5U'>RH?>(#]B^4JLW]5DDJ9_=>1ENQO2J;ZB9[H!GW4.IA!R^6;[2]6
MRH']2^6**%:14)3*F?W7DHAN+FS'@YROYPGI6!YU3E2-0NZ0.<;AWB1/>O;,
M-Y B^S,]H*3$WIZIR_G#L6Y]0E5=_=A1G4O(11Z6)Y^[KUFZFI;P']E<T*7'
MK.,N_-=*8CC_%VO52HWAOU23,ORO(W7Z$V74EIL*1,;?)9W><#":0/HY@/4N
M(9,/0P4(P 1>,P%A H.]MTIS@J2>,GDS:(T),ZENZ3BGN+;O:+0.$^5HL@L_
M^JJA>Y?;H-F&[;C;<*[/O/DVS*E^.O?JT)1'K4Y?[NZ29&/@7EK:W+$MVT?Y
M$_V"SNJP-QAT%;F_"Z9+-3<IE\>*@K(N]8:J[])93K.MI$0^YOXE:$K.H&?4
MJ(>]$T)J(M;3K;:CFK0WQHHBX;BZ6&R<-#(4NE)AFS5]K/]$(RW+$J>HA#'/
MM^?75H \N(:I]%MH$OR,C2<\=)*]"?\_/Z*//0S_98;_<K6:X7\=:6WXW\[P
M_\7C/]KAK7G]KXCE!/]ED:__E2S^7TM*\!\9?QG_#P%\3JL'(KNPO/*;OD<3
MW";PUD\MVZ$]=;'0K=,4L,]LPS?I560'_CX<#9I*ZV"DP)AZAUP4HPPF<K7@
M[K)T#QL2RZJ&3]- 7)+LI)MV4PD.O1@TY/\)_^M<_RNE8HS_LL3C_W*EG.%_
M'>F)\1^OZ5_+'/ _C?^W9^HC+_T\W85_J$K1^5^Y5*RPB$"2,ORO)27X1^.G
MX!YBZC5\7Q2$X@^AFS$'(?+&'S9(N&5F"X6.:OZQL?%+8^/W&[\)7(BO'O]$
MFK+QQXW?Q>@PD1'P_H6\%NKY;8J'Y%^5D;[+Z,E1-)/_-?[_TD'ZIA"?4)_H
M&?X?&_^141_5Q>[&?ZT4X5^JLK, J-6J8H;_=:04_M,A/CI7& V'4X!8B>> 
MP$G(/;#.:(^"]0S_Z\7_8^[^[X%_MN</\5^4^/F?6*ED^%]'NHK_-,;ON:9S
M^F/@/,/_%[#_?USP;]P'_\GZ7^3O_]0JI6*&_W6DU?U_LLW_'#C/\/]EG/^9
M:SW_JXJUY/VOX/Z_7,WB_[6DWJ!UT$T?_A'EJ*D,)YU!'PXLW5P8U*261V>[
M\-T6M.6)W%VFP]:?'W8<AP$%NNZ>LM_I W?PD=P9*RN5!<Z=:%L]\KL%Q%?T
MWUA#7 ?3MEK#/<#_P)XL:<3J>,&5Z>.+P?]C^MB#\%\-[O^R^'\]*<-_AO]K
MWO]]U!C@+OR+E5J\_Q=+_/ZODKW_NYYTC_=_4\3_^A7@#/]?,OZ%)WG]_R[\
M5VJU2GS_+XE%OOZ+&?[7DKZ!7FAS#$(MZJAL23^^!)VY A1@9H-E>T!GNO<G
M\@T\/VK:EHL3ANZ;]4!(T+;/0!3*+^'EJQVQB'\@OJQ+4KTDPM]T$Y2+!3PG
MWV#AR9R"ME@ >S,/; N\N>Z"J6ISW:+@T(6!TX<+JF& 1<\-)&+&FH'I&YZ.
M@ )//>845.4NN*QN@<HT.#;0BX5JN3JJ/=>].9)=1!D6XI("0(=WR'-T+.;9
MH-GF@EHN=A>UG=@.;\PV'/L>8*-8EU7C7+UTP?4UK,D]\0T!.T&:PX,IOR-]
M#>.A/&JR64-I=XXPO^.[SHYA:ZI!.OTQ;I2ZTYCW/!<\XJRXA[/%:SC6+?8T
M/< )@Z64R,[S''+RG!TJXNQEI;$8&1[L(5^W-,.?45S#&>$&O<C)<_;M>KD8
MZ7:87D,_9CHQ<X-.Y.0Y^W:=7(SL]P^4GMP<WRK,JJ2&[BX(Z<ELL$S58D]!
M Y9K1W*>\VZOG8N1(VS$4)Z\63(6JXYSPKX5C"-11$,WF12::4?36&[Z7A[U
MQ]/V8#0]Z+_K#][WI^U.5QFC%)>>[N-3HW#:X)D!SPPP\TY1AE/4/I)''64\
M'2GC0?=0:2&_B)+MKKR/*K"CTF#(7K$IG**'# :3)-?IR>^46&[\1N&=Y"US
MY\PAARS+Q@RQQ4;LG<*'[!-%:67(^]0@0WD\+K(G;@DVDGDT*T,!0M\)^&+ 
M;S;S0;ZTDI=8GE>L.@W-\0-JF5$=U<(6!(1*+&;,&@6Y00:'RJ@K?Y@6HQ&*
M"+S"@J$UR)X\5J;RB/41*?T&:_H(I7#D>IU),%@MI1T:3ZAS'^6]X'Z:HD>]
MP\?(W%RF_VXOLA=6:38X*4V1 C*G-UD+ U>+1PLG*)SWIII]AK/D*15L-$V_
MV5T2(F2B](9=><),X-D+?M@G>+@=( 3GM7J=&3K:]K*"X13 ;,%8@9FY%YZ+
M4 CFX//Y);+BWN-SW&/2&DQ#A4Q;3\KS3ZXF>$0_BA\PI@NIH;(@DXP2.CYF
MP@9T4P/(0*&>LT_39Y_TPF-?'@0RB$ I*LL 9++<J,RX 35/#CK!=,*8OIZ2
M6:XGTH<PZXUQ/Y,4PCG:='&CPC/X_4EGM7.U>?)7Y6"<B)JGC!D\\:^?J._R
M!\V>T3.=GF/)5 W,;')_OQNA#-OT[7=;Z <*O.C"LQ?M9QCDONA_2]XK\F$B
M9)'ES;-NN5Y@Y,V<-@-A%T(*%#2T9; )2OW$ B#PXG"VRJ.*^^E(O:9YG8[[
M*0GN>O[C-L17Q7=HN*8H3A31KE-P;4$41 @A%.FX9[&+J^4,"PKN"G7GNI*W
MB*@79-.S?6U^JU (Z&N:132#JA:R=L$QH7!R78=7ZKLJ48<V;BXVG^<XPA& 
MZG5J"D=BHS#L-!OPD6P6/DC)M*NZ+G6\QL)W:,%#N#8*=@,*'\J!A.?XE)=!
MV^WWIN/!P:BI\+DA>/=S&H"6N!IN"+4Y]H7WB1!/GUTRLY[HN#$3X&,.8:":
M%)YM;SV#@AWEA)4LQ3V:._V^6'CU S*P7C9C)?RMGU/2&@9)24X5;-R2?<0!
M6#BZY<'?X4)U3MU@9$D\U*Q=U[1J2[#3[=@2]-7\!6L.-FASJ3V"N2)G,KD;
M&K$96#D.GO!)6JC>? N$U.""H!RQH55:4[8#%$;C47/:[+62XE(PF[A;A*#M
M<:E(EWZ-S000TC_1"BGIV6"%8D:4$.QA)H(NP<4KCO]&BMSJ*4\28]QY_AO=
M_Y9%L5HJ<_'L]Y_K263"@C#\4^&$[38B?P ,FS[A-@?C(I7%0H9][D*;K<'H
M6%$ A<XN #E<+1(&4 Y%<+I!.-E2FH .#\=48S_, ER?9Q0#L)E+,&)#3L%=
M4$T_T368J\[L7,4Y@"W5&'H)!$CG!"YMGP6.21MH<,3B!BUD+!Y/1HW(4>%4
MV X:!QC?<5#DD^*F>@DXN[ES[ &9V!CYZ<9L&QS? E/BF5W6S6@A"NCN7%\(
M,$G7X] ??=VA+IG@A\=^)X^; ::S4("VZKAS=09]]9(Z.N0L_MTX]3!HMLT\
M3'SL#SV&4@F*K^JB5"^60!E/0'SUJDS6@__/[7]9RE*6/E_*[O^R\__L_O_K
M31G^,_QG]_]?;\KN_S/\9_?_7V_*[O^S^__L_C^[_\_N_[/[_^S^/[O_S^[_
.OZ[[_W\#SR/$"0!@  #\
 
end
--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 68 ===
Date:    Sun, 20 Mar 1994 05:58:40 GMT
From:    k2cheung@undergrad.math.uwaterloo.ca (Cheung Kai Chung)
Subject: source code?

    Hello. Can someone point out to me where I can find a modula 3 compiler
  source code? i.e. the source code of the c (or c++?) program which
  generate c++ code from modula 3 programs.

    Any help is greatly appreciated. Thanks in advance.

    Best regards,

  William.



======================================================================= 69 ===
Date:    21 Mar 1994 11:18:06 GMT
From:    toshok@cs.uidaho.edu (Chris Toshok)
Subject: Problem with TextPort filters

Hello all,

 I am having a problem with SRC Modula-3 release 3.1.  I try to do the
following:

   RETURN NEW(FVTypes.FVTextEdit, tp:= NEW(TextPort.T, filter:= MyFilter))

where MyFilter is defined as:

   PROCEDURE MyFilter(VAR cd  : VBT.KeyRec) =
   BEGIN
     < code deleted >
   END MyFilter;

and modula-3 gives me the following errors:

   new source -> compiling ../src/Main.m3
   "../src/Main.m3", line 988: default is incompatible with method type (filter
)
   "../src/Main.m3", line 988: procedure is not compatible with method (filter)
   2 errors encountered

Why?  I really need this code to compile.  It used to, with release 2.11
(whichever was the last release), but it doesn't anymore.  Help.

--
------------------------------+-----------------------------------
Chris Toshok                  |  Assistant Systems Administrator  
a.k.a. Toshok the Functional  |  Computer Services
                              |  University of Idaho
                              |
email: toshok@cs.uidaho.edu   |  Research Assistant      
phone: (208)885-5562          |  Laboratory for Applied Logic  
smail: P.O. Box 3900          |  University of Idaho          
       Moscow, Id 83843-1919  |
                              |  Vice Pres.  Student Chapter, ACM
------------------------------+-----------------------------------
www: http://www.cs.uidaho.edu/lal/students/toshok.dir/toshok.html
------------------------------------------------------------------


======================================================================= 70 ===
Date:    21 Mar 1994 06:23:26 GMT
From:    luca@src.dec.com (Luca Cardelli)
Subject: Announcement: Obliq paper


Obliq is a distributed scripting language. It is based on Modula-3 
Network Objects, and was designed to be embedded in Modula-3
applications.
 
It has now evolved into a self-contained language, whose direct ties 
to Modula-3 are limited to the network objects run-time, and to a 
rich collection of libraries. 

The following paper can be obtained via ftp; instructions are at 
the bottom. The Obliq software distribution (matching the paper) 
will be part Modula-3 v3.2. The current distribution of Modula-3 
v3.1 includes a slightly older version of Obliq. All these are or 
will be available from gatekeeper.pa.dec.com 



                Obliq: A Language with Distributed Scope

                            Luca Cardelli
                   Digital, Systems Research Center

Abstract

Obliq is a lexically-scoped untyped language that supports distributed 
object-oriented computation. An Obliq computation may involve multiple 
threads of control within an address space, multiple address spaces 
on a machine, heterogeneous machines over a local network, and multiple

networks over the Internet. Objects are local to a site, while
computations 
can roam over the network. 

The most novel feature of Obliq is its combination of distributed 
computation and lexical scoping. In lexically scoped languages, the 
binding location of every identifier is determined by simple analysis 
of the program text. Therefore, one can be sure of the meaning of 
program identifiers, and can much more easily reason about the behavior

of programs. In a distributed language like Obliq, lexical scoping 
assumes a further role. It ensures that computations have a precise 
meaning even when they migrate over the network: a meaning that is 
determined by the original binding location and network site of
identifiers, 
and not by their execution sites. 

Network-wide scoping becomes an issue in presence of higher-order 
distributed computation, as in the situation of remote sites accepting 
procedures for execution; the typical case being compute servers. 
The question is what happens to the free identifiers of such 
network-transmitted procedures. Obliq takes the view that such
identifiers 
are bound to their original locations, as prescribed by lexical
scoping, 
even when these locations belong to different network sites. 

Distributed computation interacts well with the notion of objects. 
For example, network services normally accept a variety of messages; 
it is then natural to see each service as a network object (or, more 
neutrally, as a network interface). Obliq supports objects in this 
spirit, relying for its implementation on Modula-3's network objects. 

The Obliq object primitives are designed to be simple and powerful; 
a main trait of the language is the relation between local and
distributed 
semantics of these primitives. Obliq objects are collections of named 
fields, with four basic operations: selection/invocation,
update/override, 
cloning, and delegation. Every object is potentially and transparently 
a network object. An object may become accessible over the network 
either by the mediation of a name server, or simply by being used 
as the argument or result of a remote method. 

In addition to the distribution of objects, the distribution of
computations 
must be designed carefully. It is clearly desirable to be able transmit

agents for remote execution. However, in general, one should not 
be satisfied with transmitting just the program text of such agents. 
Program text cannot carry with it live connections to its originating 
site, nor to any data or service at any other site. Hence the process 
of transmitting program text over the network implies a complete 
network disconnect from the currently running distributed computation. 
In addition, unpredictable dynamic scoping results from transmitting 
and then running program text containing free identifiers. 

Obliq computations, in the form of procedures or methods, can be 
freely transmitted over the network. Actual computations (i.e.
closures, 
not source text) are transmitted; lexically scoped free identifiers 
retain their bindings to the originating sites. Through these free 
identifiers, migrating computations can maintain connections to objects

and locations residing at various sites. Disconnected agents can still 
be represented as procedures with no free identifiers. 

>From the point of view of a server executing a foreign agent, distributed 
lexical scoping and strong run-time typing together provide a safety 
and security guarantee. Namely, the foreign agent has access only 
to the data that it carries with it via lexical bindings, or that 
it explicitly receives in the form of parameters. 


Contents

1. Introduction
    1.1 Language Overview
    1.2 Distributed Semantics
2. Local Objects
    2.1 Objects and their Fields
    2.2 Object Operations
    2.3 Simple Examples
3. Remote Objects
    3.1 State
    3.2 Transmission
    3.3 Distributed Computation
    3.4 Self-inflicted Operations
    3.5 Protected Objects
    3.6 Serialized Objects
    3.7 Name Servers
    3.8 Execution Engines
4. Local Techniques
    4.1 Recursion and Iteration
    4.2 The Object-Oriented Numerals
    4.3 The Prime Numbers Sieve
    4.4 A Calculator
    4.5 Surrogates
5. Distributed Techniques
    5.1 A Serialized Queue
    5.2 A Compute Server
    5.3 Remote Agents
    5.4 Agent Migration
    5.5 Object Migration
6. Conclusions
    6.1 Future Work
    6.2 Acknowledgments
7. Syntax overview
A. Language Reference
    A.1 Syntactic Structures
        A.1.1 Identifiers
        A.1.2 Definitions
        A.1.3 Terms
        A.1.4 Term Sequences
        A.1.5 Built-In Operators
        A.1.6 Operator Precedence
    A.2 Data Structures
        A.2.1 Value Identity
        A.2.2 Constants
        A.2.3 Operators
        A.2.4 Arrays
        A.2.5 Options
        A.2.6 Objects
        A.2.7 Protection and Serialization
        A.2.8 Object and Engine Servers
    A.3 Control Structures
        A.3.1 Definitions
        A.3.2 Assignment
        A.3.3 Sequencing
        A.3.4 Procedures
        A.3.5 Conditionals
        A.3.6 Case
        A.3.7 Iteration
        A.3.8 Concurrency
        A.3.9 Exceptions
        A.3.10 Errors
    A.4 Methodology
        A.4.1 Type Comments
    A.5 Lexicon
    A.6 Syntax
B. System Reference
    B.1 The Executables
    B.2 The Top-Level
    B.3 Program Files
    B.4 Modules
    B.5 The Network Objects Daemon
    B.6 Built-in Modules
        B.6.1 Sys
        B.6.2 Bool
        B.6.3 Int
        B.6.4 Real
        B.6.5 Math
        B.6.6 Ascii
        B.6.7 Text
        B.6.8 Array
        B.6.9 Net
        B.6.10 Thread
        B.6.11 Rd
        B.6.12 Wr
        B.6.13 Pickle
        B.6.14 Lex
        B.6.15 Fmt
        B.6.16 Process
        B.6.17 Color
        B.6.18 Form
C. Programming Reference
    C.1 The Package Hierarchy
    C.2 The Interfaces
    C.3 The Libraries
    C.4 Embedding Obliq
    C.5 Extending Obliq
    C.6 Extending Obliq with new Packages
    C.7 Building a Customized Obliq Interpreter
References
Index

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

    ftp gatekeeper.pa.dec.com
    anonymous
    <your email address>
    cd pub/DEC/SRC/personal/luca
    binary
    get ObliqPaper.ps.Z
    quit

    uncompress ObliqPaper.ps.Z


Print Obliq.ps on Apple or HP postscript printers, for best results.
Online postscript viewers do not necessarily work properly on this 
file (although it is legal postscript).



   Luca


======================================================================= 71 ===
Date:    21 Mar 1994 15:29:59 GMT
From:    jason@convex.com (Jason L. Eckhardt)
Subject: M3 for i860 problems


I have just recently picked up the boot-OKI tar for the i860 version of
SRC M3. I actually have a Stardent platform rather than an OKI platform, 
but they both are i860's running SVR4.
When m3boot tries to build the assembly files, many of them fail with
assembler errors: "error: st.l misaligned: 0xfff9."
The lines that produce the errors are always stores like this:
 st.l %r0, [-7]@l(%r31). The -7 is sometimes -1, -3, or -9 as well.

Can anyone tell me how to assemble these properly? It does seem that -7
displaced from %r31 would be unaligned. Is this possible a gcc compiler
error? (The assembly files have gcc2_compiled: in them).
 
Or if anyone knows of an already built binary for the i860, that would be
great.

thanks, jason.

jason@wagner.convex.com



======================================================================= 72 ===
Date:    Mon, 21 Mar 94 08:46:55 -0800
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Re: Problem with TextPort filters


In FVTypes.i3, the FVTextEdit is defined to take a Port.
A Port is a subtype of TextPort.T with the following 
comment:

    (* If you create a subtype of "FVTextEdit", its ".tp" field must
       be "NIL" or a subtype of "FVTypes.Port". *)

Thus, if you change your code from 

   RETURN NEW(FVTypes.FVTextEdit, tp:= NEW(TextPort.T, filter:= MyFilter))

to

   RETURN NEW(FVTypes.FVTextEdit, tp:= NEW(FVTypes.Port, filter:= MyFilter))

I think you'll be in business. You should also check TextPort's filter 
methd to be sure that your procedure MyFilter has the correct signature. 

Sorry for the confusion. There are probably a host of other incompatible 
changes that were made between 2.11 and 3.0 in various libraries. 
Hopefully, you'll find the changes make life in M3land sufficiently 
better that you'll endure the conversion hassles with a smile! :-) 

Marc


======================================================================= 73 ===
Date:    Mon, 21 Mar 1994 14:03:44 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: source code?


       Hello. Can someone point out to me where I can find a modula 3 compiler
     source code? i.e. the source code of the c (or c++?) program which
     generate c++ code from modula 3 programs.

The latest release is a Modula-3 program that generates an intermediate
language passed to a special version of gcc, from Modula-3 programs.
The source code is on gatekeeper.dec.com:pub/DEC/Modula-3.
--
---------------------------------------------------------------------

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

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


======================================================================= 74 ===
Date:    21 Mar 1994 13:32:37 GMT
From:    hendrik@CAM.ORG (Hendrik Boom)
Subject: Re: FOR SRC: can we have OS2 please?

mako@FNALF.FNAL.GOV wrote:

: Wouldn't it be easier to use IL (those generated in .ic/.mc files) + m3cg
: (the gcc backend) rather than trying to use 2.xx + a C compiler as a cross-
: platform bootstrapping tool? You can keep these files by uncommenting the
: line m3_option("-keep") in the make file (m3makefile).

It would be if I had a working Modula 3 version 3.1 on a system I had
access to.  Without that, it's a bit hard to generate IL.

Or is there already a 3.1 DOS port to work from?

: 						mako


======================================================================= 75 ===
Date:    Mon, 21 Mar 1994 20:15:20 GMT
From:    jmeehan@mendoza.adobe.com (Jim Meehan)
Subject: Re: Problem with TextPort filters


      PROCEDURE MyFilter(VAR cd  : VBT.KeyRec) =
      BEGIN
	< code deleted >
      END MyFilter;

MyFilter should be a procedure of two arguments. 'cd' is the
second. As Marc points out, the first should be a subtype of
FVTypes.Port.



======================================================================= 76 ===
Date:    21 Mar 1994 20:51:42 GMT
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Modula-3 User's group - Initial Call for Participation


	Modula-3 User's Group '94 - Initial Call for Participation
	-----------------------------------------------------------

Now that the much anticipated 3.x release is out, it seems like 
a good time to hold another Modula-3 User's Group Meeting. As
many of you know, the last one was in 1992 and I think all of
the attendee's found it worthwhile to attend. I'm willing to
organize this if there are enough people interested in attending.
Of course, willingness to attend is always predicated on date
and location. Here are some possible dates and locations for
it:
        Summer Usenix - Boston, Ma              June 6-10
        ASPLOS VI     - San Jose                October 4-7
        OOPSLA '94    - Portland, Or            October 23-28
        ACM MultiMedia  San Francisco           October ???

The format of the meeting would be much the same as 
the previous one; more or less a workshop style with presentations
and informal discussion groups.

If you are interested in attending please send mail directly to me 
with your preference of date/location. I'll tally the interest level 
and make another posting. If you are interested in presenting 
something informally, please let me know as well !

Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories, Inc.

2 Elizabeth Drive
Chelmsford, Ma.
01824




-- 
Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories, Inc.

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 77 ===
Date:    21 Mar 94 21:50:49 GMT
From:    harbison@tartan.com (Sam Harbison)
Subject: Harbison's "Modula-3": errata. And, new edition?

The errata list "beethoven.cs.colorado.edu:pub/M3/harbison-errs.ps.Z"
appears to be the most complete listing. I noticed only the following
omissions:

p. 28:-5:  Change "before that of A" to "before that of a". Also, interface
declarations must have constant initializers, which is not true of blocks.

p. 32:22: Change "A, B, C, and D" to "A, B, C, D, and E".

p. 100:9: Add to end of first paragraph: "Indexing expressions must be
assignable to the index type of the array.  Using an index that is outside the
range of the index type is a checked run-time error."

p. 116: In the railroad diagram, change "ALL" to "ANY".  Also, eliminate
the semicolon at the end of ProcDecl; the semicolon is shown on p. 20.

			---------

This seems to be a good time to raise the issue of doing a new edition of
"Modula-3."  The outstanding errors can be fixed, of course, but it would be
good to think of new material to add.  So, I'd like to solicit readers of this
newsgroup to tell me:

 - What new material would you like to see in a 2nd edition? A more
   complete description of SRC Modula-3? Descriptions of new libraries?
   (Basic ones, or also more advanced libraries like net objects?)

 - What existing material do you think could be improved or expanded upon?

 - How are you using the book now? Teaching, learning, referencing?

And, finally, if you have a big wish list, would you be willing to help with
the revision?

If you respond directly to me, I'll collect and repost the suggestions.

Sam Harbison, Director of Commercial Products
Tartan, Inc.; 300 Oxford Drive; Monroeville, PA 15146; USA
Phone +1 (412) 856-3600 x147. Fax +1 (412)856-3636. Email: harbison@tartan.com
-- 
Sam Harbison, Director of Commercial Products
Tartan, Inc.; 300 Oxford Drive; Monroeville, PA 15146; USA
Phone +1 (412) 856-3600 x147. Fax +1 (412)856-3636. Email: harbison@tartan.com


======================================================================= 78 ===
Date:    Wed, 23 Mar 1994 13:28:35 GMT
From:    shang@corp.mot.com (David L. Shang)
Subject: Who Win the War of Co. vs. Contra?


	Alas, I have to give up in trying to let my pony be an 
	animal. Why cann't I prohibit somebody to feed my pony 
	with flesh just because pony is an animal and flesh is 
	kind of animal food? I have to say:  my pony is not an 
	animal! I won't reuse animal definition for my pony!

What's wrong? Let's have an example:

	class Animal
	{     function  eat (food: AnimalFood); 
	};

Class Animal has a method eat, which takes animal food as its input. In a  
herbivore animal class, the animal food should be specialized to plant food:

	class HerbivoreAnimal is an Animal
	{	function  eat (food:PlantFood); 
	};

Now we have an animal variable:

	var anAnimal: Animal;

When the varaible refers to some animal, we can feed it:

	anAnimal.eat(flesh);

Is it right? Sure, it is. The variable anAnimal is declared as an Animal, and  
the eat interface in class Animal says that any animal food is okay for its  
input.

Again, is it right? No, it is not. If the variable anAnimal happens to take a  
 
herbivore animal, oops, it's going to choke.


Solution 1: Let Herbivore Animal Eat Flesh

Some people argue that it is not right to specialize the food type for a  
herbivore animal to eat. If you do not specialize the food, there is no problem
  
in your program then. Languages like C++ and Modula-3 prohibit such  
specialization.

Why no problem now? Because you let your herbivore animal be able to eat flesh!
 
Yes, there is no problem with my program. But there is a problem with my  
herbivore animal. My program does not reflect the real world.


Solution 2: Let Herbivore Animal Eat Anything

Some languages even go to an opposite extreme. You cannot specialize the food  
type, but you can generalize the food type. In class HerbivoreAnimal, you can  
specify its food as any thing, but you cannot limit it to specific animal food.
  
It doesn't matter even if it is not food at all. Languages like Sather, POOL-I,
  
and Trellis let you do this way. This approach leads to a long debate between  
covariance and contravariance.

Do you feel that contravariance is better than novariance in languages like C++
  
or Modula-3? I don't. By contravariance, now I can let my herbivore animal be  
able to eat any thing: stone, knife, cannon, needless to say flesh.


Solution 3: Animal Cannot Eat

Some people said that you should not declare eat method in animal. It should be
  
declared in subclasses respectively. Then, eat is not a property of an animal, 
 
that is, an animal cannot eat! Obviously, this is not a solution. It eliminates
  
many opportunities of code reuse.


Solution 4: Herbivore Animal Is Not an Animal

Then, some other people said that a herbivore animal is not an animal because  
it does not eat something that some other animals eat.

What? You may not accept this argument. But wait, there is a compromise: a  
herbivore animal is not a subtype of animal but they can still be a subclass of
  
animal. To be more specific, the approach tells you that in the case of a  
covariantly typed methods, the subclass is not a subtype. Therefore, a  
herbivore animal is not a subtype of animal, but it can still reuse the animal 
 
code by being a subclass.

The F-bounded polymorphism is established on this belief. A number of languages
  
are designed on this thoery. ABEL and TOOPL are examples. The latest version of
  
Eiffel will tell you that subclasses which are subtypes by declaration but not 
 
in terms of the interface which is supported.

Being not a subtype of animal, a herbivore animal cannot be assigned to a  
animal variable. An animal cannot represents a herbivore animal. After all, a  
herbivore animal is not an animal. You cannot have a polymorphic all-animal  
interface that can be shared and reused by other software components which are 
 
supposed independent to a concrete animal. This certainly affects the software 
 
reusability.

Separating the subtype concept from subclass signaficantly complicates the  
concept. When the compiler tells you that a herbivore animal is not a subtype  
of an animal, you'll definitely have a hard time to figure it out why not.

This approach also complicates the language compiler. It requires system-level 
 
type checking, which gives up on local checkability. It has been proved that to
  
determine whether a type is a subtype of another is undecidable in general.

It is an open question that whether this approach is able to work on the open  
world assumption, the essential assumption for developing large-scale software.
  
Eifel's system-level type-checking works only on  the closed world assumption, 
 
an assumption usually works for small toy programs.


The Right Solution: Let the Food Type Depend on the Animal Type

A herbivore animal should eat pland food only. A herbivore animal should be an 
 
animal and a animal variable should be able to represent a herbivore animal.
 
It is not the problem that we specialize the food in herbivore animal, nor the 
 
problem that we consider a herbivore animal being an animal.

The problem is the eat method interface defined in Animal class. It is not a  
precise interface.

Given a class C and a protocol (method interface) P defined in C, for each  
object O that belongs to C, P should be applicable to O. 

Obviously, the method eat defined in class Animal is not applicable to each  
individual animal because it can accept any type of food.

The problem comes from the type intra-dependency, which has not been fully  
recognized so far. Oftentimes, the type of a component or the protocol of a  
method interface depends on the type of the enclosing object. I call this  
phenomenon as type intra-dependency (refer to my paper: Type-Safe Redefinition 
 
in Proc. of 3rd Intl. Conf. on Software Engineering and Knowledge Engineering  
for detail).

The food class in method eat should be specified as a variable to the class of 
 
Animal:

	class Animal
	{	function eat (food: thisclass'Food);
	};

that is, the food for the animal to eat should be of the type edible to the  
animal, instead of any food.

When subclasses are derived, the class of food is automatically redefined in  
covariance with animal classes. Since the interface is accurate, local type  
checkability is always ensured.

A language named Cluster can reflect this dependency very well. The language  
was first introduced in SIGPLAN Notices, Jan. 1991. At the time I wrote this  
paper, I did not realized the covariance problem yet. Therefore, when you read 
 
the paper, you may not find the direct anwser to covariance, but the answer is 
 
there. I have recently finished a paper: Covariance Spsecification. If anybody 
 
is interested, contact me.

David Shang


======================================================================= 79 ===
Date:    Wed, 23 Mar 94 16:40:42 EST
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Converting Capability.T to text ?


Before I implement this myself, I thought I'd check
to see if  anyone has already done this and might
be willing to share..


--geoff

Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories, Inc.

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 80 ===
Date:    23 Mar 94 18:16:39
From:    jeff@karazm.math.uh.edu (Jeff M Younker)
Subject: Re: Who Win the War of Co. vs. Contra?



This discussion seems to be ignoring how things are actually done in
Sather.  We have paramaterized classes.  We also have a difference between
inheritence and implementation.

I think this code should do everything that people are arguing about.  It
should also be legal in Sather.

The first irst thing we need to do is to define what foods are.  Its a
pretty broad concept, but we can break them all down to nutrients.

Now we need to define what a nutrient is.  Since everything breaks down to
the same amino acids and protiens, we'll just use a single nutrient class.
No comments about silicon based life please.  And we'll assume water and
not ammonia for the primary liquid. 
*****

class NUTRIENT is

   ... 
   amount:INT is ... end;
   create(INT):SAME is ... end;
   ...
   
end;  -- class NUTRIENT


*******
Now that we have nutrients, lets make foods.
*******


abstract class $FOODS
is

    breakdown:NUTRIENT is end;

end;  -- abstract class $FOODS


******
Now lets do some organization.  Most of what we are talking about are
living things, so we'll make a generic class to organize the whole thing.
Something very important is that all living things can be eaten.  They
are all foods.  But notice that all foods are not living things.  Think
about twinkies and velveta cheese slices if you have any doubt of this.
******


abstract class $LIVING_THINGS < $FOODS
is

    include $FOODS;  -- we get all the definitions of what food is.

    -- living things have some other characteristics also...
    --
    metabolize(NUTRIENT) is end;
    reproduce(SAME):ARRAY{SAME} is end;
    die:NUTRIENT is end;

end;


******
Plants are living things.  By the very nature of living things plants are
also foods.   Were also going to ignore plant foods for now.  Carnivorous
plants are also ignored.  We can add them later.  What we want to talk
about today are animals. 
******


abstract class $PLANTS < $LIVING_THINGS
is

   include $LIVING_THINGS;  -- get default actions for living things $FOODS

   -- now we implement some additional plant actions...
   --
   create(INT):SAME is ... end;
   pick:SAME is end;
   ferment:ALCOHOL is end; 

end;


*****
Dung isn't very interesting to me, but some beetles like it, so they get to
eat it too.  And I don't want to model decay, so lets just leave one kind of
turd in the world.
*****


class EXCREMENT < $FOODS is

   ...
   breakdown:NUTRIENT is ... end;
   turd_size:INT is ... end;
   create(size:NUTRIENT):SAME is .. end;
   ...

end;  -- class EXCREMENT


*****
Now we seem to have enough things that we can really start making sense
with animals.  Note that all animals are also foods.
*****

abstract class $ANIMAL{FOOD<$FOODS} < $LIVING_THINGS
is

   include $LIVING_THINGS;
   ...
   create(size:INT):SAME is ... end;
   make_sound is end;
   eat(FOOD):EXCREMENT is end;

   vomit(dinner:$FOODS):VOMIT{$FOODS}
   -- all animals can get the same behavior for vomiting
   is
       return #(dinner);
   end;

   is_this_digestable_food($FOODS}:BOOL is end;
   ...

end;  -- abstract class $ANIMAL


*****
Now lets make a general class of animals.  Lets call them herbivores.  The
special thing about herbivores is that they can eat only plants, so we
build in this restriction.

However we need to notice that all herbivores can not eat all plants.  If
we feed grass to a koala it's going to starve to death.  By the same token,
flossy the cow is going to be poisoned by eucalyptis leaves.  So it makes a
great deal of sense that we are not allowed to instantiate a generic
herbivore.

The herbivore class just provides a generic framework for a group of
animals.
*****

abstract class $HERBIVORE{PLANT<$PLANTS} < $ANIMAL{PLANT}
is

   include $ANIMAL{PLANT};
   ...

   eat(dinner:PLANT):EXCREMENT
   --
   -- they all eat plants the same way
   --
   is

      return #EXCREMENT(dinner.pick.breakdown);
      -- this is a cow of perpetual motion;

   end;
   

   is_this_digestable_food(questionable_food:$FOOD):BOOL
   --
   -- all herbivores know that they can *at least* eat plants...
   --
   is
       typecase questionable_food 
           when PLANT then return #(true); end
           else return #(false);
       end;
   end;

   ...

end; -- abstract class $HERBIVORE

*****
With these classes, now we can make specific herbivores.  Notice: it makes
no sense to make a generic animal ( $ANIMAL{$FOOD} ).  It makes no sense to
make a generic herbivore ( $HERBIVORE{$PLANTS} ).  But now we can easily make
specific herbivores.  Let's start with a cow.

Cow's eat specific kinds of plants.  They eat grass (big simplification).
So we need to create grass.
*****

class GRASS < $PLANTS
is

    breakdown:NUTRIENT is ... end;
    pick:SAME is ... end;
    ferment:ALCOHOL is ... end;
   
end;  -- end class GRASS


*****
Now that we have a kind of food for our cows, we can actually create the
cows.
***** 

class BOVINE < $HERBIVORE{GRASS}
is
    include $HERBIVORE{GRASS}; -- we get the default behaviors for herbivores

    make_sound
    --
    -- cows go mmooooooo
    --
    is

       #SPEAKER::output("mmoooooo");

    end;

    come_home:SAME is ... end;  -- something that only cows can do...

end; -- end class BOVINE



******
And now we'll make another herbivore.  Lets make the koalas we mentioned
earlier.  First we make koala chow.
******


class EUCALYPTUS < $PLANTS
is

   include $PLANTS
   ...
   produce_tannin
   -- something characteristic of eucalyptus I believe
   -- 
   is ... end;

end;  -- end class EUCALYPTUS


******
And now we can create the koalas.  In addition to herbivore things, koalas
can look cuddly.  They also shred your arms.
******

class KOALA < $HERBIVORES{EUCALYPTUS}
is

    include $HERBIVORE{EUCALYPTUS};
    --
    -- and now for koala specific actions
    --
    look_cute is ... end;
    act_vicious is ... end;
    climb is ... end;

end;  -- end class KOALA



********
and now we could do things like...

 knoll::=#GRASS(10);    -- a small knoll
 tree::=#EUCALYPTUS(20);  -- a big tree
 flossy::=#BOVINE(30);  -- flossy's a fat cow
 ned::=#KOALA(5); -- a tubby koala


 ned.is_this_digestable_food(tree);  -- should be true
 ned.is_this_digestable_food(knoll); -- should be false
 flossy.is_this_digestable_food(knoll); -- should be true
 flossy.is_this_digestable_food(tree);  -- should be false

 flossy.is_this_digestable_food(ned); -- should be false also
 big_turd::=flossy.eat(knoll);
 ned.is_this_digestable_food(big_turd); -- should be false or we've got
					   one wierd koala.

******
and from here on we could create deer,antelopes, giraffes, elephants, etc.
We could also specialize $ANIMALS to make carnivores and omnivores.  Then
we could make specific wolves, bears and humans.


Does this example do everything people need it to?





--
jeff younker                                     jeff@math.uh.edu 
-     These are my opinions.  If they resemble those of the     -
-   University of Houston it is possible that I am very sick.   -
        GS/M/O d--- -p+ c++ l m*/--- s/- !g  w+ t r x++ 


======================================================================= 81 ===
Date:    24 Mar 1994 00:43:25 GMT
From:    toshok@cs.uidaho.edu (Chris Toshok)
Subject: Proxac users?

Hello all,

 I am in the process of trying to get Proxac (a text editor for program
transformation and calculation) to build with the new release of SRC
Modula-3.  Unfortunately, it is riddled with errors because of changes in
the libraries.  I was wondering if anyone had taken the time to update the
source code for this utility.

 Also, we are running proxac on a DecStation (DS3100) built with the
previous version of SRC Modula-3 and it crashes at various times, dumping a
horrendously big core image.  Has anyone out there built a stable version
of this utility (meaning one that doesn't die intermittently)?  If so, mail
me please, telling me which platform, which version of gcc, which version
of Modula-3, etc., etc....

Thanks in advance,
-- 
------------------------------+-----------------------------------
Chris Toshok                  |  Assistant Systems Administrator  
a.k.a. Toshok the Functional  |  Computer Services
                              |  University of Idaho
                              |
email: toshok@cs.uidaho.edu   |  Research Assistant      
phone: (208)885-5562          |  Laboratory for Applied Logic  
smail: P.O. Box 3900          |  University of Idaho          
       Moscow, Id 83843-1919  |
                              |  Vice Pres.  Student Chapter, ACM
------------------------------+-----------------------------------
www: http://www.cs.uidaho.edu/lal/students/toshok.dir/toshok.html
------------------------------------------------------------------


======================================================================= 82 ===
Date:    24 Mar 1994 09:43:49 GMT
From:    jsmith@red-branch.MIT.EDU ()
Subject: Any suggestions for these errors?

When attempting to compile Modula3 for Linux (486).. linux kernel pl15 i 
get the following errors:


_m3main.o: Undefined symbol _M3__I_OSErrorPosix referenced from data segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): More undefined symbol _M3__I_OSErrorPos
ix refs follow
*** error code 1
"/usr/src/Modula3/boot-LINUX/m3build/templates/COMMON.BOOT", line 46: command e
xecute failed
*** call stack ***
"/usr/src/Modula3/boot-LINUX/m3build/templates/COMMON.BOOT", line 46: call to b
uilt-in exec
"./make.boot", line 363: call to procedure boot_prog
_m3main.o: Undefined symbol _M3__I_OSErrorPosix referenced from data segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): Undefined symbol _M3__I_OSErrorPosix re
ferenced from text segment
../../libm3/LINUX/libm3.a(FSPosix_m.o): More undefined symbol _M3__I_OSErrorPos
ix refs follow
*** error code 1
"/usr/src/Modula3/boot-LINUX/m3build/templates/COMMON.BOOT", line 46: command e
xecute failed
*** call stack ***
"/usr/src/Modula3/boot-LINUX/m3build/templates/COMMON.BOOT", line 46: call to b
uilt-in exec
"./make.boot", line 13: call to procedure boot_prog
/usr/lib/crt0.o: Undefined symbol ___libc_init referenced from text segment
../gcc/genattr.c:220 (genattr.o): Undefined symbol __IO_stderr_ referenced from
 text segment
../gcc/genattr.c:221 (genattr.o): Undefined symbol __IO_stderr_ referenced from
 text segment
../gcc/genattr.c:222 (genattr.o): Undefined symbol __IO_stderr_ referenced from
 text segment
../gcc/genattr.c:429 (genattr.o): Undefined symbol __IO_stdout_ referenced from
 text segment
../gcc/genattr.c:430 (genattr.o): Undefined symbol __IO_stdout_ referenced from
 text segment
../gcc/rtl.c:454 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:457 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:458 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:463 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:463 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:463 (rtl.o): Undefined symbol __IO_stderr_ referenced from text se
gment
../gcc/rtl.c:0 (rtl.o): More undefined symbol __IO_stderr_ refs follow
make: *** [genattr] Error 1




So... anyone have any helpful suggestions on what my problem is? or even better
HOW to fix it? Or what stupid thing I've done or not done properly :0

Any help is gladly accepted.


Jonathan Smith


======================================================================= 83 ===
Date:    Thu, 24 Mar 1994 13:55:33 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Any suggestions for these errors?

The boot-LINUX compiled right out of the box for me (Slackware 1.1.0, which
i beleive is 99pl15). Perhaps your compilation died because you needed more
space and when restarted a module was half compiled... My binaries are
on ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/linux.tar.Z.
--
---------------------------------------------------------------------

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

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


======================================================================= 84 ===
Date:    Thu, 24 Mar 1994 18:28:41 GMT
From:    shang@corp.mot.com (David L. Shang)
Subject: Re: Who Win the War of Co. vs. Contra?



This thread has been directed to comp.object


David Shang


======================================================================= 85 ===
Date:    24 Mar 1994 21:48:47 GMT
From:    fraser@hare.europarc.xerox.com (Quentin Stafford-Fraser)
Subject: Source packages


The 3.1 dosumentation talks about 'source packages'. A source package
"contains a collection of Modula-3 sources; it builds nothing".

I want to create one of these because, for a complex reason, I want to
include the same source in two different libraries, but don't want to
keep a compiled version in a separate library.

Am I right in thinking that I can't install a source package using
m3ship?  If an m3makefile doesn't contain Library() or Program() then
no .M3SHIP file is created, so m3ship won't work.

Is there an 'official' solution, or do I install by hand?

Thanks,
Quentin
--

 ----------------------------------------------------------------------
                       Quentin Stafford-Fraser
            
 Cambridge University Computer Lab        Rank Xerox Cambridge EuroPARC
 qs101@cl.cam.ac.uk                           fraser@europarc.xerox.com
 Tel: +44 223 334411                                Tel: +44 223 341521
 Fax: +44 223 334679                                Fax: +44 223 341510

           http://pelican.cl.cam.ac.uk/people/qs101/me.html
 ----------------------------------------------------------------------



======================================================================= 86 ===
Date:    Thu, 24 Mar 1994 20:54:54 +0000
From:    neil@aldur.demon.co.uk (Neil Wilson)
Subject: Re: Who Win the War of Co. vs. Contra?

David L. Shang (shang@corp.mot.com) wrote:

: It is an open question that whether this approach is able to work on the open
  
: world assumption, the essential assumption for developing large-scale softwar
e.  
: Eifel's system-level type-checking works only on  the closed world assumption
,  
: an assumption usually works for small toy programs.

It is clear then that you don't fully understand Eiffel type checking, read on.

: The Right Solution: Let the Food Type Depend on the Animal Type
: The food class in method eat should be specified as a variable to the class o
f  
: Animal:

: 	class Animal
: 	{	function eat (food: thisclass'Food);
: 	};

: that is, the food for the animal to eat should be of the type edible to the  
: animal, instead of any food.

: When subclasses are derived, the class of food is automatically redefined in 
 
: covariance with animal classes. Since the interface is accurate, local type  
: checkability is always ensured.

In Eiffel this is defined as follows:

class ANIMAL

feature

	food: ANIMAL_FOOD

	eat (something: like food) is
		do
			...			
		end; -- eat

	...

end -- class ANIMAL


class HERBIVORE

inherit

	ANIMAL
		redefine
			food
		end;

feature

	food: PLANT_FOOD

end -- class HERBIVORE

class CARNIVORE

inherit

	ANIMAL 
		redefine
			food
		end

feature

	food: FLESH_FOOD

end -- class CARNIVORE

Nothing needs changing in the subclass except the type of food. All the feature
s
are automagically redefined to conform to the new interface. System level type
checking prevents the feeding of flesh to a herbivore and you can use herbivore
s
and carnivores in generalised animal code. 

Parallel co-variant redefinition is a prominent part of the Eiffel method.

Seems straightforward to me, did I miss something?

Regards
-- 
Neil Wilson (neil@aldur.demon.co.uk)			+44 532 832000 x2242
6 Spring View, Ossett, Yorkshire, WF5 0QB, UK

	...Arrive without travelling, see all without looking...


======================================================================= 87 ===
Date:    25 Mar 1994 13:37:42 GMT
From:    matthew@cpdapo.tele.nokia.fi (Matthew Faupel)
Subject: Re: Who Win the War of Co. vs. Contra?

JMY= Jeff M Younker <jeff@karazm.math.uh.edu>
     in article <JEFF.94Mar23181639@karazm.math.uh.edu>

JMY: and now we could do things like...

JMY:  knoll::=#GRASS(10);    -- a small knoll
JMY:  tree::=#EUCALYPTUS(20);  -- a big tree
JMY:  flossy::=#BOVINE(30);  -- flossy's a fat cow
JMY:  ned::=#KOALA(5); -- a tubby koala


JMY:  ned.is_this_digestable_food(tree);  -- should be true
JMY:  ned.is_this_digestable_food(knoll); -- should be false
JMY:  flossy.is_this_digestable_food(knoll); -- should be true
JMY:  flossy.is_this_digestable_food(tree);  -- should be false

JMY:  flossy.is_this_digestable_food(ned); -- should be false also
JMY:  big_turd::=flossy.eat(knoll);
JMY:  ned.is_this_digestable_food(big_turd); -- should be false or we've got
JMY: 					   one wierd koala.

JMY: Does this example do everything people need it to?

I think (if I understand the problem correctly) is that while this all works
as you've described it, it delays validity-checking to runtime where ideally
we want it done at compile time.  You could write a program with the above
system that attempts to feed ned to flossy and it wouldn't complain until
you ran it.  The "perfect" system would reject this inhuman treatment at
compile time :-)


Matthew


======================================================================= 88 ===
Date:    25 Mar 94 18:05:23 GMT
From:    partha@paul.rutgers.edu (partha)
Subject: Re: Who Win the War of Co. vs. Contra?

I have a question about Neil's proposed eiffel solution for David's
Animal and Animal_Food situation.

For brevity I am not quoting Neil's proposed class hierarchy.
Assuming his classes, consider the following declarations:

         a: ANIMAL;
         c: CARNIVORE;
         h: HERBIVORE;
         af: ANIMAL_FOOD;
         pf: PLANT_FOOD;
         ff: FLESH_FOOD;

           ...
        
         
and the following cases:

1.
       h.eat(ff)   --> static type error, right?


2.

       a.eat(af)   --> this statement is ok as far as static type is 
                       concerned.  but this is potentially dangerous
                       because of obvious reasons:
                             what if af is bound to an entity of FLESH_FOOD
                             and a is bound to an entity of HERBIVORE?
                             (both are possible according to subtype rules)
                      
                      thus the need of system-level validity and if
                      the  above kind of assignments happen  this call
                      will be system-level invalid.

                      How, then we are going to write useful
                      generalised animal code? Aren't calls like this
                      in the animal code going to be rejected as
                      system-level invalid?

--partha
   


======================================================================= 89 ===
Date:    25 Mar 94 23:59:04 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Re: Harbison's "Modula-3": errata. And, new edition?

The errata sheet is actually available via anonymous ftp from 

   beethoven@cs.colostate.edu:~ftp/pub/M3/......

and not from the site Harbison mentioned.

If I had it to do again, I would structure the errata into dated
sections, so a user who had done some of the errata would know which
to look at for more fixes.  Now a poor user has to scan each updated
errata list (ordered only by page number) to see if there are new
ones in there.  Oh well.

I'm glad to hear a new book version may happen.  Aside from the 
nine (9) (!!!) pages of errata I've compiled, I'd like to think
a minute about how the book could be improved.  I'll try to enable 
brain before engaging keyboard.


======================================================================= 90 ===
Date:    Fri, 25 Mar 94 17:36:11 -0800
From:    luca@src.dec.com
Subject: Re: Who Win the War of Co. vs. Contra?


I'll reformulate the (typecase-free) Sather solution and the (typecased) 
Cluster solution in type-theoretical terms, as I understand them. 
Why? Because this way we can discuss more quickly and rigorously. 
And if I'm wrong, you can tell me exactly where I am wrong. 

The problem types are A(nimal) and H(erbivore), with P(lant) < F(ood)

    A = {eat:F->R}
    H = {eat:P->R}

where R is some result type, and {...} are class types, with the 
subclass rule {l1:T1...ln+m:Tn+m} < {l1:S1...ln:Sn} if T1<S1 ... Tn<Sn. 

We would love to have H < A, but this is false because, by contravariance 
of -> in the domain, we need F < P, which is the opposite of what 
we have. 

Trying to believe in H < A leads to unsoundness or, to be sound, to 
Eiffel-style global analysis. There is no other way out of this. 
The Eiffel solution is outside of the domain of typing, so I won't 
comment on it any further. 

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

The Sather solution is to change the types into type operators (i.e. 
parameterized classes): 

    A = Lambda(X<:F) {eat:X->R}
    H = Lambda(X<:P) {eat:X->R}

where G = Lambda(X<T)S is a "function" that for evary type T1<T produces 
the type G(T1) = S{T1/X} (i.e. S with T1 substituted for X}. 

Now, it no longer makes sense to compare A and H (at least for the 
purposes of this discussion), since these are no longer types. We 
no longer have plain Animals nor Herbivors. However, we do have that: 

    for all X<P,    H(X) = {eat:X->R} < {eat:X->R} = A(X)

Therefore, for any Plant food X, an Herbivore(X) is an Animal(X), 
while an Herbivore(Food) is not an Animal(Food) because H(F) is not 
even a legal application. 

The general technique is to abstract every contravariant occurrence 
into a parameter. (Doesn't this get a bit heavy?) The variations 
with GenericAnimal follow from the subtype rules given above.

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

The Cluster solution is a bit less clear to me and, type-theoretically, 
quite different. It seems based on existential types (this is the 
only way I can make sense of the fact that A and H are again real 
types): 

    A = Exists(X<:F) {eat:X->R}
    H = Exists(X<:P) {eat:X->R}

(It seems that Cluster confuses "Lambda" and "Exists", allowing A(X), 
so that definitions can be reused. Probably there is no harm to that.)

The type rule for Exists is covariant in the bound (unlike Forall), 
so we obtain H < A, as desired. 

The problem (if one wants to consider this a problem) is that animals 
cannot be fed without dynamic type tests. Given an animal, we know 
from the type specification that there exists a food that it will eat, 
but we have no way to know which one, statically (this is a consequence 
of the type rules for operations on existentials, akin to the rules 
for abstract types.)

(N.B. Contrary to what David Shang seems to claim, I believe a run-time 
test is implicit in the constraints of feed, at the moment that feed 
is invoked: 
    animal:Animal; food:typeof(animal).FoodType
because typeof(animal) may not be knowable statically. So this is 
just fancy notation for a typecase on the type of food against the 
hidden food type of animal.) 

    Luca
    


======================================================================= 91 ===
Date:    Mon, 28 Mar 94 18:44:04 -0600
From:    loplas@cs.wisc.edu (Loplas Account)
Subject: LOPLAS/TOPLAS Merger

As an individual who has been involved with ACM LOPLAS,
I thought you'd be interested in the following editorial
which will appear in the next issue of TOPLAS:


Editorial

In 1991 ACM Letters on Programming Languages and Systems
(LOPLAS) was created to provide rapid publication of
short papers describing research and development efforts
in the area of programming languages and related systems.
Its mandate was to reduce publication delays to months rather
than years, while maintaining the highest editorial standards.

Starting with this issue, LOPLAS is merged into TOPLAS.
Each issue of TOPLAS will contain two or three
LOPLAS-style "short communications," reviewed and published
on an expedited basis.  Each short communication
should be a little "gem" in which the author explains an 
interesting new idea with a maximum of clarity and a minimum of
verbiage.

Charles Fischer, Editor-in-Chief of LOPLAS, is now Associate
Editor of TOPLAS with responsibility for
managing the  short communications department.
Submissions to the new section, not exceeding 5000 words,
should be sent (in Postscript) to toplas@cs.princeton.edu;
the cover letter should indicate that they are intended as
short communications. Short communications will not be part
of the normal TOPLAS backlog; they will be reviewed and published
as rapidly as is practicable.

We wish to acknowledge the outstanding contributions of
Robert Cartwright, Ron Cytron, Saumya  Debray, Susan Eggers,
Robert Halstead, Jr., Susan Horwitz, Bernard Lang,
Richard J. LeBlanc, Jr., Peter Lee, Uwe Pleban,
Bill Pugh, Barbara Ryder, and Mayer D. Schwartz,
who have served on the LOPLAS Editorial Board.
These individuals will continue to handle previous submissions
to LOPLAS which will soon appear as TOPLAS short communications.

We believe the readership of TOPLAS and LOPLAS will find this merger
beneficial.  They will continue to receive the comprehensive, in-depth
papers TOPLAS is known for, with the added dividend of concise
and timely reports on new ideas and innovations.


Andrew Appel, Editor-in-Chief, ACM TOPLAS
Charles Fischer, Editor-in-Chief, ACM LOPLAS



======================================================================= 92 ===
Date:    Mon, 28 Mar 1994 18:26:41 GMT
From:    strzelin@bnlku5.phy.bnl.gov (Robert J Strzelinski)
Subject: m3 and gcc

Will we soon see a m3 front end bundled with gcc the way c++ and obj-c
front ends are now?  Is the m3 release 3.1 an intentional step in that
direction with its dependence on gcc?  I think this would be a good way
to increase m3's visibility and exposure, as well as increasing its
availability on many architectures which are not currently "officially"
supported. 


///////////////////////////////////////////////////////////////////////////////
// Robert J Strzelinski                 // Brookhaven National Laboratory    //
// strzelin@bnl.gov                     // Upton, NY 11973-5000              //
///////////////////////////////////////////////////////////////////////////////


======================================================================= 93 ===
Date:    Tue, 29 Mar 1994 10:52:38 GMT
From:    aet@munta.cs.mu.OZ.AU (Bert THOMPSON)
Subject: ---Looking for QUEST---


This is probably not the right newgroup to post to, but...

Does anyone know if there exists an ftpable implementation
of Luca Cardelli's QUEST language?

(QUEST is the language used in his ``Typeful Programming'' paper.)


Many thanks,

	Bert.

-----------------------------------------------------------------------
bert thompson					aet@cs.mu.oz.au.
-----------------------------------------------------------------------


======================================================================= 94 ===
Date:    Tue, 29 Mar 94 11:03:54 EST
From:    wollrath@zaphod.East.Sun.COM (Ann Wollrath - Sun Microsystems Labs BOS
)
Subject: bug in date conversion

The following program crashes (sparc, sunOS 4.1.3, m3 3.1):

MODULE datetest EXPORTS Main;

IMPORT Date;
IMPORT Time;

VAR
  now: Time.T;
  today: Date.T;
  
BEGIN
  now := Time.Now();
  today := Date.FromTime(now);
  
END datetest.


It gets a segv while converting the time zone in the tm struct to a TEXT 
(in the procedure M3toC.CopyStoT).  Do you have a fix for this?

thanks,

-- Ann


Ann Wollrath				email: Ann.Wollrath@east.Sun.COM
Sun Microsystems Laboratories, Inc.	phone: (508) 442-0565
2 Elizabeth Drive			fax:   (508) 250-5067
Chelmsford, MA  01824-4195




======================================================================= 95 ===
Date:    Tue, 29 Mar 1994 14:19:22 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: ---Looking for QUEST---


In article <9408820.1997@mulga.cs.mu.OZ.AU> aet@munta.cs.mu.OZ.AU (Bert THOMPSO
N) writes:

   This is probably not the right newgroup to post to, but...

   Does anyone know if there exists an ftpable implementation
   of Luca Cardelli's QUEST language?

   (QUEST is the language used in his ``Typeful Programming'' paper.)

You can find an implementation at gatekeeper.dec.com:/pub/DEC/Quest. I
believe it was written in Modula-3, but I don't know if it will work
with the new libm3 3.x.

--farshad

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


======================================================================= 96 ===
Date:    30 Mar 1994 00:01:30 +0100
From:    hrnjad@spock.isar.muc.de (Muharem Hrnjadovic)
Subject: Q: Is there a public domain modula3 compiler available?

Hello,

I read an article Niklaus Wirth wrote for the february/1994 issue of
the Informatik Spektrum in Germany and from that reading modula3 seems 
to be a very nice language.

That's why I would like to know if there's a public domain modula3
compiler (perhaps with a debugger) available.

I am using a i486 PC driven by BSD/386 from BSDI if it matters.

thanx,

Muharem


P.S.: What about Oberon? Is it available for PC's?

-- 
Muharem Hrnjadovic
(hrnjad@Spock.isar.muc.de)


======================================================================= 97 ===
Date:    30 Mar 1994 15:46:24 +0200
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Modula-3 FAQ in WWW html format

Hi!
  Some of our PhD students are setting up a WWW site
at our CS dept. They pushed me into making my own entry,
so I fiddled around. Since my research work has to do
with Mpodula-3, I wanted a hypertext link to the FAQ
sheet, so I converted it to HTML format.
  I would love to put some images in it, so if somebody
(Sam?) can provide me with the Modula-3 logo as a gif
(postscript is fine also), please!

Anyways, below my first attempt at a WWW entry for Modula-3.

Greetings, Bert
---snip---snip---snip---8<---
<title> Modula-3 Frequently Asked Questions </title>
<h1> Modula-3 Frequently Asked Questions </h1>

Original file header:
<pre>
Newsgroups: comp.lang.modula3,news.answers
Subject: Modula-3 Frequently Asked Questions (FAQ)
Followup-To: comp.lang.modula3
Expires: 15 Mar 1993 00:00:00 GMT
Approved: news-answers-request@MIT.Edu

Archive-name: Modula-3-faq
Last-modified: Feb 04 1993
</pre>


<h2> What is Modula-3 ? </h2> <p>

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

<p>

Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+.  It also
resembles its cousins Object Pascal, Oberon, and Euclid.

<p>

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

<p>

<h2> Is Modula-3 a superset of Modula-2 ? </h2> <p>

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


<h2> Where can I get a description of Modula-3 ? </h2> <p>

<ul>
<li> The definition of Modula-3 is contained in:
     <dl>
     <dt> <i> System Programming with Modula-3, </i>
     <dd> Edited by Greg Nelson, 
     <dd> Prentice Hall Series in Innovative Technology
     <dd> ISBN 0-13-590464-1
     <dd> L.C. QA76.66.S87 1991
     </dl>
     also known as SPwM3. Here is the table of contents:
     <ol>
     <li>- Introduction
     <li>- Language Definition
     <li>- Standard Interfaces
     <li>- An Introduction to Programming with Threads
     <li>- Thread Synchronization: A Formal Specification
     <li>- I/O Streams: Abstract Types, Real Programs
     <li>- Trestle Window System Tutorial
     <li>- How the Language Got its Spots
     </ol>
     
     Chapters 2 and 3 have been reprinted in <i> Sigplan Notices, </i>
     Volume 27, Number 8, August 1992, pp 15-42.
    <p>
<li> Sam Harbison has written a more tutorial book about Modula3:
    <dl>
    <dt> <i> Modula-3 </i>
    <dd> Samuel P. Harbison
    <dd> Prentice Hall, 1992
    <dd> ISBN 0-13-596396-6
    </dl>
</ul>

<h2> Where can I get other information on Modula-3 ? </h2> <p>

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

<ul>
<li> There are a couple high-level overview articles available:
     <dl>
     <dt> <i>Modula-3</i>
     <dd> Sam Harbison, Byte, Vol. 15, No. 12, October 1990, pp 385+.
     <dt> <i>Safe Programming with Modula-3</i>
     <dd> Sam Harbison, Dr. Dobb's Journal, Vol. 17, No. 10, October 1992, pp 8
8+.
     </dl>
<li> A description of the Modula-3 type system is in
     <dl>
     <dt> <i>The Modula-3 Type System</i>

     <dd> Luca Cardelli, Jim Donahue, Mick Jordan,
        Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual
        ACM Symposium on Principles of Programming Languages (POPL), Austin
        Texas, January 11-13 1989, pp 202-212.
     </dl>
<li> The Trestle window system toolkit and higher-level FormsVBT toolkit,
   available with Modula-3, are documented in the following reports:
     <dl>
     <dt> <i>Trestle Reference Manual</i>
     <dd> Mark S. Manasse and Greg Nelson, SRC Research Report 68, December 199
1.
     <dt> <i>Trestle Tutorial</i>
     <dd> Mark S. Manasse and Greg Nelson, SRC Research Report 69, May 1, 1992.
     <dt> <i>The FormsVBT Reference Manual</i>
     <dd> Marc H. Brown and James R. Meehan, (soon to be SRC Research Report ??
).
     </dl>
   These reports can be ordered by e-mail; send your request to
   <code>src-reports@src.dec.com.</code>
</ul>
<p>

<h2> Where can I get an implementation ? </h2> <p>

There is only one implementation available today.  It has been built
by SRC and is available via anonymous ftp from <code>
gatekeeper.dec.com </code> in <code> pub/DEC/Modula-3/release. </code>
Contributed software can be found in <code>
pub/DEC/Modula-3/contrib. </code> <p>

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

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

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

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

<h2> What if I don't have ftp access ? </h2> <p>

Unfortunately, we cannot deliver Modula-3 other than by 
anonymous ftp.  <p>

Fortunately, Prime Time Freeware (PTF) includes Modula-3.  PTF is
a set of two ISO-9660 CDroms filled with 3GB of freeware, issued
semi-annually.  The latest issue, Volume 1, Number 2, July 1992,
contains SRC Modula-3 2.07.  PTF is distributed via bookstores and
mail.  You can reach PTF using:
<pre>
	Email:  ptf@cfcl.com
        Fax:    [1] (408) 738 2050
        Voice:  [1] (408) 738 4832
        Mail:   Prime Time Freeware
 	        415-112 N. Mary Ave., Suite 50
		Sunnyvale, CA 94086
	        USA
</pre>

<h2> Can I contribute Modula-3 software ? </h2> <p>

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

Right now, the <code> pub/DEC/Modula-3/contrib </code> directory contains:
<pre>
   m3rpc   an rpc system from Xerox Parc
   M2toM3  a translator from Modula-2 to Modula-3
   m3pc    an implementation of Modula-3 for PCs.
</pre>
<p>
<pre>   
-- 
Eric.
</pre>

---snip---snip---snip---8<---
  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800
-- 
  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800


======================================================================= 98 ===
Date:    Wed, 30 Mar 1994 14:53:21 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: M3 Shared libraries on LINUX


With more efforts than anticipated i got them working. The most notable
problems were, apart from the inherent complexity of building shared libs
on LINUX:

- Two fixed arrays somewhere in the shared libs tools did overflow on libm3.
  Made me realize how much time i save in M3 not having to chase bugs in
  corrupted binaries.

- The tools silently ignored symbols with '.' in them.

- The shared libs tools intercept global symbols as modules are compiled.
  Modules recompiled due to new opaque info created duplicate entries.

- Libm3 references symbols from the main program. Dummy symbols had to be
  added as place holders.

With shared libraries a sample application went from 75s link time and
2721K to 12s link time and 122K. The application startup time is not
much affected.

Here is a script that calls "buildShared" to build a number of Modula3
libraries, specifying dependencies on other libraries and setting the
fixed address where the library should be loaded at run time in virtual memory.

#! /bin/sh
#
# Where libraries get installed
#
PKG=/usr/local/soft/modula3-3.1/run/lib/m3/pkg
#
# Libm3
#
./buildShared -m /home/dagenais/disk/m3 -p libm3 -n libm3 -d $PKG/libm3/LINUX -
a "0x80000000" -j "0x4000" -g "0x2000" -x "3" -y "1" -i "/usr/lib/libc /usr/lib
/libm" -l "-lm -lc -lgcc -lc" -f "-g"
#
# Libm3X11R4
#
./buildShared -m /home/dagenais/disk/m3 -p trestle/X11R4 -n libm3X11R4 -d $PKG/
X11R4/LINUX -a "0x80100000" -j "0x4000" -g "0x2000" -x "3" -y "1" -i "$PKG/libm
3/LINUX/libm3 /usr/lib/libXext /usr/lib/libX11 /usr/lib/libc /usr/lib/libm" -l 
"-L$PKG/libm3/LINUX -lm3 -lXext -lX11 -lm -lc -lgcc -lc" -f "-g"
#
# Libm3tcp
#
./buildShared -m /home/dagenais/disk/m3 -p trestle/tcp -n libm3tcp -d $PKG/tcp/
LINUX -a "0x80200000" -j "0x4000" -g "0x2000" -x "3" -y "1" -i "$PKG/libm3/LINU
X/libm3 /usr/lib/libc /usr/lib/libm" -l "-L$PKG/libm3/LINUX -lm3 -lm -lc -lgcc 
-lc" -f "-g"
#
# Libm3ui
#
./buildShared -m /home/dagenais/disk/m3 -p trestle/ui -n libm3ui -d $PKG/ui/LIN
UX -a "0x80300000" -j "0x4000" -g "0x2000" -x "3" -y "1" -i "$PKG/X11R4/LINUX/l
ibm3X11R4 $PKG/tcp/LINUX/libm3tcp $PKG/libm3/LINUX/libm3 /usr/lib/libXext /usr/
lib/libX11 /usr/lib/libc /usr/lib/libm" -l "-L$PKG/X11R4/LINUX -lm3X11R4 -L$PKG
/tcp/LINUX -lm3tcp -L$PKG/libm3/LINUX -lm3 -lXext -lX11 -lm -lc -lgcc -lc" -f "
-g"


Now the buildShared script. One can say that building shared libraries on
LINUX is non obvious. However, global variables are automatically seperated
from the rest of the library, unlike on Suns where this has to be done by
hand if you want to have shared libraries that can really be shared in core.

#! /bin/sh
#
# Information that characterize a shared library to build:
#
M3DIR=/home/dagenais/disk/m3 # where the DEC SRC Modula-3 source tree is
PKG=libm3                    # package name (libm3, trestle/ui ...)
LIBNAME=libm3                # library name (libm3, libui ...)
LIBDEST=/usr/local/soft/modula3-3.1/run/lib/m3/pkg/$PKG/LINUX
                             # where the library built should go
ADDRESS=0x80000000           # a virtual address assigned to that library
JUMPSIZE=0x8000              # size of the jump table with space for growth
GOTSIZE=0x4000               # size of the got table with space for growth
MAJOR=3                      # major release number
MINOR=1                      # minor release number
IMPORTLIBS="/usr/lib/libc /usr/lib/libm" # shared libs on which it depends
LDLIBS="-lm -lc -lgcc -lc"   # all libs on which it depends
M3FLAGS="m3_option(\"-g\")"

#
# These values can be read from the command line
#
USAGE="buildShared \
  -m m3_directory\
  -p package_name\
  -n library_name\
  -d library_destination\
  -a shared_lib_address\
  -j jump_table_size\
  -g got_table_size\
  -x major_version_no\
  -y minor_version_no\
  -i imported_shared_libraries\
  -l libraries_to_link\
  -f m3_option\
  -F M3OPTIONS\
  "

while getopts m:p:n:d:a:j:g:x:y:i:l:f:F: name
  do
  case $name in
    m)   M3DIR=$OPTARG;;
    p)   PKG=$OPTARG;;
    n)   LIBNAME=$OPTARG;;
    d)   LIBDEST=$OPTARG;;
    a)   ADDRESS=$OPTARG;;
    j)   JUMPSIZE=$OPTARG;;
    g)   GOTSIZE=$OPTARG;;
    x)   MAJOR=$OPTARG;;
    y)   MINOR=$OPTARG;;
    i)   IMPORTLIBS=$OPTARG;;
    l)   LDLIBS=$OPTARG;;
    f)   M3FLAGS="m3_option(\"$OPTARG -Y1@gcc@-B/usr/dll/jump/@ -Y7@/usr/dll/ju
mp/as@\")";;
    F)   M3FLAGS="M3OPTIONS=\"$OPTARG -Y1@gcc@-B/usr/dll/jump/@ -Y7@/usr/dll/ju
mp/as@\"";;
    \?)  echo $USAGE
         exit 2;;
  esac
  shift; shift; OPTIND=1;
  done
shift `expr $OPTIND - 1`

#
# The shared lib toolkit needs some info to be passed by the JUMP_DIR
# and JUMP_LIB environment variables.
#
cd $M3DIR/$PKG
JUMP_DIR=$M3DIR/$PKG/jump
export JUMP_DIR
if test \! -d $JUMP_DIR; then mkdir $JUMP_DIR; fi
rm jump/*

JUMP_LIB=$LIBNAME
export JUMP_LIB
VERSION=$MAJOR.$MINOR
IMAGE=$LIBDEST/$LIBNAME

#
# To build shared libraries, special options are required in the m3makefile
# such that all assembly is performed by /usr/dll/jump/as.
#
if test \! -f src/m3makefile.orig; then 
  cp -p src/m3makefile src/m3makefile.orig
fi 
sed "s+\( *[lL]ibrary.*\)+$M3FLAGS\\
\1+" <src/m3makefile \
  >src/m3makefile.new
mv src/m3makefile.new src/m3makefile

#
# Everything must be built. The outcome is the file jump/jump.log which lists
# all the global symbols in the library
#
rm LINUX/*
m3build

#
# For libm3 we must insert dummy definitions for the symbols to appear in 
# the file _m3main.c produced by m3build when a program is compiled.
#
if test $LIBNAME = libm3; then (cat >jump/tmpm3main.s <<EOF); fi
	.file	"_tmpm3main.c"
gcc2_compiled.:
___gnu_compiled_c:
.data
.globl __type_names
	.align 2
__type_names:
	.long 2
.text
	.align 4
.globl _main
_main:
	ret
.lcomm __types,852
.comm __alloc_cnts,852
.comm __alloc_bytes,852
.comm __m3_exporters,4
EOF
if test $LIBNAME = libm3; then 
  (/usr/dll/jump/as -o LINUX/tmpm3main.o jump/tmpm3main.s) 
fi

#
# The global variables and functions are extracted from jump/jump.log.
# Because m3build recompiles some modules when it finds new opaque info,
# duplicate entries must be removed from jump.log.
#
(cd $JUMP_DIR; mv jump.log jump.log.old; sort <jump.log.old | uniq >jump.log)
(cd $JUMP_DIR; /usr/dll/bin/getvars; /usr/dll/bin/getfuncs)
(cd $JUMP_DIR; rm jump.log)

#
# Global symbols imported from other shared libs must be in jump/jump.import
#
if test -f $JUMP_DIR/jump.import; then rm $JUMP_DIR/jump.import; fi
for i in $IMPORTLIBS; do
  (cd $JUMP_DIR; nm --no-cplus -o $i.sa | grep __GOT_ | \
   sed 's/ __GOT__/ _/' >>jump.import)
done

#
# Now that we have the jump.vars, jump.funcs and jump.import files, we
# rebuild everything a second time. All the calls to global variables
# and functions will be intercepted and treated appropriately.
# The original makefile is subsequently restored.
#
rm LINUX/*
m3build
cp -p src/m3makefile.orig src/m3makefile
if test $LIBNAME = libm3; then
  (/usr/dll/jump/as -o LINUX/tmpm3main.o jump/tmpm3main.s)
fi

#
# The size of each global variable is measured before building the jump table
#
(cd $JUMP_DIR; /usr/dll/bin/getsize >jump.vars.new; \
  mv jump.vars jump.vars.old; mv jump.vars.new jump.vars)

#
# The shared library is finally constructed and verified.
#
cd LINUX
/usr/dll/bin/mkimage -f -l $IMAGE -v $VERSION -a $ADDRESS -j $JUMPSIZE \
  -g $GOTSIZE -- '*o' $LDLIBS
cp -p $LIBNAME.so.$VERSION $LIBDEST
/usr/dll/bin/mkstubs -l $IMAGE -v $VERSION -a $ADDRESS -j $JUMPSIZE \
  -g $GOTSIZE -- $LIBNAME
cp -p $LIBNAME.sa $LIBDEST
/usr/dll/bin/verify-shlib -l $IMAGE.so.$VERSION $IMAGE.sa
#
# A symlink redirects all requests to the major version to this specific
# major.minor version
#
if test -f $IMAGE.so.$MAJOR; then rm $IMAGE.so.$MAJOR; fi
ln -s $IMAGE.so.$MAJOR.$MINOR $IMAGE.so.$MAJOR

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

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

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


======================================================================= 99 ===
Date:    Wed, 30 Mar 1994 16:29:05 -0500
From:    Dick Orgass <orgass+@CMU.EDU>
Subject: Building V 3.1 on HPUX

I've run into a few non-fatal problems and one fatal problem trying to
bring up the 3.1 system on HPUX.  I'm writing in the hope that someone
will recognize them and be able to point me in the right direction.

(1) quake fails to compile with the HP C compiler because of alloca.
     Solution: Compile with gcc.

(2) The functions utimes and getdtablesize are not in the HP
    libraries.  Solutions: rewrite utimes using utime which is provided
    (and in POSIX 1001.1).  Once the compiler is up, this can be
    directly changed in the Modula-3 source.  For getdtablesize, I
    simply wrote a short C function that returns 2000, the default
    maximum in AIX -- not a very good solution but should get me started.

The fatal problem:

(3) For all of the links in the boot system, I get:

        cs: error 1405: "/bin/ld" terminated abnormally with signal.
        *** error code 139

Haven't found a hint in the man pages or /usr/include yet.

Many thanks for any help you might be willing to provide.

Dick

PS: When I try the links again with gcc, I get:

    /usr/local/bin/gcc -o m3 _m3main.o OS_i.o OS_m.o Main_m.o
    ../../libm3/HPPA/libm3.a ../../linker/HPPA/libm3linker.a -lm -lBSD
    collect2: ld terminated with signal 11 , core dumped
    *** error code 1
    "/u/decsrc/boot-HPPA/m3build/templates/COMMON.BOOT", line 46:
    command execute failed

Signal 11 is segmentation violation.


======================================================================= 100 ===
Date:    31 Mar 1994 13:19:58 +0200
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Building V 3.1 on HPUX

Dick Orgass <orgass+@CMU.EDU> writes:
>(2) The functions utimes and getdtablesize are not in the HP
>    libraries.  Solutions: rewrite utimes using utime which is provided
>    (and in POSIX 1001.1).  Once the compiler is up, this can be
>    directly changed in the Modula-3 source.  For getdtablesize, I
>    simply wrote a short C function that returns 2000, the default
>    maximum in AIX -- not a very good solution but should get me started.
I am told gcc has a compatibility library which also provides these two.
I solved this with two stub routines to call utime() and getrlimit().

>The fatal problem:
>(3) For all of the links in the boot system, I get:
>        cs: error 1405: "/bin/ld" terminated abnormally with signal.
>        *** error code 139
>Haven't found a hint in the man pages or /usr/include yet.
HP first suggested it may be a linker problem, and they sent us a
patch to ld. This didn't solve the problem however. Wat did, was to use
gcc-as instead of as all around. I suppose the backend that generated
the boot archive was configured for use with gas instead of hp-as.

When built this way, you will get into the (by now known) problem
of the big-endians, which was also plaguing SPARCs. When this is
solved by replacing libm3/src/text/UnsafeHash.ms, again the program
seems to hang. This was traced to a word-order problem in double
constants. All '.double' ops were made into comments, and two
separate '.word' entries generated instead. gas however knows about
'.double', so I manually edited all occurences back into life.

I now get a runtime error. Since the bootstrap compiler was not compiled
with '-g' I could not use gdb to find out more. (out gcc by the way
complains that '-g' is not implemented. I wonder if we could use it at
all...)

>PS: When I try the links again with gcc, I get:
>    /usr/local/bin/gcc -o m3 _m3main.o OS_i.o OS_m.o Main_m.o
>    ../../libm3/HPPA/libm3.a ../../linker/HPPA/libm3linker.a -lm -lBSD
>    collect2: ld terminated with signal 11 , core dumped
>    *** error code 1
>    "/u/decsrc/boot-HPPA/m3build/templates/COMMON.BOOT", line 46:
>    command execute failed

>Signal 11 is segmentation violation.
This is the same problem. Only when you use gas on all assembly files will
you be able to link.
-- 
  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800


======================================================================= 101 ===
Date:    Wed, 30 Mar 1994 17:20:06 GMT
From:    shang@corp.mot.com (David L. Shang)
Subject: Re: Who Win the War of Co. vs. Contra?



In article <9403260136.AA17864@tsktsk.pa.dec.com> luca@src.dec.com writes:
> 
> I'll reformulate the (typecase-free) Sather solution and the (typecased) 
> Cluster solution in type-theoretical terms, as I understand them. 
> Why? Because this way we can discuss more quickly and rigorously. 
> And if I'm wrong, you can tell me exactly where I am wrong. 
> ...

The followup to this message has been redirected to comp.object.

David Shang


======================================================================= 102 ===
Date:    Thu, 31 Mar 1994 20:37:24 GMT
From:    mikeg@psg.com (Mike Gallo)
Subject: Re: Q: Is there a public domain modula3 compiler available?

        There is a freeware version available from Digital 
Equipment Corp. on gatekeeper.dec.com.  Try the newsgroup 
Comp.lang.modula3 for details.
 
> 
> P.S.: What about Oberon? Is it available for PC's?
> 
 
        Yup.  Ports of the Oberon system are freely available 
from neptune.inf.ethz.ch in /Oberon.  See the upcoming Oberon 
FAQ for more details.

-- 
I meant what I said and said what I meant,
An elephant is faithful one hundred percent.
				-- Horton


======================================================================= 103 ===
Date:    Thu, 31 Mar 1994 15:14:10 -0500
From:    Dick Orgass <orgass+@CMU.EDU>
Subject: Re: Building V 3.1 on HPUX

Thanks to Bert Laverman for the suggestions concerning building version
3.1 for HPUX.

Here's a report on what happened so far.

We're running gcc version 2.5.8 and -g is not supported by this port
either.  I compiled all C code using gcc, assembled all source using the
assembler with gcc and then linked with gnu ld which is automatically
invoked by gcc.  This was all vanilla source from the SRC distribution.

I changed my getdtablesize stub to match Bart's suggestion.  (My C code
is below.)

After I assembled, compiled, created libraries, linked an installed the
system, I got a different result than Bert: My build of m3 goes into a
long (probably infinite) loop trying to compile Hello.m3.  I once ran it
for over 4.5 CPU minutes and it was still gong strong.  (Assuming that
the time in HPUX's ps is actual CPU time.)

At the moment, I'm compiling version 2.11 in the hope that I can use it
to get on with some implementation work.  I'm retaining the 3.1 system
in the hope that it will be possible to get it working sometime soon.

Dick

--------------------- utimes.c -------------------------
#include <utime.h>

struct timeval {
  long tv_sec;
  long tv_msec;
};

void utimes (file, tvp)
char *file;
struct timeval tvp[2];
{
  struct utimbuf tmp;

  tmp.actime = tvp[0].tv_sec;
  tmp.modtime = tvp[1].tv_sec;
  utime(file, &tmp);
}
------------------------ getdtablesize.c ------------------
#include <sys/resource.h>

int getdtablesize () {
  struct rlimit rlp;
  getrlimit(RLIMIT_NOFILE, &rlp);
  return (rlp.rlim_cur);
}
-------------------------- end ---------------------------


