======================================================================= 1 ===
Date:    1 Mar 1995 00:23:08 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Where is ParseParams?

In article <D4oBot.7nC@undergrad.math.uwaterloo.ca>,
bwbecker <bwbecker@dragon.uwaterloo.ca> wrote:
>I think I remember a promise that ParseParams would be
>returned to libm3 in v3.5.  I can't find it, although
>it is documented in the WWW pages at
>http://www.research.digital.com/SRC/m3sources/html/parseparams/src/Parse
>Params.i3


 I don't know about 3.5, but there's a `parseparams' package in 3.5.1
which appears to be it...


Richard.
-- 
`There comes a time when you look into the mirror and you realise that what you
 
see is all that you will ever be. And then you accept it. Or you kill 
yourself. Or you stop looking in mirrors.'
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 2 ===
Date:    1 Mar 1995 10:39:38 GMT
From:    sd@inf.rl.ac.uk
Subject: M3 on Solaris

I'm having severe problems building the latest Modula-3 compiler on a Sparc 
10 under Solaris 2.3 (SunOS 5.3).  It seems to compile the bootstrap compiler 
correctly, but can't build the standard library from the source code.

I've unpacked boot-SOLsun.tar.gz, m3cc.tar.gz and m3.tar.gz.  I've managed to
compile everything under boot-SOLsun (after a few problems with wrong C 
compilers and lost libraries :-).  I then try to build the library from m3.  
Running m3build correctly builds mtex, then core dumps with a segmentation
fault trying to build m3core.  dbx says the problem is in a routine called 
_INITMRTLinker.

This is the first time I've tried to build Modula 3, so I'm not in a position 
to fix problems like this.  Has anyone else managed to get the compiler built
under Solaris?  And if so, could they help?  Is boot-SOLgnu any better?

Thanks in advance,


-- Si

Dr Simon A. Dobson

Computing and Information Systems   \ My mind is racing, as it always will,
DRAL, Rutherford Appleton Laboratory \ My hands tired, my heart aches
Chilton, Didcot, Oxon OX11 0QX, UK.   \ I'm half a world away.

sd@inf.rl.ac.uk            http://www.cis.rl.ac.uk/people/sd/contact.html


======================================================================= 3 ===
Date:    Wed, 01 Mar 1995 8:57:02 MET
From:    rudy@cs.rug.nl
Subject: Language Definition 2

At this moment I find Modula-3 one of the best programming languages.
Working with Modula-3 I still find minor points where the language
(definition) could be improved. Therefore I will propose some minor changes
to the language definition. I hope to initiate a fruitful discussion about
the language definition. I will collect the reactions and write a final
report. 

Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup
comp.lang.modula3. Reactions can also be sent to me personally:
rudy@cs.rug.nl

Introduction
============

I introduce the second proposal to change the language definition with two
examples of unsafe implementations. I use the new definition of "ADR(x)",
where instead of "ADDRESS", "ADR(x)" returns an "UNTRACED REF T" when the
static type of "x" is "T". The new definition increases the safety of
interfacing with the C world.

I have showed these examples to some members of my department, and they all
find them lunatic. So I have reported these examples as bugs to Bill Kalsow
and he states that the error messages are correct according to the language
definition, and really they are! From my point of view the language
definition should be changed.

Example 1
=========

VAR x:UNTRACED REF REAL;
    y:UNTRACED REF INTEGER;
    z:ADDRESS;

BEGIN
  x:=y; (* error *)
  z:=y;   
  x:=z; (* correct *)
END Test.

Are "x" and "y" assignable? "x" and "y" are not assignable. So you would
expect "y" is not assignable to "z" or "z" is not assignable to "x". Besides
the error in "x:=y" you would also expect an error in "z:=y" or "x:=z"!  The
statement "z:=y" is a normal assignment of a subtype expression to its
supertype.  According to the language is "x:=z" allowed by an implicit
unsafe narrow, so "x:=z" is also a legal assignment of a supertype
expression to a subtype.

The problems are caused by (Language definition section 1.8 Unsafe
operations) the rule: In unsafe modules the definition of "assignable" for
types is extended: two reference types "T" and "U" are assignable if "T <:
U" or "U <: T". The only effect of this change is to allow a value of type
"ADDRESS" to be assigned to a variable of type "UNTRACED REF T". It is an
unchecked runtime error if the value does not address a variable of type
"T".

I believe it will be better to remove these lines from the language
definition. If one wants to assign an expression of the type "ADDRESS" to a
variable of the type "UNTRACED REF T" one can always use the transfer
function "LOOPHOLE"

Example 2
=========

VAR x:REAL;
    y:=ADR(x);
    z:=y+1;

BEGIN
  x:=z^;     (* error *)
  x:=(y+1)^; (* error *)
  y:=y+1;
  x:=y^ 
END Test.

What is the type of the expression "y+1": "ADDRESS" or "UNTRACED REF REAL"?
It is likely that "y+1" is not pointing to a real anymore, so "ADDRESS"
would be a good choise. On the other hand, address arithmetic is frequently
used to compute references to array elements, so "UNTRACED REF REAL" is
defendable. According to the language definition the type of "y+1" is
"ADDRESS": "+" is not defined on "UNTRACED REF REAL", so "y" is widened to
"ADDRESS" before the addition.

The type of "y+1" is "ADDRESS", so "z:=y+1" gives a variable "z" of type
"ADDRESS" and the assignment "x:=z^" produces an error. For similar reason
"x:=(y+1)^ is also not allowed. Because the type of the expression "y+1" is
"ADDRESS" and the type "UNTRACED REF REAL" is a subtype of "ADDRESS", the
types "y:=y+1" are not assignable.  According to the language definition an
implicit, unsafe narrow is generated to allow this assignment. Now we obtain
the peculiar situation that "x:=(y+1)^" is not allowed and "y:=y=1; x:=y^"
is allowed.

Proposal 2: untraced references and addresses
=============================================

The common accepted rules for subtyping are violated in case of unsafe
modules. I propose therefore to remove the lines mentioned above from the
language definition.

The new definition of "ADR" makes this function as safe as "NEW", so it can
also be used in safe modules:

             ADR(VAR x: Any)          : UNTRACED REF Any

This function becomes dangerous if its result is used as the argument of
"DISPOSE", because the result is an indisposable untraced reference. We have
a similar problem in case of disposing an already disposed untraced
reference. So the "DISPOSE" should remain unsafe.

Address arithmetic in not unsafe as long as the computed addresses are not
dereferenced. This means that the following operations are all safe:

infix +  (    x: ADDRESS, y: INTEGER): ADDRESS
infix -  (    x: ADDRESS, y: INTEGER): ADDRESS
infix -  (    x: ADDRESS, y: ADDRESS): INTEGER
    INC  (VAR x: ADDRESS; n: INTEGER := 1)
    DEC  (VAR x: ADDRESS; n: INTEGER := 1)

Because now the implicit narrow is forbidden, addresses can not be converted
to untraced references by safe operations. So an explicit unsafe "LOOPHOLE" is
necessary to dereference an address! Notice that in the new situation "INC"
and "DEC" are only defined on variables of type "ADDRESS" and not on
"UNTRACED REF Any".

Furthermore the following operations are defined

infix =  (    x, y: ADDRESS         ): BOOLEAN
infix #  (    x, y: ADDRESS         ): BOOLEAN
infix <  (    x, y: ADDRESS         ): BOOLEAN
infix <= (    x, y: ADDRESS         ): BOOLEAN
infix => (    x, y: ADDRESS         ): BOOLEAN
infix >  (    x, y: ADDRESS         ): BOOLEAN

    MIN  (    x, y: ADDRESS         ): ADDRESS
    MIN  (    x, y: UNTRACED REF T  ): UNTRACED REF T
    MAX  (    x, y: ADDRESS         ): ADDRESS
    MIN  (    x, y: UNTRACED REF T  ): UNTRACED REF T

Notice that in the new situation the character of the operation, safe or
unsafe, only depends on the operation and not on the arguments! This results
in the unsafe keywords "DISPOSE" and "LOOPHOLE".

What are unsafe oprations:

  1) dereferencing of variables of type "ADDRESS" (forbidden)
  2) using the "LOOPHOLE" transfer function
  3) using the "DISPOSE" statement
  4) using unsafe interfaces
  5) mixing traced and untraced references

All other operations are in the new situation safe!

Syntax
======

No changes.


======================================================================= 4 ===
Date:    1 Mar 1995 15:23:51 GMT
From:    ljw1004@thor.cam.ac.uk (L.J. Wischik)
Subject: Re: Language Definition


< proposal for READONLY variable declarations >

>The WITH statement already does what you are proposing.

Not really.
As already noted, WITH a=b, can have 'a' a writable value, depending on 
what b is.
Also, the READONLY as proposed would be very convenient because you would 
be able to declare variables precisely where you wanted them. But, some 
more has to be said about its initialisation.

If you declare
READONLY a;
in an interface, you have to be able to set its initial value somewhere.
If it was a VAR a, you would set its initial value in the BEGIN..END of 
some module that exported the interface; but with READONLY, it would get 
very messy. There are two solutions: either have some ugly syntax 
specifying where a READONLY is not a READONLY, or allow READONLY 
variables only in restricted locations. I think because of this problem, 
the proposed READONLY becomes not-that-useful.

--
Lucian Wischik, Queens' College, Cambridge CB3 9ET, UK. ljw1004@cam.ac.uk



======================================================================= 5 ===
Date:    Wed, 1 Mar 1995 08:31:25 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: M3 on Solaris

sd@inf.rl.ac.uk writes:
 > I'm having severe problems building the latest Modula-3 compiler on a Sparc 
 > 10 under Solaris 2.3 (SunOS 5.3).  It seems to compile the bootstrap compile
r 
 > correctly, but can't build the standard library from the source code.
 > 
 > I've unpacked boot-SOLsun.tar.gz, m3cc.tar.gz and m3.tar.gz.  I've managed t
o
 > compile everything under boot-SOLsun (after a few problems with wrong C 
 > compilers and lost libraries :-).  I then try to build the library from m3. 
 
 > Running m3build correctly builds mtex, then core dumps with a segmentation
 > fault trying to build m3core.  dbx says the problem is in a routine called 
 > _INITMRTLinker.

Are you building 3.5.1 or 3.5 ? This problem was present in 3.5 and has been 
fixed in 3.5.1. If you are building 3.5.1, you can send me you configuration
file and I'll take a quick look to see if there is anything obviously wrong.

I've successfully built 3.5.1 (SOLsun) without any problems.


--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 6 ===
Date:    1 Mar 1995 21:11:15 GMT
From:    gabrius@riker.cig.mot.com (David M. Gabrius)
Subject: Modula-3 for Amiga?

I was wondering if there's a port underway for Modula-3 for the Amiga.  

Thanks!
-- 
 David Gabrius -- Motorola Cellular \\ gabrius@cig.mot.com \\ 708-632-5944
 Software Engineer \\"You miss too much these days if you stop to think" -U2 
 "And you can find/Your own way out/You can build/And I can will..." -U2 
 "Some days take less but most days take more" \\ #include<stddisclaimer.h>


======================================================================= 7 ===
Date:    2 Mar 1995 00:05:03 GMT
From:    schaub@ponder.csci.unt.edu (Stephen Schaub)
Subject: Netobjects: ASSERT failure in ThreadPosix

  I'm working on a small netobjects program and am running into the
following run-time error:

***
*** runtime error:
***    ASSERT failed
***    file "../src/thread/POSIX/ThreadPosix.m3", line 1174
***
 
  This occurs when I make a network object method call and attempt to
transfer a linked list with more than, say, roughly 30 nodes.
Sometimes the error occurs on the client side, and sometimes on the server
side.  Lists with fewer nodes don't cause problems.

  I'm using the Linux version 3.4 release.  The application is a
Trestle demo that attempts to check drawings in and out from a central
repository.  Drawings are represented by a linked list of points,
managed by a (non-network) drawing object.  When a drawing is checked
out, the client makes a method call to obtain a drawing object from
the server; the client can then make modifications to the drawing
object (by adding new points) and then checks the drawing back in by
transferring the drawing object to the central repository using
another method call.

  Again, the programs work fine for drawings consisting of just a few
points, but the run-time error rears its head when more nodes are
involved.  Any ideas what might be wrong?

Thanks,

Stephen Schaub
schaub@cs.unt.edu



======================================================================= 8 ===
Date:    1 Mar 1995 20:16:12 -0700
From:    mian@beethoven.cs.colostate.edu (adnan mian)
Subject: How do you find the EOF for a file?

How do you find the EOF?

I am reading in the file like this
  run<input

I am using a WHILE NOT(IO.EOF() DO to read in the data in.
Then I read in the data.  This is not getting out of the loop.


What should I use??

Adnan Mian



======================================================================= 9 ===
Date:    Thu, 2 Mar 1995 02:08:21 GMT
From:    hgeorge@eskimo.com (Harry George)
Subject: WinNT questions

I'm ready to try Modula3 on WinNT. But... 
1. Will it work if I install using the DOS file system (FAT),
   so that I can work with both WinNT and DOS/Windows (WfW) 
   on the same files?

   Or do I actually need to do a partition, and install the NTFS?

2. Which (if any) Modula-3 release is stable on WinNT?  I'd prefer
   an ftp-able binary.  Something rock solid, so I could concentrate
   on writing app code rather than debugging the installation.
   (I'd be willing to do a compile if it was a pretty sure thing.)

3. Is there a Modula-3 .i3 for WinNT's Win32?  How about for OpenGL?
 

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



======================================================================= 10 ===
Date:    2 Mar 1995 16:58:12 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: WinNT questions

In article <D4sJ9x.4F2@eskimo.com>, hgeorge@eskimo.com (Harry George) writes:
> I'm ready to try Modula3 on WinNT. But... 
> 1. Will it work if I install using the DOS file system (FAT),
>    so that I can work with both WinNT and DOS/Windows (WfW) 
>    on the same files?

I doubt it will work.  The NT port of SRC Modula-3 generates and
uses long file names.

> 2. Which (if any) Modula-3 release is stable on WinNT?  I'd prefer
>    an ftp-able binary.  Something rock solid, so I could concentrate
>    on writing app code rather than debugging the installation.
>    (I'd be willing to do a compile if it was a pretty sure thing.)

We don't have a binary to distribute.  Installing a binary copy
of the system in a location you specify will require a bit of new
machinery.

So far we've done our development on NT (beta 3.1).  We've received
some messages indicating that the released version (3.5) is slightly
different.

> 3. Is there a Modula-3 .i3 for WinNT's Win32?  How about for OpenGL?

There's a collection of .i3 files that describe much of the Win32
interface.  The coverage is not 100%.

I don't know of any Modula-3 interfaces for OpenGL.

  - Bill Kalsow



======================================================================= 11 ===
Date:    2 Mar 1995 11:58:25 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Where is ParseParams?

In article <D4pr4E.7ot@watdragon.uwaterloo.ca>,
Byron Weber Becker <bwbecker@watdragon.uwaterloo.ca> wrote:
>>bwbecker@watdragon.uwaterloo.ca writes:
>> > I think I remember a promise that ParseParams would be
>> > returned to libm3 in v3.5.  I can't find it, although
>> > it is documented in the WWW pages at
>> > http://www.research.digital.com/SRC/m3sources/html/parseparams/src/Parse
>> > Params.i3
>> >
>> > Thanks for any help...
>>
>>It's in 3.5.1 in m3/parseparams
>
>Thanks for the response, but I still don't see it.  The folks
>who installed M3 claim it's 3.5.1.  I think the right
>place to look (on our system) is
>.../modula3/lib/m3/pkg/lim3/src
>but I see no m3 or parseparams in that directory, nor does
>the find command find it in any subdirectories.  m3which
>doesn't find it, nor does m3build when I try to IMPORT it
>in a program.  Further clues?

 It's in pkg/parseparams (ie. .../modula3/lib/m3/pkg/parseparams) 
- you'll have to include

import(parseparams)

 In your m3makefile to import the library before you can import
the ParseParams interface in your program.
 (this is assuming parseparams has been installed at your site, 
though I can't see any reason for it not to be).


Richard.
-- 
`There comes a time when you look into the mirror and you realise that what you
 
see is all that you will ever be. And then you accept it. Or you kill 
yourself. Or you stop looking in mirrors.'
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 12 ===
Date:    Thu, 2 Mar 1995 14:55:58 -0500
From:    douglm@rpi.edu
Subject: Re: Network objects, threads and stacks

>Another solution that doesn't require any changes to the network object's
>interfaces or runtime is for you to fork off your own thread in those cases
>where you know that you will need a large stack. That is, the method
>implementation in your server forks off a thread of its own with the size
>that you choose. It's a little more work on your part, but doesn't require
>any changes to the current interfaces.
>
I'm certainly aware that I could do that, and I'm not trying to avoid the
work of doing so.  However, I presume that one of the aims of having
network objects is to hide such details. I don't want to have to change the
program structure to get around an implementation feature.

I think the implementation of network objects is great and should work well
for most cases. If, however, the application begins to develop accretions
as we try to avoid problems with the implementation I don't think it's
inappropriate to consider changes.
(That sounds awful but I hate those smiley things)

I believe I could solve my own problems if I could register another
transport mechanism. My belief is that there is no way to do so currently
although the mechanism seems to be partially in place.





======================================================================= 13 ===
Date:    2 Mar 1995 19:51:48 GMT
From:    lrau@hal.COM (Larry Rau)
Subject: Re: WinNT questions

As of Win NT 3.5 the FAT filesystem supports long filenames, and as
long as the runtime uses OS calls there should be no requirement for
NTFS -- although I think NTFS is better, for various other reasons.

-- 
Larry Rau 
Migration Software Systems
(lrau@migration.com)



======================================================================= 14 ===
Date:    Thu, 2 Mar 1995 18:47:22 GMT
From:    "Jason D. Smith" <jasons@ngc.com>
Subject: Re: Building NT binaries

ahmiles@uk.oracle.com (Hugh Miles) wrote:
>
> In article <3i0f44$f6u@news1.is.net>, cadmus@cadmusinteractive.is.net (Reggie
 Burnett) says:
> >
> >I have tried building NT binaries of SRC Modula 3 3.5.1 (or something like t
hat).
> >I build quake, but now I am getting alot of "system cannot find specified fi
le".
> >
> >Is there anyone else out there trying to build NT binaries?
> >
> >If DEC people are listening, why don't you make NT binaries available?
> >
> >Reggie
> >
> >
> I am alos tyring to build the mod3 complier on windows NT 3.5.
> When I build quake.exe I get the linker error 
> : unresolved external __imp___p__iob.
> 
> Can any one help! or dose any have the NT binaries?
> 
> Andy


If you are using VC2.0, try changing all ocurrences of CRTDLL.LIB 
with MSVCRT20.LIB in all make- and quakefiles
(i.e. m3build\template\NT386 and quake\makefile.nt)

WRT binaries, I had to make room on my drive ... 8-( 

Sorry.

Jason.




======================================================================= 15 ===
Date:    3 Mar 1995 11:13:36 GMT
From:    sd@inf.rl.ac.uk
Subject: Re: M3 on Solaris


Thanks to the people who responded to my posting about problems
compiling Modula-3 under Solaris.

The solution (due to Geoff Wyant at Sun) is to move to release 3.5.1 which
has corrected the trouble.  Having acquired the new archives the system
built "out of the box" with a single exception of one incorrectly-terminated
interface (I'll leave the solution as an excercise for the reader :-).

Blair MacIntyre at Columbia reported that the Solaris GNU version works
fine, so that's an alternative way out.

Thanks again!  It's good to see that news still has the power to fix 
people's difficulties!


-- Si

Dr Simon A. Dobson

Computing and Information Systems   \ My mind is racing, as it always will,
DRAL, Rutherford Appleton Laboratory \ My hands tired, my heart aches
Chilton, Didcot, Oxon OX11 0QX, UK.   \ I'm half a world away.

sd@inf.rl.ac.uk            http://www.cis.rl.ac.uk/people/sd/contact.html


======================================================================= 16 ===
Date:    2 Mar 1995 17:17:38 -0500
From:    atlas@alpha.bin-sixx.com (Atlas Computer Systems)
Subject: WD_1_GIG_DRIVE

*********************************ADVERTISEMENT********************************
Atlas Computer Systems is pleased to announce the arrival of the Western 
Digital Caviar AC31000 1.08 GB EIDE hard drive for the unbelievably low 
price of $389 plus $10 shipping and handling. Call Atlas Computer Systems 
at (904) 694-2900 Monday through Friday 9 a.m. to 6 p.m. EST with your 
credit card ready to place an order. All orders placed within the 
continental United States will be shipped via UPS Second Day Air. Ask 
your ACS sales representative for information on international shipping. If 
you're interested in having our current price list e-mailed to you, send 
a request to us001663@interramp.com. We look forward to hearing from you.
*********************************ADVERTISEMENT********************************


======================================================================= 17 ===
Date:    2 Mar 1995 19:56:55 GMT
From:    fld@Informatik.Uni-Bremen.DE ()
Subject: M3_3.5.1, SOLgnu, Solaris 2.4, missing library -laio


 I have succsessfully bootstraped m3_3.5.1, Sol2.4, GNU version.
A lot of the whole m3 libraries and applications have been installed.
The applications can be executed without any problem.

 But when I try to create 'netobjd' or 'stubgen' the following message
occurs:
	ld: fatal: library -laio: not found
	ld: fatal: File processing errors.  No output written to ...

Can anyone explain to me where to find this library? Why is it needed ?
I could not find any reference to this library in the m3makefiles.
How does the compiler or m3build know about it?

-- 
	

Guenter Feldmann		EMail:  fld@informatik.Uni-Bremen.de
FB 3, Informatik
Univ. Bremen, Germany			




======================================================================= 18 ===
Date:    Fri, 3 Mar 95 13:47:25 GMT
From:    buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409)
Subject: Re: Language Definition 2

In article <9503010755.AA22038@inet-gw-1.pa.dec.com> you wrote:

: I introduce the second proposal to change the language definition with two
: examples of unsafe implementations. I use the new definition of "ADR(x)",
: where instead of "ADDRESS", "ADR(x)" returns an "UNTRACED REF T" when the
: static type of "x" is "T". The new definition increases the safety of
: interfacing with the C world.

I have also thought of an "ADR(x)" operator, with the same
semantics. It might be nice to have. 

You now can have pointers to the stack. This is an advantage and a
disadvantage, at the same time. You can build complicated
datastructures on the stack, pass them around, and don't need to think
about deallocation.. But you can also generate a dangling pointer when
you put the generated reference into a global variable. So "ADR(x)"
would be only possible inside an unsave module, where you can always
use "ADDRESS(x)".

You also take away some choices from the languages implementor. As
long, as s/he is guaranteed, that there are no untraced references to
the stack, s/he might do some estoic things to increase
performance. Some optimisations can't be done when there are aliases
to locations.


: Address arithmetic in not unsafe as long as the computed addresses are not
: dereferenced. This means that the following operations are all safe:

: infix +  (    x: ADDRESS, y: INTEGER): ADDRESS
: infix -  (    x: ADDRESS, y: INTEGER): ADDRESS
: infix -  (    x: ADDRESS, y: ADDRESS): INTEGER
:     INC  (VAR x: ADDRESS; n: INTEGER := 1)
:     DEC  (VAR x: ADDRESS; n: INTEGER := 1)

: Because now the implicit narrow is forbidden, addresses can not be converted
: to untraced references by safe operations. So an explicit unsafe "LOOPHOLE" i
s
: necessary to dereference an address! Notice that in the new situation "INC"
: and "DEC" are only defined on variables of type "ADDRESS" and not on
: "UNTRACED REF Any".

The problem is, you can do address arithmetic outside of unsave
modules, now. So you have to take into account all the client code of
an unsave module, when checking the code for robustness. 

Passing an ADDRESS somewhere dosn't change it's value. Inside an
unsave module, you know, you are system dependant, and may have to
check, if a generated ADDRESS is a) valid and b) points to something.

When accepting an ADDRESS, someone else did arithmetic on, you don't
know anything about it. You even might be unable to check, if it is
save to use.


: Furthermore the following operations are defined

: infix =  (    x, y: ADDRESS         ): BOOLEAN
: infix #  (    x, y: ADDRESS         ): BOOLEAN
: infix <  (    x, y: ADDRESS         ): BOOLEAN
: infix <= (    x, y: ADDRESS         ): BOOLEAN
: infix => (    x, y: ADDRESS         ): BOOLEAN
: infix >  (    x, y: ADDRESS         ): BOOLEAN

:     MIN  (    x, y: ADDRESS         ): ADDRESS
:     MIN  (    x, y: UNTRACED REF T  ): UNTRACED REF T
:     MAX  (    x, y: ADDRESS         ): ADDRESS
:     MIN  (    x, y: UNTRACED REF T  ): UNTRACED REF T

This assumes that either

 a) all values of Type ADDRESS are ordered

or

 b) ``x < y''  isn't equivalent to  ``NOT (x >= y)''  for Type ADDRESS.

    if x and y are unordered, ``x < y'' evaluates to FALSE and 
    ``x >= y'' evaluates to FALSE, too.


The Modula3 Language Definition doesn't say anything about the
Ordering of Values of Type ADDRESS. 

You can implement it even for a strange CPU architecture.


				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

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

	buschman@lts.sel.alcatel.de


======================================================================= 19 ===
Date:    02 Mar 1995 22:48:23 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Re: WinNT questions

>>>>> On 2 Mar 1995 16:58:12 GMT, kalsow@src.dec.com (Bill Kalsow)
>>>>> said:

>> 3. Is there a Modula-3 .i3 for WinNT's Win32?  How about for OpenGL?

Bill> There's a collection of .i3 files that describe much of the
Bill> Win32 interface.  The coverage is not 100%.

Bill> I don't know of any Modula-3 interfaces for OpenGL.

I have a set of .i3 files for OpenGL on the IRIS.  If anyone wants
them, I'll put the current set up on ftp -- they'll most likely change
as we work with them.  I don't know if they are the same as is
required for NT.

(When the WinNT support for netobj's is working, I will be installing
 it here.  At that point, the first thing I will be doing is porting
 the OpenGL code we are writing on our IRIS to NT (in fact, the main
 reason for using NT will be as a cheaper 3D display driver).  So, I'll
 make OpenGL i3's for NT then.

 So, if anyone has any hints as to when netobjs will be supported,
 you'll then know when we'll be making OpenGL i3's for NT. :-)
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

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


======================================================================= 20 ===
Date:    1 Mar 1995 19:45:34 -0500
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: Netobjects: ASSERT failure in ThreadPosix

>>>>> On 2 Mar 1995 00:05:03 GMT, schaub@ponder.csci.unt.edu (Stephen
>>>>> Schaub) said:

Stephen>   I'm working on a small netobjects program and am running into the
Stephen> following run-time error:

Stephen> ***
Stephen> *** runtime error:
Stephen> ***    ASSERT failed
Stephen> ***    file "../src/thread/POSIX/ThreadPosix.m3", line 1174
Stephen> ***
 
Stephen>   This occurs when I make a network object method call and
Stephen> attempt to transfer a linked list with more than, say,
Stephen> roughly 30 nodes.  Sometimes the error occurs on the client
Stephen> side, and sometimes on the server side.  Lists with fewer
Stephen> nodes don't cause problems.

The network object stubs will be using the Pickling library for
transfering your object, since it isn't one of the set of simple types
it handles directly.  Since the Pickling stuff is recursive, my guess
is that you are running out of stack space.

Look at the Pickle.i3 file, or the paper documentation that derives
from it.  It describes how to register a Pickling routine for your
type.  Create a pickler that iteratively scans your linked list,
instead of recursively.   That will hopefully solve your problem.

Also, looking at the source would help you figure this out.  Line 1174
in my installation (3.5.1) isn't an assert, but it's quite close to
the Transfer proc, which appears to be checking if a guard at the
beginning or end of you stack has been tromped.



======================================================================= 21 ===
Date:    03 Mar 1995 16:12:59 GMT
From:    bm@ground.cs.columbia.edu (Blair MacIntyre)
Subject: Re: M3_3.5.1, SOLgnu, Solaris 2.4, missing library -laio

>>>>> On 2 Mar 1995 19:56:55 GMT, fld@Informatik.Uni-Bremen.DE ()
>>>>> said:

GF> I have succsessfully bootstraped m3_3.5.1, Sol2.4, GNU version.
GF> A lot of the whole m3 libraries and applications have been installed.
GF> The applications can be executed without any problem.

GF> But when I try to create 'netobjd' or 'stubgen' the following message
GF> occurs:
GF> 	ld: fatal: library -laio: not found
GF> 	ld: fatal: File processing errors.  No output written to ...

GF> Can anyone explain to me where to find this library? Why is it needed ?
GF> I could not find any reference to this library in the m3makefiles.
GF> How does the compiler or m3build know about it?

I think the problem is that the m3makefiles for those programs specify
build_standalone(), which doesn't work properly on Solaris.  In this
case, the problem is there is no libaio.a (at least on my system),
only a libaio.so.

I posted a script a while ago that partially fixes (I hope) the
build_standalone problem on Solaris: it arranges things to that the m3
libraries are statically linked when building standalone, but the
Solaris ones are linked dynamically.
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

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


======================================================================= 22 ===
Date:    2 Mar 1995 12:52:11 GMT
From:    Quentin Stafford-Fraser <fraser@europarc.xerox.com>
Subject: Re: Where is ParseParams?

bwbecker@watdragon.uwaterloo.ca (Byron Weber Becker) wrote:

> I think the right
> place to look (on our system) is
> ..../modula3/lib/m3/pkg/lim3/src

No, it's a separate package, not part of libm3, so it's probably 
under ...modula3/lib/m3/pkg/parseparams/src.

> m3which
> doesn't find it, nor does m3build when I try to IMPORT it
> in a program.  Further clues?

You need import("parseparams") in your m3makefile.

Hope this helps,
Quentin



======================================================================= 23 ===
Date:    4 Mar 1995 13:20:05 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Re: Netobjects: ASSERT failure in ThreadPosix

In article <199503020045.TAA06441@shadow.cs.columbia.edu>, bm@news.cs.columbia.
edu (Blair MacIntyre) writes:
>>>>>> On 2 Mar 1995 00:05:03 GMT, schaub@ponder.csci.unt.edu (Stephen
>>>>>> Schaub) said:
>
>Stephen>   I'm working on a small netobjects program and am running into the
>Stephen> following run-time error:
>
>Stephen> ***
>Stephen> *** runtime error:
>Stephen> ***    ASSERT failed
>Stephen> ***    file "../src/thread/POSIX/ThreadPosix.m3", line 1174
>Stephen> ***
> 
>Stephen>   This occurs when I make a network object method call and
>Stephen> attempt to transfer a linked list with more than, say,
>Stephen> roughly 30 nodes.  Sometimes the error occurs on the client
>Stephen> side, and sometimes on the server side.  Lists with fewer
>Stephen> nodes don't cause problems.
>
>The network object stubs will be using the Pickling library for
>transfering your object, since it isn't one of the set of simple types
>it handles directly.  Since the Pickling stuff is recursive, my guess
>is that you are running out of stack space.
>
>Look at the Pickle.i3 file, or the paper documentation that derives
>from it.  It describes how to register a Pickling routine for your
>type.  Create a pickler that iteratively scans your linked list,
>instead of recursively.   That will hopefully solve your problem.

Maybe the Pickle generic module should automatically register a pickelr
for it's list type that will pickle it iteratively. This would save
people having to write their own versions. 

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 24 ===
Date:    04 Mar 1995 19:12:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Language Definition 2

rudy@cs.rug.nl wrote on 01.03.95 in <9503010755.AA22038@inet-gw-1.pa.dec.com>:

> I have showed these examples to some members of my department, and they all
> find them lunatic. So I have reported these examples as bugs to Bill Kalsow
> and he states that the error messages are correct according to the language
> definition, and really they are! From my point of view the language
> definition should be changed.

I don't see anything lunatic here; on the contrary, that's _exactly_ what  
I would expect.

> Example 1
> =========
>
> VAR x:UNTRACED REF REAL;
>     y:UNTRACED REF INTEGER;
>     z:ADDRESS;
>
> BEGIN
>   x:=y; (* error *)
>   z:=y;
>   x:=z; (* correct *)
> END Test.
>
> Are "x" and "y" assignable? "x" and "y" are not assignable. So you would
> expect "y" is not assignable to "z" or "z" is not assignable to "x". Besides

No, I wouldn't. That's the exact behaviour lots of other languages have.  
For example, consider C - you can't assign a int* to a float*, but you can  
assign both to void* and vice versa. I think Modula-2 also works that way.  
Turbo Pascal certainly does.

> Example 2
> =========
>
> VAR x:REAL;
>     y:=ADR(x);
>     z:=y+1;
>
> BEGIN
>   x:=z^;     (* error *)
>   x:=(y+1)^; (* error *)
>   y:=y+1;
>   x:=y^
> END Test.
>
> What is the type of the expression "y+1": "ADDRESS" or "UNTRACED REF REAL"?

As you use the new form of ADR, it's the latter.

> It is likely that "y+1" is not pointing to a real anymore, so "ADDRESS"

Correct - y+1 _is_ a REAL instead. Adding 1 to a UNTRACED REF REAL (or to  
a traced one, at that) doesn't do address arithmetic, but instead  
dereferences and does real arithmetic. In short, "y+1" is exactly the same  
as "y^+1".

Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 25 ===
Date:    5 Mar 1995 03:36:30 GMT
From:    pje120@cs.usask.ca (Patrick John Edwards)
Subject: Re: Language Definition

douglm@rpi.edu wrote:
: Sam Kendall pointed out:

: >The WITH statement already does what you are proposing.
: >

: In general there is more than one way of doing something. I guess the value
: of such a feature is the self-documenting aspect. WITH doesn't really tell
: us why it's being used other than as a shorthand construct.

I agree completely here, the READONLY statement made the code much more
readable.


======================================================================= 26 ===
Date:    Mon, 6 Mar 95 07:58:17 GMT
From:    ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB)
Subject: Why no multiple inheritance in Modula-3?

I have looked at the language definition of Modula-3, and I see that it only
allows single inheritance. Are there any reasons for this except for the obviou
s
complication in implementing it? 

In my experience, multiple inheritance can be
really useful, because it allows you to define different concepts and mix them 
in
a class as you please, instead of having to force everything into a big,
unwieldy class hierarchy.

Does Modula-3 have any other mechanism which makes multiple inheritance
superfluous?

Btw., I'm not bashing the language, just curious about why it was designed this
way.

Ole-Hj. Kristensen


======================================================================= 27 ===
Date:    3 Mar 1995 04:05:48 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Re: Language Definition


Some have claimed that READONLY is not needed because we have WITH.
Where I would like to see READONLY is in *interfaces*, so I can export
variables that won't be touched.  I'll usually initialize such
variables this way:
  READONLY x := NEW(T).init(...);
You can't do this using WITH.

I'm sure I've seen the words
  VAR (*READONLY*) 
in libm3 to document this sort of intention.

Norman




======================================================================= 28 ===
Date:    Mon, 6 Mar 1995 12:58:28 GMT
From:    jhagman@tportti.helsinki.fi (Jussi Hagman)
Subject: Langage definitions


Where could I find the language definitions for Modula-2, Modula-3 and 
Oberon?

Thanks in advance, Jussi



======================================================================= 29 ===
Date:    6 Mar 1995 16:56:39 GMT
From:    chase@centerline.com (David Chase)
Subject: Re: Why no multiple inheritance in Modula-3?

ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes:
> I have looked at the language definition of Modula-3, and I see that it only
> allows single inheritance. Are there any reasons for this except for the obvi
ous
> complication in implementing it? 

There's non-obvious complications in defining its interactions with
the rest of the language.  Also, people tried programming in it
with single inheritance, and ported code written using multiple
inheritance, and decided that the lack of MI was a tolerable
deficiency.  That's not the same thing as "not a deficiency".
Read on to find out (some reasons) why it was left out.

The major difficulties come from the casting rules and the
desire to avoid "accidents".  If you draw the usual multiple-
inheritance shared-base/super-class "diamond",

  A  (super, base)
 B C
  D  (sub, derived)

you have to decide what is supposed to happen if B and C are
both depending upon state (not interface, but state -- crucial
difference here) stored in A.  There's no reason to assume that
B and C were written with any knowledge of each other, and (as
the language stands now) one can use a superclass and know that
the subclass controls all access to the state there -- that is,
no surprises.  Adding multiple inheritance (with sharing) changes
this, unless you also add to the language some way to announce
that "this base class can be shared" (as opposed to the C++
technique for distinguishing shared from unshared base classes,
where the decision is made at the point of inheritance -- that is,
in the derived class).

There are two additional implementation interactions that may not
be obvious.  The first is the time and space complexity of narrow
and typecase -- with single inheritance, the costs can be
 O(1) time/narrow, O(log #cases) time/typecase
 O(1) storage/type, O(#cases) storage/typecase
For multiple inheritance, provided that sharing is associated with
the base class and not its inheritance site, these figures can be
maintained for "old" (single inheritance only) programs.  However,
this was not known at the time that the language was designed.

The second implementation interactions occurs when you cast
function pointers.  Modula-3 lets you perform contravariant
function casting -- that is, you may substitute an A -> B where a
C -> D is expected, provided that A is a super(base) type of C and
B is a sub(derived) type of D (this follows from an easy-to-verify
rule -- if a C -> D is expected, then an A -> B will never be
passed something that is not an A, and will always return something
that is at least a D).  There's no problem with the pointer to code
itself, since all objects have the same representation and all
types/classes are "rooted at" the same address.

When you add multiple inheritance, this changes.  Now, suppose that
we pass an A -> B into a C -> D context.  Suppose "A" is a strict
(not equal) supertype of C at offset 16 from C's root (the fact
that I know the offset will be constant for all objects passed is
something that depends on my assumption that sharing is declared at
the base type, not the inheritance site -- I may not know the value
of the constant until runtime), and that D is a supertype of B
occurring at offset 32.  If you'll permit me to mix machine code
and the lambda calculus, if the original function (from A -> B) was
called "F", the the function that needs to be passed into the C ->
D context will be this thunk:

  (lambda (x) (+ (F (- x 16) ) 32) )

The subtraction of 16 turns the representation of an A into the
representation of a C, and the addition of 32 turns the
representation of a B into the representation of a D.  No run-time
checks are necessary (the legality was statically verified) but
something like runtime code generation IS required.  Note that this
was a function of one parameter -- more code means a messier thunk.
Of course, for an "old" single inheritance program, this is not a
problem, because all the offsets will be zero, and no thunk needs
to be generated (this, however, may not be visible at compile time,
given the interesting things that opaque inheritance can do to/for
you).

The need to generate thunks like this appears to be a sticking
point for many people.  I don't understand why, but I think that's
partly because I've been playing with run-time code generation on
and off for a while now, and because after a few years of working
on a code generator, I decided that it's really all just data,
anyhow.  It just doesn't seem to be a problem to me.
There are some architectures where the separation between
code and data is more explicit, but I've managed to implement
limited-but-sufficient-for-this-purpose thunks for split I/D
machines (basic idea -- the thunks all do about the same thing but
with different parameters.  Create a cache of code+data pairs. 
Only write the code once, to fill the cache, but modify the data
each time you need a new thunk).  You can think of this as a
special case of mixing interpreted code with binary code --
in the most general case, the "code" branches into the interpreter,
and the "data" is a set of byte codes to modify the parameters and
return values.  

And, if all else fails, do note that if something runs very slowly
on a machine because of implementation difficulties, that is still
much faster than not running at all because it was banned from the
language.  Do note that code using only single inheritance would
not be slowed down by all this crazy thunk machinery.

As if you cannot tell, I've been thinking about this for some time,
and I haven't completely figured it out -- for instance, I strongly
suspect that there could be some unforeseen glitches arising from
the combination of opaque inheritance, multiple inheritance, and
the usual changes made to programs in the course of normal
development (suppose an interface is changed in a way that reveals
a previously hidden supertype -- this could introduce ambiguities
in existing code.  I think this example motivates banning any
automatic rules for resolving such an ambiguity, which in turn
motivates adding a way to explicitly designate or rename a
supertype).

> Does Modula-3 have any other mechanism which makes multiple
> inheritance superfluous?

Some, but not all, applications of multiple inheritance can be
implemented with opaque supertypes.  The other approach is to
contain the things that you need, and delegate manually.  This
isn't perfect.

yours,

David Chase


======================================================================= 30 ===
Date:    6 Mar 1995 21:59:53 GMT
From:    mastchen@des4 (Mastchenko Cyrille)
Subject: Modula-3.x and Windows 95

I want to know if i can program in Modula-3 with thread, ... with
windows'95, i have Visual C++ 2.1 and Watcom c++ 10.0 for compile it.

	MASTCHENKO Cyrille.
	email:mastchen@des8.u-strasbg.fr



======================================================================= 31 ===
Date:    7 Mar 1995 03:16:54 GMT
From:    mako@fnalv1.fnal.gov (Makoto Shimojima, Univ of Tsukuba/CDF)
Subject: Re: Language Definition

> Where I would like to see READONLY is in *interfaces*, so I can export
> variables that won't be touched.  I'll usually initialize such
> variables this way:
>   READONLY x := NEW(T).init(...);
> You can't do this using WITH.

If you want to restrict access to a variable, write a method to handle it
and hide the variable itself in the interface. If the inline pragma is
properly implemented, the overhead should be minimum.

						mako


======================================================================= 32 ===
Date:    7 Mar 1995 23:25:59 GMT
From:    COBA Computing Center <jk14@sol.acs.unt.edu>
Subject: linked lists

Does anyone know where I can find some info or see some example
code explaining how to implement linked lists in objects?

			Thanx


======================================================================= 33 ===
Date:    Wed, 8 Mar 1995 15:53:55 +0000
From:    mhoward@darklord.demon.co.uk ("c:internetka9qspoolmail")
Subject: Hardware & Operating Systems

Some of you out there may have already been down this avenue...

I am investigating possible tools/languages for developing large, 
distributed C/S applications.

How portable is Modula-3? What platforms / operating systems is it 
available on?

TIA

/------------------------------------------------------------------------------
\
| Mark Howard                                     mhoward@darklord.demon.co.uk 
|
| Cheif Systems Architect                                                      
|
\------------------------------------------------------------------------------
/



======================================================================= 34 ===
Date:    Wed, 8 Mar 1995 09:00:42 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: linked lists

COBA Computing Center writes:
 > Does anyone know where I can find some info or see some example
 > code explaining how to implement linked lists in objects?
 > 
 > 			Thanx

Why implement it yourself ? Just use the 'List' generic type that is 
supplied with the SRC release.

If you are just curious about how to implement linked lists, then
take a look the the List.ig and List.mg source files.

--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 35 ===
Date:    07 Mar 1995 16:34:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Problems building 3.5.1/boot-LINUX

Building the library, to be exact.

After hunting after an obscure bug in the dll tools-2.1.6 (a buffer  
[wrapup, in mkimage.c] was too small, overwriting critical variables) and  
telling the linker where to find lgcc, I'm now getting unresolved  
references.

What's going on here?!  I thought 3.5.1 was supposed to be bug-fixed ...  
but from the errors I already fixed, I'm beginning to doubt that.

Script started on Tue Mar  7 16:08:15 1995
khms[tty1]:/opt/m3/m3# m3build ; exit--- building in LINUX ---
-- mtex done --

---------------------- building m3core ----------------------

--- building in LINUX ---
mkdir -p jump; mkdir -p jumpas
m3 -w1 -why -g -times -a libm3core.a -F/tmp/qk20931aaa

 seconds  #times  operation
    2.18       2  inhaling library link info
    1.40       1  getting derived timestamps
    1.73     181  checking timestamps
    0.65     177  checking old link info
    0.01       1  merging new link info
    0.99       2  garbage collection
    1.69          other
---------------------------------------------------
    8.63          TOTAL

/opt/SRCm3/lib/m3/LINUX/buildShared -n libm3core -a 0x64400000 -j 0x4000 -g 0x2
000 -x 3 -y 5 -l " "
/usr/dll/jump/as -o BasicCtypes.io BasicCtypes.is
/usr/dll/jump/as -o CConvert.io CConvert.is
/usr/dll/jump/as -o CConvert.mo CConvert.ms
/usr/dll/jump/as -o Cerrno.io Cerrno.is
/usr/dll/jump/as -o Convert.io Convert.is
/usr/dll/jump/as -o Convert.mo Convert.ms
/usr/dll/jump/as -o Csetjmp.io Csetjmp.is
/usr/dll/jump/as -o Csignal.io Csignal.is
/usr/dll/jump/as -o Cstdarg.io Cstdarg.is
/usr/dll/jump/as -o Cstdarg.mo Cstdarg.ms
/usr/dll/jump/as -o Cstddef.io Cstddef.is
/usr/dll/jump/as -o Cstdio.io Cstdio.is
/usr/dll/jump/as -o Cstdio.mo Cstdio.ms
/usr/dll/jump/as -o Cstdlib.io Cstdlib.is
/usr/dll/jump/as -o Cstring.io Cstring.is
/usr/dll/jump/as -o Ctypes.io Ctypes.is
/usr/dll/jump/as -o Date.io Date.is
/usr/dll/jump/as -o DateLinux.mo DateLinux.ms
/usr/dll/jump/as -o DragonInt.io DragonInt.is
/usr/dll/jump/as -o DragonInt.mo DragonInt.ms
/usr/dll/jump/as -o DragonT.io DragonT.is
/usr/dll/jump/as -o DragonT.mo DragonT.ms
/usr/dll/jump/as -o Extended.io Extended.is
/usr/dll/jump/as -o Extended.mo Extended.ms
/usr/dll/jump/as -o ExtendedFloat.io ExtendedFloat.is
/usr/dll/jump/as -o ExtendedFloat.mo ExtendedFloat.ms
/usr/dll/jump/as -o FPU.io FPU.is
/usr/dll/jump/as -o FPU.mo FPU.ms
/usr/dll/jump/as -o Fingerprint.io Fingerprint.is
/usr/dll/jump/as -o Fingerprint.mo Fingerprint.ms
/usr/dll/jump/as -o FloatMode.io FloatMode.is
/usr/dll/jump/as -o FloatMode.mo FloatMode.ms
/usr/dll/jump/as -o FmtTime.io FmtTime.is
/usr/dll/jump/as -o FmtTime.mo FmtTime.ms
/usr/dll/jump/as -o IEEESpecial.io IEEESpecial.is
/usr/dll/jump/as -o IEEESpecial.mo IEEESpecial.ms
/usr/dll/jump/as -o LongFloat.io LongFloat.is
/usr/dll/jump/as -o LongFloat.mo LongFloat.ms
/usr/dll/jump/as -o LongReal.io LongReal.is
/usr/dll/jump/as -o LongReal.mo LongReal.ms
/usr/dll/jump/as -o LongRealRep.io LongRealRep.is
/usr/dll/jump/as -o M3toC.io M3toC.is
/usr/dll/jump/as -o M3toC.mo M3toC.ms
/usr/dll/jump/as -o Main.io Main.is
/usr/dll/jump/as -o Poly.io Poly.is
/usr/dll/jump/as -o Poly.mo Poly.ms
/usr/dll/jump/as -o PolyBasis.io PolyBasis.is
/usr/dll/jump/as -o PolyBasis.mo PolyBasis.ms
/usr/dll/jump/as -o RT0.io RT0.is
/usr/dll/jump/as -o RT0.mo RT0.ms
/usr/dll/jump/as -o RT0u.io RT0u.is
/usr/dll/jump/as -o RT0u.mo RT0u.ms
/usr/dll/jump/as -o RTAllocator.io RTAllocator.is
/usr/dll/jump/as -o RTAllocator.mo RTAllocator.ms
/usr/dll/jump/as -o RTArgs.io RTArgs.is
/usr/dll/jump/as -o RTArgs.mo RTArgs.ms
/usr/dll/jump/as -o RTCollector.io RTCollector.is
/usr/dll/jump/as -o RTCollector.mo RTCollector.ms
/usr/dll/jump/as -o RTCollectorSRC.io RTCollectorSRC.is
/usr/dll/jump/as -o RTExRep.io RTExRep.is
/usr/dll/jump/as -o RTException.io RTException.is
/usr/dll/jump/as -o RTException.mo RTException.ms
/usr/dll/jump/as -o RTHeap.io RTHeap.is
/usr/dll/jump/as -o RTHeap.mo RTHeap.ms
/usr/dll/jump/as -o RTHeapDebug.io RTHeapDebug.is
/usr/dll/jump/as -o RTHeapDebug.mo RTHeapDebug.ms
/usr/dll/jump/as -o RTHeapDep.io RTHeapDep.is
/usr/dll/jump/as -o RTHeapDep.mo RTHeapDep.ms
/usr/dll/jump/as -o RTHeapEvent.io RTHeapEvent.is
/usr/dll/jump/as -o RTHeapInfo.io RTHeapInfo.is
/usr/dll/jump/as -o RTHeapInfo.mo RTHeapInfo.ms
/usr/dll/jump/as -o RTHeapMap.io RTHeapMap.is
/usr/dll/jump/as -o RTHeapMap.mo RTHeapMap.ms
/usr/dll/jump/as -o RTHeapRep.io RTHeapRep.is
/usr/dll/jump/as -o RTHeapRep.mo RTHeapRep.ms
/usr/dll/jump/as -o RTHeapStats.io RTHeapStats.is
/usr/dll/jump/as -o RTHeapStats.mo RTHeapStats.ms
/usr/dll/jump/as -o RTHooks.io RTHooks.is
/usr/dll/jump/as -o RTHooks.mo RTHooks.ms
/usr/dll/jump/as -o RTIO.io RTIO.is
/usr/dll/jump/as -o RTIO.mo RTIO.ms
/usr/dll/jump/as -o RTLinker.io RTLinker.is
/usr/dll/jump/as -o RTLinker.mo RTLinker.ms
/usr/dll/jump/as -o RTMachine.io RTMachine.is
/usr/dll/jump/as -o RTMapOp.io RTMapOp.is
/usr/dll/jump/as -o RTMapOp.mo RTMapOp.ms
/usr/dll/jump/as -o RTMisc.io RTMisc.is
/usr/dll/jump/as -o RTMisc.mo RTMisc.ms
/usr/dll/jump/as -o RTModule.io RTModule.is
/usr/dll/jump/as -o RTModule.mo RTModule.ms
/usr/dll/jump/as -o RTOS.io RTOS.is
/usr/dll/jump/as -o RTOS.mo RTOS.ms
/usr/dll/jump/as -o RTPacking.io RTPacking.is
/usr/dll/jump/as -o RTPacking.mo RTPacking.ms
/usr/dll/jump/as -o RTParams.io RTParams.is
/usr/dll/jump/as -o RTParams.mo RTParams.ms
/usr/dll/jump/as -o RTPerfTool.io RTPerfTool.is
/usr/dll/jump/as -o RTPerfTool.mo RTPerfTool.ms
/usr/dll/jump/as -o RTProcedure.io RTProcedure.is
/usr/dll/jump/as -o RTProcedure.mo RTProcedure.ms
/usr/dll/jump/as -o RTProcedureSRC.io RTProcedureSRC.is
/usr/dll/jump/as -o RTProcess.io RTProcess.is
/usr/dll/jump/as -o RTProcess.mo RTProcess.ms
/usr/dll/jump/as -o RTSignal.io RTSignal.is
/usr/dll/jump/as -o RTSignal.mo RTSignal.ms
/usr/dll/jump/as -o RTThread.io RTThread.is
/usr/dll/jump/as -o RTThread.mo RTThread.ms
/usr/dll/jump/as -o RTThreadInit.io RTThreadInit.is
/usr/dll/jump/as -o RTThreadStk.mo RTThreadStk.ms
/usr/dll/jump/as -o RTTipe.io RTTipe.is
/usr/dll/jump/as -o RTTipe.mo RTTipe.ms
/usr/dll/jump/as -o RTType.io RTType.is
/usr/dll/jump/as -o RTType.mo RTType.ms
/usr/dll/jump/as -o RTTypeFP.io RTTypeFP.is
/usr/dll/jump/as -o RTTypeFP.mo RTTypeFP.ms
/usr/dll/jump/as -o RTTypeMap.io RTTypeMap.is
/usr/dll/jump/as -o RTTypeMap.mo RTTypeMap.ms
/usr/dll/jump/as -o RTTypeSRC.io RTTypeSRC.is
/usr/dll/jump/as -o RTWeakRef.io RTWeakRef.is
/usr/dll/jump/as -o RTutils.io RTutils.is
/usr/dll/jump/as -o RTutils.mo RTutils.ms
/usr/dll/jump/as -o Real.io Real.is
/usr/dll/jump/as -o Real.mo Real.ms
/usr/dll/jump/as -o RealFloat.io RealFloat.is
/usr/dll/jump/as -o RealFloat.mo RealFloat.ms
/usr/dll/jump/as -o RealRep.io RealRep.is
/usr/dll/jump/as -o Scheduler.io Scheduler.is
/usr/dll/jump/as -o SchedulerPosix.io SchedulerPosix.is
/usr/dll/jump/as -o Text.io Text.is
/usr/dll/jump/as -o Text.mo Text.ms
/usr/dll/jump/as -o TextConv.io TextConv.is
/usr/dll/jump/as -o TextConv.mo TextConv.ms
/usr/dll/jump/as -o TextF.io TextF.is
/usr/dll/jump/as -o Thread.io Thread.is
/usr/dll/jump/as -o ThreadEvent.io ThreadEvent.is
/usr/dll/jump/as -o ThreadF.io ThreadF.is
/usr/dll/jump/as -o ThreadPosix.mo ThreadPosix.ms
/usr/dll/jump/as -o Tick.io Tick.is
/usr/dll/jump/as -o TickPortable.mo TickPortable.ms
/usr/dll/jump/as -o Time.io Time.is
/usr/dll/jump/as -o TimePosix.io TimePosix.is
/usr/dll/jump/as -o TimePosix.mo TimePosix.ms
/usr/dll/jump/as -o Udir.io Udir.is
/usr/dll/jump/as -o Uerror.io Uerror.is
/usr/dll/jump/as -o Uerror.mo Uerror.ms
/usr/dll/jump/as -o Uexec.io Uexec.is
/usr/dll/jump/as -o Ugrp.io Ugrp.is
/usr/dll/jump/as -o Uin.io Uin.is
/usr/dll/jump/as -o Uin.mo Uin.ms
/usr/dll/jump/as -o Uipc.io Uipc.is
/usr/dll/jump/as -o Umman.io Umman.is
/usr/dll/jump/as -o Umsg.io Umsg.is
/usr/dll/jump/as -o Umsg.mo Umsg.ms
/usr/dll/jump/as -o Unetdb.io Unetdb.is
/usr/dll/jump/as -o Unetdb.mo Unetdb.ms
/usr/dll/jump/as -o Unix.io Unix.is
/usr/dll/jump/as -o UnsafeHash.mo UnsafeHash.ms
/usr/dll/jump/as -o Uprocess.io Uprocess.is
/usr/dll/jump/as -o Upwd.io Upwd.is
/usr/dll/jump/as -o Uresource.io Uresource.is
/usr/dll/jump/as -o Usem.io Usem.is
/usr/dll/jump/as -o Ushm.io Ushm.is
/usr/dll/jump/as -o Usignal.io Usignal.is
/usr/dll/jump/as -o Usignal.mo Usignal.ms
/usr/dll/jump/as -o Usocket.io Usocket.is
/usr/dll/jump/as -o Ustat.io Ustat.is
/usr/dll/jump/as -o Usyslog.io Usyslog.is
/usr/dll/jump/as -o Utime.io Utime.is
/usr/dll/jump/as -o Utypes.io Utypes.is
/usr/dll/jump/as -o Utypes.mo Utypes.ms
/usr/dll/jump/as -o Uugid.io Uugid.is
/usr/dll/jump/as -o Uuio.io Uuio.is
/usr/dll/jump/as -o Uutmp.io Uutmp.is
/usr/dll/jump/as -o WeakRef.io WeakRef.is
/usr/dll/jump/as -o WeakRef.mo WeakRef.ms
/usr/dll/jump/as -o Word.io Word.is
/usr/dll/jump/as -o Word.mo Word.ms
/usr/dll/jump/as -o cca01290.o cca01290.s
/usr/dll/jump/as -o cca01296.o cca01296.s
/usr/dll/jump/as -o cca01546.o cca01546.s
/usr/dll/jump/as -o cca01701.o cca01701.s
getvars v2.16
Reading jump.log file from /opt/m3/m3/m3core/LINUX/jump
getfuncs v2.16
Reading jump.log file from /opt/m3/m3/m3core/LINUX/jump
/usr/dll/jump/as -o BasicCtypes.io BasicCtypes.is
/usr/dll/jump/as -o CConvert.io CConvert.is
/usr/dll/jump/as -o CConvert.mo CConvert.ms
/usr/dll/jump/as -o Cerrno.io Cerrno.is
/usr/dll/jump/as -o Convert.io Convert.is
/usr/dll/jump/as -o Convert.mo Convert.ms
/usr/dll/jump/as -o Csetjmp.io Csetjmp.is
/usr/dll/jump/as -o Csignal.io Csignal.is
/usr/dll/jump/as -o Cstdarg.io Cstdarg.is
/usr/dll/jump/as -o Cstdarg.mo Cstdarg.ms
/usr/dll/jump/as -o Cstddef.io Cstddef.is
/usr/dll/jump/as -o Cstdio.io Cstdio.is
/usr/dll/jump/as -o Cstdio.mo Cstdio.ms
/usr/dll/jump/as -o Cstdlib.io Cstdlib.is
/usr/dll/jump/as -o Cstring.io Cstring.is
/usr/dll/jump/as -o Ctypes.io Ctypes.is
/usr/dll/jump/as -o Date.io Date.is
/usr/dll/jump/as -o DateLinux.mo DateLinux.ms
/usr/dll/jump/as -o DragonInt.io DragonInt.is
/usr/dll/jump/as -o DragonInt.mo DragonInt.ms
/usr/dll/jump/as -o DragonT.io DragonT.is
/usr/dll/jump/as -o DragonT.mo DragonT.ms
/usr/dll/jump/as -o Extended.io Extended.is
/usr/dll/jump/as -o Extended.mo Extended.ms
/usr/dll/jump/as -o ExtendedFloat.io ExtendedFloat.is
/usr/dll/jump/as -o ExtendedFloat.mo ExtendedFloat.ms
/usr/dll/jump/as -o FPU.io FPU.is
/usr/dll/jump/as -o FPU.mo FPU.ms
/usr/dll/jump/as -o Fingerprint.io Fingerprint.is
/usr/dll/jump/as -o Fingerprint.mo Fingerprint.ms
/usr/dll/jump/as -o FloatMode.io FloatMode.is
/usr/dll/jump/as -o FloatMode.mo FloatMode.ms
/usr/dll/jump/as -o FmtTime.io FmtTime.is
/usr/dll/jump/as -o FmtTime.mo FmtTime.ms
/usr/dll/jump/as -o IEEESpecial.io IEEESpecial.is
/usr/dll/jump/as -o IEEESpecial.mo IEEESpecial.ms
/usr/dll/jump/as -o LongFloat.io LongFloat.is
/usr/dll/jump/as -o LongFloat.mo LongFloat.ms
/usr/dll/jump/as -o LongReal.io LongReal.is
/usr/dll/jump/as -o LongReal.mo LongReal.ms
/usr/dll/jump/as -o LongRealRep.io LongRealRep.is
/usr/dll/jump/as -o M3toC.io M3toC.is
/usr/dll/jump/as -o M3toC.mo M3toC.ms
/usr/dll/jump/as -o Main.io Main.is
/usr/dll/jump/as -o Poly.io Poly.is
/usr/dll/jump/as -o Poly.mo Poly.ms
/usr/dll/jump/as -o PolyBasis.io PolyBasis.is
/usr/dll/jump/as -o PolyBasis.mo PolyBasis.ms
/usr/dll/jump/as -o RT0.io RT0.is
/usr/dll/jump/as -o RT0.mo RT0.ms
/usr/dll/jump/as -o RT0u.io RT0u.is
/usr/dll/jump/as -o RT0u.mo RT0u.ms
/usr/dll/jump/as -o RTAllocator.io RTAllocator.is
/usr/dll/jump/as -o RTAllocator.mo RTAllocator.ms
/usr/dll/jump/as -o RTArgs.io RTArgs.is
/usr/dll/jump/as -o RTArgs.mo RTArgs.ms
/usr/dll/jump/as -o RTCollector.io RTCollector.is
/usr/dll/jump/as -o RTCollector.mo RTCollector.ms
/usr/dll/jump/as -o RTCollectorSRC.io RTCollectorSRC.is
/usr/dll/jump/as -o RTExRep.io RTExRep.is
/usr/dll/jump/as -o RTException.io RTException.is
/usr/dll/jump/as -o RTException.mo RTException.ms
/usr/dll/jump/as -o RTHeap.io RTHeap.is
/usr/dll/jump/as -o RTHeap.mo RTHeap.ms
/usr/dll/jump/as -o RTHeapDebug.io RTHeapDebug.is
/usr/dll/jump/as -o RTHeapDebug.mo RTHeapDebug.ms
/usr/dll/jump/as -o RTHeapDep.io RTHeapDep.is
/usr/dll/jump/as -o RTHeapDep.mo RTHeapDep.ms
/usr/dll/jump/as -o RTHeapEvent.io RTHeapEvent.is
/usr/dll/jump/as -o RTHeapInfo.io RTHeapInfo.is
/usr/dll/jump/as -o RTHeapInfo.mo RTHeapInfo.ms
/usr/dll/jump/as -o RTHeapMap.io RTHeapMap.is
/usr/dll/jump/as -o RTHeapMap.mo RTHeapMap.ms
/usr/dll/jump/as -o RTHeapRep.io RTHeapRep.is
/usr/dll/jump/as -o RTHeapRep.mo RTHeapRep.ms
/usr/dll/jump/as -o RTHeapStats.io RTHeapStats.is
/usr/dll/jump/as -o RTHeapStats.mo RTHeapStats.ms
/usr/dll/jump/as -o RTHooks.io RTHooks.is
/usr/dll/jump/as -o RTHooks.mo RTHooks.ms
/usr/dll/jump/as -o RTIO.io RTIO.is
/usr/dll/jump/as -o RTIO.mo RTIO.ms
/usr/dll/jump/as -o RTLinker.io RTLinker.is
/usr/dll/jump/as -o RTLinker.mo RTLinker.ms
/usr/dll/jump/as -o RTMachine.io RTMachine.is
/usr/dll/jump/as -o RTMapOp.io RTMapOp.is
/usr/dll/jump/as -o RTMapOp.mo RTMapOp.ms
/usr/dll/jump/as -o RTMisc.io RTMisc.is
/usr/dll/jump/as -o RTMisc.mo RTMisc.ms
/usr/dll/jump/as -o RTModule.io RTModule.is
/usr/dll/jump/as -o RTModule.mo RTModule.ms
/usr/dll/jump/as -o RTOS.io RTOS.is
/usr/dll/jump/as -o RTOS.mo RTOS.ms
/usr/dll/jump/as -o RTPacking.io RTPacking.is
/usr/dll/jump/as -o RTPacking.mo RTPacking.ms
/usr/dll/jump/as -o RTParams.io RTParams.is
/usr/dll/jump/as -o RTParams.mo RTParams.ms
/usr/dll/jump/as -o RTPerfTool.io RTPerfTool.is
/usr/dll/jump/as -o RTPerfTool.mo RTPerfTool.ms
/usr/dll/jump/as -o RTProcedure.io RTProcedure.is
/usr/dll/jump/as -o RTProcedure.mo RTProcedure.ms
/usr/dll/jump/as -o RTProcedureSRC.io RTProcedureSRC.is
/usr/dll/jump/as -o RTProcess.io RTProcess.is
/usr/dll/jump/as -o RTProcess.mo RTProcess.ms
/usr/dll/jump/as -o RTSignal.io RTSignal.is
/usr/dll/jump/as -o RTSignal.mo RTSignal.ms
/usr/dll/jump/as -o RTThread.io RTThread.is
/usr/dll/jump/as -o RTThread.mo RTThread.ms
/usr/dll/jump/as -o RTThreadInit.io RTThreadInit.is
/usr/dll/jump/as -o RTThreadStk.mo RTThreadStk.ms
/usr/dll/jump/as -o RTTipe.io RTTipe.is
/usr/dll/jump/as -o RTTipe.mo RTTipe.ms
/usr/dll/jump/as -o RTType.io RTType.is
/usr/dll/jump/as -o RTType.mo RTType.ms
/usr/dll/jump/as -o RTTypeFP.io RTTypeFP.is
/usr/dll/jump/as -o RTTypeFP.mo RTTypeFP.ms
/usr/dll/jump/as -o RTTypeMap.io RTTypeMap.is
/usr/dll/jump/as -o RTTypeMap.mo RTTypeMap.ms
/usr/dll/jump/as -o RTTypeSRC.io RTTypeSRC.is
/usr/dll/jump/as -o RTWeakRef.io RTWeakRef.is
/usr/dll/jump/as -o RTutils.io RTutils.is
/usr/dll/jump/as -o RTutils.mo RTutils.ms
/usr/dll/jump/as -o Real.io Real.is
/usr/dll/jump/as -o Real.mo Real.ms
/usr/dll/jump/as -o RealFloat.io RealFloat.is
/usr/dll/jump/as -o RealFloat.mo RealFloat.ms
/usr/dll/jump/as -o RealRep.io RealRep.is
/usr/dll/jump/as -o Scheduler.io Scheduler.is
/usr/dll/jump/as -o SchedulerPosix.io SchedulerPosix.is
/usr/dll/jump/as -o Text.io Text.is
/usr/dll/jump/as -o Text.mo Text.ms
/usr/dll/jump/as -o TextConv.io TextConv.is
/usr/dll/jump/as -o TextConv.mo TextConv.ms
/usr/dll/jump/as -o TextF.io TextF.is
/usr/dll/jump/as -o Thread.io Thread.is
/usr/dll/jump/as -o ThreadEvent.io ThreadEvent.is
/usr/dll/jump/as -o ThreadF.io ThreadF.is
/usr/dll/jump/as -o ThreadPosix.mo ThreadPosix.ms
/usr/dll/jump/as -o Tick.io Tick.is
/usr/dll/jump/as -o TickPortable.mo TickPortable.ms
/usr/dll/jump/as -o Time.io Time.is
/usr/dll/jump/as -o TimePosix.io TimePosix.is
/usr/dll/jump/as -o TimePosix.mo TimePosix.ms
/usr/dll/jump/as -o Udir.io Udir.is
/usr/dll/jump/as -o Uerror.io Uerror.is
/usr/dll/jump/as -o Uerror.mo Uerror.ms
/usr/dll/jump/as -o Uexec.io Uexec.is
/usr/dll/jump/as -o Ugrp.io Ugrp.is
/usr/dll/jump/as -o Uin.io Uin.is
/usr/dll/jump/as -o Uin.mo Uin.ms
/usr/dll/jump/as -o Uipc.io Uipc.is
/usr/dll/jump/as -o Umman.io Umman.is
/usr/dll/jump/as -o Umsg.io Umsg.is
/usr/dll/jump/as -o Umsg.mo Umsg.ms
/usr/dll/jump/as -o Unetdb.io Unetdb.is
/usr/dll/jump/as -o Unetdb.mo Unetdb.ms
/usr/dll/jump/as -o Unix.io Unix.is
/usr/dll/jump/as -o UnsafeHash.mo UnsafeHash.ms
/usr/dll/jump/as -o Uprocess.io Uprocess.is
/usr/dll/jump/as -o Upwd.io Upwd.is
/usr/dll/jump/as -o Uresource.io Uresource.is
/usr/dll/jump/as -o Usem.io Usem.is
/usr/dll/jump/as -o Ushm.io Ushm.is
/usr/dll/jump/as -o Usignal.io Usignal.is
/usr/dll/jump/as -o Usignal.mo Usignal.ms
/usr/dll/jump/as -o Usocket.io Usocket.is
/usr/dll/jump/as -o Ustat.io Ustat.is
/usr/dll/jump/as -o Usyslog.io Usyslog.is
/usr/dll/jump/as -o Utime.io Utime.is
/usr/dll/jump/as -o Utypes.io Utypes.is
/usr/dll/jump/as -o Utypes.mo Utypes.ms
/usr/dll/jump/as -o Uugid.io Uugid.is
/usr/dll/jump/as -o Uuio.io Uuio.is
/usr/dll/jump/as -o Uutmp.io Uutmp.is
/usr/dll/jump/as -o WeakRef.io WeakRef.is
/usr/dll/jump/as -o WeakRef.mo WeakRef.ms
/usr/dll/jump/as -o Word.io Word.is
/usr/dll/jump/as -o Word.mo Word.ms
/usr/dll/jump/as -o cca01290.o cca01290.s
/usr/dll/jump/as -o cca01296.o cca01296.s
/usr/dll/jump/as -o cca01546.o cca01546.s
/usr/dll/jump/as -o cca01701.o cca01701.s
getsize v2.16
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_BasicCtypes.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_CConvert.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_CConvert.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cerrno.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Convert.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Convert.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Csetjmp.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Csignal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdarg.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Cstdarg.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstddef.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdio.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Cstdio.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdlib.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstring.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ctypes.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Date.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DateLinux.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonInt.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DragonInt.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonT.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DragonT.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Extended.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Extended.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ExtendedFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_ExtendedFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FPU.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FPU.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Fingerprint.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Fingerprint.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FloatMode.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FloatMode.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FmtTime.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FmtTime.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_IEEESpecial.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_IEEESpecial.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_LongFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongReal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_LongReal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongRealRep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_M3toC.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_M3toC.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Main.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Poly.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Poly.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_PolyBasis.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_PolyBasis.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RT0.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RT0.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RT0u.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RT0u.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTAllocator.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTAllocator.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTArgs.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTArgs.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTCollector.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTCollector.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTCollectorSRC.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTExRep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTException.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTException.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapDebug.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapDebug.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapDep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapDep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapEvent.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapInfo.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapInfo.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapMap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapMap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapRep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapRep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapStats.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapStats.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHooks.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHooks.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTIO.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTIO.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTLinker.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTLinker.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMachine.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMapOp.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTMapOp.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMisc.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTMisc.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTModule.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTModule.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTOS.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTOS.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTPacking.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTPacking.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTParams.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTParams.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTPerfTool.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTPerfTool.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcedure.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTProcedure.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcedureSRC.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcess.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTProcess.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTSignal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTSignal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTThread.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTThread.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTThreadInit.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTThreadStk.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTipe.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTipe.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTType.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTType.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeFP.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTypeFP.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeMap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTypeMap.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeSRC.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTWeakRef.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTutils.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTutils.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Real.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Real.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RealFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RealFloat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RealRep.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Scheduler.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_SchedulerPosix.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Text.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Text.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TextConv.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TextConv.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TextF.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Thread.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ThreadEvent.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ThreadF.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_ThreadPosix.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Tick.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TickPortable.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Time.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TimePosix.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TimePosix.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Udir.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uerror.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Uerror.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uexec.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ugrp.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uin.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Uin.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uipc.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Umman.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Umsg.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Umsg.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Unetdb.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Unetdb.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Unix.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_UnsafeHash.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uprocess.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Upwd.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uresource.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usem.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ushm.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usignal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Usignal.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usocket.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ustat.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usyslog.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Utime.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Utypes.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Utypes.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uugid.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uuio.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uutmp.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_WeakRef.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_WeakRef.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Word.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Word.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__tables_built.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__LoBits.s
/opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__LoBits.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__HiBits.s
/opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__HiBits.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_M3_BUILTIN.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__ThreadF__myId.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__RT0u__inCritical.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__RTThread__handlerStack.s
/usr/dll/bin/mkimage -f -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -
- jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc
mkimage v2.16
Warning - non-absolute pathname specified for library
Reading configuration files from /opt/m3/m3/m3core/LINUX/jump
Recording new library parameters.
executing:ld -x -Ttext 64400000 -o libm3core.so.3.5 /opt/m3/m3/m3core/LINUX/jum
p/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__cutoffAdju
st.0 referenced from text segment
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__fixup.1 re
ferenced from text segment
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__fixup.1 re
ferenced from text segment
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__cutoffAdju
st.0 referenced from text segment
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _M_RTCollector_LINE_176
9.0 referenced from text segment
/opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _M_ThreadPosix_LINE_331
.0 referenced from text segment
system: No such file or directory

/usr/dll/bin/mkimage: error running 'ld -x -Ttext 64400000 -o libm3core.so.3.5 
/opt/m3/m3/m3core/LINUX/jump/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i48
6-linux/2.5.8 -lgcc -lc'

/usr/dll/bin/mkstubs -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -- l
ibm3core
mkstubs v2.16
Warning - non-absolute pathname specified for library
Reading configuration files from /opt/m3/m3/m3core/LINUX/jump
libm3core.sa: ___libm3core_3_500, cca01290, cca01296, cca01701, BasicCtypes, CC
onvert, Cerrno, Convert, Csetjmp, Csignal, Cstdarg, Cstddef, Cstdio, Cstdlib, C
string, Ctypes, Date, DateLinux, DragonInt, DragonT, Extended, ExtendedFloat, F
PU, Fingerprint,
 FloatMode, FmtTime, IEEESpecial, LongFloat, LongReal, LongRealRep, M3toC, Main
, Poly, PolyBasis, RT0, RT0u, RTAllocator, RTArgs, RTCollector, RTCollectorSRC,
 RTExRep, RTException, RTHeap, RTHeapDebug, RTHeapDep, RTHeapEvent, RTHeapInfo,
 RTHeapMap, RTHe
apRep, RTHeapStats, RTHooks, RTIO, RTLinker, RTMachine, RTMapOp, RTMisc, RTModu
le, RTOS, RTPacking, RTParams, RTPerfTool, RTProcedure, RTProcedureSRC, RTProce
ss, RTSignal, RTThread, RTThreadInit, RTThreadStk, RTTipe, RTType, RTTypeFP, RT
TypeMap, RTTypeS
RC, RTWeakRef, RTutils, Real, RealFloat, RealRep, Scheduler, SchedulerPosix, Te
xt, TextConv, TextF, Thread, ThreadEvent, ThreadF, ThreadPosix, Tick, TickPorta
ble, Time, TimePosix, Udir, Uerror, Uexec, Ugrp, Uin, Uipc, Umman, Umsg, Unetdb
, Unix, UnsafeHa
sh, Uprocess, Upwd, Uresource, Usem, Ushm, Usignal, Usocket, Ustat, Usyslog, Ut
ime, Utypes, Uugid, Uuio, Uutmp, WeakRef, Word, cca01546, _LoBits, _HiBits, seq
uencing, done
verify v2.16 (experimental)

jumpkit: Unable to open libm3core.so.3.5

*** error code 1
"/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: command execute fail
ed
*** call stack ***
"/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: call to built-in exe
c
"/opt/m3/m3/m3core/src/m3makefile", line 960: call to procedure after_library_h
ooks
"/opt/SRCm3/lib/m3/pkg/m3build/templates/COMMON", line 1: call to procedure lib
rary
"/opt/m3/m3/m3core/src/m3makefile", line 42: call to procedure Library
m3build: /opt/SRCm3/bin/quake failed (status = 256)
*** error code 255
"/opt/m3/m3/src/m3makefile", line 41: command execute failed
*** call stack ***
"/opt/m3/m3/src/m3makefile", line 41: call to built-in exec
"/opt/m3/m3/src/m3makefile", line 63: call to procedure BuildChunk
m3build: /opt/SRCm3/bin/quake failed (status = 256)
exit


Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 36 ===
Date:    Wed, 8 Mar 1995 16:35:16 +0000
From:    mhoward@darklord.demon.co.uk ("c:internetka9qspoolmail")
Subject: Platforms

Does anyone have any idea about the variety of platforms / operating 
system a standard implementation of modula-3 is available for?

TIA
Mark





======================================================================= 37 ===
Date:    8 Mar 1995 12:42:36 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Problems building 3.5.1/boot-LINUX

In article <5hRGNa1EcsB@khms.westfalen.de>,
Kai Henningsen <kai@khms.westfalen.de> wrote:
>Building the library, to be exact.
>
>After hunting after an obscure bug in the dll tools-2.1.6 (a buffer
>[wrapup, in mkimage.c] was too small, overwriting critical variables) and
>telling the linker where to find lgcc, I'm now getting unresolved
>references.
>
>What's going on here?!  I thought 3.5.1 was supposed to be bug-fixed ...
>but from the errors I already fixed, I'm beginning to doubt that.

 It is bugfixed (well, modulo Linux changing underneath everyone). There
are just a lot of bugs in the DLL tools :-) (well, not actually bugs -
fixed-size buffers which tend to overflow). You can get patches that
worked for me from
http://www.cl.cam.ac.uk/m3doc/linux/archive/3.5.1/index.html

[trace deleted]

Richard.
-- 
`There comes a time when you look into the mirror and you realise that what you
 
see is all that you will ever be. And then you accept it. Or you kill 
yourself. Or you stop looking in mirrors.'
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 38 ===
Date:    Tue, 7 Mar 1995 17:40:19 GMT
From:    rodney@bcsaic.boeing.com (Rodney M. Bates)
Subject: Re: Language Definition

I hate to even bring it up, but while language changes are being
proposed, here is one I wish for.

I want to be able to write:

  TYPE Colors 
    = { Plum , Red , Orange , Yellow , Green , Turquiose , Blue , Purple } ;

  TYPE ColorSet = SET OF Colors ;
  CONST Primaries = ColorSet { Red , Green , Blue } ;
  CONST InfraReds = ColorSet { Plum } ;  
  CONST InfraGreens = ColorSet { Orange , Yellow } ;  
  CONST InfraBlues = ColorSet { Turquiose } ;  
  CONST UltraBlues = ColorSet { Purple } ;  

And elsewhere:

  IF C IN InfraReds THEN ...

And elsewhere (this is where the language change is needed):

  CASE C OF
  | Primaries => ...
  | InfraReds => ...
  | InfraGreens => ...
  | InfraBlues => ...
  | UltraBlues => ...
  END

I want to do this so that later, I can, for example, add Periwinkle to 
Colors and to UltraBlues without having to locate all the CASE statements 
in the world which might be affected.  I can do this now with IF statments, 
but not with CASE statements. I don't believe the CASE statement is just 
syntactic sugar for:

  IF C IN Primaries THEN ...
  ELSIF C IN InfraReds THEN ...
  ELSIF C IN InfraGreens THEN ...
  ELSIF C IN InfraBlues THEN ...
  ELSIF C IN UltraBlues THEN ...
  END

If it is, then _all_ CASE statements are just syntactic sugar.

The change would be to allow a case label to be a constant expression
of type SET OF T and whose elements are members of T, where T is the
type of the expression Expr in CASE Expr ... .

Rodney Bates


======================================================================= 39 ===
Date:    Wed, 8 Mar 1995 16:16:09 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: re: postability of M3 and suitability for C/S apps

mhoward@darklord.demon.co.uk writes:
 > Some of you out there may have already been down this avenue...
 > 
 > I am investigating possible tools/languages for developing large, 
 > distributed C/S applications.
 > 
 > How portable is Modula-3? What platforms / operating systems is it 
 > available on?
 > 
 > TIA
 > 
 > /---------------------------------------------------------------------------
---\
 > | Mark Howard                                     mhoward@darklord.demon.co.
uk |
 > | Cheif Systems Architect                                                   
   |
 > \---------------------------------------------------------------------------
---/
 > 

I'd definitely encourage you to use Modula-3 for large distributed, client/serv
er
systems. I think you'd be hard pressed to find a better programming system. I'v
e
developed distributed applications in C/C++ and Modula-3, much prefer the latte
r.
I waged a long and finally successfull compaign to get Modula-3 adopted as the
programming language for our group. No one here regrets it, and very enthusiast
ic
users of it now. We've develop a number of distributed applications in our grou
p
with Modula-3 (a naming service, a transaction monitor, an event management sys
tem,
etc.)

On to your specific questions. I believe that the 3.5.1 release runs on the fol
lowing
platforms: SunOS 4.1, Solaris 2.X, Ultrix, OSF/1, HPUX, AIX, SGI, and Windows-N
T. When
Windows-95 becomes available, it will run on that platform as well.

Modula-3 applications tend to be very portable for a number of reasons. First, 
the 
standard libraries provide an excellent set of interfaces that abstract common 
OS
functionality. Secondly, it is much harder to write machine dependent code in M
odula-3.
Not impossible, but you must explicitly document it by putting it in an "unsafe
" 
module. So in general, Modula-3 applications can be written at a higher level o
f
abstraction than your typical C/C++ application.

Hope this helps ! Feel free to contact me if you have any more questions !


--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 40 ===
Date:    09 Mar 1995 02:16:31 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: OpenGL (was Re: WinNT questions)

>>>>> On 6 Mar 1995 11:40:59 GMT, Quentin Stafford-Fraser
>>>>> <fraser@europarc.xerox.com> said:

Quentin> bm@shadow.cs.columbia.edu (Blair MacIntyre) wrote:
>> So, if anyone has any hints as to when netobjs will be supported,
>> you'll then know when we'll be making OpenGL i3's for NT. :-)

Quentin> ..which I presume is equivalent to asking whether anybody is
Quentin> working on porting the TCP/IP stuff to Winsock?

Yep, I think that they are equivalent.

As for my OpenGL .i3's, they are online on our home page.
(http://www.cs.columbia.edu/graphics/modula3/m3browser.html)

Any code I want to make available will appear under that page, which
is automatically generated by the m3browser program included in the M3
distribution (cool program!)

They are only slightly tested, so let me know if you find any
problems.

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

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


======================================================================= 41 ===
Date:    6 Mar 1995 11:40:59 GMT
From:    Quentin Stafford-Fraser <fraser@europarc.xerox.com>
Subject: Re: WinNT questions

bm@shadow.cs.columbia.edu (Blair MacIntyre) wrote:

>  So, if anyone has any hints as to when netobjs will be supported,
>  you'll then know when we'll be making OpenGL i3's for NT. :-)

..which I presume is equivalent to asking whether anybody is working
on porting the TCP/IP stuff to Winsock?

(That was two questions :-) )

Quentin


======================================================================= 42 ===
Date:    9 Mar 1995 06:52:44 GMT
From:    taj@vanbc.wimsey.com (Taj Khattra)
Subject: try-finally-except


Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead
of a single TRY-FINALLY-EXCEPT statement ?

Is the following case the main reason why ?

    TRY
        RAISE e;
    FINALLY
	IF (foobar) RAISE e;
    EXCEPT
	e => (* this may or may not be executed *)
    END

I am trying to write a Modula-3 like exception handling mechanism
for ANSI C (based on Eric Robert's package) and am trying to justify
to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead
of just TRY-FINALLY-EXCEPT.

Thanks.

--taj


======================================================================= 43 ===
Date:    Thu, 9 Mar 1995 13:06:01 GMT
From:    faegri@dcs.glasgow.ac.uk (Tor Erlend Faegri)
Subject: netobjd problems (SRC M3 3.3)

I'm experiencing some problems using the netobj-daemon, netobjd(1). As
far as I managed to find out, there is no option to the netobjd(1) to
make it say what's going on, and what it's object-tables contains.

Because of this, (and of course the fact that my program doesn't work),
I'm asking this group for hints as to how I should proceed.

My program is currently very simple, I'll outline it below:

The type NSR.T is a subtype of NetObj.T, and is specified like this in a
file NSR.i3:

TYPE
  T = NetObj.T OBJECT METHODS
    init(n : TEXT) RAISES {NetObj.Error, Thread.Alerted};
    alive() : TEXT RAISES {NetObj.Error, Thread.Alerted};
  END;


The implementation of the type, in file NSR.m3 looks like this:
TYPE
  NSR_T = T OBJECT
    name : TEXT;
  OVERRIDES
    init := Init;
    alive := Alive;
  END;
	
PROCEDURE Init(self : NSR_T; n : TEXT)
  RAISES {NetObj.Error, Thread.Alerted} =
  (*
    Documentation:
      Sets the name of the replica.
   *)
  BEGIN
    self.name := n;
  END Init;

...
...


In my main module, I use NSR.T objects in the following way:

  VAR
    aReplica : NSR.T := NIL;
  ...
  (* Register an instance of a replica in node's netobjd object tables *)
  NetObj.Export("replica", NEW(NSR.T), NetObj.Locate(node));
  (* node is a name of a machine running netobjd(1) *)
  ...
  ...
  (* Retrieve a reference to the replica from node's netobjd object tables *)
  aReplica := NetObj.Import("replica", NetObj.Locate(node));
  ...
  (* Try to invoce a method on the replica *)
  IF aReplica # NIL THEN aReplica.init("replica_xx"); END;


During the execution of the last statement, the method invocation, I get the
following runtime error:

    "attempted invocation of undefined method"

Because I got no complaints during compilation, I'm suspecting either that
the surrugate hasn't been correctly set up on the local machine, or that
the netobjd doesn't send me the right object, even though it obviously
sends me something. (It might be the case I'm not using it correctly either
of course ...).
Could someone provide me with some hints?

BTW: my configuration: Sun SPARC running SunOS 4.1.3,  DEC SRC M3 rel. 3.3.
     All the tests in ../netobj/netobj/tests runs fine.

---
 -*******************************************************************-
 -*  Tor E. Faegri, M.Sc. student, University of Glasgow, Scotland  *-
 -*  URL:    http://www.dcs.gla.ac.uk/~faegri                       *-
 -*  E-mail: faegri@dcs.gla.ac.uk                                   *-
 -*******************************************************************-



======================================================================= 44 ===
Date:    9 Mar 1995 15:39:11 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: netobjd problems (SRC M3 3.3)

In article <D56CE1.81L@dcs.gla.ac.uk>, faegri@dcs.glasgow.ac.uk (Tor Erlend Fae
gri) writes:
> 
> During the execution of the last statement, the method invocation, I get the
> following runtime error:
> 
>     "attempted invocation of undefined method"

Because you exported an NSR.T which has no procedures bound to its methods?
You'll probably be happier if you call NetObj.Export with NEW(NSR_T).

  - Bill Kalsow


======================================================================= 45 ===
Date:    10 Mar 1995 00:04:22 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Netobjects: ASSERT failure in ThreadPosix

>>>>> On 4 Mar 1995 13:20:05 GMT, pbm1001@cam.ac.uk (Paul Menage)
>>>>> said:

Paul> Maybe the Pickle generic module should automatically register a pickelr
Paul> for it's list type that will pickle it iteratively. This would save
Paul> people having to write their own versions. 

Here is the file ListPkl.i3, in the netobj/src/netobjrt directory:

(* Copyright 1992 Digital Equipment Corporation.               *)
(* Distributed only by permission.                             *)
(* ListPkl.i3 *)
(* Last modified on Tue Sep  1 15:42:30 PDT 1992 by evers  *)

(* If a program contains an import of this interface, a "Pickle.Special"
   with "sp.sc = TYPECODE (List.T)" will be passed to
   "Pickle.RegisterSpecial" during initialization.  This special pickles
   references "r" with "TYPECODE (r) = TYPECODE (List.T)" iteratively rather
   than recursively, and is thus useful for long lists in small stacks. *)

INTERFACE ListPkl;

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

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


======================================================================= 46 ===
Date:    9 Mar 95 09:40:23
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Problems building 3.5.1/boot-LINUX


   After hunting after an obscure bug in the dll tools-2.1.6 (a buffer  
   [wrapup, in mkimage.c] was too small, overwriting critical variables) and  
   telling the linker where to find lgcc, I'm now getting unresolved  
   references.

   What's going on here?!  I thought 3.5.1 was supposed to be bug-fixed ...  
   but from the errors I already fixed, I'm beginning to doubt that.

There are more bugs than that in the dll tools. Look into
ftp.vlsi.polymtl.ca:pub/m3/linux for a "fixed" version of tools-2.11.
Although it is older than 2.16, it has worked quite well. Last time
I checked, newer versions of tools did not include all my bug fixes.

You have to realize that the dll tools have not progressed much since
a year or so because everyone knew they were a dead end soon to be
replaced by ELF tools. The ELF tools are now in Beta state and working
beautifully. A linux ELF release of SRC M3 is available from the same
ftp site in pub/m3/linuxelf.
--

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



======================================================================= 47 ===
Date:    Thu, 09 Mar 95 13:05:52 -0800
From:    heydon@pa.dec.com
Subject: Re: try-finally-except

Taj Khattra writes:

> I am trying to write a Modula-3 like exception handling mechanism
> for ANSI C (based on Eric Robert's package) and am trying to justify
> to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead
> of just TRY-FINALLY-EXCEPT.

I don't think the answer is that deep: most of the time, you need
either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design
philosophy was to provide simple language features, so both were
provided individually. If you want to get the effect of your
proposed:

  TRY
    S1
  FINALLY
    S2
  EXCEPT
    Handlers
  END

statement, you can simply write:

  TRY
    TRY
      S1
    FINALLY
      S2
    END
  EXCEPT
    Handlers
  END

But most of the time, I tend to use only one or the other, not both
together. TRY-FINALLY is provided if some "clean up" action must be
taken --- such as closing a file --- even in if an exception has
occurred. An important example of this is the LOCK statement (See
Section 2.3.19, "Systems Programming with Modula-3" (SPwM3), page 36).
The semantics of:

  LOCK mu DO S END

is defined using TRY-FINALLY so that the lock will always be unlocked,
even if an exception occurs during the execution of S:

  WITH m = mu DO (* needed in case evaluating "mu" has side-effects *)
    Thread.Acquire(m);
    TRY S FINALLY Thread.Release(m) END
  END

This is also why the semantics of the EXIT and RETURN statements are
defined in terms of exceptions: if EXIT or RETURN occurs within the
first part of TRY-FINALLY statement, the statements in the FINALLY
portion are guaranteed to be evaluated before the loop is exited or
the procedure returns, respectively.

> Is the following case the main reason why ?
>
>     TRY
>       RAISE e;
>     FINALLY
> 	IF (foobar) RAISE e;
>     EXCEPT
> 	e => (* this may or may not be executed *)
>     END

I think you don't quite understand the semantics of TRY-FINALLY. The
statement "TRY S1 FINALLY S2 END" re-raises any exception raised in
"S1" (unless "S2" raises a different exception). So in your example,
even if "foobar" is FALSE, the exception "e" will be raised by the
initial TRY-FINALLY portion. In particular, the statement:

  TRY RAISE e FINALLY S END

will *always* raise the exception "e", unless the statement "S" raises
some other exception "e'", in which case that exception is raised by
the statement as a whole. Hence, if I understand the intended
semantics of your proposed TRY-FINALLY-EXCEPT statement, the comment
in your example is incorrect: the exception handler for "e" is
guaranteed to be invoked. See Section 2.3.8 (pg 31) of SPwM3.

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 48 ===
Date:    Thu, 9 Mar 1995 20:38:30 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: looking for possibly existing generics


Maybe I'm daft, but after searching through all the libm3 directories,
I have been unable to find an acceptable generic implementation of a
list (couldn't even find one for a set).

What passes as a linked list List.ig is very useless because I am
unable to delete elements.  Then I discovered Sequence.ig; close, but
still not what I need.  I want to be able to add to/delete from the
middle of the sequence.

Is there a library that exists with the things I guess I've become
accustom to not having to implement myself?  ie. I want a Queue,
Stack, Set, Singly-Linked and Doubly-Linked List, and possibly a few
other things of that nature.

I mistakenly assumed that libm3 contained these "basic" generic
objects, and really don't want to go through the effort of creating
them myself when they must certainly exist in some other "standard"
library.

Having been forced to use C++ where one of the worst problems is the
lack of a good standard library -- although STL is a step in the right
direction --  I'd be very disappointed if Modula-3 didn't have what I
consider almost essentials.

>From what I've attempted to learn on my own, I'm quite pleased with
the Modula-3 semantics, but I'll be very displeased if generic Sets
are an exercise for the reader, much like an Array class is in C++.

-Spencer Allain
Engineering Research Associates


======================================================================= 49 ===
Date:    9 Mar 95 09:46:26
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Hardware & Operating Systems


   I am investigating possible tools/languages for developing large, 
   distributed C/S applications.

   How portable is Modula-3? What platforms / operating systems is it 
   available on?

Modula-3 is an excellent vehicle for distributed, graphical, applications
(check Network Objects). The FAQ (ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps)
will tell you more.

It runs on over a dozen Unix variants (including LINUX and FreeBSD)
and on Win32 (Windows NT and Windows 9X but some libraries are still
being ported).
--

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



======================================================================= 50 ===
Date:    10 Mar 1995 02:20:45 GMT
From:    taj@vanbc.wimsey.com (Taj Khattra)
Subject: Re: try-finally-except

heydon@pa.dec.com wrote:

: I don't think the answer is that deep: most of the time, you need
: either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design
: philosophy was to provide simple language features, so both were
: provided individually.

I agree that if most of the time either TRY-EXCEPT or TRY-FINALLY, but not
both, are used, then having both is better than a single TRY-FINALLY-EXCEPT
statement. 

But, I thought that code like

    TRY
        TRY S1 FINALLY S2 END
    EXCEPT
        E1 => H1
	...
	En => Hn
    END

would be quite common, which is why I assume that TRY-FINALLY-EXCEPT, where
both the FINALLY and EXCEPT sections were optional, might be a bit more
convenient *syntactically* only. Perhaps I'm mistaken in assuming this, not
having read or written all that much Modula-3 code myself.


: > Is the following case the main reason why ?
: >
: >     TRY
: >         RAISE e;
: >     FINALLY
: >         IF (foobar) RAISE e;
: >     EXCEPT
: >         e => (* this may or may not be executed *)
: >     END

: I think you don't quite understand the semantics of TRY-FINALLY.

Sorry for not making myself clear.

I should have included this in my original message -

    -------------------------------------------
    TRY
        S[T]
    FINALLY                  <- FINALLY is optional
        S[F]
    EXCEPT                   <- EXCEPT is optional
        E1 => S[E1]
    ...
        En => S[En]
    END

    execute stmt S[T] followed by stmt S[F]

    if (S[F] raises exception E[F]) (* propagate E[F] *)
        the result of the TRY stmt is exception E[F] (* ignore E1 ... En *) [1]
    elif (S[T] raises exception E[T])
        if (E[T] matches Ei in {E1, E2, ..., En}) (* handle E[T] *)
            the result of the TRY stmt is the result of stmt S[Ei]
        else (* propagate E[T] *)
            the result of the TRY stmt is exception E[T]
        endif
    endif
    -------------------------------------------

[1] implies that "TRY TRY S1 FINALLY S2 END EXCEPT e => S3 END" is NOT
equivalent to "TRY S1 FINALLY S2 EXCEPT e => S3 END", if "S2" raises an
exception - this is what my example was meant to convey. But [1] could easily
be modified (and it might be preferable to do so) so that both forms were
equivalent, so my example really wasn't worth anything.

So I guess all I've ended up worrying about is whether or not to provide some
"syntactic sugar", not knowing if it would be used often enough in practice to
be worth the trouble.

--taj


======================================================================= 51 ===
Date:    Fri, 10 Mar 1995 08:19:38 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: looking for possibly existing generics

Spencer Allain writes:
 > 
 > Maybe I'm daft, but after searching through all the libm3 directories,
 > I have been unable to find an acceptable generic implementation of a
 > list (couldn't even find one for a set).
 > 
 > What passes as a linked list List.ig is very useless because I am
 > unable to delete elements.  Then I discovered Sequence.ig; close, but
 > still not what I need.  I want to be able to add to/delete from the
 > middle of the sequence.
 > 
 > Is there a library that exists with the things I guess I've become
 > accustom to not having to implement myself?  ie. I want a Queue,
 > Stack, Set, Singly-Linked and Doubly-Linked List, and possibly a few
 > other things of that nature.
 > 
 > I mistakenly assumed that libm3 contained these "basic" generic
 > objects, and really don't want to go through the effort of creating
 > them myself when they must certainly exist in some other "standard"
 > library.
 > 
 > Having been forced to use C++ where one of the worst problems is the
 > lack of a good standard library -- although STL is a step in the right
 > direction --  I'd be very disappointed if Modula-3 didn't have what I
 > consider almost essentials.
 > 
 > >From what I've attempted to learn on my own, I'm quite pleased with
 > the Modula-3 semantics, but I'll be very displeased if generic Sets
 > are an exercise for the reader, much like an Array class is in C++.
 > 
 > -Spencer Allain
 > Engineering Research Associates

I believe that most, if not all, of the functionality that you descibed is
provided by the existing generics. How is a set different than a table ?
A queue is a sequence the only operations are: addhi, remlo. A stack is
a sequence where the only operations are: addlo, remlo. Deleting from the
middle of list can be done in several ways. It can be done functionally by
creating a new list that contains the elements from the two sides of the 
element being deleted; and this isn't necessarily inefficient - it merely a 
matter of an allocation and some pointer copying. It can also be done "destruct
ively"
(that is by overwriting existing pointers) the 'AppendD' operation on a list.

Hope this helps point you in the right direction !

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 52 ===
Date:    Fri, 10 Mar 95 10:28:17 -0800
From:    detlefs@pa.dec.com
Subject: Re: looking for possibly existing generics


I must respectfully disagree with Geoff Wyant, and agree with Spencer
Allain's implicit assertion, to wit: that the set of M3 standard
generics distributed with SRC's libm3 is not as comprehensive as one
might like.

To answer Geoff's question "How is a set different than a table?" I
will include my generic set package at the end of this message.  The
executive summary is that a good Set package supports operations such
as union, intersection, set equality, set difference, etc. that don't
appear in the Table interface.  Obviously, Table is an excellent
implementation strategy for Set -- as long as you have an obvious hash
function for your element type, and you expect your sets to be
sufficiently large so that the overhead of a table (vs., say a
linked-list implementation) is justified.  (In fact, I also provide a
linked list implementation, which I use heavily myself; I've also
implemented the Table.T interface with a association list
representation.)

Another item from Spencer's list that cannot be easily dismissed is
"Doubly-Linked List."  I don't find Geoff's argument that

  Deleting from the middle of list can be done in several ways. It can
  be done functionally by creating a new list that contains the
  elements from the two sides of the  element being deleted; and this
  isn't necessarily inefficient - it's merely a matter of an allocation
  and some pointer copying.

very convincing; occasionally one has to solve problems in which the
asymptotic complexity of algorithm really is a practical concern, and
the ability to insert into a list before *or* after a given element in
a list in constant time is something I've needed time and time again.
This one I haven't implemented generically, but maybe someone ought
to...

Dave

Below follow the 8 source files of the set package:

m3makefile
set.tmpl
Set.ig, Set.mg
SetDef.ig, SetDef.mg
SetList.ig, SetList.mg


The "set.tmpl" template file defines quake procedures for building set
instantiations.  You have to instantiate both Set(Foo) and
Set{Def,List}(Foo) to get a set implementation.  (Def is the table
implementation, List the linked-list version.  The examples in the
m3makefile should make it clear how to do so.

----------------  m3makefile ------------------------------------------------
/* Copyright (C) 1992, Digital Equipment Corporation                         */
/* All rights reserved.                                                      */
/* See the file COPYRIGHT for a full description.                            */

/* Last modified on Fri Mar 10 10:28:10 PST 1995 by detlefs                  */
/*      modified on Tue Feb 11 20:48:28 PST 1992 by muller                   */

import(libm3)

Generic_module (Set)
Generic_module (SetDef)
Generic_module (SetList)

template(set)

MkSet(Atom, Atom)
MkSetDef(Atom, Atom)
MkSetList(Atom, Atom)

MkSet(Int, Integer)
MkSetDef(Int, Integer)
MkSetList(Int, Integer)

MkSet(Text, Text)
MkSetDef(Text, Text)
MkSetList(Text, Text)

MkSet(Ref, Refany)
MkSetList(Ref, Refany)

Library(set)

----------------  set.tmpl ------------------------------------------------
% Copyright (C) 1993 Digital Equipment Corporation
% All rights reserved.
% See the file COPYRIGHT for a full description.
%
%      modified on Mon Sep 20 12:26:41 PDT 1993 by kalsow 

%
%  Quake functions to instantiate a generic table.
%

readonly proc MkSet (nm, elem) is
  local set = nm & "Set"
  build_generic_intf (set, "Set", [elem], VISIBLE)
  build_generic_impl (set, "Set", [elem])
end

readonly proc mkSet (nm, elem) is
  local set = nm & "Set"
  build_generic_intf (set, "Set", [elem], HIDDEN)
  build_generic_impl (set, "Set", [elem])
end

%
% Table-based implementation
%

readonly proc MkSetDef (nm, elem) is
  local set = nm & "Set"
  local setDef = nm & "SetDef"
  local elemRefTbl = nm & "RefTbl"
  build_generic_intf (setDef, "SetDef", [set], VISIBLE)
  build_generic_impl (setDef, "SetDef", [elem, set, elemRefTbl])
end

readonly proc mkSetDef (nm, elem) is
  local set = nm & "Set"
  local setDef = nm & "SetDef"
  local elemRefTbl = nm & "RefTbl"
  build_generic_intf (setDef, "SetDef", [set], HIDDEN)
  build_generic_impl (setDef, "SetDef", [elem, set, elemRefTbl])
end

%
% List-based implementation
%

readonly proc MkSetList (nm, elem) is
  local set = nm & "Set"
  local setList = nm & "SetList"
  local elemList = nm & "List"
  build_generic_intf (setList, "SetList", [set], VISIBLE)
  build_generic_impl (setList, "SetList", [elem, set, elemList])
end

readonly proc mkSetList (nm, elem) is
  local set = nm & "Set"
  local setList = nm & "SetList"
  local elemList = nm & "List"
  build_generic_intf (setList, "SetList", [set], HIDDEN)
  build_generic_impl (setList, "SetList", [elem, set, elemList])
end

----------------  Set.ig ---------------------------------------------------
(* Copyright (C) 1992, Digital Equipment Corporation                         *)
(* All rights reserved.                                                      *)
(* See the file COPYRIGHT for a full description.                            *)
(*      modified on Tue Feb 11 20:48:45 PST 1992 by muller                   *)

(* "Set" is a generic interface defining sets of "Elem.T"'s. *)

GENERIC INTERFACE Set(Elem);
(* Where "Elem.T" is a type that is not an open array type and "Elem" contains

| PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN;

   "Equal" must be an equivalence relation.

   "Equal" may be declared with a parameter mode of either "VALUE" or
   "READONLY", but not "VAR".
*)

TYPE 
  Public = OBJECT METHODS
    fromArray(READONLY a: ARRAY OF Elem.T): T;
    copy(): T;
    member(e: Elem.T): BOOLEAN;
    insert(e: Elem.T): BOOLEAN;
    delete(e: Elem.T): BOOLEAN;
    size(): CARDINAL;
    isEmpty(): BOOLEAN;
    subset(s2: T): BOOLEAN;
    equal(s2: T): BOOLEAN;
    union(s2: T): T;
    intersection(s2: T): T;
    diff(s2: T): T;
    unionD(s2: T): T;
    intersectionD(s2: T): T;
    diffD(s2: T): T;
    iterate(): Iterator;
  END;
  T <: Public;
  Iterator = OBJECT METHODS
    next(VAR e: Elem.T): BOOLEAN
  END;

(* A "Set(Elem)" is a set of "Elem.T"'s.  "Elem.T"'s that are equivalent
   under "Elem.Equal" are treated as equivalent by "Set";
   for example, if you are creating a set with an "Elem.T" of "TEXT",
   you are likely to want "Text.Equal" as the equivalence relation.
   The equivalence relation must be time-invariant.  For example,
   it can't depend on the values of particular references since some
   garbage collectors may move "REF" values.

   Formally, a set "s" has the component

| set(s) `a set of equivalence classes of "Elem.T"'s`.

   We will use "equiv(e)" to denote the equivelance class containing
   an "Elem.T" "e".

   For efficiency, a set is not monitored: it is up to the clients
   to avoid illegal concurrent accesses on the methods of a set.  A
   set's "insert" and "delete" methods have side-effects on the set,
   so can't be performed concurrently with any other method of that
   set or of an iterator on that set.  An iterator's "next" method
   has side-effects on the iterator, and is also considered to be a
   side-effect free operation on the parent set.

   The methods of an object "s" of type "Set.T" have the following
   specifications:

   The call "s.fromArray(a)" causes "set(s)" to contain exactly
   the equivalence classes containing all the elements of the array "a".

   The call "s.copy()" returns a set "s2" whose abstract state "set(s2)" 
   is the same as "set(s)".

   The call "s.member(e)" returns "TRUE" iff "e" is in an equivalence
   class in "set(s)".

   The call "s.insert(e)" returns "TRUE" and does not modify "s" if
   "equiv(e)" is in "set(s)"; otherwise it adds "equiv(e)" to "set(s)"
   and returns "FALSE".

   The call "s.delete(e)" ensures that "set(s)" does not contain
   "equiv(e)", returning "TRUE" iff "set(s)" contained "equiv(e)"
   before the call.

   The call "s.isEmpty()" returns "TRUE" iff "set(s)" is the empty set. 

   The call "s.size()" returns the cardinality of "set(s)".

   The call "s.subset(s2)" returns "TRUE" iff "set(s)" is a subset of
   "set(s2)".

   The call "s.equal(s2)" returns "TRUE" iff "set(s)" and "set(s2)" are the
   same set.

   The call "s.union(s2)" returns a new set "s3" such that "set(s3)" is
   the union of "set(s)" and "set(s2)".

   The call "s.intersection(s2)" returns a new set "s3" such that
   "set(s3)" is the intersection of "set(s)" and "set(s2)".

   The call "s.diff(s2)" returns a set "s3" such that "set(s3)"
   contains all equivalence classes in "set(s)" but not in "set(s2)".

   The call "s.unionD(s2)" modifies "s" so that "set(s)" contains the
   union of "set(s`)" and "set(s2)", where "s`" is the state of "s"
   immediately before the call, and returns the modified set.

   The call "s.intersectionD(s2)" modifies "s" so that "set(s)"
   contains the intersection of "set(s`)" and "set(s2)", where "s`" is
   the state of "s" immediately before the call, and returns the
   modified set.

   The call "s.diffD(s2)" modifies "s" so that "set(s)" contains no
   equivalence classes that are in "set(s2)", and returns the modified
   set.

   The call "s.iterate()" returns an iterator, which is an object
   that can be used to iterate over the elements in "s".  See below
   for the specification of the "Iterator" type.

   If "it" is the result of the call "s.iterate()", then the call
   "it.next(e)" selects an element from "s" that has not already been
   returned by "it", sets "e" to that element, and returns
   "TRUE".  If no entries remain, the call returns "FALSE" without
   setting "e".  It is a checked runtime error to call "next"
   after it has returned "FALSE".
*)

PROCEDURE Equal(s1, s2: T): BOOLEAN;
(* Equivalent to "s1.equal(s2)".  Exported so that "Set"'s may be used as
   arguments to generic interfaces. *)

END Set.


----------------  Set.mg ---------------------------------------------------
(* Copyright (C) 1992, Digital Equipment Corporation                         *)
(* All rights reserved.                                                      *)
(* See the file COPYRIGHT for a full description.                            *)
(*      modified on Tue Feb 11 20:48:45 PST 1992 by muller                   *)

(* "Set" is a generic interface defining sets of "Elem.T"'s. *)

GENERIC MODULE Set(Elem);

(* Set is an abstract type, but many of it's operations can be implemented
   reasonably efficiently independently of any specific representation
   decisison.  Those are defined here.  Of course, subtypes may choose
   representations that offer the possibility of more efficient
   implementations, and would therefore override these methods.
*)

REVEAL
  T = Public BRANDED OBJECT
   OVERRIDES
    isEmpty := IsEmpty;
    subset := Subset;
    equal := Equal;
    union := Union;
    intersection := Intersection;
    diff := Diff;
    unionD := UnionD;
    intersectionD := IntersectionD;
    diffD := DiffD;
  END;

PROCEDURE IsEmpty(s: T): BOOLEAN =
  BEGIN RETURN s.size() = 0 END IsEmpty;

PROCEDURE Subset(s: T; s2: T): BOOLEAN =
  BEGIN
    IF s.size() > s2.size() THEN
      RETURN FALSE
    ELSE
      VAR iter := s.iterate();
          e: Elem.T;
      BEGIN
        WHILE iter.next(e) DO
          IF NOT s2.member(e) THEN RETURN FALSE END (* IF *)
        END (* WHILE *)
      END (* BEGIN *);
      RETURN TRUE
    END (* IF *)
  END Subset;

PROCEDURE Equal(s1, s2: T): BOOLEAN =
  BEGIN
    RETURN s1.size() = s2.size() AND s1.subset(s2) AND s2.subset(s1)
  END Equal;

PROCEDURE Union(s1: T; s2: T): T =
  VAR s3 := s1.copy(); BEGIN
    RETURN s3.unionD(s2)
  END Union;
    
PROCEDURE Intersection(s1: T; s2: T): T =
  VAR s3 := s1.copy(); BEGIN
    RETURN s3.intersectionD(s2)
  END Intersection;
    
PROCEDURE Diff(s1: T; s2: T): T =
  VAR s3 := s1.copy(); BEGIN
    RETURN s3.diffD(s2)
  END Diff;
    
PROCEDURE UnionD(s1: T; s2: T): T =
  VAR iter := s2.iterate(); e: Elem.T; BEGIN
    WHILE iter.next(e) DO EVAL s1.insert(e) END (* WHILE *);
    RETURN s1
  END UnionD;

PROCEDURE IntersectionD(s1: T; s2: T): T =
  VAR iter := s1.iterate(); e: Elem.T; BEGIN
    WHILE iter.next(e) DO
      IF NOT s2.member(e) THEN EVAL s1.delete(e) END (* IF *)
    END (* WHILE *);
    RETURN s1
  END IntersectionD;

PROCEDURE DiffD(s1: T; s2: T): T =
  VAR iter := s1.iterate(); e: Elem.T; BEGIN
    WHILE iter.next(e) DO
      IF s2.member(e) THEN EVAL s1.delete(e) END (* IF *)
    END (* WHILE *);
    RETURN s1
  END DiffD;

BEGIN
END Set.


----------------  SetDef.ig ---------------------------------------------------
(* Copyright (C) 1992, Digital Equipment Corporation                         *)
(* All rights reserved.                                                      *)
(* See the file COPYRIGHT for a full description.                            *)
(*      modified on Tue Feb 11 20:48:45 PST 1992 by muller                   *)

(* "SetDef" is a generic interface defining sets of "Elem.T"'s,
   implemented via hash tables.
*)

GENERIC INTERFACE SetDef(ElemSet);
(* WHERE    "ElemSet = Set(Elem)", and "Elem.T" is a type that is not an
   open array type and "Elem" contains 

| PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN;
| PROCEDURE Hash(k: Key.T): Word.T;

   "Equal" must be an equivalence relation and "Hash" must respect
   that equivalence relation, i.e., if "Equal(k1, k2)", then
   "Hash(k1)=Hash(k2)".

   "Hash" and "Equal" may be declared with a parameter mode of either
   "VALUE" or "READONLY", but not "VAR".
*)

TYPE 
  Public = ElemSet.T OBJECT METHODS
    init(sizeHint: CARDINAL := 0): T
  END;
  T <: Public;
  Iterator <: ElemSet.Iterator;

(* The expression

| NEW(SetDef.T).init(sz)

   creates a new, empty set.  The argument "sz" is a hint; the set may
   be more efficient if "sz" accurately predicts the maximum number of
   elements it will ever contain.

*)

END SetDef.

----------------  SetDef.mg ---------------------------------------------------
(* Copyright 1993 Digital Equipment Corporation. *)
(* Distributed only by permission. *)
(* See the file COPYRIGHT for a full description. *)

GENERIC MODULE SetDef(Elem, ElemSet, ElemRefTable);
(* WHERE "ElemSet = Set(Elem)" and "ElemRefTable = Table(Elem, Refany)". *)

REVEAL
  T = Public BRANDED OBJECT
    t: ElemRefTable.Default;
   OVERRIDES
    init := Init;
    fromArray := FromArray;
    copy := Copy;
    member := Member;
    insert := Insert;
    delete := Delete;
    size := Size;
    intersection := Intersection;
    diff := Diff;
    intersectionD := IntersectionD;
    iterate := Iterate;
  END (* OBJECT *);

  Iterator = ElemSet.Iterator BRANDED OBJECT
    tIter: ElemRefTable.Iterator;
   OVERRIDES
    next := Next;
  END (* OBJECT *);

PROCEDURE Init(s: T; sizeHint: CARDINAL): T =
  BEGIN
    s.t := NEW(ElemRefTable.Default).init(sizeHint);
    RETURN s
  END Init;

PROCEDURE FromArray(s: T; READONLY a: ARRAY OF Elem.T): ElemSet.T =
  BEGIN
    s.t := NEW(ElemRefTable.Default).init(NUMBER(a));
    FOR i := 0 TO LAST(a) DO EVAL s.insert(a[i]) END (* FOR *);
    RETURN s
  END FromArray;

PROCEDURE Copy(s: T): ElemSet.T =
  VAR res := NEW(T).init(s.size());
      iter := s.iterate();
      e: Elem.T;
  BEGIN
    WHILE iter.next(e) DO EVAL res.insert(e) END (* WHILE *);
    RETURN res
  END Copy;

PROCEDURE Member(s: T; e: Elem.T): BOOLEAN =
  VAR dummy: REFANY; BEGIN
    RETURN s.t.get(e, dummy)
  END Member;

PROCEDURE Insert(s: T; e: Elem.T): BOOLEAN =
  BEGIN RETURN s.t.put(e, NIL) END Insert;

PROCEDURE Delete(s: T; e: Elem.T): BOOLEAN =
  VAR dummy: REFANY; BEGIN
    RETURN s.t.delete(e, dummy)
  END Delete;

PROCEDURE Size(s: T): CARDINAL =
  BEGIN RETURN s.t.size() END Size;

PROCEDURE Intersection(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR s3: T;
      larger: ElemSet.T;
      smallerIter: ElemSet.Iterator;
      e: Elem.T;
  BEGIN
    IF s1.size() >= s2.size() THEN
      larger := s1; smallerIter := s2.iterate()
    ELSE
      larger := s2; smallerIter := s1.iterate()
    END;
    s3 := NEW(T).init(larger.size());
    WHILE smallerIter.next(e) DO
      IF larger.member(e) THEN EVAL s3.insert(e) END (* IF *)
    END (* WHILE *);
    RETURN s3
  END Intersection;
    
PROCEDURE Diff(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR s3 := NEW(T).init(s1.size());
      iter := s1.iterate();
      e: Elem.T;
  BEGIN
    WHILE iter.next(e) DO
      IF NOT s2.member(e) THEN EVAL s3.insert(e) END (* IF *)
    END (* WHILE *);
    RETURN s3
  END Diff;

CONST SizeFactor = 3;

(* This is overridden because there is a more efficient implementation than
   the default when "s2" is significantly smaller than "s1". *)
PROCEDURE IntersectionD(s1: T; s2: ElemSet.T): ElemSet.T =
  BEGIN
    IF s2.size() * SizeFactor < s1.size() THEN
      VAR tOld := s1.t;
          tNew := NEW(ElemRefTable.Default).init(s2.size());
          iter := s2.iterate();
          e: Elem.T;
          dummy: REFANY;
      BEGIN
        WHILE iter.next(e) DO
          IF tOld.get(e, dummy) THEN EVAL tNew.put(e, NIL) END (* IF *)
        END (* WHILE *);
        s1.t := tNew;
      END (* BEGIN *);
      RETURN s1
    ELSE
      RETURN ElemSet.T.intersectionD(s1, s2)
    END (* IF *)
  END IntersectionD;

PROCEDURE Iterate(s: T): ElemSet.Iterator =
  VAR res := NEW(Iterator, tIter := s.t.iterate()); BEGIN
    RETURN res;
  END Iterate;

PROCEDURE Next(iter: Iterator; VAR e: Elem.T): BOOLEAN =
  VAR dummy: REFANY; BEGIN
    RETURN iter.tIter.next(e, dummy)
  END Next;
    
BEGIN
END SetDef.

----------------  SetList.ig ------------------------------------------------
(* Copyright (C) 1992, Digital Equipment Corporation                         *)
(* All rights reserved.                                                      *)
(* See the file COPYRIGHT for a full description.                            *)
(*      modified on Tue Feb 11 20:48:45 PST 1992 by muller                   *)

(* "SetList" is a generic interface defining sets of "Elem.T"'s,
   implemented as linked lists.  This implementations is appropriate
   only for small sets.
*)

GENERIC INTERFACE SetList(ElemSet);
(* WHERE "Elem.T" is a REF type and contains 

| PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN;

   "ElemSet = Set(Elem)".

   "Equal" must be an equivalence relation.

   "Equal" may be declared with a parameter mode of either "VALUE" or
   "READONLY", but not "VAR".
*)

TYPE 
  Public = ElemSet.T OBJECT METHODS
    init(): T;
  END;
  T <: Public;
  Iterator <: ElemSet.Iterator;

(* If "s" is an object of type "SetDefault.T", the expression

| NEW(SetDef.T).init()

   creates a new, empty set.

   The call "s.toRefList()" returns a "RefList.T" whose elements
   include an element from each of the equivalence classes in
   "set(s)", and no other elements. 
*)

END SetList.


----------------  SetList.mg ------------------------------------------------
(* Copyright 1993 Digital Equipment Corporation. *)
(* Distributed only by permission. *)
(* See the file COPYRIGHT for a full description. *)

GENERIC MODULE SetList(Elem, ElemSet, ElemList);
(* WHERE "ElemSet = Set(Elem)", and "ElemList = List(Elem)". *)

REVEAL
  T = Public BRANDED OBJECT
    l: ElemList.T := NIL
   OVERRIDES
    init := Init;
    fromArray := FromArray;
    copy := Copy;
    member := Member;
    insert := Insert;
    delete := Delete;
    size := Size;
    intersection := Intersection;
    diff := Diff;
    intersectionD := IntersectionD;
    diffD := DiffD;
    iterate := Iterate;
  END (* OBJECT *);

  Iterator = ElemSet.Iterator BRANDED OBJECT
    l: ElemList.T
   OVERRIDES
    next := Next;
  END (* OBJECT *);

PROCEDURE Init(s: T): T =
  BEGIN RETURN s END Init;

PROCEDURE FromArray(s: T; READONLY a: ARRAY OF Elem.T): ElemSet.T =
  BEGIN
    s.l := NIL;
    FOR i := 0 TO LAST(a) DO EVAL s.insert(a[i]) END (* FOR *);
    RETURN s
  END FromArray;

PROCEDURE Copy(s: T): ElemSet.T =
  VAR res := NEW(T).init(); rl := s.l; BEGIN
    WHILE rl # NIL DO
      res.l := ElemList.Cons(rl.head, res.l);
      rl := rl.tail
    END (* WHILE *);
    RETURN res
  END Copy;

PROCEDURE Member(s: T; e: Elem.T): BOOLEAN =
  VAR rl := s.l; BEGIN
    WHILE rl # NIL DO
      IF Elem.Equal(rl.head, e) THEN RETURN TRUE END (* IF *);
      rl := rl.tail
    END (* WHILE *);
    RETURN FALSE
  END Member;

PROCEDURE Insert(s: T; e: Elem.T): BOOLEAN =
  BEGIN
    IF s.member(e) THEN
      RETURN TRUE
    ELSE
      s.l := ElemList.Cons(e, s.l);
      RETURN FALSE
    END (* IF *)
  END Insert;

PROCEDURE Delete(s: T; e: Elem.T): BOOLEAN =
  VAR pl: ElemList.T := NIL; rl := s.l; BEGIN
    WHILE rl # NIL DO
      IF Elem.Equal(e, rl.head) THEN
        IF pl = NIL THEN
          s.l := rl.tail
        ELSE
          pl.tail := rl.tail
        END (* IF *);
        RETURN TRUE
      ELSE
        pl := rl;
        rl := rl.tail
      END (* IF *)
    END (* WHILE *);
    RETURN FALSE
  END Delete;

PROCEDURE Size(s: T): CARDINAL =
  BEGIN RETURN ElemList.Length(s.l) END Size;

PROCEDURE Intersection(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR rl1 := s1.l; res := NEW(T).init(); BEGIN
    WHILE rl1 # NIL DO
      IF s2.member(rl1.head) THEN
        res.l := ElemList.Cons(rl1.head, res.l)
      END (* IF *);
      rl1 := rl1.tail
    END (* WHILE *);
    RETURN res
  END Intersection;
    
PROCEDURE Diff(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR rl1 := s1.l; res := NEW(T).init(); BEGIN
    WHILE rl1 # NIL DO
      IF NOT s2.member(rl1.head) THEN
        res.l := ElemList.Cons(rl1.head, res.l)
      END (* IF *);
      rl1 := rl1.tail
    END (* WHILE *);
    RETURN res
  END Diff;
    
PROCEDURE IntersectionD(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR prl1: ElemList.T := NIL;
      rl1 := s1.l;
  BEGIN
    WHILE rl1 # NIL DO
      IF NOT s2.member(rl1.head) THEN
        IF prl1 = NIL THEN
          s1.l := rl1.tail
        ELSE
          prl1.tail := rl1.tail
        END (* IF *)
      ELSE
        prl1 := rl1
      END (* IF *);
      rl1 := rl1.tail
    END (* WHILE *);
    RETURN s1
  END IntersectionD;

PROCEDURE DiffD(s1: T; s2: ElemSet.T): ElemSet.T =
  VAR prl1: ElemList.T := NIL;
      rl1 := s1.l;
  BEGIN
    WHILE rl1 # NIL DO
      IF s2.member(rl1.head) THEN
        IF prl1 = NIL THEN
          s1.l := rl1.tail
        ELSE
          prl1.tail := rl1.tail
        END (* IF *)
      ELSE
        prl1 := rl1
      END (* IF *);
      rl1 := rl1.tail
    END (* WHILE *);
    RETURN s1
  END DiffD;

PROCEDURE Iterate(s: T): ElemSet.Iterator =
  VAR res := NEW(Iterator, l := s.l); BEGIN
    RETURN res;
  END Iterate;

PROCEDURE Next(iter: Iterator; VAR e: Elem.T): BOOLEAN =
  BEGIN
    IF iter.l = NIL THEN
      RETURN FALSE
    ELSE
      e := iter.l.head;
      iter.l := iter.l.tail;
      RETURN TRUE
    END (* IF *)
  END Next;
    
BEGIN
END SetList.



======================================================================= 53 ===
Date:    10 Mar 1995 12:37:21 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Re: Network objects, threads and stacks

In article <9502281543.AA28627@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.COM (
Geoffrey Wyant - Sun Microsystems Labs BOS) writes:
>douglm@rpi.edu writes:
> > A more general solution might be some extension to the network objects
> > package which allows us to register our own new thread routine. One
> > parameter would be the typecode of the object for which the thread is
> > required (at least).
> > 
>Another solution that doesn't require any changes to the network object's
>interfaces or runtime is for you to fork off your own thread in those cases 
>where you know that you will need a large stack. That is, the method 
>implementation in your server forks off a thread of its own with the size
>that you choose. It's a little more work on your part, but doesn't require
>any changes to the current interfaces.

But if you are passing complicated structures around, the Pickle
packacge may well exceed the available stack space whilst unmarshalling
parameters, before the user code is reached.

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 54 ===
Date:    10 Mar 1995 12:34:26 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Re: netobjd problems (SRC M3 3.3)

In article <D56CE1.81L@dcs.gla.ac.uk>, 
faegri@dcs.glasgow.ac.uk (Tor Erlend Faegri) writes:
>
>In my main module, I use NSR.T objects in the following way:
>
>  VAR
>    aReplica : NSR.T := NIL;
>  ...
>  (* Register an instance of a replica in node's netobjd object tables *)
>  NetObj.Export("replica", NEW(NSR.T), NetObj.Locate(node));

				^^^^^^
This line should read NEW(NSR_T). An NSR.T object has _no_ default
methods, so you export a subtype of it that does have the methods
defined, namely an NSR_T object.

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 55 ===
Date:    10 Mar 1995 16:10:32 GMT
From:    bm@play.cs.columbia.edu (Blair MacIntyre)
Subject: Re: OpenGL (was Re: WinNT questions)

To all those who noticed the unqualified host names in the html page
that contains my OpenGL headers, I've fixed m3browser so the host
names should be qualified now.
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

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


======================================================================= 56 ===
Date:    Fri, 10 Mar 1995 13:24:21 MET
From:    rudy@cs.rug.nl
Subject: Report: Language definition (readonly)


              On  the  language  definition  of  Modula-3



                         R. Moddemeijer


                          March 10, 1995


    Department of Computing Science, University of Groningen, P.O.Box
800, NL-9700 AV Groningen, The Netherlands, Telephone: + 31 50 63 3940,
Telefax: + 31 50 63 3800, e-mail: rudy@cs.rug.nl

1     Introduction

   As I have promised, I now present the report on the subject readonly 
variables. This report consist out of the modified original proposal 
and a discussion based on the reactions on the Modula-3 newsgroup.


2     Readonly  variables


2.1    Proposal

There is a certain symmetry between procedure parameters and
variable declarations.  In case of procedure parameters we pos-
sess the VAR-parameter, the VALUE-parameter and the READONLY-
parameter.  These parameters have there counterparts:  the VAR-
declaration, the CONST-declaration and the not existing READONLY-
declaration. I therefore propose the introduction of READONLY vari-
ables. A readonly variable is a constant after initialization. At the
moment of declaration a readonly variable will be initialized by
an expression.  After initialization readonly variables can not be
changed. So a readonly variable is an RHS variable. Notice: con-
stants can only be initialized by a constant expresssions, readonly
variables by any expression.



2.2    Syntax

The Modula-3 syntax (Language report section 1.10.7 Compila-
tion Unit Productions) should be changed into:
Declaration    =  CONST  {ConstDecl  ";"}
                  |  TYPE  {TypeDecl  ";"}
                  |  EXCEPTION  {ExcecptionDecl  ";"}
                  |  READONLY  {ReadOnlyDecl  ";"}
                  |  VAR  {VariableDecl  ";"}
                  |  ProcedureHead  ["="  Block  Indent]  ";"
                  |  REVEAL  {Type  ID  ("="|"<:")  Type.


ReadonlyDecl   =  Ident  [":"  Type]":="  Expr.



2.3    Example

An example program could be the computation of the roots of the
equation ax2 + bx + c = 0:
IMPORT  RealFloat;


PROCEDURE  tgp(a,b,c:REAL;  VAR  x1,x2:REAL)=
READONLY  disc  :=  b*b  -  4.0*a*c;
            root  :=  RealFloat.Sqrt(disc);
  BEGIN
     x1  :=  (-b+root)/(2.0*a);
     x2  :=  (-b-root)/(2.0*a);
  END;
END  tgp;
   Notice that disc and root are used as constants;  they are
never changed. In larger programs the READONLY variables increase
the security. READONLY variables can never be changed accidently.



2.4    Discussion

Farshad Nayeri: Often, you can achieve the same effect by using
a WITH statement:
    IMPORT  RealFloat;


    PROCEDURE  tgp(a,b,c:REAL;  VAR  x1,x2:REAL)=
    BEGIN
      WITH  disc  =  b*b  -  4.0*a*c,
             root  =  RealFloat.Sqrt(disc)  DO
         x1  :=  (-b+root)/(2.0*a);
         x2  :=  (-b-root)/(2.0*a);
      END;
    END  tgp;
   WITH is a bit looser than READONLY as it may give a writable
designator.  Lucian Wischik:  On the other hand, with READONLY
you are able to declare variables precisely where you wanted them;
e.g. in the declaration block and not in the statement block. Self:
If the expression E in WITH  V  =  E is a writable designator, the
WITH-statement is an alternative for a VAR-declaration with ini-
tialization, if not, it is an alternative for a READONLY-declaration.
The main argument to introduce this READONLY construction is
security. And security is one of the most important advantages of
Modula-3 with respect to C++. The WITH construction does not
increase the security.  Norman Ramsey:  The READONLY declara-
tion in interfaces can export variables that won't be touched. You
can't do this using WITH. Makoto Shimojima:  To restrict access
to a variable, one can write a method to handle it and hide the
variable itself in the interface.  If the inline pragma is properly
implemented, the overhead should be minimum. Self: This would
cost a lot of additional source code.  This source code is difficult
to read and makes bugs more probable.  douglm@rpi.edu:  The
value of the READONLY-declaration is the self-documenting aspect.
WITH doesn't really tell us why it's being used other than as a
shorthand construct.  Patrick John Edwards:  The READONLY de-
claration makes the code much more readable. Self: I concude the
proposal to introduce the READONLY is widely accepted.


3 Thanks

   I thank all researchers which have contributed to the discussion on
the internet: Patrick John Edwards, Sam Kendall, Farshad Nay-
eri, Norman Ramsey, Makoto Shimojima, Lucian Wischik and douglm@rpi.edu


======================================================================= 57 ===
Date:    10 Mar 1995 16:09:02 GMT
From:    bm@play.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Question.


Well, that was a failed experiment (cc:ing a mail message with a mime
attachment to the newsgroup ... could anybody read the attachment with
the news readers?) 

The attachment was my current IRIX5 template file, which I'm attaching
here.  Actually, I'm only attaching the end of if where the changes occur.
The changes are in the function before_program_hooks(x), and adding
the M3_STANDALONE variable (which is set in a few places).

-------------------------------------------------
[.... lot's deleted .....]

% used by the stuff below.
M3_STANDALONE = ""

proc build_standalone() is
   % --- reset the linker to avoid shared libraries.
   M3_CONFIG += "-Y2@/bin/cc@-Wl,-B,static@"
   M3_STANDALONE = "yes"
end

proc build_nodebug() is
   % Use the gcc distribution that comes with M3 (2.5.7) -- this
   % version of gcc does not support debugging on Irix, but is
   % probably better debugged than gcc 2.6.0
   M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1-2.5.7@-quiet@"
end

proc build_shared() is
   % --- reset the linker to use shared libraries.
   M3_CONFIG += "-Y2@/bin/cc@-call_shared@-Wl,-rpath," & LIB_USE & "@"
   M3_STANDALONE = ""
end

%-------------------------------------------------------------------- hooks ---
% These are the "last chance" hooks that are called each time a library
% or program is built.  They might build shared libraries or strip
% executables...

proc before_library_hooks(x) is
end

proc after_library_hooks(x) is
  local lib_a  = format ("lib%s.a", x)
  local lib_so = format ("lib%s.so", x)
  if defined ("_all")
    if stale (lib_a, lib_a)
      write ("missing ", lib_a, ": not building ", lib_so, CR)
    else
      if stale (lib_so, lib_a)
        exec ("ld -shared -ignore_unresolved -o", lib_so, "-all", lib_a,
               "-none", IMPORT_LIBS, OTHER_LIBS_L, "-lm -lc")
      end
      install_derived (lib_so)
      install_link_to_derived (lib_so, LIB_INSTALL)
    end
  end
  deriveds (lib_so, no_extension)
  deriveds ("so_locations", no_extension)
end

proc before_program_hooks(x) is
   local arr = ""

   if not M3_STANDALONE
       foreach ov in PKG_OVERRIDES
	 if not equal(normalize("..", PKG_CACHE{ov}), PKG_CACHE{ov}) or not equ
al(normalize(".", PKG_CACHE{ov}), PKG_CACHE{ov}) 
            write ("m3build: relative override(", PKG_CACHE{ov}, ") may cause p
roblems if package contains a shared library", CR)
         end
         arr = arr & PKG_CACHE{ov} & SL & TARGET & ":"
       end
       M3_CONFIG += "-Y2@/bin/cc@-call_shared@-Wl,-rpath," & arr & LIB_USE & "@
"
   end
end

proc after_program_hooks(x) is
end

%------------------------------------------------------------- installation ---
% "install_file" is called during an "m3build install" for
% each file that neededs to be externally exported.

readonly proc install_file (src, dest, mode) is
  Note_install (src, dest)
  exec ("@cp -p", src, dest)
  % exec ("install -c -m", mode, src, dest)
end

%---------------------------------------------- the rest of the environment ---

if defined("_bootstrap") include("COMMON.BOOT") end
include ("COMMON")

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

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


======================================================================= 58 ===
Date:    Fri, 10 Mar 1995 13:30:09 MET
From:    rudy@cs.rug.nl
Subject: Language definition (overrides)

At this moment I find Modula-3 one of the best programming languages.
Working with Modula-3 I still find minor points where the language
(definition) could be improved. Therefore I will propose some minor changes
to the language definition. I hope to initiate a fruitful discussion about
the language definition. I will collect the reactions and write a final
report. 

Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup
comp.lang.modula3. Reactions can also be sent to me personally:
rudy@cs.rug.nl

Example
=======

What is a hidden method? A hidden method is a method in a parent object
which is not accessible because there exists a method with the same name in
a child object. For example:

TYPE Parent=OBJECT
              ...
            METHODS
              hidden():INTEGER; (* hidden method *)
            END;
     Child =parent OBJECT
              ...
            METHODS
              hidden():REAL;    (* the overlaying method *)
            END;

In an expression we can choose to activate the hidden or the overlaying
method:

VAR child:=NEW(Child);
    i:INTEGER;
    r:REAL;
BEGIN
  i:=NARROW(child,Parent).hidden;(* hidden method with dynamic binding *)
  i:=Parent.hidden(child);       (* hidden method without dynamic binding *)
  r:=child.hidden;               (* overlaying method *)

In case of overriding a method, we do not have this choise. We can only
override the overlaying method. This is especially a problem in case of
generics, where the interface containing the parent and the interface
containing the child are generated with the same generic interface.

Proposal: hidden methods
========================

I propose a more liberal "OVERRIDES" clause. The method to be overridden can
be identified by a single identifier or a quallified identifier followed by
an identifier. The quallified identifier must refer to a parent objecttype
or the objecttype itself.

After the declarations 

TYPE
  A =   OBJECT METHODS m() := P END;
  B = A OBJECT METHODS m() := Q OVERRIDES A.m := R END;
VAR
  b:=NEW(B);

we have that
  
  A.m(b)          activates P(b)
  b.m()           activates Q(b)
  NARROW(b,A).m() activates R(b)

Syntax
======

The Modula-3 syntax (Language report section 1.10.9 Type productions) should
be changed into:

Override = [ QualId "." ] Id ":=" ConstExpr.

  



======================================================================= 59 ===
Date:    Fri, 10 Mar 95 16:03:33 EST
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: looking for possibly existing generics

> Spencer Allain writes:
> > 
> > Maybe I'm daft, but after searching through all the libm3 directories,
> > I have been unable to find an acceptable generic implementation of a
> > list (couldn't even find one for a set).

>I believe that most, if not all, of the functionality that you descibed is
>provided by the existing generics. How is a set different than a table ?
>A queue is a sequence the only operations are: addhi, remlo. A stack is
>a sequence where the only operations are: addlo, remlo. Deleting from the
>middle of list can be done in several ways. It can be done functionally by
>creating a new list that contains the elements from the two sides of the 
>element being deleted; and this isn't necessarily inefficient - it merely a 
>matter of an allocation and some pointer copying. It can also be done "destruc
tively"
>(that is by overwriting existing pointers) the 'AppendD' operation on a list.
>
>Hope this helps point you in the right direction !
>
>Geoff Wyant
>Geoff.Wyant@east.sun.com
>Sun Microsystems Laboratories, Inc.

Ok, I probably shouldn't have included Stack and Queue in this discussion,
but I guess I was looking for a predifined Queue and Stack so I didn't
have to create my own special interface so that only "Stack" operations
could be done on my sequence.

I've also realized that "List" fits more neatly with my concept of a
"Collection" and that I could easily define "Set" operations on it, where
my definition of Set is an unordered collection of exactly "one" instance
of any value placed into the collection. ie. duplicate values can either
be thought of as "overwriting" the previously inserted value or can be
considered no-ops.  A table requires a key and a value pair, which I have
encountered being called everything from a "Map", a "Hash-Table", to an
"Associated Array".

I guess it's not so much that I couldn't easily construct them myself, but
adding the appropriated methods in the inherited objects, I just wanted to
know if the structures that I mentioned existed in some standard library.

Why is it so important to me.  Well, for one thing I like to be consistent.
With a Sequence I can use it directly as a queue by either using the 
"addhi/remhi" or "addlo/remlo" pair of operations.  Now unless I define a
consistent Queue Interface somewhere, other people could easily do it in
the opposite fashion that I do.  Not a problem unless you start to mix and
match the two styles.  The same goes for the Stack operations.

The Set that I was looking for, would have been as consistent as possible,
with the language's builtin set for Ordinal Types.  Sure I can create this
from the generic List, but there is plenty of room for procedural name
conflicts between individual creation of this structure.  What I mean, is
that if I define a Set, and somebody else defines a Set with slightly
different procedure names, and I think his/her set is better, then I have
to search through all my code to change to the new names.  If there were
a standard for this type of structure, then I wouldn't have to write my
potentially "non-standard" interface.

Believe me, this has been more than a major pain-in-the-you-know-what for
my group in our C++ work, and I would hate to see something similar happen
to Modula-3 once enough people start using it and encounter more and more
library "clashes".  It has been so difficult to switch to a new library
because there isn't even close to a standard for the basic operations that
should be present in every implementation of say a Stack (this is one of
the things that STL addresses).

I'm pleased to death that Modula-3 has a very robust standard library, but
I also believe that some higher level types need to be standardized also.
The best way to drag people kicking and screaming from their present
language is to provide them the high-level object types that everyone
who took programming courses had to do for themselves.  Sure many people
will want to write their own Queues, Stacks, Linked Lists, Sets, and
what-not, but many would prefer to not have to worry about it.  I've found
that the majority of people would rather use a pre-made structure than
create one that would possibly perform faster.

Hmm, I guess that I've rambled on a bit.  From what I've learned so far 
of Modula-3 I've been pretty pleased.  It's not the end-all language,
but I can see where it would be the logical choice over C++ in many
instances, and a potential loser in others.

After all that babbling, I'd like to thank you for taking the time to
respond to my inquiry.  I guess since I enjoy the Modula-3 style, I
want to help make sure that everything is as good as it can be for
people looking for another language when they've gotten completely fed
up with what they're using now.

-Spencer Allain
Engineering Research Associates


======================================================================= 60 ===
Date:    10 Mar 1995 09:39:55 -0500
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Question.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1900020681-993439912-794846390=:21791
Content-Type: TEXT/PLAIN; charset=US-ASCII

(Eric, I'm CC'ing you since you might be interested.  I'm also CC:ing 
this to the newsgroup, although I have no idea how the attached MIME 
message will appear on News ... if it's really messed up, I'll repost the 
file)

I have a fix for the following problem on IRIX5, but I haven't used 
it extensively.  It appears to work, at least for the one case that was 
causing the problem I describe, so I'm attaching my template here. 

In the template, the LINK command has the parameter 
   -rpath,...../lib/m3/IRIX5 
which puts the modula3 library in an RPATH variable inside the 
executable.  Thus, that directory will be searched in addition to the 
standard ones for the dynamic libraries.

Now, if I override a package location using m3_override, and that package 
has a library in it, it's IRIX5 build directory is not automatically 
searched. That's no problem, though, since I can just add it's directory to 
the LD_LIBRARY_PATH environment variable, and it will get searched at 
run time.

The problem is that if the overridden package _also_ exists in the modula3 
installation directory (that is embedded in the binary file via the 
-rpath switch above) the run time loader will always find the one in the 
standard installation directory, since it looks there before the 
directories set via LD_LIBRARY_PATH!

The easy fix is to remove the rpath switch from the link phase, and 
require a LD_LIBRARY_PATH variable be set that includes the standard 
installation directory.

The not so easy fix (when you don't know quake), is to add all the 
override build directories to the -rpath command, which is what I've 
tried to do.  It looks like it works.  I made it issue a warning if the 
path starts with . or .., since the resulting binary will only be 
runnable from a small selection of subdirectories in that case.

I hope this helps someone. :-)

--1900020681-993439912-794846390=:21791
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=IRIX5
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SUN.3.91.950310093950.21791L@shadow.cs.columbia.edu>
Content-Description: IRIX5 template

JSBDb3B5cmlnaHQgKEMpIDE5ODksIDE5OTIgRGlnaXRhbCBFcXVpcG1lbnQg
Q29ycG9yYXRpb24gDQolIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQolIFNlZSB0
aGUgZmlsZSBDT1BZUklHSFQgZm9yIGEgZnVsbCBkZXNjcmlwdGlvbi4NCiUg
DQolIExhc3QgTW9kaWZpZWQgT24gRnJpIEZlYiAxMCAxMzoyMjowMyBQU1Qg
MTk5NSBieSBrYWxzb3cgIA0KJSAgICAgIE1vZGlmaWVkIE9uIFR1ZSBPY3Qg
MjUgMTE6MjM6MDMgUERUIDE5OTQgYnkgZXJpY3YgICANCiUNCiUgU3RhbmRh
cmQgY29uZmlndXJhdGlvbiBmaWxlIGZvciBTaWxpY29uIEdyYXBoaWNzIG1h
Y2hpbmUNCiUgKE1JUFMxIG9yIE1JUFMyIGFyY2hpdGVjdHVyZSkgcnVubmlu
ZyBJcml4IDUuMi4NCiUNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGNvbXBpbGF0aW9uIGVudmlyb25t
ZW50IC0tLQ0KDQpyZWFkb25seSBUQVJHRVQgPSAiSVJJWDUiDQpyZWFkb25s
eSBERUZBVUxUX0JVSUxEX0RJUiA9IFRBUkdFVA0KDQppbmNsdWRlICgiUExB
VEZPUk1TIikgICUgZ2V0IHRoZSB0YXJnZXQtZGVwZW5kZW50IG1hcHBpbmdz
DQppbmNsdWRlIChPU19UWVBFKSAgICAgICUgZ2V0IHRoZSBPUy1kZXBlbmRl
bnQgZnVuY3Rpb25zDQoNCnJlYWRvbmx5IE5BTUlOR19DT05WRU5USU9OUyA9
ICIwIg0KJSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBvYmplY3QgZmlsZXMgICAgICAgbGlicmFyaWVzDQolICAwPVVuaXggICAg
ICAgICAgICAgICAgICAgICAgICAgID0+ICAubyAgIC5pbyAgICAubW8gICAg
ICAgbGliWFguYQ0KJSAgMT1Vbml4IHdpdGggYSBncnVtcHkgQyBjb21waWxl
ciA9PiAgLm8gICBfaS5vICAgX20ubyAgICAgIGxpYlhYLmENCiUgIDI9V2lu
ZG93cy9OVCAgICAgICAgICAgICAgICAgICAgPT4gIC5vYmogLmlvICAgIC5t
byAgICAgICBYWC5saWINCiUNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gZXhwb3J0
IHBhdGhzIC0tLQ0KJSBEdXJpbmcgdGhlIGluc3RhbGxhdGlvbiwgZGVzdGlu
YXRpb24gZGlyZWN0b3JpZXMgdGhhdCBkbyBub3QgZXhpc3QNCiUgd2lsbCBi
ZSBjcmVhdGVkLiAgWW91IG5lZWQgdGhlIG5lY2Vzc2FyeSBwZXJtaXNzaW9u
cyB0byBkbyBzbzsgb3RoZXJ3aXNlLA0KJSB0aGUgaW5zdGFsbGF0aW9uIHdp
bGwgZmFpbCwgYnV0IGNhbiBiZSByZXN0YXJ0ZWQgYWZ0ZXIgeW91IGhhdmUg
DQolIGZpeGVkIHRoZSBwZXJtaXNzaW9ucy4NCg0KDQpJTlNUQUxMX1JPT1Qg
PSAiL3Byb2ovZ3JhcGhpY3Mvc29mdHdhcmUvbW9kdWxhMy92My41LjEvIg0K
JS0tIGhhbmR5IGZvciBpbnN0YWxsYXRpb25zIHRoYXQga2VlcCBhbGwgTTMg
c3R1ZmYgdG9nZXRoZXINCg0KQklOX0lOU1RBTEwgICA9IElOU1RBTExfUk9P
VCAmICJiaW4vaXJpeDUiCQklIGV4ZWN1dGFibGVzDQpMSUJfSU5TVEFMTCAg
ID0gSU5TVEFMTF9ST09UICYgImxpYi9tMy8iICYgVEFSR0VUCSUgbGlicmFy
aWVzDQpET0NfSU5TVEFMTCAgID0gSU5TVEFMTF9ST09UICYgImxpYi9tMy9k
b2MiCQklIGRvY3VtZW50cw0KUEtHX0lOU1RBTEwgICA9IElOU1RBTExfUk9P
VCAmICJsaWIvbTMvcGtnIgkJJSBwYWNrYWdlcw0KRU1BQ1NfSU5TVEFMTCA9
IElOU1RBTExfUk9PVCAmICJsaWIvZWxpc3AiCQklIGVtYWNzIGxpc3AgY29k
ZQ0KTUFOX0lOU1RBTEwgICA9IElOU1RBTExfUk9PVCAmICJtYW4iCQkJJSBt
YW4gcGFnZXMNCkhUTUxfSU5TVEFMTCAgPSBJTlNUQUxMX1JPT1QgJiAibGli
L20zL3d3dyIJCSUgcHVibGljIGh5cGVydGV4dA0KDQolIFRoZSBtYW51YWwg
cGFnZXMgbm9ybWFsbHkgZ28gaW4gc3ViZGlyZWN0b3JpZXMgbWFuezEsLi4u
OH0gb2YNCiUgdGhlIE1BTl9JTlNUQUxMIGRpcmVjdG9yeS4gIElmIHlvdSBw
cmVmZXIgdG8gaGF2ZSB0aGVtIGFsbCBpbg0KJSBhIHNpbmdsZSBzZWN0aW9u
LCBkZWZpbmUgTUFOX1NFQ1RJT04gdG8gYmUgdGhhdCBzZWN0aW9uJ3MgbmFt
ZS4NCiUgTUFOX1NFQ1RJT04gPSAibCINCg0KJSBPbiBzb21lIHN5c3RlbXMg
KGUuZy4gQUZTKSB5b3UgbXVzdCBpbnN0YWxsIHB1YmxpYyBmaWxlcyBpbiBh
IGRpZmZlcmVudA0KJSBwbGFjZSBmcm9tIHdoZXJlIHlvdSB1c2UgdGhlbS4g
IElmIHRoYXQgaXMgdGhlIGNhc2UgZm9yIHlvdXIgc3lzdGVtLA0KJSBzcGVj
aWZ5IHRoZSAidXNlIiBsb2NhdGlvbiBoZXJlLCBvdGhlcndpc2UgbGVhdmUg
dGhlbSBhbG9uZS4NCkJJTl9VU0UgICA9IEJJTl9JTlNUQUxMDQpMSUJfVVNF
ICAgPSBMSUJfSU5TVEFMTA0KUEtHX1VTRSAgID0gUEtHX0lOU1RBTEwNCg0K
cmVhZG9ubHkgSU5TVEFMTF9JTVBMUyA9ICJUUlVFIg0KJSAiVFJVRSINCiUg
ICAgPT4gc2F2ZSBhbGwgc291cmNlIGZpbGVzIGR1cmluZyB0aGUgaW5zdGFs
bA0KJSAgICA9PiBtYWtlcyBkZWJ1Z2dpbmcgZWFzaWVyIGFuZCBicm93c2lu
ZyBtb3JlIGZydWl0ZnVsDQolICIiIChpLmUuIEZBTFNFKQ0KJSAgICA9PiBz
YXZlIG9ubHkgdGhlIGV4cG9ydGVkIGludGVyZmFjZXMgYW5kIHRlbXBsYXRl
cyANCiUgICAgPT4gbWFrZXMgdGhlIGluc3RhbGxlZCBzeXN0ZW0gc2xpZ2h0
bHkgc21hbGxlci4NCg0KcmVhZG9ubHkgTkVFRF9PQkpFQ1RTID0gIiINCiUg
IlRSVUUiDQolICAgID0+IGFjY3VtdWxhdGUgYSBsaXN0IG9mIGRlcml2ZWQg
b2JqZWN0cyBpbiBDT01QSUxFX09CSkVDVFMNCiUgICAgPT4gZm9yIGJ1aWxk
aW5nIHNoYXJlZCBsaWJyYXJpZXMgaW4gdGhlIGxpYnJhcnlfaG9va3MgZnVu
Y3Rpb24gYmVsb3cNCiUgIiINCiUgICAgPT4gZG9uJ3QgYm90aGVyDQoNCiUt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFgxMSAtLS0NCiUgSWYgeW91IGhh
dmUgWDExUjQgaW5zdGFsbGVkIGFuZCB3b3VsZCBsaWtlIHRoZSBYMTFSNCBi
aW5kaW5nIGludGVyZmFjZXMNCiUgdG8gYmUgYnVpbHQsIGRlZmluZSB0aGUg
cHJvY2VkdXJlICJpbXBvcnRfWDExUjQiIHRvIGltcG9ydCB0aGUgbGlicmFy
aWVzDQolIHRoYXQgYXJlIG5lZWRlZC4gIE90aGVyd2lzZSwgZGVmaW5lICJp
bXBvcnRfWDExUjQiIHRvIGJlIGFuIGVtcHR5IHByb2NlZHVyZS4NCiUNCiUg
SWYgeW91IHVzZSB0aGUgTUlUIHNlcnZlciB3aXRoIERFQ25ldCBzdXBwb3J0
LCB5b3UgbmVlZCBYMTEgYW5kIGRuZXQsDQolIG90aGVyd2lzZSBYMTEgc2hv
dWxkIGJlIGVub3VnaC4NCiUgDQolIFNpbmNlIFgxMVI1IGlzIGFuIGV4dGVu
c2lvbiBvZiBYMTFSNCwgeW91IGNhbiB1c2UgdGhlIFgxMVI1IGxpYnJhcmll
cw0KJSBpbnN0ZWFkIG9mIFgxMVI0LiAgSG93ZXZlciwgdGhlIE1vZHVsYS0z
IGJpbmRpbmcgaW50ZXJmYWNlcyBoYXZlIG5vdA0KJSB5ZXQgYmVlbiB1cGdy
YWRlZCB0byBYMTFSNS4NCiUNCg0KcmVhZG9ubHkgcHJvYyBpbXBvcnRfWDEx
UjQoKSBpcw0KICBpbXBvcnRfbGliKCJYYXciLCAgIi91c3IvbGliIikNCiAg
aW1wb3J0X2xpYigiWG11IiwgICIvdXNyL2xpYiIpDQogIGltcG9ydF9saWIo
IlhleHQiLCAiL3Vzci9saWIiKQ0KICBpbXBvcnRfbGliKCJYdCIsICAgIi91
c3IvbGliIikNCiAgaW1wb3J0X2xpYigiWDExIiwgICIvdXNyL2xpYiIpDQpl
bmQNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGVtYWNzIC0tLQ0KJSBJ
ZiB5b3UgaGF2ZSBlbWFjcyBhbmQgd2FudCB0byBjb21waWxlICIuZWwiIGZp
bGVzIHRvICIuZWxjIiBmaWxlcywNCiUgZmlsbCBpbiB0aGUgZnVuY3Rpb24g
YmVsb3cuICBPdGhlcndpc2UsIGNvbW1lbnQgb3V0IG9yIGRlbGV0ZSB0aGUN
CiUgZW50aXJlIGZ1bmN0aW9uLiAgTm90ZSwgdGhlIGRpc3RyaWJ1dGVkIGNv
ZGUgYXNzdW1lcyBnbnVlbWFjcyB2ZXJzaW9uIDE5DQolIG9yIGxhdGVyLg0K
DQpyZWFkb25seSBwcm9jIGVtYWNzX2NvbXBpbGUgKGVsKSBpcw0KICBleGVj
ICgiZW1hY3MgLWJhdGNoIC1mIGJhdGNoLWJ5dGUtY29tcGlsZSIsIGVsKQ0K
ZW5kDQoNCiUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tIEMgY29tcGlsZXIgYW5kIGxpbmtlciAtLS0NCiUg
VGhlIGZvbGxvd2luZyBkZWZpbml0aW9ucyBhcmUgdXNlZCB0byBjb21waWxl
IGFuZCBsaW5rIEMgbW9kdWxlcy4NCiUgTm90ZSB0aGF0IHRoZXNlIGRlZmlu
aXRpb25zIGNhbiBiZSBvdmVycmlkZGVuIG9uIHRoZSBtM2J1aWxkIGNvbW1h
bmQNCiUgbGluZSB3aXRoICItRCIuICAoZS5nLiAgbTNidWlsZCAtRENDPWdj
YykNCiUNCiUgX2lmZGVmKGEsYixjKSA9PSBpZiBkZWZpbmVkKGEpIHJldHVy
biBiIGVsc2UgcmV0dXJuIGMNCiUNCiUgVGhlIGFjdHVhbCBkZWZpbml0aW9u
cyBtdXN0IGJlIGtlcHQgb24gb25lIGxpbmUgZHVlIHRvIGZpbmlja3kgZGV0
YWlscw0KJSBvZiB0aGUgYm9vdHN0cmFwIHByb2Nlc3MuDQoNCkNDID0gX2lm
ZGVmICgiQ0MiLCBDQywgWyAiL2Jpbi9jYyIsICItRHZmb3JrPWZvcmsiLCAi
LWNja3IiIF0pDQolLS0tIEMgY29tcGlsZXIgd2l0aCBmbGFncyBmb3IgY29t
cGlsaW5nIGEgc2luZ2xlICIuYyIgZmlsZQ0KDQpMSU5LID0gX2lmZGVmICgi
TElOSyIsIExJTkssIFsgIi9iaW4vY2MiLCAiLWNhbGxfc2hhcmVkIiwgIi1X
bCwtcnBhdGgsIiAmIExJQl9VU0UgXSkNCg0KJS0tLSBDIGNvbXBpbGVyIHdp
dGggZmxhZ3MgZm9yIGxpbmtpbmcNCiUgICAgYW5kIGZpbmQgc2hhcmVkIGxp
YnJhcmllcyBpbiB0aGUgaW5zdGFsbGVkIGxpYnJhcnkNCg0KTUFLRUxJQiA9
IF9pZmRlZiAoIk1BS0VMSUIiLCBNQUtFTElCLCBbICIvYmluL2FyIiwgImNy
dSIgXSkNCiUtLS0gcHJvZ3JhbSB0byBidWlsZCBsaWJyYXJ5IGFyY2hpdmVz
DQoNClJBTkxJQiA9IF9pZmRlZiAoIlJBTkxJQiIsIFJBTkxJQiwgWyAiL3Vz
ci9iaW4vdG91Y2giIF0pDQolLS0tIHByb2dyYW0gdG8gaW5kZXggbGlicmFy
aWVzDQoNCkFTTSA9IF9pZmRlZiAoIkFTTSIsIEFTTSwgWyAiZ2FzIiBdKQ0K
JS0tLSBhc3NlbWJsZXINCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gR05VIHZhcmlh
bnRzIC0tLQ0KJSBUaGUgdHdvIGxhcmdlIHBpZWNlcyBvZiBHTlUgc29mdHdh
cmUgdXNlZCBieSB0aGUgTW9kdWxhLTMgc3lzdGVtDQolIGdjYyg9bTNjYykg
YW5kIGdkYig9bTNnZGIpIG9mdGVuIHJlcXVpcmUgc2xpZ2h0bHkgZGlmZmVy
ZW50IEMgY29tcGlsZXJzDQolIG9yIGZsYWdzLiAgVGhleSBhcmUgc3BlY2lm
aWVkIGhlcmUuICBOb3RlIHRoYXQgdGhleSBtYXkgYmUgb3ZlcnJpZGRlbg0K
JSBmcm9tIHRoZSBtM2J1aWxkIGNvbW1hbmQgbGluZS4NCiUNCiUgVG8gdXNl
IHRoZSBHTlUgZGVmYXVsdHMgZm9yIENDIGFuZCBDRkxBR1MsIHNwZWNpZnkg
IioiLg0KJQ0KDQpHTlVfQ0MgICAgID0gX2lmZGVmICgiR05VX0NDIiwgICAg
IEdOVV9DQywgICAgICIqIikNCkdOVV9DRkxBR1MgPSBfaWZkZWYgKCJHTlVf
Q0ZMQUdTIiwgR05VX0NGTEFHUywgIioiKQ0KR05VX01BS0UgICA9IF9pZmRl
ZiAoIkdOVV9NQUtFIiwgICBHTlVfTUFLRSwgICAibWFrZSIpDQoNCiUtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSBNb2R1bGEtMyBjb21waWxlciAtLS0NCiUgVGhlIHN5bnRheCBm
b3IgdGhlIHZhbHVlcyBwYXNzZWQgdG8gbW9zdCBvZiB0aGUgTTNfQ09ORklH
IG9wdGlvbnMgaXMNCiUgIkBwZ21AYXJnMUAuLi5AYXJnbkAiIHdoZXJlICJA
IiBpcyBhbiBhcmJpdHJhcnkgY2hhcmFjdGVyLiAgVGhlDQolIHNlcGFyYXRv
ciBjaGFyYWN0ZXIgbXVzdCBiZWdpbiBhbmQgZW5kIHRoZSB2YWx1ZS4NCg0K
JSBXaGVyZSBpcyB0aGUgZHJpdmVyPw0KTTMgPSBMSUJfVVNFICYgIi9tMyIN
Cg0KJSBXaGF0IGFyZSB0aGUgc3RhbmRhcmQgZmxhZ3M/DQpNM09QVElPTlMg
PSBbICItdzEiLCAiLXdoeSIsICItZyIgXQ0KDQpNM19DT05GSUcgPSBbDQog
ICAiLVkxIiAmIF9wYWNrX2FyZ3MgKENDKSwNCiAgICItWTIiICYgX3BhY2tf
YXJncyAoTElOSyksDQogICAiLVkzIiAmIF9wYWNrX2FyZ3MgKE1BS0VMSUIp
LA0KICAgIi1ZNCIgJiBfcGFja19hcmdzIChSQU5MSUIpLA0KICAgIi1ZNyIg
JiBfcGFja19hcmdzIChBU00pLA0KDQogICAiLVk2QCIgJiBMSUJfVVNFICYg
Ii9tM2NnYzFALXF1aWV0QCIsDQogICAlIC0tLSB0aGUgTW9kdWxhLTMgSUwg
dG8gYXNzZW1ibHkgbGFuZ3VhZ2UgcGFzcw0KDQogICAiLXoyQC1sbUAiLCAg
JSAtLS0gbGlicmFyaWVzIHN5c3RlbWF0aWNhbGx5IGxpbmtlZCB3aXRoIGFs
bCBwcm9ncmFtcw0KDQogICAiLXozIiAmIExJQl9VU0UgJiBTTCAmICJyZXBv
cnRfY292ZXJhZ2UubyIsDQogICAlIC0tLSBsaWJyYXJ5IGxpbmtlZCBpbiBw
cm9ncmFtcyBjb21waWxlZCB3aXRoICItWiIgY292ZXJhZ2Ugb3B0aW9uDQoN
CiAgICItejUiICYgTkFNSU5HX0NPTlZFTlRJT05TLA0KICAgJSBTZXQgdGhl
IGhvc3QgbmFtaW5nIGNvbnZlbnRpb25zLg0KDQogICAiLXo2MCIsDQogICAl
IFZhbHVlcyBvZiAiLXo2IjoNCiAgICUgICAiMCIgPT4gdGhlIG0zIGRyaXZl
ciB3aWxsIHNwbGl0IGxpYnJhcnkgbmFtZXMgYW5kIHBhc3MgLUwvLWwNCiAg
ICUgICAgICAgICAgYXJndW1lbnRzIHRvIHRoZSBsaW5rZXINCiAgICUgICAi
MSIgPT4gdGhlIG0zIGRyaXZlciB3aWxsIHBhc3MgbGlicmFyaWVzIHdpdGgg
ZnVsbCBwYXRoIG5hbWVzDQogICAlICAgIjIiID0+IGxpa2UgIjAiIGV4Y2Vw
dCB0aGF0IGZvciBzaGFyZWQgbGlicmFyaWVzLCB0aGUgZHJpdmVyDQogICAl
ICAgICAgICAgIHBhc3NlcyAtUmRpciBhcyB3ZWxsIGFzIC1MZGlyIHRvIHRo
ZSBsaW5rZXINCg0KICAgIi16QTAiLA0KICAgJSBUaGUgIi16QSIgb3B0aW9u
IHNwZWNpZmllcyB0aGUgbWF4aW11bSBzaXplIChpbiBtZWdhYnl0ZXMpIHRo
YXQgUGFzczANCiAgICUgaXMgYWxsb3dlZCB0byByZWFjaCBhcyBhIHBlcnNp
c3RlbnQgc2VydmVyIGJlZm9yZSB0aGUgZHJpdmVyIGtpbGxzIGl0Lg0KICAg
JSBTZXR0aW5nIGl0IHRvIHplcm8gZGlzYWJsZXMgc2VydmVyIG1vZGUuDQog
ICAlIE5PVEU6IHRoZSBjdXJyZW50IGNvbXBpbGVyIGlzIGJ1Z2d5LCBsZWF2
ZSAiLXpBIiBhbG9uZSENCg0KICAgIi16QkAtTzJAIiwgICUgLS0tIHBhc3Mg
MSBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0KICAgIi16Q0AtTzJAIiwgICUg
LS0tIHBhc3MgNiBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0KICAgIi16REAt
TzJAIiwgICUgLS0tIHBhc3MgNyBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0K
DQogICAiLXpFQC1nQCIsICAlIC0tLSBwYXNzIDEgb3B0aW9ucyBpbXBsaWVk
IGJ5ICItZyINCiAgICItekZALWdAIiwgICUgLS0tIHBhc3MgNiBvcHRpb25z
IGltcGxpZWQgYnkgIi1nIg0KICAgIi16R0BAIiwgICUgLS0tIHBhc3MgNyBv
cHRpb25zIGltcGxpZWQgYnkgIi1nIg0KICAgJSAtLS0gRm9yIElSSVgsIHlv
dSBtdXN0IHVwZ3JhZGUgdG8gZ2NjIDIuNi4wIHRvIGdldCBkZWJ1Z2dpbmcg
c3VwcG9ydC4NCg0KICAgIi16SCIgJiBOQU1JTkdfQ09OVkVOVElPTlMsDQog
ICAlIC0tLSB0aGUgdGFyZ2V0J3MgbmFtaW5nIGNvbnZlbnRpb25zDQoNCiAg
ICItekkiICYgVEFSR0VULA0KICAgJSAtLS0gdGhlIHRhcmdldCBhcmNoaXRl
Y3R1cmUNCg0KICAgJSAiLXpKMTAiLA0KICAgJSBUaGUgb3B0aW9uICItekp4
MSIgc3BlY2lmaWVzIHRoYXQgcGFzcyAieCIgaXMgIm5vaXN5IiwgIi16Sngw
Ig0KICAgJSBzcGVjaWZpY2VzIHRoYXQgaXQncyBub3QuICBUaGUgZGVmYXVs
dCBpcyB0byBhc3N1bWUgdGhhdCBwYXNzZXMNCiAgICUgYXJlIG5vdCBub2lz
eS4gIFRoZSBkcml2ZXIgY29sbGVjdHMgdGhlIHN0YW5kYXJkIG91dHB1dCBv
ZiBub2lzeQ0KICAgJSBwYXNzZXMgaW4gYSBmaWxlIGFuZCB0aGVuIGRlbGV0
ZXMgdGhlIGZpbGUsIHVubGVzcyAiLWtlZXAiIG9yDQogICAlICItdmVyYm9z
ZSIgaXMgc3BlY2lmaWVkLg0KDQogICAiLXpLMCIsDQogICAlIC0tLSBTZXQg
dGhlIHZhbHVlIG9mICIteksiIHRvICIxIiBpZiB5b3Ugd2FudCB0aGUgbTMg
ZHJpdmVyIHRvDQogICAlICAgICBzdXBwbHkgLUJkeW5hbWljLy1Cc3RhdGlj
IG9wdGlvbnMgdG8gdGhlIGxpbmtlciwgIjAiIG90aGVyd2lzZS4NCg0KICAg
Ii1CZHluYW1pYyIsDQogICAlIC0tLSBsaWJyYXJpZXMgYXJlIHNoYXJlZCBi
eSBkZWZhdWx0LiAgSWYgeW91IGdpdmUgLXpLMSB5b3Ugc2hvdWxkDQogICAl
ICAgICBhbHNvIHByb3ZpZGUgYW4gaW5pdGlhbCAtQmR5bmFtaWMgb3IgLUJz
dGF0aWMuDQoNCiAgICItekwwIg0KICAgJSAtLS0gU2V0IHRoZSB2YWx1ZSBv
ZiAiLXpMIiB0byAiMSIgaWYgeW91IHdhbnQgLk0zTElOSyBmaWxlcyBwcm9k
dWNlZA0KICAgJSAgICAgZm9yIGEgZHluYW1pYyBsb2FkZXINCl0NCg0KJSB1
c2VkIGJ5IHRoZSBzdHVmZiBiZWxvdy4NCk0zX1NUQU5EQUxPTkUgPSAiIg0K
DQpwcm9jIGJ1aWxkX3N0YW5kYWxvbmUoKSBpcw0KICAgJSAtLS0gcmVzZXQg
dGhlIGxpbmtlciB0byBhdm9pZCBzaGFyZWQgbGlicmFyaWVzLg0KICAgTTNf
Q09ORklHICs9ICItWTJAL2Jpbi9jY0AtV2wsLUIsc3RhdGljQCINCiAgIE0z
X1NUQU5EQUxPTkUgPSAieWVzIg0KZW5kDQoNCnByb2MgYnVpbGRfbm9kZWJ1
ZygpIGlzDQogICAlIFVzZSB0aGUgZ2NjIGRpc3RyaWJ1dGlvbiB0aGF0IGNv
bWVzIHdpdGggTTMgKDIuNS43KSAtLSB0aGlzDQogICAlIHZlcnNpb24gb2Yg
Z2NjIGRvZXMgbm90IHN1cHBvcnQgZGVidWdnaW5nIG9uIElyaXgsIGJ1dCBp
cw0KICAgJSBwcm9iYWJseSBiZXR0ZXIgZGVidWdnZWQgdGhhbiBnY2MgMi42
LjANCiAgIE0zX0NPTkZJRyArPSAiLVk2QCIgJiBMSUJfVVNFICYgIi9tM2Nn
YzEtMi41LjdALXF1aWV0QCINCmVuZA0KDQpwcm9jIGJ1aWxkX3NoYXJlZCgp
IGlzDQogICAlIC0tLSByZXNldCB0aGUgbGlua2VyIHRvIHVzZSBzaGFyZWQg
bGlicmFyaWVzLg0KICAgTTNfQ09ORklHICs9ICItWTJAL2Jpbi9jY0AtY2Fs
bF9zaGFyZWRALVdsLC1ycGF0aCwiICYgTElCX1VTRSAmICJAIg0KICAgTTNf
U1RBTkRBTE9ORSA9ICIiDQplbmQNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tIGhvb2tzIC0tLQ0KJSBUaGVzZSBhcmUgdGhlICJsYXN0IGNoYW5jZSIg
aG9va3MgdGhhdCBhcmUgY2FsbGVkIGVhY2ggdGltZSBhIGxpYnJhcnkNCiUg
b3IgcHJvZ3JhbSBpcyBidWlsdC4gIFRoZXkgbWlnaHQgYnVpbGQgc2hhcmVk
IGxpYnJhcmllcyBvciBzdHJpcA0KJSBleGVjdXRhYmxlcy4uLg0KDQpwcm9j
IGJlZm9yZV9saWJyYXJ5X2hvb2tzKHgpIGlzDQplbmQNCg0KcHJvYyBhZnRl
cl9saWJyYXJ5X2hvb2tzKHgpIGlzDQogIGxvY2FsIGxpYl9hICA9IGZvcm1h
dCAoImxpYiVzLmEiLCB4KQ0KICBsb2NhbCBsaWJfc28gPSBmb3JtYXQgKCJs
aWIlcy5zbyIsIHgpDQogIGlmIGRlZmluZWQgKCJfYWxsIikNCiAgICBpZiBz
dGFsZSAobGliX2EsIGxpYl9hKQ0KICAgICAgd3JpdGUgKCJtaXNzaW5nICIs
IGxpYl9hLCAiOiBub3QgYnVpbGRpbmcgIiwgbGliX3NvLCBDUikNCiAgICBl
bHNlDQogICAgICBpZiBzdGFsZSAobGliX3NvLCBsaWJfYSkNCiAgICAgICAg
ZXhlYyAoImxkIC1zaGFyZWQgLWlnbm9yZV91bnJlc29sdmVkIC1vIiwgbGli
X3NvLCAiLWFsbCIsIGxpYl9hLA0KICAgICAgICAgICAgICAgIi1ub25lIiwg
SU1QT1JUX0xJQlMsIE9USEVSX0xJQlNfTCwgIi1sbSAtbGMiKQ0KICAgICAg
ZW5kDQogICAgICBpbnN0YWxsX2Rlcml2ZWQgKGxpYl9zbykNCiAgICAgIGlu
c3RhbGxfbGlua190b19kZXJpdmVkIChsaWJfc28sIExJQl9JTlNUQUxMKQ0K
ICAgIGVuZA0KICBlbmQNCiAgZGVyaXZlZHMgKGxpYl9zbywgbm9fZXh0ZW5z
aW9uKQ0KICBkZXJpdmVkcyAoInNvX2xvY2F0aW9ucyIsIG5vX2V4dGVuc2lv
bikNCmVuZA0KDQpwcm9jIGJlZm9yZV9wcm9ncmFtX2hvb2tzKHgpIGlzDQog
ICBsb2NhbCBhcnIgPSAiIg0KDQogICBpZiBub3QgTTNfU1RBTkRBTE9ORQ0K
ICAgICAgIGZvcmVhY2ggb3YgaW4gUEtHX09WRVJSSURFUw0KCSBpZiBub3Qg
ZXF1YWwobm9ybWFsaXplKCIuLiIsIFBLR19DQUNIRXtvdn0pLCBQS0dfQ0FD
SEV7b3Z9KSBvciBub3QgZXF1YWwobm9ybWFsaXplKCIuIiwgUEtHX0NBQ0hF
e292fSksIFBLR19DQUNIRXtvdn0pIA0KICAgICAgICAgICAgd3JpdGUgKCJt
M2J1aWxkOiByZWxhdGl2ZSBvdmVycmlkZSgiLCBQS0dfQ0FDSEV7b3Z9LCAi
KSBtYXkgY2F1c2UgcHJvYmxlbXMgaWYgcGFja2FnZSBjb250YWlucyBhIHNo
YXJlZCBsaWJyYXJ5IiwgQ1IpDQogICAgICAgICBlbmQNCiAgICAgICAgIGFy
ciA9IGFyciAmIFBLR19DQUNIRXtvdn0gJiBTTCAmIFRBUkdFVCAmICI6Ig0K
ICAgICAgIGVuZA0KICAgICAgIE0zX0NPTkZJRyArPSAiLVkyQC9iaW4vY2NA
LWNhbGxfc2hhcmVkQC1XbCwtcnBhdGgsIiAmIGFyciAmIExJQl9VU0UgJiAi
QCINCiAgIGVuZA0KZW5kDQoNCnByb2MgYWZ0ZXJfcHJvZ3JhbV9ob29rcyh4
KSBpcw0KZW5kDQoNCiUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGluc3RhbGxhdGlvbiAt
LS0NCiUgImluc3RhbGxfZmlsZSIgaXMgY2FsbGVkIGR1cmluZyBhbiAibTNi
dWlsZCBpbnN0YWxsIiBmb3INCiUgZWFjaCBmaWxlIHRoYXQgbmVlZGVkcyB0
byBiZSBleHRlcm5hbGx5IGV4cG9ydGVkLg0KDQpyZWFkb25seSBwcm9jIGlu
c3RhbGxfZmlsZSAoc3JjLCBkZXN0LCBtb2RlKSBpcw0KICBOb3RlX2luc3Rh
bGwgKHNyYywgZGVzdCkNCiAgZXhlYyAoIkBjcCAtcCIsIHNyYywgZGVzdCkN
CiAgJSBleGVjICgiaW5zdGFsbCAtYyAtbSIsIG1vZGUsIHNyYywgZGVzdCkN
CmVuZA0KDQolLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSB0aGUgcmVzdCBvZiB0aGUgZW52aXJvbm1lbnQgLS0tDQoN
CmlmIGRlZmluZWQoIl9ib290c3RyYXAiKSBpbmNsdWRlKCJDT01NT04uQk9P
VCIpIGVuZA0KaW5jbHVkZSAoIkNPTU1PTiIpDQoNCg==
--1900020681-993439912-794846390=:21791--


======================================================================= 61 ===
Date:    10 Mar 1995 22:20:24 GMT
From:    dmoen@mks.com (Doug Moen)
Subject: VAR parameters and garbage collection

There is an interesting interaction between VAR parameters and garbage
collection.

The usual implementation of VAR parameters is to pass the address of the
designator that is given as the actual parameter.  But, the designator might
designate a field in the middle of a record object R in the traced heap.
If so, then the formal parameter will be bound to a pointer into the middle
of R.  What happens if a garbage collection occurs during this procedure call?

a) It could be that this pointer into the middle of R is the last reference
   to R at the time of the garbage collection.  The collector had better
   recognize this; if R is collected, then a subsequent assignment to the
   formal parameter could corrupt the heap.

b) If a copying garbage collector is used, then the pointer into the middle
   of R will need to be updated if R is moved.

The only garbage collector that I know of that is capable of recognizing
pointers into the middle of an object is Hans Boehm's conservative garbage
collector.  (Are there any others?)

If your garbage collector is not capable of recognizing pointers into the
middle of an object, then you could represent a VAR parameter as an
(address, offset) pair, where the address points to the beginning of the
object.

If you don't do either of the above two things, then VAR parameters will
be unsafe to use.

How does the SRC Modula 3 compiler deal with this issue?


======================================================================= 62 ===
Date:    10 Mar 1995 14:47:19 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: READONLY Revisited

Let me add my personal opinion to the previous thread about READONLY:

As for software engineering reasons, Modula-3 would greatly benefit from two
READONLY syntax additions with non-uniform semantics. Although the latter is
generally undesirable, its benefits seem to prevail in this special case.

1.  Decl = (READONLY | VAR) VariableDecl {";" VariableDecl} ";" .

2.  Binding = [READONLY] Id "=" Expr .

The first rule allows for READONLY variable declarations and the second for
READONLY bindings in WITH statements.

Whereas the semantics of READONLY bindings are straightforward, I propose the
following non-uniform, i.e. context sensitive, semantics for READONLY variable
declarations.

1.1  READONLY variables declared in interfaces must neither be used as nor
     bound to writable designators by client modules importing the interface.
     However, modules exporting the interface may freely do so.

1.2  READONLY variables declared in non-interface blocks (i.e. all others)
     have to be initialized upon declaration and, subsequently, must neither
     be used as nor bound to writable designators.

I feel that the above semnatics exactly capture what Modula-3 programmers
long for --- any comments welcome!

Of course, I know that proposing new language features is very easy as
compared to the effort of their actual implementation. Any volunteers out
there on the net?

Cheers.

=Ernst=
-- 
+--------------------------------------------------------+-------------------+
| Ernst A. Heinz              (email: heinze@ira.uka.de) |                   |
| Institut fuer Programmstrukturen und Datenorganisation | Make it as simple |
| Fakultaet fuer Informatik, Universitaet Karlsruhe      | as possible, but  |
| Postfach 6980, D-76128 Karlsruhe, F.R. Germany         | not simpler.      |
| (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092)  |                   |
+--------------------------------------------------------+-------------------+

"It has recently been found out that research causes cancer in rats!"


======================================================================= 63 ===
Date:    11 Mar 1995 09:07:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Why no multiple inheritance in Modula-3?

chase@centerline.com wrote on 06.03.95 in <3jfes7$pbd@wcap.centerline.com>:

> ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes:
> > I have looked at the language definition of Modula-3, and I see that it
> > only allows single inheritance. Are there any reasons for this except for
> > the obvious complication in implementing it?
>
> There's non-obvious complications in defining its interactions with
> the rest of the language.  Also, people tried programming in it
> with single inheritance, and ported code written using multiple
> inheritance, and decided that the lack of MI was a tolerable
> deficiency.  That's not the same thing as "not a deficiency".
> Read on to find out (some reasons) why it was left out.

[implementation difficulties deleted]

Don't forget the third type of reason - keeping the language definition  
short and clear. I've yet to see a definition of multiple inheritance  
(complete with clarification of all ramifications) that meets these  
criteria. It may well be impossible to do.

Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 64 ===
Date:    11 Mar 1995 22:44:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Problems building 3.5.1/boot-LINUX

dagenais@notung.vlsi.polymtl.ca wrote on 09.03.95 in <DAGENAIS.95Mar9094023@not
ung.vlsi.polymtl.ca>:

> There are more bugs than that in the dll tools. Look into
> ftp.vlsi.polymtl.ca:pub/m3/linux for a "fixed" version of tools-2.11.
> Although it is older than 2.16, it has worked quite well. Last time
> I checked, newer versions of tools did not include all my bug fixes.

So I tried that one ... unfortunately, the results seem to me to be a lot  
worse than what I had! I think my slightly-patched 2.16 is a much better  
prospect than your massively-patched 2.11 ...

No complete listing this time, as it's more than 100 KB ...

[...]
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DateLinux.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonInt.s
/opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__L_2.s
/opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__L_2.s

/usr/dll/bin/getsize: no source file for symbol '_L_2'
/usr/dll/bin/mkimage -f -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -
- jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc
mkimage v2.11
Warning - non-absolute pathname specified for library
Reading configuration files from /opt/m3/m3/m3core/LINUX/jump
Recording new library parameters.
executing:ld -x -T 64400000 -o libm3core.so.3.5 /opt/m3/m3/m3core/LINUX/jump/__
jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc
jumpas/BasicCtypes.io: Undefined symbol "_MI_BasicCtypes" referenced
jumpas/CConvert.io: Undefined symbol "_MI_CConvert" referenced
jumpas/CConvert.mo: Undefined symbol "_MM_CConvert" referenced
jumpas/Cerrno.io: Undefined symbol "_MI_Cerrno" referenced
jumpas/Convert.io: Undefined symbol "_MI_Convert" referenced
Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference
d from text segment
Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta
ck referenced from text segment
Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta
ck referenced from text segment
Convert.m3:51 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference
d from text segment
Convert.m3:67 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference
d from text segment
Convert.m3:79 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert reference
d from text segment
Convert.m3:79 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks reference
d from text segment
Convert.m3:86 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference
d from text segment
Convert.m3:93 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta
ck referenced from text segment
Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference
d from text segment
Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta
ck referenced from text segment
Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta
ck referenced from text segment
Convert.m3:113 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc
ed from text segment
Convert.m3:122 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc
ed from text segment
Convert.m3:122 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:128 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc
ed from text segment
Convert.m3:135 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt
ack referenced from text segment
Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc
ed from text segment
Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt
ack referenced from text segment
Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt
ack referenced from text segment
Convert.m3:144 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt
ack referenced from text segment
Convert.m3:155 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc
ed from text segment
Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__RTThread__handle
rStack refs follow
Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__MM_Convert refs 
follow
Convert.m3:204 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:249 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:486 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:488 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:492 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc
ed from text segment
Convert.m3:492 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:508 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:510 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc
ed from text segment
Convert.m3:514 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc
ed from text segment
Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__MI_RTHooks refs 
follow
Convert.m3:536 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc
ed from text segment
jumpas/Convert.mo: Undefined symbol "_MM_Convert" referenced
jumpas/Csetjmp.io: Undefined symbol "_MI_Csetjmp" referenced
jumpas/Csignal.io: Undefined symbol "_MI_Csignal" referenced
jumpas/Cstdarg.io: Undefined symbol "_MI_Cstdarg" referenced
jumpas/Cstdarg.mo: Undefined symbol "_MM_Cstdarg" referenced
jumpas/Cstddef.io: Undefined symbol "_MI_Cstddef" referenced
jumpas/Cstdio.io: Undefined symbol "_MI_Cstdio" referenced
Cstdio.m3:10 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f
rom text segment
Cstdio.m3:11 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f
rom text segment
Cstdio.m3:12 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f
rom text segment
jumpas/Cstdio.mo: Undefined symbol "_MM_Cstdio" referenced
jumpas/Cstdlib.io: Undefined symbol "_MI_Cstdlib" referenced
jumpas/Cstring.io: Undefined symbol "_MI_Cstring" referenced
jumpas/Ctypes.io: Undefined symbol "_MI_Ctypes" referenced
jumpas/Date.io: Undefined symbol "_MI_Date" referenced
DateLinux.m3:27 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_TimePosix ref
erenced from text segment
DateLinux.m3:28 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:41 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:46 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:61 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc
ed from text segment
DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc
ed from text segment
DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc
ed from text segment
DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc
ed from text segment
DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc
ed from text segment
DateLinux.m3:69 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref
erenced from text segment
jumpas/DateLinux.mo: Undefined symbol "_MM_DateLinux" referenced
jumpas/DragonInt.io: Undefined symbol "_MI_DragonInt" referenced
DragonInt.m3:42 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt ref
erenced from text segment
DragonInt.m3:44 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt ref
erenced from text segment
DragonInt.m3:345 (jumpas/DragonInt.mo): Undefined symbol __GOT__MI_DragonInt re
ferenced from text segment
DragonInt.m3:382 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt re
ferenced from text segment
DragonInt.m3:397 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt re
ferenced from text segment
jumpas/DragonInt.mo: Undefined symbol "_MM_DragonInt" referenced
jumpas/DragonT.io: Undefined symbol "_MI_DragonT" referenced
DragonT.m3:37 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen
ced from text segment
DragonT.m3:40 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen
ced from text segment
DragonT.m3:42 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen
ced from text segment
DragonT.m3:43 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen
ced from text segment
[... and so on ...]
UnsafeHash.m3:273 (jumpas/UnsafeHash.mo): Undefined symbol __GOT__MM_UnsafeHash
 referenced from text segment
UnsafeHash.m3:276 (jumpas/UnsafeHash.mo): Undefined symbol __GOT__MM_UnsafeHash
 referenced from text segment
UnsafeHash.m3:0 (jumpas/UnsafeHash.mo): More undefined symbol __GOT__MM_UnsafeH
ash refs follow
jumpas/UnsafeHash.mo: Undefined symbol "_MM_UnsafeHash" referenced
jumpas/Uprocess.io: Undefined symbol "_MI_Uprocess" referenced
jumpas/Upwd.io: Undefined symbol "_MI_Upwd" referenced
jumpas/Uresource.io: Undefined symbol "_MI_Uresource" referenced
jumpas/Usem.io: Undefined symbol "_MI_Usem" referenced
jumpas/Ushm.io: Undefined symbol "_MI_Ushm" referenced
jumpas/Usignal.io: Undefined symbol "_MI_Usignal" referenced
Usignal.m3:17 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference
d from text segment
Usignal.m3:18 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference
d from text segment
Usignal.m3:19 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference
d from text segment
Usignal.m3:20 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference
d from text segment
Usignal.m3:21 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference
d from text segment
jumpas/Usignal.mo: Undefined symbol "_MM_Usignal" referenced
jumpas/Usocket.io: Undefined symbol "_MI_Usocket" referenced
jumpas/Ustat.io: Undefined symbol "_MI_Ustat" referenced
jumpas/Usyslog.io: Undefined symbol "_MI_Usyslog" referenced
jumpas/Utime.io: Undefined symbol "_MI_Utime" referenced
jumpas/Utypes.io: Undefined symbol "_MI_Utypes" referenced
Utypes.m3:59 (jumpas/Utypes.mo): Undefined symbol __GOT__MM_Utypes referenced f
rom text segment
jumpas/Utypes.mo: Undefined symbol "_MM_Utypes" referenced
jumpas/Uugid.io: Undefined symbol "_MI_Uugid" referenced
jumpas/Uuio.io: Undefined symbol "_MI_Uuio" referenced
jumpas/Uutmp.io: Undefined symbol "_MI_Uutmp" referenced
jumpas/WeakRef.io: Undefined symbol "_MI_WeakRef" referenced
WeakRef.m3:15 (jumpas/WeakRef.mo): Undefined symbol __GOT__MI_RTWeakRef referen
ced from text segment
WeakRef.m3:20 (jumpas/WeakRef.mo): Undefined symbol __GOT__MI_RTWeakRef referen
ced from text segment
jumpas/WeakRef.mo: Undefined symbol "_MM_WeakRef" referenced
jumpas/Word.io: Undefined symbol "_MI_Word" referenced
Word.m3:48 (jumpas/Word.mo): Undefined symbol __GOT__MM_Word referenced from te
xt segment
jumpas/Word.mo: Undefined symbol "_MM_Word" referenced
../src/Csupport/Common/hand.c:168 (jumpas/cca02744.o): Undefined symbol __GOT__
tables_built referenced from text segment
../src/Csupport/Common/hand.c:174 (jumpas/cca02744.o): Undefined symbol __GOT__
LoBits referenced from text segment
../src/Csupport/Common/hand.c:180 (jumpas/cca02744.o): Undefined symbol __GOT__
HiBits referenced from text segment
../src/Csupport/Common/hand.c:195 (jumpas/cca02744.o): Undefined symbol __GOT__
tables_built referenced from text segment
../src/Csupport/Common/hand.c:200 (jumpas/cca02744.o): Undefined symbol __GOT__
HiBits referenced from text segment
../src/Csupport/Common/hand.c:200 (jumpas/cca02744.o): Undefined symbol __GOT__
LoBits referenced from text segment
../src/Csupport/Common/hand.c:202 (jumpas/cca02744.o): Undefined symbol __GOT__
HiBits referenced from text segment
../src/Csupport/Common/hand.c:203 (jumpas/cca02744.o): Undefined symbol __GOT__
HiBits referenced from text segment
../src/Csupport/Common/hand.c:204 (jumpas/cca02744.o): Undefined symbol __GOT__
LoBits referenced from text segment
jumpas/cca02744.o: Undefined symbol "_tables_built" referenced
jumpas/cca02744.o: Undefined symbol "_LoBits" referenced
jumpas/cca02744.o: Undefined symbol "_HiBits" referenced
jumpas/cca02797.o: Undefined symbol "_MI_M3_BUILTIN" referenced
jumpas/cca02955.o: Undefined symbol "_ThreadF__myId" referenced
jumpas/cca02955.o: Undefined symbol "_RT0u__inCritical" referenced
jumpas/cca02955.o: Undefined symbol "_RTThread__handlerStack" referenced
system: No such file or directory

/usr/dll/bin/mkimage: error running 'ld -x -T 64400000 -o libm3core.so.3.5 /opt
/m3/m3/m3core/LINUX/jump/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-li
nux/2.5.8 -lgcc -lc'

/usr/dll/bin/mkstubs -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -- l
ibm3core
mkstubs v2.11
Warning - non-absolute pathname specified for library
Reading configuration files from /opt/m3/m3/m3core/LINUX/jump
libm3core.sa: ___libm3core_3_500, cca02744, cca02750, cca02955, sequencing, don
e
verify v2.11 (experimental)

jumpkit: Unable to open libm3core.so.3.5

*** error code 1
"/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: command execute fail
ed
*** call stack ***
"/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: call to built-in exe
c
"/opt/m3/m3/m3core/src/m3makefile", line 960: call to procedure after_library_h
ooks
"/opt/SRCm3/lib/m3/pkg/m3build/templates/COMMON", line 1: call to procedure lib
rary
"/opt/m3/m3/m3core/src/m3makefile", line 42: call to procedure Library
m3build: /opt/SRCm3/bin/quake failed (status = 256)
*** error code 255
"/opt/m3/m3/src/m3makefile", line 41: command execute failed
*** call stack ***
"/opt/m3/m3/src/m3makefile", line 41: call to built-in exec
"/opt/m3/m3/src/m3makefile", line 63: call to procedure BuildChunk
m3build: /opt/SRCm3/bin/quake failed (status = 256)
khms[tty1]:/opt/m3/m3# exit
exit


Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 65 ===
Date:    11 Mar 1995 11:44:55 GMT
From:    mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
Subject: Re: VAR parameters and garbage collection

Doug Moen (dmoen@mks.com) wrote:
> If your garbage collector is not capable of recognizing pointers into the
> middle of an object, then you could represent a VAR parameter as an
> (address, offset) pair, where the address points to the beginning of the
> object.

Another way to do this is to save the address of the object in the caller's
stack frame. That's relatively easy to implement and probably doesn't cause
much overhead. This could even be implemented for languages without builtin
garbage collection support (like C[++]) as a source transformation. I guess
it should be more efficient than having to recognize pointers to the middle
of objects, as long as you don't want to move objects.

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>


======================================================================= 66 ===
Date:    11 Mar 1995 11:52:52 GMT
From:    mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
Subject: Re: Why no multiple inheritance in Modula-3?

Kai Henningsen (kai@khms.westfalen.de) wrote:
> I've yet to see a definition of multiple inheritance  
> (complete with clarification of all ramifications) that meets these  
> criteria. It may well be impossible to do.

It shouldn't be too difficult if one defines inheritance (multiple or not)
as a combination of including transformed source code and message passing.
If one requires that naming conflicts must be resolved explicitly (as soon
as the clash would occur, not at the place of calls) it doesn't become too
complicated.

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>


======================================================================= 67 ===
Date:    12 Mar 1995 11:37:35 GMT
From:    mako@FNALA.FNAL.GOV (Makoto Shimojima, Univ of Tsukuba/CDF)
Subject: Re: READONLY Revisited

> 1.1  READONLY variables declared in interfaces must neither be used as nor
>      bound to writable designators by client modules importing the interface.
>      However, modules exporting the interface may freely do so.

The Oberon language has readonly exports. It would be interesting to see
how they implemented it.
						mako


======================================================================= 68 ===
Date:    12 Mar 1995 13:34:17 GMT
From:    dmoen@mks.com (Doug Moen)
Subject: Re: try-finally-except

Taj Khattra <taj@vanbc.wimsey.com> wrote:
>Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead
>of a single TRY-FINALLY-EXCEPT statement ?
>
>Is the following case the main reason why ?
>
>    TRY
>        RAISE e;
>    FINALLY
>	IF (foobar) RAISE e;
>    EXCEPT
>	e => (* this may or may not be executed *)
>    END
>
>I am trying to write a Modula-3 like exception handling mechanism
>for ANSI C (based on Eric Robert's package) and am trying to justify
>to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead
>of just TRY-FINALLY-EXCEPT.

I wrote an exception handling mechanism for C several years ago.  The
design evolved over a three-year period, with feedback from about a dozen
other people using the package on a daily basis.  (It is described in the
Summer 1992 Usenix conference proceedings.)

My package supports the following structure (with slightly different syntax):
    TRY
	<statement list 1>
    THEN_TRY
	<statement list 2>
    THEN_TRY
	<statement list 3>
    EXCEPT
	<handler>
    END
You could repeat the 'THEN_TRY' part zero or more times.
Each <statement list> is executed in sequence.  If <statement list i> is
terminated by an exception, then execution resumes at <statement list i+1>.

After all of the statement lists have been executed, if any of them raised
an exception, then the handler is invoked on the *first* (not the last)
exception that was raised by any of the statement lists.

Here is a typical use of this generalized TRY statement:
    f1 = f2 = NULL;
    TRY
	f1 = efopen(file1, mode1);
	f2 = efopen(file2, mode2);
	<use f1 and f2>
    THEN_TRY
	efclose(f1);
    THEN_TRY
	efclose(f2);
    EXCEPT
	<handler>
    END
efopen() and efclose() are wrappers for fopen() and fclose() that raise an
exception on error.  efclose() ignores a NULL argument.

In this example (which is typical), it is the first exception raised that
is of most interest to the exception handler.  Subsequent exceptions, if
they occur, might be side effects of the original exception, and you don't
want these follow on exceptions to mask the original exception.

In Modula-3, TRY s1 FINALLY s2 END reraises the exception from s2 if both
s1 and s2 raise an exception.  In my experience (which is based on using
C with exceptions, not Modula-3), this is the opposite of what you normally
want.  Can anyone offer a rationale?


======================================================================= 69 ===
Date:    11 Mar 95 09:40:43
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: try-finally-except


In article <3jod1t$9rh@wolfe.wimsey.com> taj@vanbc.wimsey.com (Taj Khattra) wri
tes:
   : I don't think the answer is that deep: most of the time, you need
   : either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design
   : philosophy was to provide simple language features, so both were
   : provided individually.

   I agree that if most of the time either TRY-EXCEPT or TRY-FINALLY, but not
   both, are used, then having both is better than a single TRY-FINALLY-EXCEPT
   statement. 

   But, I thought [that TRY-FINALLY-EXCEPT] would be quite common,
   [...].

I tend to think the difference is deeper than Alan points out. It
boils down to a difference in programmer's expectation: Modula-3
programmer writes code assuming automatic garbage collection, while
the C programmer needs to account for the memory used upon an
exception.

This hit me when I read Alan writing:

   TRY-FINALLY is provided if some "clean up" action must be
   taken --- such as closing a file --- even in if an exception has
   occurred. 

I suspect that in C, the most important form of clean up upon an
exception is freeing memory.  I am guessing this is why Taj is feeling
that TRY-EXCEPT-FINALLY has been so important: he frees memory there.

Alan goes on to say:

   An important example of this is the LOCK statement [...]

I speculate that for the miniscule portion of C programmers who do
multi-threaded programming, the second-most popular usage of FINALLY
is to unlock locks. In Modula-3, you are doing multi-threaded stuff
all the time, so if the LOCK statement didn't exist in M3, you'd be
doing FINALLY's all the time to unlock locks. Hence the syntactic
sugar in Modula-3.

Later, Taj says:

   So I guess all I've ended up worrying about is whether or not to
   provide some "syntactic sugar", not knowing if it would be used
   often enough in practice to be worth the trouble.

Other than dealing with external systems resources like files handles,
I am guessing that TRY-FINALLY would be used more in unsafe modules
than safe ones. I looked around some packages to informally test this
hypothesis. If you look at unsafe modules in ui/src/xvbt for example,
you see that there is a lot of TRY-FINALLYs to do DISPOSEs or Exits.
As Modula-3 encourages safety and simplicity, the designers' choice
makes more sense.

Forgive me for a possible over-generalization, but I think this
illustrates the abstraction power of a strong synergy between garbage
collection, threads and exceptions that we asume in Modula-3 which is
not present in many other languages.

-- Farshad


--
Farshad Nayeri
nayeri@gte.com


======================================================================= 70 ===
Date:    12 Mar 1995 17:36:18 GMT
From:    adiwan@cs.cmu.edu (Amer Diwan)
Subject: Re: VAR parameters and garbage collection

Our scheme (reference given below) deals with derived pointers by having the
compiler generate tables describing each derived pointer at each program point
where garbage collection might occur.  The garbage collector uses these tables
to ensure that when an object is copied, all derived pointers that reference
it are properly updated.  Derived pointers include pointers to the middle of
objects (such as var parameters, pointers created by the WITH statement, etc.)
and pointers outside the referenced object (such as those created by some
compiler optimizations, eg., those that compute a virtual array base to
reference an array).  

Reference:

Compiler Support for Garbage Collection in a Statically Typed Language , Amer
Diwan, Eliot Moss, and Richard Hudson. SIGPLAN Conference on Programming
Language Design and Implementation '92, pp. 273-282.  Also available from:
  http://osl-www.cs.umass.edu/~oos/home.html


    Amer
------------------------------------------------------------------------------
Amer Diwan                                    Department of Computer Science
Object Systems Lab                            University of Massachusetts   
diwan@cs.umass.edu                            Amherst, MA 01003
(413) 545-0256                                
http://www.cs.umass.edu/~diwan/home.html



======================================================================= 71 ===
Date:    Sun, 12 Mar 1995 18:31:09 GMT
From:    wolfmom@netcom.com (Jennifer York)
Subject: Generating an exception from a signal?

Greetings.
I'm wondering if it possible to generate an exception in reponse
to a UNIX signal (say, SIGSEGV or SIGILL).  Obviously, it wouldn't
be possible to continue code from inside the signal handler, but I
was wondering if Modula-3 might handle something like this
(preferably in a (semi-)system independent fasion).

If it makes a difference, the apllication I'm thinking about
working on would be a somewhat dynamic system that would
allow various users to add code to the executable and run it.
I would like to be able to ensure that the added code does not
cause the system to crash.

Any help, suggestions, etc., would be welcome.
                                Joel
Newsgroups: comp.lang.modula-3
Subject: Possible to generate exceptions from signal?
Summary: 
Followup-To: 
Distribution: world
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Keywords: 


Greetings.
I'm wondering if it possible to generate an exception in reponse
to a UNIX signal (say, SIGSEGV or SIGILL).  Obviously, it wouldn't
be possible to continue code from inside the signal handler, but I
was wondering if Modula-3 might handle something like this
(preferably in a (semi-)system independent fasion).

If it makes a difference, the apllication I'm thinking about
working on would be a somewhat dynamic system that would
allow various users to add code to the executable and run it.
I would like to be able to ensure that the added code does not
cause the system to crash.

Any help, suggestions, etc., would be welcome.
                                Joel


======================================================================= 72 ===
Date:    Sun, 12 Mar 1995 22:28:57 GMT
From:    gasboy@eskimo.com (Dan Wilder)
Subject: Re: Why no multiple inheritance in Modula-3?

kai@khms.westfalen.de (Kai Henningsen) writes:

>chase@centerline.com wrote on 06.03.95 in <3jfes7$pbd@wcap.centerline.com>:

>> ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes:
>> > I have looked at the language definition of Modula-3, and I see that it
>> > only allows single inheritance. Are there any reasons for this except for
>> > the obvious complication in implementing it?

>[stuff deleted]

>Don't forget the third type of reason - keeping the language definition  
>short and clear. I've yet to see a definition of multiple inheritance  
>(complete with clarification of all ramifications) that meets these  
>criteria. It may well be impossible to do.

Have you looked into the Eiffel handling of MI?
Not sure quite what would pass "short,"  Eiffel stuff runs more
than a few sentences, but by most accounts it passes "clear." 
Certainly some of the most serious ramifications, the name collision
and diamond (repeat) inheritance problems, are dealt with quite simply, 
one might say summarily.  For the most part the subobject reference
problem is not a problem in Eiffel, though this is probably because
objects are not structures there.

So, depending again on just how demanding your "short and clear" is,
it might be fair to say here is a counterexample illustrating it
is indeed possible to do.  Which is not, of course, to say it belongs
in M3, just that being impossible might not be the best reason for leaving
it out.

---
Dan Wilder


======================================================================= 73 ===
Date:    12 Mar 1995 18:32:15 -0700
From:    jmacnish@CS.Arizona.EDU (J MacNish)
Subject: Generics and getting them to instantiate

I'm having a problem getting a linked list generic to work.  I realize there
is a predefined List generic, but I want my own doubly-linked list.

I am trying desperately to follow the example in Harbison's _Modula-3_ book,
on page 193, and am using the SRC M3 compiler.  If I am reading it
correctly, you would create 6 files(all straight from the example) 

	Integer.m3
	Integer.i3
	IList.m3
	IList.i3
	List.ig
	List.mg

and then a file to use the list, say 

	count.m3	
	

I have all these files, copied straight out of the book for the most part,
and then I have an M3 makefile like:

	import ("libm3")
	Generic_module("List")
	Module("IntegerE")
	Module("IList")
	implementation ("count")
	program ("count")

IntegerE is exactly like the "Integer" module & interface the example describes
on pg 193, but is renamed so that I don't get a name clash (?) with the Integer
interface in (I am guessing) libm3.
 
The compiler chokes on the two modules that supposedly instantiate it:
IntegerE and IList with:

"../src/IList.i3", line 1: syntax error: missing 'END'
"../src/IList.i3", line 1: Initial module name doesn't match final name (<missi
ng id>)
2 errors encountered
new source -> compiling ../src/IntegerE.m3
"../src/IntegerE.m3", line 1: syntax error: missing 'BEGIN'
"../src/IntegerE.m3", line 2: Initial module name doesn't match final name (<mi
s

Errors like this make me think that I mistyped something/left something out/
didn't capitalize an END somewhere, but they are as close as I can get them
to the examples on page 193.

I don't want to be rude and throw a bunch of code up and ask people to debug
it.  If there is something obviously wrong with what I'm doing, though, I
would appreciate some help, or a ridiculously simple example of getting
generics to work--I saw the set generic instantiation a few messages back,
and it was a lot different from all that _Modula-3_'s example says for 
using generics.  I thought getting templates in C++ was a pain to get working,
I hope generics in M3 aren't as bad.

Thanks...
-- 
J MacNish
jmacnish@cs.arizona.edu
					Any minute now, pop will eat itself.


======================================================================= 74 ===
Date:    Mon, 13 Mar 1995 10:14:03 GMT
From:    joel@bris.ac.uk (Joel Crisp)
Subject: Re: Network objects, threads and stacks

Paul Menage (pbm1001@cam.ac.uk) wrote:
: In article <9502281543.AA28627@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.COM
 (Geoffrey Wyant - Sun Microsystems Labs BOS) writes:
: >douglm@rpi.edu writes:
: > > A more general solution might be some extension to the network objects
: > > package which allows us to register our own new thread routine. One
: > > parameter would be the typecode of the object for which the thread is
: > > required (at least).
: > > 
: >Another solution that doesn't require any changes to the network object's
: >interfaces or runtime is for you to fork off your own thread in those cases 
: >where you know that you will need a large stack. That is, the method 
: >implementation in your server forks off a thread of its own with the size
: >that you choose. It's a little more work on your part, but doesn't require
: >any changes to the current interfaces.

: But if you are passing complicated structures around, the Pickle
: packacge may well exceed the available stack space whilst unmarshalling
: parameters, before the user code is reached.

Can't you get round this by providing a special Pickle agent, which
calls you back first ? ( I forget the exact terminology, but for 
particular object types, you can tell pickle to call your code instead
of the default ).

: Paul

: -- 
: Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
: 'One of its satellites, a green and insignificant planet, is now dead'

Joel 
Cynicism, sarcasm, psychosis


======================================================================= 75 ===
Date:    13 Mar 1995 08:18:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Problems building 3.5.1/boot-LINUX

kai@khms.westfalen.de wrote on 11.03.95 in <5heGuV7EcsB@khms.westfalen.de>:

> So I tried that one ... unfortunately, the results seem to me to be a lot
> worse than what I had! I think my slightly-patched 2.16 is a much better
> prospect than your massively-patched 2.11 ...

I think I got it now ... mostly. I'm still not through compiling, though -  
this is one big monster.

Bundles still seem to exhibit some problems. Most problems I found so far  
are the parsing code in the dll tools - it's mighty sloppy.

I think after I'm through, I'll make my version of tools 2.16 available  
somewhere.

Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}



======================================================================= 76 ===
Date:    13 Mar 1995 10:57:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Why no multiple inheritance in Modula-3?

gasboy@eskimo.com wrote on 12.03.95 in <D5CMG9.E1L@eskimo.com>:

> Have you looked into the Eiffel handling of MI?

Yes, but that's been a long time ago - I don't remember any of it, so I  
can't comment on it.


Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 77 ===
Date:    13 Mar 1995 15:23:49 GMT
From:    chase@centerline.com (David Chase)
Subject: Re: Why no multiple inheritance in Modula-3?

gasboy@eskimo.com (Dan Wilder) writes:
> kai@khms.westfalen.de (Kai Henningsen) writes:

> >Don't forget the third type of reason - keeping the language definition  
> >short and clear. I've yet to see a definition of multiple inheritance  
> >(complete with clarification of all ramifications) that meets these  
> >criteria. It may well be impossible to do.

> Have you looked into the Eiffel handling of MI?
> Not sure quite what would pass "short,"  Eiffel stuff runs more
> than a few sentences, but by most accounts it passes "clear." 
> Certainly some of the most serious ramifications, the name collision
> and diamond (repeat) inheritance problems, are dealt with quite simply, 
> one might say summarily.

It could be clearer.  I'd worry about how they (Eiffel rules)
interact with opaque inheritance, and how they interact with mix-in
style programming.  I gather that this is not what B.  Meyer had in
mind when he designed Eiffel, so mix-ins may not work well in
Eiffel (I may gather wrongly), of course.

David


======================================================================= 78 ===
Date:    13 Mar 1995 15:06:34 GMT
From:    chase@centerline.com (David Chase)
Subject: Re: Language definition (overrides)

Why?  What purpose does this serve? How does
this interact with the rest of the language? 
Do you have a proposed implementation
technique for this change to the language?

And, again, why?  Can you at least motivate
this change?  Simply saying "I can't do this,
but if I made this change to the language,
then I could" is all well and good, but that
holds for many things (complex numbers,
unbounded integers, non-contiguous subarrays,
distributed arrays on MPPs, first-class
functions, method closures, continuations,
inheritance among exception types, operator
overloading, constrained generics ...).

I suspect that this also might make programs
slightly less readable -- whenever I say
"O.m" I know that the function from the method
suite is being referred to.  Whenever I say
"T.m" I know that the function statically
bound to type T is being referred to (and it
is my understanding that if T <: S, and T
overrides method m visible in S, then T.m
gets me the overriding method, even though
the function name is not visible to me).

I think this would also violate the reference
manual rule, in that it would increase the
size of the reference manual out of all
proportion to its usefulness.

Sorry for the skeptical tone, but I'm
skeptical.  My tendency is to resist changes
to the language, even those there's quite a
few changes I'd like to make myself
(everything in the list above except
continuations and operator overloading), and
one that I even hope to propose when I get
the time to write it up properly.

I have similar reservations about your
"READONLY" proposal -- as near as I can tell,
it has only local effects (i.e., does not
assist in the building of large systems or
the reuse of code).  If this was of
tremendous concern to you, I might lobby for
a pragma, but this seems like a tiny frob. 
It provides only minor assistance in the
generation of efficient code, since it's
fairly easy for an optimizer to verify that a
variable is only assigned to once.

yours,

David Chase


======================================================================= 79 ===
Date:    13 Mar 95 09:09:32
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: looking for possibly existing generics


   The Set that I was looking for, would have been as consistent as possible,
   with the language's builtin set for Ordinal Types.  Sure I can create this
   from the generic List, but there is plenty of room for procedural name
   conflicts between individual creation of this structure.  What I mean, is
...
   Believe me, this has been more than a major pain-in-the-you-know-what for
   my group in our C++ work, and I would hate to see something similar happen
   to Modula-3 once enough people start using it and encounter more and more
   library "clashes".  It has been so difficult to switch to a new library
...
   Hmm, I guess that I've rambled on a bit.  From what I've learned so far 
   of Modula-3 I've been pretty pleased.  It's not the end-all language,
   but I can see where it would be the logical choice over C++ in many
   instances, and a potential loser in others.

There are some pretty good arguments in there. It is of course difficult
to strike the perfect balance between "simplicity and generality"
and "adequation to the task and specialization".

My proposition would be to collect interesting modules such that everyone
knows what is available and therefore reduce/avoid duplication, 
and insure that proper feedback helps module designers improve their interface
(implementation optimization can come gradually).

The "wish list" section of the FAQ wanted to be a step in that direction.
Perhaps i should put a more explicit entry in the FAQ saying: please
contribute any interesting module you have to xxx, and insure that
some people provide useful feedback.

Note that DEC SRC has always been willing to receive such contributions but
it does not seem to be a very popular channel. Something more interactive
with an automated submission procedure (a forms being filled through the
World Wide Web to insert a new module in the library database) may be
more appealing.

I will try to come up with something. The user base outside SRC seems to
have grown quite a bit recently and it may be time to install an efficient
module "sharing" mechanism.
--

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



======================================================================= 80 ===
Date:    13 Mar 1995 13:26:57 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Re: Network objects, threads and stacks

In article <D5DJ3G.IJG@info.bris.ac.uk>, joel@bris.ac.uk (Joel Crisp) writes:
>Paul Menage (pbm1001@cam.ac.uk) wrote:
>: In article <9502281543.AA28627@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.CO
M (Geoffrey Wyant - Sun Microsystems Labs BOS) writes:
>: >douglm@rpi.edu writes:
>: > > A more general solution might be some extension to the network objects
>: > > package which allows us to register our own new thread routine. One
>: > > parameter would be the typecode of the object for which the thread is
>: > > required (at least).
>: > > 
>: >Another solution that doesn't require any changes to the network object's
>: >interfaces or runtime is for you to fork off your own thread in those cases
 
>: >where you know that you will need a large stack. That is, the method 
>: >implementation in your server forks off a thread of its own with the size
>: >that you choose. It's a little more work on your part, but doesn't require
>: >any changes to the current interfaces.
>
>: But if you are passing complicated structures around, the Pickle
>: packacge may well exceed the available stack space whilst unmarshalling
>: parameters, before the user code is reached.
>
>Can't you get round this by providing a special Pickle agent, which
>calls you back first ? ( I forget the exact terminology, but for 
>particular object types, you can tell pickle to call your code instead
>of the default ).
>

Yes, but it's a hassle, and tends to defeat the effect of having
transparent access to network objects. 

Something like NetObj.MinDefaultStackSize() would be useful ( and can
be simulated by calling Thread.MinDefaultStackSize(). ).

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 81 ===
Date:    Mon, 13 Mar 95 23:29:10 GMT
From:    dh1@ukc.ac.uk (D.Hunt)
Subject: FormsVBT Browsers and FileBrowsers

     We have a problem and we are hoping that someone out there can help.

     We are using FormsVBT to create a GUI for a small Modula 3 program.
What we require is a Browser that acts like a FileBrowser, but the contents
of the Browser are a limited number of filenames (that are the result of a
search.)
     We have an S-expression that we believe will do the job, but we are
trying to write the underlying Modula 3 code. The documentation that we have
is sketchy at best and the only example program that we have is so complicated
and involved that we cannot even find out what structure the Browser takes.
     We could appreciate any help that could be given, especially if anyone
has a small example program that creates at runtime a variable length list
and puts it into a Browser, that they could let us have a copy of. If it deals
with the results of the Browser selection, all the better!

                   Thanks for any help you can give

                              David Hunt 
--
== Babylon 5 Mantra:                                               ==
== Ivanova is always right.  I will listen to Ivanova.  I will not ==
== ignore Ivanova's recommendations.  Ivanova is God.  And if this ==
== ever happens again, Ivanova will personally rip your lungs out! ==


======================================================================= 82 ===
Date:    14 Mar 1995 00:37:51 GMT
From:    jason_jb@postoffice.utas.edu.au (Idio)
Subject: --- pascal user wants to know... ---


  Hiya!

    I just wanna know what the main imrovements that modula3 has over
Modula2
    and Pascal.
    Also, are there any good (ie:*fast* with good interface) for m3 which
might
    compare with Borland Pascal ??
  
    I love Pascal for it's structure and neatness (well ... it can be!)
    and hate C for similar reasons, so if m3 is any imrovment over Pascal
then
    I might give it a try!

  ta


======================================================================= 83 ===
Date:    Mon, 13 Mar 95 18:17:38 -0800
From:    heydon@pa.dec.com
Subject: Re: FormsVBT Browsers and FileBrowsers


David Hunt writes:

> What we require is a Browser that acts like a File Browser, but the
> contents of the Browser are a limited number of filenames (that are
> the result of a search.)
>
> We have an S-expression that we believe will do the job, but we are
> trying to write the underlying Modula 3 code. The documentation that
> we have is sketchy at best and the only example program that we have
> is so complicated and involved that we cannot even find out what
> structure the Browser takes.
>
> We could appreciate any help that could be given, especially if
> anyone has a small example program that creates at runtime a variable
> length list and puts it into a Browser, that they could let us have a
> copy of. If it deals with the results of the Browser selection, all
> the better!

I don't know if this is what you're looking for, but it may give you a
start. I have a program that reads a list of filenames from a file,
sorts them, and then displays them in a FormsVBT "Browser". In my
FormsVBT ".fv" file, the "Browser" is named "moduleBrowser":

  (Browser %moduleBrowser)

In my Modula-3 code, I use the "Lex" interface to read names from a
file, and "TextList.Cons" to prepend each name to a "TextList.T" (the
details of this parsing are omitted here). Then I use the "ListSort"
interface to sort the names and call a "FillBrowser" procedure to
insert the sorted names into the browser:

  VAR modList: TextList.T; BEGIN
    (* Parse file here -- prepend each name to "modList" *)
    FillBrowser(FormsVBT.GetVBT(w, "moduleBrowser"),
      TextListSort.SortD(modList));
  END;

(In this code, "w" is the top-level "FormsVBT.T" window that contains
the "Browser" component.)

A FormsVBT "Browser" component corresponds to the Modula-3 type
"ListVBT.T". Here is the "FillBrowser" procedure:

  PROCEDURE FillBrowser(v: ListVBT.T; modList: TextList.T) =
  (* Prepend the names in "modList" to "v". *)
    VAR i := 0; BEGIN
      v.insertCells(0, TextList.Length(modList));
      WHILE modList # NIL DO
	v.setValue(i, modList.head);
	modList := modList.tail;
        INC(i)
      END
    END FillBrowser;

As the comment says, this procedure *prepends* the names to the list. 
If the "ListVBT.T" is new, it will be empty initially, so this procedure 
will set the browser to contain exactly the names in "modList" (in 
order). If the "ListVBT.T" "v" already contains some names, you can 
delete them by writing: 

  v.removeCells(0, v.count());

See the "ListVBT" interface for details.

You will need to attach a Modula-3 callback procedure to the "Browser"
(using "FormsVBT.AttachProc") to respond when the user selects one of
the filenames.

I hope this helps. Let me know if you have any other questions.

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 84 ===
Date:    13 Mar 1995 14:57:55 GMT
From:    mbk@.seas.ucla.edu (Kennel)
Subject: Re: Why no multiple inheritance in Modula-3?

Kai Henningsen (kai@khms.westfalen.de) wrote:
> gasboy@eskimo.com wrote on 12.03.95 in <D5CMG9.E1L@eskimo.com>:

> > Have you looked into the Eiffel handling of MI?

> Yes, but that's been a long time ago - I don't remember any of it, so I  
> can't comment on it.

Also see Sather, related to Eiffel.  (http://www.icsi.berkeley.edu/Sather)

Because it has implementation inheritance which does not imply subtyping,
and subtyping which does not imply inheritance, the definition of each
is quite clear and without hidden traps, even allowing for multiple
inheritance and multiple subtyping.

> Kai
> --
> Internet: kh@ms.maus.de, kai@khms.westfalen.de
> Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

> ## CrossPoint v3.02 ##


======================================================================= 85 ===
Date:    Tue, 14 Mar 1995 08:35:09 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: re: --- pascal user wants to know... ---

jason_jb@postoffice.utas.edu.au writes:
 > 
 >   Hiya!
 > 
 >     I just wanna know what the main imrovements that modula3 has over
 > Modula2
 >     and Pascal.
 >     Also, are there any good (ie:*fast* with good interface) for m3 which
 > might
 >     compare with Borland Pascal ??
 >   
 >     I love Pascal for it's structure and neatness (well ... it can be!)
 >     and hate C for similar reasons, so if m3 is any imrovment over Pascal
 > then
 >     I might give it a try!
 > 
 >   ta

Well, Modula-3 takes the basic Modula-2 structure and adds to it:

  1. Exceptions
  2. Garbage collection
  3. Seperation of safe from unsafe code
  4. Generic interfaces and modules
  5. Threads, mutexes, and condition variable
  6. dynamic typing (in addition to the normal static typing)
  7. Object types

I think those constitute the main language differences.

There is an implementation that is freely available in source form
that is being done by Digital Equipment Corporation's Systems Research
Center (DEC SRC). The compiler is moderately fast, and there is a lot
of work going on to speed it up. There is currently no Borland style
GUI/IDE available, though there are several projects in the works to
provide such a thing.

The implementation provides a fairly well document and large set of libraries.
There is a library for creating multithread GUIs together with a simple
interactive GUI layout tool. There are libraries for peristent and distributed
programming, and an embeddable distributed scripting language.

The implementation can be gotten via anonymous ftp from:

	gatekeeper.dec.com:/pub/DEC/Modula-3/release-3.5.1

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 86 ===
Date:    14 Mar 95 09:25:46
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: --- pascal user wants to know... ---


       I just wanna know what the main imrovements that modula3 has over
   Modula2 and Pascal.

Modula-3 has Objects, generics, exception handling and garbage collection.
For more details, check the FAQ at ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps

       Also, are there any good (ie:*fast* with good interface) for m3 which
   might compare with Borland Pascal ??

The current compiler on Unix platforms is reasonably fast, at least
when compared with C++ compilers :-), although it goes through a GCC
based backend. The compiler with the integrated backend, currently
available on Windows NT and Windows 9X but hopefully soon on other
platforms, is REAL FAST. The next step will be a nice graphical shell
around the compiler and debugger. I know of a few people starting to
work towards this but nothing is available as of yet.

(A few people have expressed interest in working on modifying the NT386
integrated backend for LINUX ELF but no one had the time to do it until
a few weeks. For a LINUX/80386 guru this may be a relatively small job
of a few days, any takers?).
--

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



======================================================================= 87 ===
Date:    Tue, 14 Mar 1995 10:41:51 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Stacks overflows

Stack overflows are a major concern when attempting to develop a reliable
system. The nasty aspect of overflow is that it can go undetected for some
time allowing programs to run incorrectly.

The addition of guard pages to the end of the stack can be defeated by
routines with a large stack frame which hops over the guard page into the
unprotected memory following.

Even when it does fail it's fairly unhelpful. What I usually see on the
SPARC is Illegal Instruction or random segmentation faults.

If what I say above is correct, then stack overflow presents a threat to
program integrity, more so as we make increased use of threads.

The point of all this, (other than to make people feel uneasy), is to ask
what thought has been given to run time stack checking? I have seen this in
action in an environment where it was probably much more difficult to
implement and it worked well.

Stack checking would involve a little extra overhead on program entry and
thread switching but I feel the improvement in error reporting and
reliability make it worthwhile.




======================================================================= 88 ===
Date:    14 Mar 1995 15:03:54 GMT
From:    bm@play.cs.columbia.edu (Blair MacIntyre)
Subject: Re: looking for possibly existing generics

>>>>> On 13 Mar 95 09:09:32, dagenais@notung.vlsi.polymtl.ca (Michel
>>>>> Dagenais) said:

Michel> My proposition would be to collect interesting modules such
Michel> that everyone knows what is available and therefore
Michel> reduce/avoid duplication, and insure that proper feedback
Michel> helps module designers improve their interface (implementation
Michel> optimization can come gradually).

What I'm starting to do is put any potentially useful, standalone
packages I write in a directory, run "m3browser" on the hierarchy, and
attach it to my web page.

We could do something similar, where anybody who wants to contribute a
package submits it, we just put it in the directory tree, and less
than 30 minutes later (m3browser default rescan interval) it's on the
web.


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

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


======================================================================= 89 ===
Date:    14 Mar 95 08:46:18
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: looking for possibly existing generics


I agree with Spencer Allain and Michel that it is a good idea to
settle on at least interfaces (and I would hope good implementations)
to the basic generic types now, so that these trivial
incompatibilities can be avoided later when they may affect many
people. SRC Modula-3 libraries are one of its strengths, and it is
important that it would stay that way.

Generic datatypes are also easy to contribute, as they are
well-separated from the core of the language, and well-understood
problem by many.

Michel goes on to say:

   Note that DEC SRC has always been willing to receive such
   contributions but it does not seem to be a very popular channel.
   Something more interactive with an automated submission procedure
   (a forms being filled through the World Wide Web to insert a new
   module in the library database) may be more appealing.

I have often wondered about the lack of library contributions outside
SRC. I think this is an important issue, because if Modula-3 is to
become really popular, it needs the "power of multiples", as the case
is for systems such as Linux, and tcl/Tk. Note that there is much
outside contribution for porting to different systems.

I personally don't tend to think it has as much to do with the lack of
sharing mechanism.  I can think of some other reasons, though:

   - The existing "core" libraries are quite nice and complete in many
     areas, as compared to many other *single* environments. The
     mode-of-operation for many Modula-3 programmers is just "get
     their work done" as was noted before on this group.

   - This "perfect balance between simplicity and generality" is hard
     to strike for many people outside SRC! Or at least outsiders may
     feel this, so they tend to not distribute what they have. I think
     to some extent, this push for "perfection" intimidates some
     people. (I hate to say this, but I think it is true.)

   - Possibly the type of people contributing; they may have been less
     application-programmer types, or numerical-programmer types and
     more systems-programmer types. (Whatever this means.)

   - Various company (and university) policies for outside
     distribution of developed programs. I think companies and people
     who are worried about "intellectual property" worry less about
     releasing porting information and bug reports than new library
     releases. Coupled with SRC releasing solid libraries, this tends
     to provide for less motivation for individuals within
     organizations to release code.

   - Lack of communication about priorities. This thread, Bill's todo
     list, and Michel's wanted list are good steps in resolving some
     of the issues, but you never know if SRC (or outside SRC for that
     matter) is going to release something next time that does exactly
     what your package does. I guess this is lack of communication is
     a backlash against vaporware, but maybe it is too far back? I am
     not saying this is SRC's responsibility , I am just observing
     that I have seen this happen.

   - Ratio of outside contributors to SRC contributors (just a
     speculation)

   - We are not considering summer intern contributions as outside
     contributions. VideoVBT, Visual Obliq, portions of Obliq, among
     other packages were written by summer visitors working with SRC
     folks. (May just be a technicality, but I do think it has to do
     with the points I made about communication and perfection.)

I am not saying any of these are "bad", they just "are". I imagine
some of these may have to change if Modula-3 is going to become
"popular". 

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


======================================================================= 90 ===
Date:    Wed, 15 Mar 1995 09:33:36 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: Stack overflows

>Mike Douglass writes:
> > Stack overflows are a major concern ...
>Geoff Wyant writes
>I think the addition of stack boundary checking would be good, though I'm
>concerned about the cost, especially in the face of multithreading. I don't
>know if you can get the stack end in a cheap manner on entry to a procedure.
>Most processors don't keep that information in a register.
>
>How often do you see gaurd pages not being touched on a stack overflow ?
>
>Actually right now, I don't think the runtime allocates gaurd pages for
>any thread. That might be a useful starting point for OSs with the
>appropriate VM primitives.
>

I have experienced stack checking implemented in a relatively unfriendly
environment, that is an operating system written many years ago where most
of the system didn't follow any noticable coding convention. Furthermore,
asyncronous entries could occur in routines as the result of system events,
interrupts etc.

However we managed to graft onto that a stack oriented run-time system
which handled the problems of asynchronous entry into routines with the
correct stack and global environment.

I cannot remember all of the details but stack checking involved having a
stack descriptor which was accessible at a known location (global base
actually) and checking the current stack pointer against the top of the
stack.

The overhead is relatively low.

 I would guess that, machine architecture permitting, it would be easier to
implement in Modula3 because we have more control over the run time
environment.





======================================================================= 91 ===
Date:    Wed, 15 Mar 1995 10:31:13 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Re: Stack overflows

Mike Douglass writes:
 > >Mike Douglass writes:
 > > > Stack overflows are a major concern ...
 > >Geoff Wyant writes
 > >I think the addition of stack boundary checking would be good, though I'm
 > >concerned about the cost, especially in the face of multithreading. I don't
 > >know if you can get the stack end in a cheap manner on entry to a procedure
.
 > >Most processors don't keep that information in a register.
 > >
 > >How often do you see gaurd pages not being touched on a stack overflow ?
 > >
 > >Actually right now, I don't think the runtime allocates gaurd pages for
 > >any thread. That might be a useful starting point for OSs with the
 > >appropriate VM primitives.
 > >
 > 
 > I have experienced stack checking implemented in a relatively unfriendly
 > environment, that is an operating system written many years ago where most
 > of the system didn't follow any noticable coding convention. Furthermore,
 > asyncronous entries could occur in routines as the result of system events,
 > interrupts etc.
 > 
 > However we managed to graft onto that a stack oriented run-time system
 > which handled the problems of asynchronous entry into routines with the
 > correct stack and global environment.
 > 
 > I cannot remember all of the details but stack checking involved having a
 > stack descriptor which was accessible at a known location (global base
 > actually) and checking the current stack pointer against the top of the
 > stack.
 > 
 > The overhead is relatively low.
 > 
 >  I would guess that, machine architecture permitting, it would be easier to
 > implement in Modula3 because we have more control over the run time
 > environment.
 > 
 > 

Thinking about it some more, it seems like it should be relatively
straightforward.  What you want is to have instantaneous access to the
stack bounds (or at least how big the stack is allowed to grow). The
easiest way to do this is to dedicate a register to it, which I suspect
the code generator could do pretty easily. You wouldn't get stack
checking when calling into a non-M3 routine, but at least you would have
an indication of where it might have occurred. On a RISC machine, it is probabl
y
reasonable to do this, but it might create register pressure on the x86 
architecture. Does the x86 maintain stack bounds in a register anyway ?

If you can't put it in a register, then it may too expensive to do. On a 
machine with kernel support for threads, especially running on a multiprocessor
,
there isn't a single global variable where you could stick this information.
You'd have to do some sort of table lookup based on the current thread
to get this information or make an OS/system call to get it (on Solaris-2 and N
T
there is thread private storage where it could be stored), but the overhead
would not be very acceptable, I suspect.

When a thread is created, you would need to set the stack limit register which,
while system dependent, is relatively straightforward for all but the root thre
ad, 
since it is the runtime that allocates the thread stacks. The root thread stack
 is 
allocated by the OS, and it may not be possible to get the stack bounds for it.
 Under 
Solaris-2 it is, but I don't think it is for SunOS. I don't know about other OS
's. I
don't know how hard it is to make the code generator generate code that is depe
ndent 
on the target OS. It may be fairly straightforward. Bill K. do you know ?


--geoff


======================================================================= 92 ===
Date:    Thu, 16 Mar 1995 01:18:19 GMT
From:    nagle@netcom.com (John Nagle)
Subject: Re: Stacks overflows

douglm@rpi.edu (Mike Douglass) writes:
>The point of all this, (other than to make people feel uneasy), is to ask
>what thought has been given to run time stack checking? I have seen this in
>action in an environment where it was probably much more difficult to
>implement and it worked well.

     If each stack is in a separate segment, the hardware should do
it for you.

     There are certain advantages to not having a flat address space.

					John Nagle



======================================================================= 93 ===
Date:    Thu, 16 Mar 95 00:23:44 GMT
From:    ic4@ukc.ac.uk (I.Chatzigiannakis)
Subject: Undefined number of arguments


Do you have any idea how I can make a procedure that accepts many
arguments without a preset number.
I know how to code it in c++ (void myfunc(char *format,...)) but
what about modula-3?

Thanks for the help
Yannis




======================================================================= 94 ===
Date:    16 Mar 1995 01:22:16 GMT
From:    birdi@ponder.csci.unt.edu (Arvinder S. Birdi )
Subject: m3makefiles, libraries

Hello, 
I have just started using m3build. I can create simple m3makefiles
that generate one item. (ie either one executable program or one
library). Is it possible to have one  m3makefile generate multiple
executable files and libraries?

thanks
-birdi

-- 
///////////////////////////////////////////////////////////////////////////////
			       )\& &/(
		       ---oQQo-- (^) --oQQo---
				  U


======================================================================= 95 ===
Date:    16 Mar 1995 03:57:52 GMT
From:    schaub@ponder.csci.unt.edu (Stephen Schaub)
Subject: Re: Undefined number of arguments

I.Chatzigiannakis (ic4@ukc.ac.uk) wrote:

: Do you have any idea how I can make a procedure that accepts many
: arguments without a preset number.
: I know how to code it in c++ (void myfunc(char *format,...)) but
: what about modula-3?

: Thanks for the help
: Yannis

As far as I know, Modula-3 doesn't permit this, but you can simulate it 
nicely under certain circumstances using default parameters.  For an
example, see the Fmt interface, particularly the F routine, defined
as follows:
  PROCEDURE F(fmt: TEXT; t1, t2, t3, t4, t5: TEXT := NIL) : TEXT;

This allows the user to call the routine like this:
  IO.Put(Fmt.F("Hello\n"));
or
  IO.Put(Fmt.F("Hello, %s\n", name));  (* <name> is a TEXT variable *)
or
  IO.Put(Fmt.F("%s: %s\n", name, Fmt.Int(35)));

Then the common way to deal with such a situation in, say, the definition 
of F, is to put all the parameters in an array so you can index them
conveniently like this:

  PROCEDURE F(fmt: TEXT; t1, t2, t3, t4, t5: TEXT := NIL) : TEXT =
    VAR
      txtArr := ARRAY [1..5] OF TEXT{t1, t2, t3, t4, t5};
    BEGIN
      FOR i := FIRST(txtArr) TO LAST(txtArr) DO
        IF txtArr[i] = NIL THEN EXIT END;
        ...
      END
    END F;

It's a really nice example of how parameter defaults and array constructors
can work together to provide high-level support for variable parameters
without having to mess around with low-level stack stuff as is required in
C/C++.

Stephen Schaub
schaub@cs.unt.edu


======================================================================= 96 ===
Date:    Thu, 16 Mar 95 12:32:51 GMT
From:    buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409)
Subject: Re: Stack overflows

Geoffrey Wyant - Sun Microsystems Labs BOS (gwyant@cloyd.East.Sun.COM) wrote:
: Mike Douglass writes:
:  > >Mike Douglass writes:
:  > > > Stack overflows are a major concern ...
:  > >Geoff Wyant writes
:  > >I think the addition of stack boundary checking would be good, though I'm
:  > >concerned about the cost, especially in the face of multithreading. I don
't
:  > >know if you can get the stack end in a cheap manner on entry to a procedu
re.
:  > 
:  > I cannot remember all of the details but stack checking involved having a
:  > stack descriptor which was accessible at a known location (global base
:  > actually) and checking the current stack pointer against the top of the
:  > stack.
:  > 
:  > The overhead is relatively low.

: Thinking about it some more, it seems like it should be relatively
: straightforward.  What you want is to have instantaneous access to the
: stack bounds (or at least how big the stack is allowed to grow). The
: easiest way to do this is to dedicate a register to it, which I suspect
: the code generator could do pretty easily. You wouldn't get stack
: checking when calling into a non-M3 routine, but at least you would have
: an indication of where it might have occurred. On a RISC machine, it is proba
bly
: reasonable to do this, but it might create register pressure on the x86 
: architecture. Does the x86 maintain stack bounds in a register anyway ?

yes, there is a special segment register for the stack. You can have
all necessary checking in hardware (It still takes time!)

: If you can't put it in a register, then it may too expensive to do. On a 
: machine with kernel support for threads, especially running on a multiprocess
or,
: there isn't a single global variable where you could stick this information.
: You'd have to do some sort of table lookup based on the current thread
: to get this information or make an OS/system call to get it (on Solaris-2 and
 NT
: there is thread private storage where it could be stored), but the overhead
: would not be very acceptable, I suspect.

If you want the stack bound in a register, you may become very
processordependant. For every processor, there may be a fast and
usable solution. But you 'll need a different one for every
processorarchitecture.

Guard pages are straight forward. Should be the same semantics on
every paged mmu. Hope you have OS support for using them.

If procedurecalls do not happen too frequently, a simple compare on
procedure entry (and maybe exit) should be fast enough. You 'll need
three to five loads and a compare. The stack bound can be kept in the
thread global dataspace, and you don't sacrifice a register.

possible Algorithm:

	r1 := thread id
	r2 := thread global dataspace [r1]
	r3 := offset of stack bound [r2]
	r4 := [r3]
	compare r4 and sp

Ok, three to five loads isn't nothing, but shouldn't hurt to much as a
generic implementation. If you want it faster, you 'll have to become
processor specific.

So how fast do you need it?


				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

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

	buschman@lts.sel.alcatel.d


======================================================================= 97 ===
Date:    Thu, 16 Mar 1995 15:17:54 -0500
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: re: stack checking

Andreas Buschmann writes:
 > If you want the stack bound in a register, you may become very
 > processordependant. For every processor, there may be a fast and
 > usable solution. But you 'll need a different one for every
 > processorarchitecture.
 > 

The code generator could take care of some of this. Setting the 
register would be done in the runtime at thread startup. This would
entail a little machine-specific code, but only a couple of lines. 
The runtime is already factored to support this.

 > Guard pages are straight forward. Should be the same semantics on
 > every paged mmu. Hope you have OS support for using them.
 > 

This whole discussion started because Mike Douglass felt that 
gaurd pages weren't sufficient. I don't know how frequently they
fail in practice, 

 > If procedurecalls do not happen too frequently, a simple compare on
 > procedure entry (and maybe exit) should be fast enough. You 'll need
 > three to five loads and a compare. The stack bound can be kept in the
 > thread global dataspace, and you don't sacrifice a register.
 > 
 > possible Algorithm:
 > 
 > 	r1 := thread id
 > 	r2 := thread global dataspace [r1]
 > 	r3 := offset of stack bound [r2]
 > 	r4 := [r3]
 > 	compare r4 and sp
 > 
 > Ok, three to five loads isn't nothing, but shouldn't hurt to much as a
 > generic implementation. If you want it faster, you 'll have to become
 > processor specific.
 > 

On machines where you control the thread switching, and there is only
one thread running at a time, you can do as you describe. On the NT 
implementation, which has kernel supported threads and multiprocessor 
support, I don't think you could as you described. I think you would 
need to stash the stack bound in thread private storage (or what ever it
is called in NT), and make a call on procedure entrance to get it. I suspect
that this would slow down procedure invocation quite a bit. Solaris also
supports kernel level threads, and a call to get a value from thread private 
storage is a kernel call. You wouldn't want to make a kernel call on every
procedure invocation. 

 > So how fast do you need it?

No more than a couple of instructions in the normal case. 

--geoff


======================================================================= 98 ===
Date:    Thu, 16 Mar 1995 15:57:19 PST
From:    boehm.PARC@xerox.com
Subject: Re: Stack overflows

Let's say that the guard area between stacks is 10% of the stack size.  I think
that usually means (except on register window machines) that you can skip the
guard page only if the size of a stack frame is at least 5% of the stack size.
I rarely write such code, and I tend to be careful if I do.  I'm not enough of
a Modula 3 expert, but I suspect the compiler can eliminate nearly all call
frames as safe, so that you should be able to insert explicit tests in only a
small fraction of the functions, even if you do want to check.  This argues
that an explicit check should rely on guard pages.

On a SPARC the constants are different, but I still believe you need
exceptionally large frames to get into trouble.

I don't have Modula 3 stats, but according to a tech report by Calder,
Grunwald, and Zorn, the average dynamic function size in C++ was 46.1
instructions for the programs they measured.  So 5-10 instructions per function
call is likely to be more than 5%.

Hans-J. Boehm
(boehm@parc.xerox.com)
Standard disclaimer ...


======================================================================= 99 ===
Date:    Thu, 16 Mar 1995 15:44:48 GMT
From:    george@bcstec.ca.boeing.com (Harry G. George)
Subject: Re: Undefined number of arguments

In article <9543@merlin.ukc.ac.uk>, I.Chatzigiannakis <ic4@ukc.ac.uk> wrote:
>
>Do you have any idea how I can make a procedure that accepts many
>arguments without a preset number.
>I know how to code it in c++ (void myfunc(char *format,...)) but
>what about modula-3?
>
>Thanks for the help
>Yannis
>
>

I use:
    PROCEDURE myfunc(format:TEXT; parm1,parm2,parm3,parm4,parm5:REFANY:=NIL);

If it may take more than an obvious maximum, then I go to dynamic arrays:
    PROCEDURE myfunc(format:TEXT; args:ARRAY OF REFANY);

Of course then I need to set up an adequately large array (e.g., via
a dynamic array), and then do an array constructor in the call:

    myfunc("my format here",Args{p1,p2,p3,p4,p5,p6,p7,p8,p9,p10});

-- 
Disclaimer:  Any opinions expressed herein are my own and
             not those of The Boeing Company.
Contact:     Harry George, BCAG Advanced Software Technology  
Phone:       (206) 237-6915  Org: 6-6541  M-S: 6H-WT


======================================================================= 100 ===
Date:    17 Mar 1995 11:47:59 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Re: Undefined number of arguments

In article <9543@merlin.ukc.ac.uk>, ic4@ukc.ac.uk (I.Chatzigiannakis) writes:
>
>Do you have any idea how I can make a procedure that accepts many
>arguments without a preset number.
>I know how to code it in c++ (void myfunc(char *format,...)) but
>what about modula-3?

You can simulate it using default values for parameters, initialised to 
some suitably invalid value ( or with one parameter specifying the
validity of the others ). E.g. For doing execution tracing, I have a 
procedure with the following signature:

Trace(format:TEXT;
      i1,i2,i3,i4,i5:=0;
      f1,f2,f3,f4,f5:=0.0;
      r1,r2,r3,r4,r5:REFANY:=NIL);

where format specifies a the string to be printed ( a la printf ) and
the other parameters are substituted into the output as required. It is
a little innefficient, in that up to 15 unecessary parameters are
passed each time, but in a routine like this that does terminal output, 
this should hopefully not create a noticeable effect.  

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 101 ===
Date:    16 Mar 1995 16:15:39 GMT
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Dylan, Modula-3 and OMG


>  I'm interested in finding a good (better than C++) language for
>  developing ORB-based applications. There are a lot of factors to
>  consider, for example, the naturalness of the mapping to IDL; the
>  ease of providing 'proxies' for remote objects; the appropriateness
>  of the object creation paradigm to a distributed environment etc.
>  etc.
>  
>  Although I'd be interested people's views of Dylan's suitability in
>  general, to start with I was wondering whether Dylan offered useful
>  features that Modula-3 didn't (or vice-versa!).
>
>  I read with interest a summary from Geoff Wyant a while ago
>  outlining Modula- 3's features, some of which seem appropriate to a
>  CORBA environment:
>
>     [many nice Modula-3 features deleted.]
>
>  How does Dylan compare? I expect that CORBA is a consideration for
>  the Apple developers, if only because OpenDoc is aligned with it.
 

How do you build a reliable (and easily maintainable) distributed
program in presence of generic dispatch anyway? Due to the emphasis on
reliability, engineering a distributed program entails careful
treatment of network calls. For me, this does not sit well with the
nature of programming with generic functions, where I can add mixins
to any of the parameters, and changing the nature of the distributed
call in unpredictable ways.

I am not refuting the value of having generic functions; I'd love to
have them sometimes. I just don't know if I want them to get in my way
of ensuring that my distributed program is robust! Maybe if it were
possible to restrict their genericity for certain tasks...

I am also not saying that it's impossible to do distributed
programming in Dylan. I am just wondering how hard it would be. I
wonder if this is simply not a priority for Dylan folks at the moment.
Anyone trying to do this out there? What are your experiences? 

Finally, in response to the previous post, I'd like to note that
stating that a programming language:

     - has an OMG IDL binding (or supports OpenDoc)

     - provides at least the minimal support for building of
       large-scale and reliable distributed applications

     - has no built-in support for distributed programming but it
       makes sure that it doesn't get in the way of distributed
       programming as the problems of building distributed systems
       were considered in the design of the language

mean different things, each promising a different level of support for
its ability to support large distributed systems.

Am I correct to assume that Dylan has none of the above?

-- Farshad

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 102 ===
Date:    17 Mar 1995 00:21:12 GMT
From:    egustafs@ecepc44.uccs.edu (Eric Gustafson)
Subject: Q: raw or cbreak char input

Is there some form of "curses" like module or a way to get unbuffered
input from a terminal other than reverting to the C library?  I dug
through all of the m3 library interfaces and couldn't find anything
that would let me get a character at a time from a stream.

thanks,
--
Eric Gustafson                                    egustafs@ecepc44.uccs.edu
Electrical & Computer Engineering                    egustafs@cpe.valpo.edu
University of Colorado -- UCCS                        Phone: (719) 637-8022
** Warning ** Planet is 97% full please remove unneeded inhabitants !!


======================================================================= 103 ===
Date:    17 Mar 1995 13:03:47 GMT
From:    normark@iesd.auc.dk (Kurt Noermark)
Subject: Reminder: Demos at ECOOP'95.

As the coordinator of the demonstrations at ECOOP'95
in Aarhus, Denmark, I would like to remind everyone
that the deadline for submissions of demo proposals is
April 12, 1995.

The Aim of a Demo at Ecoop'95 is to demonstrate
innovative concepts, techniques or tools within
object-oriented software. Demonstrations will be
selected on the basis of technical merits, novelty
and relevance.

Please send proposals to me, using the address below.
The proposal must contain descriptions of the
qualities of the demo (technical merits, novelty and
relevance) as well as a description of the hardware
requirements.


Kurt Normark
Department of Mathematics and Computer Science
Institute for Electronic Systems
Aalborg University
Fredrik Bajers Vej 7,
DK-9220 Aalborg 
DENMARK

Phone: +45 98 158522
Fax: +45 98 158129
E-mail: normark@iesd.auc.dk



======================================================================= 104 ===
Date:    17 Mar 1995 11:24:35 -0500
From:    pjensen@csi.compuserve.com (Phil Jensen)
Subject: Re: stack checking

Well, here's one way stack checking could work on Intel boxen.  Keep
the limit value always at -4(ebp).  So the entry code would be (in MIT
"source, dest" order):

	mov	-4(ebp),eax
	push	ebp
	mov	esp,ebp
	push	eax
	cmp	eax,esp
	jb	stack-overflow

(or maybe you could arrange it so the test instruction caused overflow
on failure and use the one-byte "into" instruction to trap it)

Penalty: 4 instructions plus 2 memory references.



======================================================================= 105 ===
Date:    Fri, 17 Mar 1995 12:09:22 GMT
From:    olaf@logware.de (Olaf Wagner)
Subject: M3 rel. 3.5.1 and FreeBSD


As some people already have run into problems, I feel it is time
to post something about the state of M3 3.5.1 for FreeBSD.

First of all:

  The boot-archives on gatekeeper.dec.com and its mirrors dated
  14.02.1995 do NOT work! There is no way bo build a working
  system using these archives, if you don't have a running m3
  compiler and all the sources.

This is because of bugs in the Udir.i3 and Ustat.i3 interfaces
for FreeBSD 1.1 and FreeBSD 2.0. The old compiler obviously didn't
use the buggy definitions... The corrected interface definitions are
appended to the end of this article.

  The binary distribution on ftp.vlsi.polymtl.ca is okay, but it
  also contains the buggy interfaces. The compiler is a release
  3.3 compiler, and you cannot easily use it to compile the
  3.5.1 source archives. You will have to build intermediate
  libraries and compilers, and of course you will have to use
  the corrected system interfaces. I have done that, but I really
  cannot remember all the steps I took do get things up...

  You can use the 3.3 binary distribution for FreeBSD 1.1(.5)
  together with the 3.3 source archives. Unfortunately these
  sources have disappeared from gatekeeper.dec.com, but they
  still should be carried on some mirror sites. One site I know
  of is

     ftp.germany.eu.net:/pub/programming/languages/modula-3

  Probably there will be nearer sites for all those in the US.

The new release (3.5.1) does (principally) work on FreeBSD 1.1.5
and FreeBSD 2.0, but I think my home site is the only one in the
world at this moment where it is installed. There are still some
problems I would like to tackle before I prepare another binary
distribution. These include

 * multiple definition of _strtod when building standalone in
   the presence of shared libraries

 * a working debugger 

 * lots of relocation warnings when using shared libraries

I will do what I can, but it might take some time... Perhaps there
is anybody else who would like to share the work with me? ;-)

One last warning:

  The binary distribution on ftp.vlsi.polymtl.ca does NOT run on
  FreeBSD 2.0/2.1. This is due to changes in the size of off_t and
  some system interfaces. As of now, there is no easy way for 
  anybody out there to get a working M3 system on these versions
  of the OS that I know of. You will have to wait for a corrected
  boot-archive or for a binary distribution.

Perhaps I will prepare a minimal binary distribution regardless
of the problems stated above, so that some more people can get 
started...

Sorry for all the inconveniences, but it's really not that easy
to distribute packages that install and run smoothly.

Here are the source patches for the buggy interfaces:
----------------------------------------------------
First the interface definitions for FreeBSD 1.1.5:
--------
Udir.i3
--------
(* Copyright (C) 1990, Digital Equipment Corporation.         *)
(* All rights reserved.                                       *)
(* See the file COPYRIGHT for a full description.             *)

(*      modified on Sat Apr 16 by rrw1000@hermes.cam.ac.uk    *)
(*      modified on Mon Apr 13 10:04:46 PDT 1992 by muller    *)

(*      modified on Mon Jul  2 13:25:12 PDT 1990 by mjordan   *)
(*      modified on Sat Feb 18 23:43:23 MET 1995 by ow        *)

UNSAFE INTERFACE Udir;

(*** <dir.h> ***)

IMPORT Ctypes;

CONST
  MAXNAMLEN = 255;   (* maximum length of component of file path name *)
  MAXPATHLEN = 1024; (* maximum length of file path name *)

  (* file types *)
  DT_UNKNOWN =      0;
  DT_FIFO    =      1;
  DT_CHR     =      2;
  DT_DIR     =      4;
  DT_BLK     =      6;
  DT_REG     =      8;
  DT_LNK     =     10;
  DT_SOCK    =     12;

(*
 * The dirent structure defines the format of directory entries returned by
 * the getdirentries(2) system call.
 *
 * A directory entry has a struct dirent at the front of it, containing its
 * inode number, the length of the entry, and the length of the name
 * contained in the entry.  These are followed by the name padded to a 4
 * byte boundary with null bytes.  All names are guaranteed null terminated.
 * The maximum length of a name in a directory is MAXNAMLEN.
 *)
TYPE
  dirent = RECORD                    (* describes directory entry *)
    d_fileno:   Ctypes.long;           (* inode number of entry *)
    d_reclen:   Ctypes.unsigned_char;  (* record length in bytes *)
    d_type:     Ctypes.unsigned_char;  (* file types, see above *)
    d_namelen:  Ctypes.unsigned_short; (* name length in bytes *)
    d_name:     ARRAY [0..MAXNAMLEN] OF Ctypes.char;  (* name *)
  END;

  direct = dirent;                    (* backwards compatibility *)
  
  DIR = RECORD
    dd_fd:    Ctypes.int;  (* file descriptor associated with directory *)
    dd_loc:   Ctypes.long;  (* offset in current buffer *)
    dd_size:  Ctypes.long;  (* amount of data returned by getdirentries *)
    dd_buf:   UNTRACED REF Ctypes.char;  (* data buffer *)
    dd_len:   Ctypes.int;  (* size of data buffer *)
    dd_seek:  Ctypes.long;  (* magic cookie returned by getdirentries *)
    dd_ddloc: Ctypes.void_star;  (* Linked list of ddloc structs for telldir/se
ekdir *)
  END;

  DIR_star = UNTRACED REF DIR;

  direct_star = UNTRACED REF direct;

<*EXTERNAL*> PROCEDURE opendir (filename: Ctypes.char_star): DIR_star;
<*EXTERNAL*> PROCEDURE readdir (dirp: DIR_star): direct_star;
<*EXTERNAL*> PROCEDURE telldir (dirp: DIR_star): Ctypes.long;
<*EXTERNAL*> PROCEDURE seekdir (dirp: DIR_star; loc: Ctypes.long);
<*EXTERNAL*> PROCEDURE rewinddir (dirp: DIR_star);
<*EXTERNAL*> PROCEDURE closedir(dirp: DIR_star): Ctypes.int;
<*EXTERNAL*> PROCEDURE getdirentries(fd  : Ctypes.int;
                                     buf : UNTRACED REF Ctypes.char;
                                     nbytes : Ctypes.int;
                                     basep  : UNTRACED REF Ctypes.long): Ctypes
.int;

END Udir.

--------
Ustat.i3
--------
(* Copyright (C) 1989, Digital Equipment Corporation           *)
(* All rights reserved.                                        *)
(* See the file COPYRIGHT for a full description.              *)
(*                                                             *)
(* Last modified on Mon Jan 10 13:32:59 PST 1994 by kalsow     *)
(*      modified on Tue Mar 24 20:42:39 PST 1992 by muller     *)
(*      modified on Sat Feb 18 19:20:16 MET 1995 by ow         *)

INTERFACE Ustat;

FROM Ctypes IMPORT int, char_star;
FROM Utypes IMPORT u_short, u_long, dev_t, ino_t, off_t;
FROM Utypes IMPORT mode_t, nlink_t, uid_t, gid_t, time_t;

CONST
  S_IFMT  : u_short = 8_0170000;
  S_IFSOCK: u_short = 8_0140000;
  S_IFLNK : u_short = 8_0120000;
  S_IFREG : u_short = 8_0100000;
  S_IFPIPE: u_short = 8_0000000; (* no such constant in stat.h! *)
  S_IFBLK : u_short = 8_0060000;
  S_IFDIR : u_short = 8_0040000;
  S_IFCHR : u_short = 8_0020000;
  S_IFIFO : u_short = 8_0010000;
  S_IFPORT          = S_IFIFO;
  S_ISUID : u_short = 8_0004000;
  S_ISGID : u_short = 8_0002000;
  S_ISVTX : u_short = 8_0001000;
  S_IREAD : u_short = 8_0000400;
  S_IWRITE: u_short = 8_0000200;
  S_IEXEC : u_short = 8_0000100;
  S_GREAD : u_short = 8_0000040;
  S_GWRITE: u_short = 8_0000020;
  S_GEXEC : u_short = 8_0000010;
  S_OREAD : u_short = 8_0000004;
  S_OWRITE: u_short = 8_0000002;
  S_OEXEC : u_short = 8_0000001;

TYPE
  struct_stat = RECORD
    st_dev    : dev_t;
(*      pad1    : u_short; *)
    st_ino    : ino_t;
    st_mode   : mode_t;
    st_nlink  : nlink_t;
    st_uid    : uid_t;
    st_gid    : gid_t;
    st_rdev   : dev_t;
(*      pad2    : u_short; *)
    st_size   : off_t;
    st_atime  : time_t;
    st_spare1 : u_long;
    st_mtime  : time_t;
    st_spare2 : u_long;
    st_ctime  : time_t;
    st_spare3 : u_long;
    st_blksize: u_long;
    st_blocks : u_long;
    st_flags  : u_long;
    st_gen    : u_long;
  END;

  struct_stat_star = UNTRACED REF struct_stat;

<*EXTERNAL*> PROCEDURE stat (path: char_star; buf: struct_stat_star): int;

<*EXTERNAL*> PROCEDURE lstat (path: char_star; buf: struct_stat_star): int;

<*EXTERNAL*> PROCEDURE fstat (fd: int;  buf: struct_stat_star): int;

END Ustat.

-----------------------------------------------------
And now the interface definitions for FreeBSD 2.0/2.1
-----------------------------------------------------
Udir.i3
--------
(* Copyright (C) 1990, Digital Equipment Corporation.         *)
(* All rights reserved.                                       *)
(* See the file COPYRIGHT for a full description.             *)

(*      modified on Sat Apr 16 by rrw1000@hermes.cam.ac.uk    *)
(*      modified on Mon Apr 13 10:04:46 PDT 1992 by muller    *)

(*      modified on Mon Jul  2 13:25:12 PDT 1990 by mjordan   *)
(*      modified on Sat Feb 18 23:43:23 MET 1995 by ow        *)

UNSAFE INTERFACE Udir;

(*** <dir.h> ***)

IMPORT Ctypes;

CONST
  MAXNAMLEN = 255;   (* maximum length of component of file path name *)
  MAXPATHLEN = 1024; (* maximum length of file path name *)

  (* file types *)
  DT_UNKNOWN =      0;
  DT_FIFO    =      1;
  DT_CHR     =      2;
  DT_DIR     =      4;
  DT_BLK     =      6;
  DT_REG     =      8;
  DT_LNK     =     10;
  DT_SOCK    =     12;

(*
 * The dirent structure defines the format of directory entries returned by
 * the getdirentries(2) system call.
 *
 * A directory entry has a struct dirent at the front of it, containing its
 * inode number, the length of the entry, and the length of the name
 * contained in the entry.  These are followed by the name padded to a 4
 * byte boundary with null bytes.  All names are guaranteed null terminated.
 * The maximum length of a name in a directory is MAXNAMLEN.
 *)
TYPE
  dirent = RECORD                    (* describes directory entry *)
    d_fileno:   Ctypes.long;           (* inode number of entry *)
    d_reclen:   Ctypes.unsigned_char;  (* record length in bytes *)
    d_type:     Ctypes.unsigned_char;  (* file types, see above *)
    d_namelen:  Ctypes.unsigned_short; (* name length in bytes *)
    d_name:     ARRAY [0..MAXNAMLEN] OF Ctypes.char;  (* name *)
  END;

  direct = dirent;                    (* backwards compatibility *)
  
  DIR = RECORD
    dd_fd:    Ctypes.int; (* file descriptor associated with directory *)
    dd_loc:   Ctypes.long; (* offset in current buffer *)
    dd_size:  Ctypes.long; (* amount of data returned by getdirentries *)
    dd_buf:   UNTRACED REF Ctypes.char; (* data buffer *)
    dd_len:   Ctypes.int; (* size of data buffer *)
    dd_seek:  Ctypes.long (* magic cookie returned by getdirentries *);
    dd_rewind: Ctypes.long; (* magic cookie for rewinding *)
  END;

  DIR_star = UNTRACED REF DIR;

  direct_star = UNTRACED REF direct;

<*EXTERNAL*> PROCEDURE opendir (filename: Ctypes.char_star): DIR_star;
<*EXTERNAL*> PROCEDURE readdir (dirp: DIR_star): direct_star;
<*EXTERNAL*> PROCEDURE telldir (dirp: DIR_star): Ctypes.long;
<*EXTERNAL*> PROCEDURE seekdir (dirp: DIR_star; loc: Ctypes.long);
<*EXTERNAL*> PROCEDURE rewinddir (dirp: DIR_star);
<*EXTERNAL*> PROCEDURE closedir(dirp: DIR_star): Ctypes.int;
<*EXTERNAL*> PROCEDURE getdirentries(fd  : Ctypes.int;
                                     buf : UNTRACED REF Ctypes.char;
                                     nbytes : Ctypes.int;
                                     basep  : UNTRACED REF Ctypes.long): Ctypes
.int;

END Udir.

--------
Ustat.i3
--------
(* Copyright (C) 1989, Digital Equipment Corporation           *)
(* All rights reserved.                                        *)
(* See the file COPYRIGHT for a full description.              *)
(*                                                             *)
(*      modified on Tue Mar 24 20:42:39 PST 1992 by muller     *)

INTERFACE Ustat;

FROM Ctypes IMPORT int, char_star, long;
FROM Utypes IMPORT u_short, u_long, dev_t, ino_t, off_t;
FROM Utypes IMPORT mode_t, nlink_t, uid_t, gid_t, time_t, quad_t;

CONST
  S_IFMT  : u_short = 8_0170000;
  S_IFSOCK: u_short = 8_0140000;
  S_IFLNK : u_short = 8_0120000;
  S_IFREG : u_short = 8_0100000;
  S_IFPIPE: u_short = 8_0000000; (* no such constant in stat.h!*)
  S_IFBLK : u_short = 8_0060000;
  S_IFDIR : u_short = 8_0040000;
  S_IFCHR : u_short = 8_0020000;
  S_IFIFO : u_short = 8_0010000;
  S_IFPORT          = S_IFIFO;
  S_ISUID : u_short = 8_0004000;
  S_ISGID : u_short = 8_0002000;
  S_ISVTX : u_short = 8_0001000;
  S_IREAD : u_short = 8_0000400;
  S_IWRITE: u_short = 8_0000200;
  S_IEXEC : u_short = 8_0000100;
  S_GREAD : u_short = 8_0000040;
  S_GWRITE: u_short = 8_0000020;
  S_GEXEC : u_short = 8_0000010;
  S_OREAD : u_short = 8_0000004;
  S_OWRITE: u_short = 8_0000002;
  S_OEXEC : u_short = 8_0000001;

TYPE
  struct_stat = RECORD
    st_dev    : dev_t;
    st_ino    : ino_t;
    st_mode   : mode_t;
    st_nlink  : nlink_t;
    st_uid    : uid_t;
    st_gid    : gid_t;
    st_rdev   : dev_t;
    st_atime  : time_t;
    st_spare1 : u_long;
    st_mtime  : time_t;
    st_spare2 : u_long;
    st_ctime  : time_t;
    st_spare3 : u_long;
    st_size   : off_t;
    st_pad1   : long;
    st_blocks : quad_t;
    st_blksize: u_long;
    st_flags  : u_long;
    st_gen    : u_long;
    st_lspare : long;
    st_qspare1: quad_t;
    st_qspare2: quad_t;
  END;

  struct_stat_star = UNTRACED REF struct_stat;

<*EXTERNAL*> PROCEDURE stat (path: char_star; buf: struct_stat_star): int;

<*EXTERNAL*> PROCEDURE lstat (path: char_star; buf: struct_stat_star): int;

<*EXTERNAL*> PROCEDURE fstat (fd: int;  buf: struct_stat_star): int;

END Ustat.

-------------------------
All this is of course without any guarantee, and there may still
be numerous bugs. But it is working for me...

Olaf
-- 
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Olaf Wagner              at Logware GmbH       Schwedenstrasse 9     \
\ olaf@logware.de (work)                         13359 Berlin 65       \
\ wagner@luthien.in-berlin.de (private)          Germany / Deutschland \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

-- 
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Olaf Wagner              at Logware GmbH       Schwedenstrasse 9     \
\ olaf@logware.de (work)                         13359 Berlin 65       \
\ wagner@luthien.in-berlin.de (private)          Germany / Deutschland \


======================================================================= 106 ===
Date:    18 Mar 1995 02:12:49 GMT
From:    schaub@ponder.csci.unt.edu (Stephen Schaub)
Subject: Modula-3 info file available


I've created an info file for Modula-3 for the benefit of my students.  It
consists of a simplified language reference and a guide to using the SRC
implementation.  It's available in both .info and .html formats via 
anonymous ftp:
  replicant.csci.unt.edu/pub/m3info.tar.gz

The information is basically a boiled-down and reworked version of what's
on the Modula-3 home page, hopefully more accessible to the beginning
Modula-3 user.  Some language features are not discussed (generics, unsafe
features, several built-in operators) because my students don't need them.
If there's enough interest shown I'll consider adding them.

Errata reports and other comments are welcome.

Stephen Schaub
schaub@cs.unt.edu


======================================================================= 107 ===
Date:    Sat, 18 Mar 1995 21:53:13 GMT
From:    eric@telebit.com (Eric Smith)
Subject: Re: Stacks overflows

In article <ab8b66810102100436bd@[128.113.24.157]> douglm@rpi.edu (Mike Douglas
s) writes:
> Stack checking would involve a little extra overhead on program entry and
> thread switching but I feel the improvement in error reporting and
> reliability make it worthwhile.

To guard against the scenario you suggested where a function has a huge stack
frame, you need stack limit checking everywhere that stack frames are created
(i.e., in function prologs), not just on program entry and thread switching.

On an experimental port of the NetBlazer router to an AMD 29000 RISC processor
a few years ago, I added a limit check to the spill handler (which pushes
stack frames from the internal registers to main memory).  On the 29000 this
can be done by a single assert instruction, which takes only one cycle to
execute unless the assertion fails, in which case it traps.  This seemed like
a reasonably small performance hit since the spill handler isn't executed for
every function call.

On the 29K each process actually has two stacks.  The "other" stack is used
for any locals beyond the first 124 32-bit words.  To limit check this stack
required a change to the prolog which the compiler generates for functions
that use this stack to add an assert instruction.

The NetBlazer is unfortunately written in C rather than Modula 3, but the
same changes would have worked for Modula 3.  Other processors with assert
or trap-on-compare instructions would offer similar efficiency for the stack
checking.

Cheers,
Eric




======================================================================= 108 ===
Date:    Sat, 18 Mar 95 19:28:10 TZ
From:    bryant@microsoft.com (Bryan Tuttle)
Subject: re: stack checking

| > Guard pages are straight forward. Should be the same semantics on
| > every paged mmu. Hope you have OS support for using them.
|
|This whole discussion started because Mike Douglass felt that
|gaurd pages weren't sufficient. I don't know how frequently they
|fail in practice,

I didn't see this message.  Can someone forward to me?

| > If procedurecalls do not happen too frequently, a simple compare on
| > procedure entry (and maybe exit) should be fast enough. You 'll need
| > three to five loads and a compare. The stack bound can be kept in the
| > thread global dataspace, and you don't sacrifice a register.
| >
| > possible Algorithm:
| >
| > 	r1 := thread id
| > 	r2 := thread global dataspace [r1]
| > 	r3 := offset of stack bound [r2]
| > 	r4 := [r3]
| > 	compare r4 and sp
| >
| > Ok, three to five loads isn't nothing, but shouldn't hurt to much as a
| > generic implementation. If you want it faster, you 'll have to become
| > processor specific.
|
|On machines where you control the thread switching, and there is only
|one thread running at a time, you can do as you describe. On the NT
|implementation, which has kernel supported threads and multiprocessor
|support, I don't think you could as you described. I think you would
|need to stash the stack bound in thread private storage (or what ever it
|is called in NT), and make a call on procedure entrance to get it. I suspect
|that this would slow down procedure invocation quite a bit. Solaris also
|supports kernel level threads, and a call to get a value from thread private
|storage is a kernel call. You wouldn't want to make a kernel call on every
|procedure invocation.

Assuming M3 works like it did the last time I looked (ie: the C 
compiler ultimately generates the objects), this isn't an issue on NT.  
The compiler will add stack probes for functions who's local storage 
requirements exceeds the range of the guard page (4k on x86/Mips/PPC, 
8k on Alpha).  The only time this won't work is if you manipulate the 
stack pointer outside the bounds of the code generator w/o observing 
this rule.  In that case, you get what you deserve.  You still run the 
risk of exceeding the reserved stack size, but there are simple 
workarounds for that also (reserve a larger stack or add a handler for 
EXCEPTION_STACK_OVERFLOW to deal with it).  There's no need to make a 
kernel transition and for most cases, the probe isn't needed.

Bryan


======================================================================= 109 ===
Date:    19 Mar 1995 23:26:34 GMT
From:    ljw1004@thor.cam.ac.uk (L.J. Wischik)
Subject: Re: try-finally-except

In article <3jm8js$lf8@wolfe.wimsey.com>,
Taj Khattra <taj@vanbc.wimsey.com> wrote:
>Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead
>of a single TRY-FINALLY-EXCEPT statement ?
>Is the following case the main reason why ?
>    TRY
>        RAISE e;
>    FINALLY
>	IF (foobar) RAISE e;
>    EXCEPT
>	e => (* this may or may not be executed *)
>    END

I find that I myself more often use
TRY
  TRY
    something-or-other
  EXCEPT
    exceptions-that-are-normal-and-signify-the-end-of-something
  END
FINALLY
  just-in-case-there-were-unusual-exceptions;
  the tidy-up code for whatever iterators also goes here.
END;

So, perhaps Modula-3 has separate try-except and try-finally simply so 
both formations can be used.

--
Lucian


======================================================================= 110 ===
Date:    Mon, 20 Mar 1995 15:38:16 MET
From:    rudy@cs.rug.nl
Subject: Re: Language definition (overrides)


Reaction on "Re: Language definition (overrides)" of David Chase 

> Why?  What purpose does this serve? 

I can not tell you the full story of my implementation problems, because it
is to complicated to explain it on one page. So I will try to show you the
problems I have.

I am developing an image processing programming environment.  Images can be
of the type RGB (red, green and blue), complex, real grayscale, integer
grayscale, byte grayscale or black and white. To implement the appropriate
type conversions an object hierarchy between the image types is
helpful. This means a real grayscale image is a subtype of a complex image,
an integer grayscale image is a subtype of a real grayscale image and
soon. On the other hand complex, real and integer images have so much in
common, that it is possible to use generics to implement the major part of
them. So I obtain an object hierarchy like

           A(complex)
            /    \
           /      \
       B(complex) A(real)
                   /  \
                  /    \
               B(real) A(integer)
                         /
                        /
                     B(integer)

In the generic interfaces A and B an object type T (image) is defined.  The
objects in the A interfaces are objects which define Abstract Data Types and
they can not be allocated. The actual implementation of every objecttype is
done in the B interfaces and implementations. Every object has two methods
"put" and "get" to manipulate pixels. So A(real) has the methods:

   put(x:real);
   get():real;

In the implementation B(integer) I want to override for example the method
A(complex).get to obtain an complex pixel from an integer image. I can give
up the abstract "put" and "get" and replace them by something like
"putcomplex" and "getcomplex".  If I do so, I can not benifit from the
generic character of A. I have not been able to solve this problem
satisfactory with the current definition of Modula-3.

> How does
> this interact with the rest of the language? 
> Do you have a proposed implementation
> technique for this change to the language?

Handling qualified identifiers instead of not qualified identifiers is no
problem.  The compiler does this in case of expression evaluation,
references to existing types and soon.

The code generation is simple if all methods (hidden or not) are members of
the method suite. (See the suggested implementation in Harbison). In this
case the hidden pointer refering to a procedure must be changed. The method
suite is an array of pointers. The index can be computed by using the parent
type. Notice: as far as methods are member of both the child and the parent,
they have the same indices. 

> And, again, why?  Can you at least motivate
> this change?  Simply saying "I can't do this,
> but if I made this change to the language,
> then I could" is all well and good, but that
> holds for many things (complex numbers,
> unbounded integers, non-contiguous subarrays,
> distributed arrays on MPPs, first-class
> functions, method closures, continuations,
> inheritance among exception types, operator
> overloading, constrained generics ...).

In complex data structures using both generics and objects, you must be able
to override hidden methods. If you are only using objects, you can better
choose different names for your identifiers. The generics make this
impossible.

> I suspect that this also might make programs
> slightly less readable -- whenever I say
> "O.m" I know that the function from the method
> suite is being referred to.  

Which method suite (parent of child)? 

TYPE Parent OBJECT METHOD m():=P1 END;
     Child  OBJECT OVERRIDES m:=P2 END:

VAR O:Parent;

BEGIN
  O:=NEW(Child);
  O.m();
  O:=NEW(Parent);
  O.m();

Can you tell me to which procedure (P1 or P2) your "O.m" is refering to?

> Whenever I say
> "T.m" I know that the function statically
> bound to type T is being referred to (and it
> is my understanding that if T <: S, and T
> overrides method m visible in S, then T.m
> gets me the overriding method, even though
> the function name is not visible to me).

This correct and should remain so.

> I think this would also violate the reference
> manual rule, in that it would increase the
> size of the reference manual out of all
> proportion to its usefulness.

The same argument is valid for all qualified identifiers. We could also
import them using FROM X IMPORT Y. I can even state that now in the
reference manual you have to forbid explicitely qualified identifiers at
certain places.

> Sorry for the skeptical tone, but I'm
> skeptical.  My tendency is to resist changes
> to the language, even those there's quite a
> few changes I'd like to make myself
> (everything in the list above except
> continuations and operator overloading), and
> one that I even hope to propose when I get
> the time to write it up properly.

You must be very careful if you propose changes in the language definition. 
I only want to open the discussion about minor changes which improve the
language. In case of the READONLY proposal I have only had positive
reactions and reactions like "you can also do it by this way". I am waiting
for the first negative reaction!

> I have similar reservations about your
> "READONLY" proposal -- as near as I can tell,
> it has only local effects (i.e., does not
> assist in the building of large systems or
> the reuse of code). 

Debugging programs cost a lot of time. Often it costs more time to debug a
program then to write a program. If there is a simple and efficient
mechanism to detect bugs, you must use it. READONLY declarations are with
respect to the produced code equivalent to VAR declarations. But the author
also states, I have introduced this variable with the intension that nobody
should change its value. If the READONLY variable is changed, the bug will
be detected at compile time and not after a painful dubugging procedure.

> If this was of
> tremendous concern to you, I might lobby for
> a pragma, but this seems like a tiny frob. 

Sorry for the skeptical tone, but now I'm skeptical.
As a consequence it seems to be an improvement to the language to introduce

<* CONSTANT *> VAR x := 3;

instead of 

CONST x = 3;

> It provides only minor assistance in the
> generation of efficient code, since it's
> fairly easy for an optimizer to verify that a
> variable is only assigned to once.
 
Efficiency is not important and it has never been an argument to introduce
READONLY variables.  But it is unknown to the compiler that it was the
intention of the author that a variable is only assigned to once.

yours,

R. Moddemeijer





======================================================================= 111 ===
Date:    20 Mar 1995 15:44:47 -0600
From:    beede@gateway.sctc.com (Mike Beede)
Subject: Installing boot-SOLgnu

I've been trying to install the boot-SOLgnu package on a Solaris 2.3
system.  I had to modify a makefile to use gcc to build quake.  After
that, things work till we get to m3.  At that time, I get an error
from gcc saying it doesn't recognize "-compat-bsd" and a link error as
follows:

    gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o
    Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o
    Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o
    ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a
    ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a
    ../../m3core/SOLgnu/libm3core.a -lsocket -lnsl -lm
    gcc: unrecognized option `-compat-bsd'
    Undefined			first referenced
     symbol  			    in file
    getdtablesize
    ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o)
    getwd
    ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o)
    _longjmp
    ../../m3core/SOLgnu/libm3core.a(RTThreadC.o)
    _setjmp
    ../../m3core/SOLgnu/libm3core.a(RTThreadC.o)

Well, there is a "setjmp" and "longjmp" in the libraries, but none
with underscores.  getdtablesize and getwd are easier -- I could write
them from the man pages.  However, the idea I got was that the 3.5.1
Solaris versions had been checked.  If they have, I'm probably doing
something wrong.  I was suspicious when I saw it looking for the
/usr/ucb/cc compiler.  Is it supposed to build just with gcc?

On a related note, I got the Linux version installed after getting the
patched DLL tools.  That works fine (except for some packages that
don't compile -- I'm happy because I can compile and run).

Thanks for any suggestions,

	Mike

-- 
Mike Beede - (612) 628-2720
SCC
beede@sctc.com


======================================================================= 112 ===
Date:    17 Mar 1995 11:28:11 GMT
From:    kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: Stack overflows

In article <1995Mar16.123251.10988@lts.sel.alcatel.de>
buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409) writes:

|> Geoffrey Wyant - Sun Microsystems Labs BOS (gwyant@cloyd.East.Sun.COM) wrote
:
|> : Mike Douglass writes:
|> :  > >Mike Douglass writes:
|> :  > > > Stack overflows are a major concern ...
|> :  > >Geoff Wyant writes
|> :  > >I think the addition of stack boundary checking would be good, though 
I'm
|> :  > >concerned about the cost, especially in the face of multithreading. I 
don't
|> :  > >know if you can get the stack end in a cheap manner on entry to a proc
edure.
|> :  > 
|> :  > I cannot remember all of the details but stack checking involved having
 a
|> :  > stack descriptor which was accessible at a known location (global base
|> :  > actually) and checking the current stack pointer against the top of the
|> :  > stack.
|> :  > 
|> :  > The overhead is relatively low.

|> : Thinking about it some more, it seems like it should be relatively
|> : straightforward.  What you want is to have instantaneous access to the
|> : stack bounds (or at least how big the stack is allowed to grow). The
|> : easiest way to do this is to dedicate a register to it, which I suspect
|> : the code generator could do pretty easily. You wouldn't get stack
|> : checking when calling into a non-M3 routine, but at least you would have
|> : an indication of where it might have occurred. On a RISC machine, it is pr
obably
|> : reasonable to do this, but it might create register pressure on the x86 
|> : architecture. Does the x86 maintain stack bounds in a register anyway ?

|> yes, there is a special segment register for the stack. You can have
|> all necessary checking in hardware (It still takes time!)

This is actually a simplistic answer, although it is the solution I
generally used on 8086/80186.  Note that in this case, the stack bound
is a compile time constant (0), so you don't have to worry about
allocating a register for it.

Most of the implementations for 80386 up in protected mode use a flat
memory model.  In this case, stack checking is exactly the same as it
would be on most RISC machines.  Except that given the paucity of
registers, you really don't want to dedicate one for the bounds.


Does anyone have any thoughts on how to handle stack overflow in a
virtual memory environment?  Generally (Sparc, Motorola 68K,88K and
Intel 80386 up), we have the stack at the top growing down, and the
heap at the bottom growing up.  Given the address range of these
processors, there is no worry that they cross, and no point in
checking the stack against the top of heap.  At some point in time,
however, the process will core dump because there is no more virtual
memory available to allocate to the stack.  Does anyone know of a way
to convert this into an exception (or code that would somehow detect
the condition before it arrises, and generate an exceptions)?
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung




======================================================================= 113 ===
Date:    Wed, 22 Mar 95 12:37:30 GMT
From:    pda1@ukc.ac.uk (P.D.Austin)
Subject: Re: Most efficient way to handle strings


In my previous article I forgot to initialise the s variable so the VAR
line should be VAR s    : TEXT :=""; or VAR s      :=" ";.

Paul Austin



======================================================================= 114 ===
Date:    21 Mar 95 16:23:22
From:    nayeri@gte.com (Farshad Nayeri)
Subject: SRC M3 3.5.1 on AIX 3.1 with gcc 2.6.0


I am trying to compile SRC Modula-3 3.5.1 on AIX 3.1. I have gcc 2.6.0
for AIX, and /bin/cc but no other compiler that I know of (the
templates refer to bsdcc, which I don't have.) Has anyone had any
success in building the AIX port lately? I used the m3cc that uses gcc
2.6.3.

In my first attempt, I was able to build boot-IBMR2 and ship it, but
when I strated building m3core, the "m3" driver would core dump with a
nil dereference.

If you have done this, and have any pointers, please send them to me.
This is the first time I have touched an AIX machine.

I will be happy to make the binary release available on the net once I
get it working.

Thank you in advance, -- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 115 ===
Date:    Wed, 22 Mar 95 10:45:46 GMT
From:    pda1@ukc.ac.uk (P.D.Austin)
Subject: Most efficient way to handle strings

I was doing a simple program wich required the procedure below and I was
wondering if there was any difference in execution times between having
s:=s & " " or s:=" " & s or if it made any difference at all.

PROCEDURE spaces(num : CARDINAL) : TEXT =
VAR s                : TEXT;
BEGIN
  FOR loop := 1 TO num DO
    s:=s & " ";
  END;
END;

If anyone has an answer I would appriciate it, the speed is not really a major
issue but it would be nice to know.

thanks in advance

Paul Austin

"Improving the little things can also improve the bigger things..."


======================================================================= 116 ===
Date:    22 Mar 1995 13:24:34 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Problems building 3.5.1/boot-LINUX

In article <5hmz4B0EcsB@khms.westfalen.de>,
Kai Henningsen <kai@khms.westfalen.de> wrote:
>kai@khms.westfalen.de wrote on 11.03.95 in <5heGuV7EcsB@khms.westfalen.de>:
>
>> So I tried that one ... unfortunately, the results seem to me to be a lot
>> worse than what I had! I think my slightly-patched 2.16 is a much better
>> prospect than your massively-patched 2.11 ...
>
>I think I got it now ... mostly. I'm still not through compiling, though -
>this is one big monster.
>
>Bundles still seem to exhibit some problems. Most problems I found so far
>are the parsing code in the dll tools - it's mighty sloppy.

 There's a copy of some patched 2.16 DLL tools under :

http://www.cl.cam.ac.uk/m3doc/linux/m3.html

 In the 3.5.1 binary archive. They're just a quick hack I slammed together, but
they seem to work for compiling 3.5.1. Sorry I didn't post earlier - only just
had time to read this group thoroughly :-(((.

>
>I think after I'm through, I'll make my version of tools 2.16 available
>somewhere.
>

 :-))). Thanks ! :-). I, for one, would be grateful for some purposeful
patches (I just hacked Michel Dagenais' patches into 2.16).


Richard.
-- 
`There comes a time when you look into the mirror and you realise that what you
 
see is all that you will ever be. And then you accept it. Or you kill 
yourself. Or you stop looking in mirrors.'
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 117 ===
Date:    22 Mar 1995 22:09:16 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Most efficient way to handle strings

In article <9607@merlin.ukc.ac.uk>, pda1@ukc.ac.uk (P.D.Austin) writes:
> I was doing a simple program wich required the procedure below and I was
> wondering if there was any difference in execution times between having
> s:=s & " " or s:=" " & s or if it made any difference at all.
> 
> PROCEDURE spaces(num : CARDINAL) : TEXT =
> VAR s                : TEXT;
> BEGIN
>   FOR loop := 1 TO num DO
>     s:=s & " ";
>   END;
> END;

The order makes no difference.  The SRC Modula-3 runtime represents
TEXTs as flat arrays of char.  So, your loop will allocate "num" arrays,
each with a 12-byte fixed overhead.  The total space allocated will
be about num*(num+25)/2.  All but 1 array, 12+num bytes, will be reclaimed
by the garbage collector.  The program below allocates 2 arrays with
a total space of 24+2*num bytes, half of which is reclaimed.

  PROCEDURE spaces (num: CARDINAL) : TEXT =
    VAR a := NEW (REF ARRAY OF CHAR, num);
    BEGIN
      FOR i := 0 TO num-1 DO a[i] := ' '; END;
      RETURN Text.FromChars (a^);
    END spaces;

And finally, if there's a reasonable bound on "num", the following
allocates only the final result:

  CONST
    Blanks := "                                                        ";

  PROCEDURE spaces (num: CARDINAL) : TEXT =
    BEGIN
      <*ASSERT num <= Text.Length (Blanks)*>
      RETURN Text.Sub (Blanks, 0, num);
    END spaces;



  - Bill Kalsow


======================================================================= 118 ===
Date:    23 Mar 1995 01:55:19 GMT
From:    ljw1004@thor.cam.ac.uk (L.J. Wischik)
Subject: Proposal---network objects, impurity, and partial revelations

	    PROPOSAL FOR MODIFICATION TO NETWORK OBJECTS
          ------------------------------------------------

	Network objects are, at the moment, limited to being totally
pure, and to being fully revealed. I propose a small modification to
network objects, and to stubgen in particular, to permit partial
revelations and semi-impure objects to be used.

	I shall start with a concise statement of my proposal. Next, I
shall give a brief illustration of what it means, in a more readable
form. After this, I shall give a practical illustration of where
current network objects are inadequate and of how my solution would
help. A few notes and general observations of the impact and
significance of these changes comes next, and finally I shall
conclude.



1. PROPOSAL

That a new command be added for m3makefiles, viz. `netobjp' (the `p'
is for `partial').

It takes three parameters:
netobjp(interface_with_type,object_name,interface_with_revelations)

The `interface_with_type' is the interface in which the type of the
object was first declared. The `interface_with_revelations' is some
interface, in which as many revelations as are wanted are
revealed. Only the methods present in these revelations will be
stubgen-ed: all the rest will be left as local methods. It is
required that what appears of the object through these partial
revelations is a pure object (ie. with no fields).

It is a compile-time error to try to netobj one object with more than one
`netobjp'.

Exporting and importing work just as they do now.

Suppose you invoke a method that was revealed to the stubgen. This
would cause a network call, as normal.

Suppose you invoke a method that was not revealed to stubgen. The
network object type would not have overwritten this method; so, the
method invocation would be handled locally and normally.



2. ILLUSTRATION

Suppose we have this object hierarchy:

            +--> C --> D
   A --> B -+
            +--> E --> F

and suppose further that the revelations were split into interfaces,
and that there happened to be an interface X in which was visible
public methods for A and C, and an interface Y in which was visible A,
E and F.
If we did
netobjp(.., D, X) and
netobjp(.., F, Y), then we would have a hierarchy that, including the
objects generated by stubgen, would look like this:

                           /A',C'
           +--> C --> D --+ 
  A --> B -+                /E',F'
           +--> E --> F ---+

where /A',C' is an object which has stub-overrides for all the methods
declared in A and in C.

If the user imported the /E',F' object, then method invocations for
methods in A and B would be done locally, and those for methods in E
and F would be done remotely.
Hopefully, somewhere between A,B and E,F, would be implementations for
the methods in A and B, as well as whatever fields were needed for
these. The fields would initially be set to the state in which they
would be set if we had called NEW(F). It is up to the user to
initialise fields to appropriate values after a NetObj.Import call.



3. EXAMPLE OF USE

	Consider a penumbra-object. (The penumbra is the region of
partial-shadow, which surrounds the full shadow, or umbra, which is
cast when an object is illuminated by an extended light source such as
a fluorescent strip-light). This penumbra is an item in a special sort of
client-server database, in which each client maintains a penumbra and
the server maintains a central version. Some methods of the penumbra,
such as reads (which occur frequently) are handled by the penumbra and
it's data fields itself; other methods are farmed off to the
server. Also, there is some property that is specific to each client,
and is stored in the 'local' part of the object.
So, things look like this:

     Object, with two aspects.
         _______________
        / //// | \\\\\\ \    
       | ///// | \\\\\\\ |  ------->
       | local | network |  -------> Some calls are farmed off
       | \\\\\ | /////// |  -------> to the server.
        \_\\\\_|_//////_/    
             
          ^    ^    ^
          |    |    |
          |    |    |
     method invocations come to the object. The user of the object
     may or may not be aware of which calls go where.
     The local calls are handled internally.

The hierarchy to represent this object could be this:
NetObj.T --> network-interface --> local-interface -->local-implement. --> T

The problem (under the existing scheme) comes when we want to descend
new types from this one. Suppose the object I have described is a
'Cell', and I wish to descend a 'path' from it:

      <Cell.Local-----Cell.Network>
                  |
                  v
      <Path.Local-----Path.Network>

The hierarchy now looks like this:

NetObj.T --> Cell.Local --> Cell.Network --> Cell.Impl. --> Cell.T
     --> Path.Local --> Path.Network --> Path.Impl. --> Path.T
The Path.Network here cannot be made into a network object under the
existing scheme, because Cell.Impl. (the implementation for Cell,
along with various fields) comes above it.

But, under my scheme, we could simply declare Path.Network in an
interface that happened also to import Cell.Network. The
network-object that was created, would then include stubs for
Path.Network and for Cell.Network, but calls to Path.Local or to
Cell.Local would still be handled locally.



4. NOTES

	I am not trying to introduce multiple-inheritance by the back
door. The narrowing procedure currently used still works with no
modifications. (Exports work by finding the closest ancestor that has
been stubgened, and exporting this; Imports work by examining the
ancestry of the imported object and finding the narrowest match).

	The mechanism I have proposed is not overly
restrictive. Indeed, it can be seen that the current regime is a
subcase of my proposal. I suspect too that it is not overly generous;
but I do not know how to justify this assertion.

	The only major change required would be to stubgen. It would
have to be made to search only the specified interfaces, and to work
with partial revelations. I do not expect this to be difficult, but
find it hard to tell.

	In the example I gave above, a solution using current network
objects could be found; but it would involve maintaining three
parallel object hierarchies and would involve many, many method
duplications.



5. CONCLUSION

	This proposal has come from a very real limitation up against
which I have come. I do feel that network objects are castrated by
their current limitations, which seem unnecessarily restrictive. The
changes I have suggested do seem sufficiently minor and useful that
their implementation would be worthwhile.

	If my proposal was born of a flawed understanding of the
current capabilities of network objects, then please forgive me for
wasting time.

	If there are flaws or inconsistencies, or if I have
misestimated the effect of these changes or their difficulty, then
please do tell me.

	If not, and if it is felt that these changes would be
worthwhile, then please do tell me as well. (And---would anyone care
to implement them?)


--
Lucian Wischik, Queens' College, U of Cambridge. ljw1004@cam.ac.uk
	


======================================================================= 119 ===
Date:    23 Mar 1995 17:46:22 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: SRC Modula-3 release 3.5.2

Release 3.5.2 of SRC Modula-3 is now on gatekeeper.

Here are the differences that I can remember:

   + m3browser contains the enhancements contributed by Peter Klein
   + the FreeBsd bootstrap uses the new Ustat and Udir interfaces
   + the HPPA bootstrap was built with m3cc-2.5.7
   + m3zume is shipped properly
   + miscellaneous bug fixes

We still don't have the HPPA platform working with the backend based
on gcc 2.6.3.  You must use the m3cc-2.5.7.tar.gz archive with HPPA.

  - Bill Kalsow


======================================================================= 120 ===
Date:    23 Mar 1995 12:05:03 GMT
From:    rga1002@cus.cam.ac.uk (R.G. Anteleme)
Subject: NetObj.Export question

Hi 

I'm trying to NetObj.Export a method and I get the following error messages:

  Binding TCP socket: Address already in use
  Error: 
  Fatal server error!
  Error: Cannot establish any listening socketsError: 
  Abort (core dumped)

Any ideas as to what's going on?!

Thanks in advance for any suggestions.


======================================================================= 121 ===
Date:    23 Mar 1995 22:26:22 GMT
From:    <brown@src.dec.com>
Subject: Re: SRC Modula-3 release 3.5.2

> Release 3.5.2 of SRC Modula-3 is now on gatekeeper.
> 
> Here are the differences that I can remember:
> 
>    + m3browser contains the enhancements contributed by Peter Klein
>    + the FreeBsd bootstrap uses the new Ustat and Udir interfaces
>    + the HPPA bootstrap was built with m3cc-2.5.7
>    + m3zume is shipped properly
>    + miscellaneous bug fixes
> 
> We still don't have the HPPA platform working with the backend based
> on gcc 2.6.3.  You must use the m3cc-2.5.7.tar.gz archive with HPPA.

What kind of errors are to be expected if it is compiled with gcc 2.6.3?  Also,
what is m3cc for and why does it include a version of gcc?

I have managed to compile modula 3 for HPPA using gcc 2.6.3.  Some included
programs ran although the X stuff was screwed up, some ran fine, and some have
run-time errors possibly due to hp keyboard or character set stuff and other
things.  Are these normal symptoms of using gcc 2.6.3 or are they unrelated?

Perhaps someone can answer a few of these.

Thanks,

Andrew


-- 
Andrew Brown
Class of '97
System Administrator
Swarthmore College Engineering



======================================================================= 122 ===
Date:    Thu, 23 Mar 1995 03:17:06 GMT
From:    ras@dynastar.princeton.edu (Robert Shillner)
Subject: m3gdb crashing problem

I'm using SRC Modula-3 v3.3 on an alpha running OSF/1.  m3gdb crashes
with a segmentation fault almost every time the program I'm debugging
stops, whether from a breakpoint, segfault, CTRL-C or whatever.  I
have used m3gdb with v3.3 at SRC with only the usual problems; the
current situation is completely different.  The smallest example for
which the problem exists is "hello, world".

Has anyone seen this problem before?  Any ideas on how to fix it?
-- 
***********************************************************************  (___)
* Rob Shillner                  Princeton University Computer Science *  |===|
* ras@cs.princeton.edu              http://www.cs.princeton.edu/~ras/ *   \_/
*********************************************************************** RoboCow


======================================================================= 123 ===
Date:    23 Mar 1995 23:22:21 GMT
From:    montjoy@thor.ece.uc.edu (Robert Montjoy)
Subject: Re: Installing boot-SOLgnu

You need a newer version of gcc that understands -compat-bsd flag.
Than all will work. 

Now why Modula-3 needs to be linked with the Berkeley libraries at
all is the question. It should not need them to work. A purely
native port is possible.


In article <3kkt0f$chv@gateway.sctc.com>,
Mike Beede <beede@gateway.sctc.com> wrote:
>I've been trying to install the boot-SOLgnu package on a Solaris 2.3
>system.  I had to modify a makefile to use gcc to build quake.  After
>that, things work till we get to m3.  At that time, I get an error
>from gcc saying it doesn't recognize "-compat-bsd" and a link error as
>follows:
>
>    gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o
>    Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o
>    Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o
>    ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a
>    ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a
>    ../../m3core/SOLgnu/libm3core.a -lsocket -lnsl -lm
>    gcc: unrecognized option `-compat-bsd'
>    Undefined			first referenced
>     symbol  			    in file
>    getdtablesize
>    ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o)
>    getwd
>    ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o)
>    _longjmp
>    ../../m3core/SOLgnu/libm3core.a(RTThreadC.o)
>    _setjmp
>    ../../m3core/SOLgnu/libm3core.a(RTThreadC.o)
>
>Well, there is a "setjmp" and "longjmp" in the libraries, but none
>with underscores.  getdtablesize and getwd are easier -- I could write
>them from the man pages.  However, the idea I got was that the 3.5.1
>Solaris versions had been checked.  If they have, I'm probably doing
>something wrong.  I was suspicious when I saw it looking for the
>/usr/ucb/cc compiler.  Is it supposed to build just with gcc?
>
>On a related note, I got the Linux version installed after getting the
>patched DLL tools.  That works fine (except for some packages that
>don't compile -- I'm happy because I can compile and run).
>
>Thanks for any suggestions,
>
>	Mike
>
>-- 
>Mike Beede - (612) 628-2720
>SCC
>beede@sctc.com


-- 
Rob Montjoy  		     - Systems Engineer
University of Cincinnati     - Electrical/Computer Engineering/Computer Science
 
E-Mail: Rob.Montjoy@UC.EDU   - Personal or Other E-Mail
	ecehelp@ece.uc.edu   - For Network and UNIX Workstation Support.


======================================================================= 124 ===
Date:    23 Mar 1995 23:21:08 GMT
From:    fraser@wingham.com (Fraser Campbell)
Subject: Should I learn Modula-3? How?

I want to learn how to program.  I have dabbled in C and understand the
basics but have never done anything very significant.  What I am wondering
is whether Modula-3 is worth learning ... that article in Linux Journal made
it sound very good!

Any advice on how to learn modula-3 would be appreciated - books, text
files, newsgroups, etc.  Also, I need some help with basic (language
independant) program development.  I have a couple of apps in mind and just
need some advice to get me of the ground ...  then I plan to learn as I go
along (probably not the best way ;).  I realize that eventually C is a
language I must become comfortable with especially using UNIX ... but
Modula-3 sounds intriguing!

So if you know of any good books (or whatever) outlining basic programming
concepts and perhaps on Modula-3 please share your knowledge.  Thanks ...


======================================================================= 125 ===
Date:    24 Mar 1995 00:07:16 -0600
From:    sysop@kitana.org (JL Gomez)
Subject: Re: Should I learn Modula-3? How?

I suggest you get the FAQ.  It will list several publications.

And don't forget the WWW M3 home page too. :)
-- 
sysop@kitana.org


======================================================================= 126 ===
Date:    23 Mar 1995 22:59:59 GMT
From:    chase@centerline.com (David Chase)
Subject: Re: Language definition (overrides)

rudy@cs.rug.nl writes:

[in support of a language change]

> In complex data structures using both generics and objects, you must be able
> to override hidden methods. If you are only using objects, you can better
> choose different names for your identifiers. The generics make this
> impossible.

This begins to make more sense.  However, could you possibly
expand your generic interface slightly to get the same effect?
That is, in your generic, could you also make use of a procedure
(not a method) that would accomplish what your change to overrides
might do?  (I'm not entirely certain of this, I'm just asking.)

What I gather (your original post has vanished, sorry) is that for
objects of a type T, you wish to dispatch using the method suite,
except in those cases where the variable or expression is also
of type T, in which case you wish to use a static binding that
can be found in the declaration of a type T.

Couldn't you do this with a procedure, along the lines of

  GENERIC INTERFACE Thing(Elem);

   (* All the derivation stuff is omitted. *)

   (* Expect 
      PROCEDURE Elem.static_method(x:Elem.T):Elem.U
    *)

That is, this procedure "static_method" is something that
the generic expects "Elem" to have defined.  In those
cases where you want the non-dispatched binding (where,
already, you have an object of type Elem.T), you call
static_method. 

> > I think this would also violate the reference
> > manual rule, in that it would increase the
> > size of the reference manual out of all
> > proportion to its usefulness.

> The same argument is valid for all qualified identifiers. We could also
> import them using FROM X IMPORT Y. ...

Ah, but that is very often useful.  So far, you've shown us
one difficult-to-understand example.

> You must be very careful if you propose changes in the language definition. 
> I only want to open the discussion about minor changes which improve the
> language. In case of the READONLY proposal I have only had positive
> reactions and reactions like "you can also do it by this way". I am waiting
> for the first negative reaction!

Ok, call this a negative reaction.  Any change that is
not a whole-lot-better than no change is a Bad Idea, simply
because it is change.  Bad because people have to
(perhaps) whack on their compilers, bad bacause they
might have to whack on their existing code (seems unlikely
in this case, though) bad because language implementations
get out of sync.

> > I have similar reservations about your
> > "READONLY" proposal -- as near as I can tell,
> > it has only local effects (i.e., does not
> > assist in the building of large systems or
> > the reuse of code). 

> Debugging programs cost a lot of time. Often it costs more time to debug a
> program then to write a program. If there is a simple and efficient
> mechanism to detect bugs, you must use it. READONLY declarations are with
> respect to the produced code equivalent to VAR declarations. But the author
> also states, I have introduced this variable with the intension that nobody
> should change its value. If the READONLY variable is changed, the bug will
> be detected at compile time and not after a painful dubugging procedure.

In the case of parameters, this documents something at an
interface.  It helps specify the behavior of an interface.  For
WITH-READONLY, as near as I can tell, you are only specifying
behavior within a single source file.  This is a benefit, but a
minor one.  A comment serves nearly as well.  The compiler can
whine at you if you pass one of these as a VAR parameter, but it's
unlikely to do more than that.  In theory, it could somehow impose
checks on modifications to the referenced data across procedure
boundaries, but this is not something I expect to see happen often.
In which case, let it be a pragma.  (Have I misunderstood
something here?  It looks to me like your READONLY proposal
will only flag errors of the form:

  READONLY foo := <initialization>;
  ...
  foo := <another value>; (* This will be rejected. *)
  ...
  proc_with_var_param(foo); (* This will generate a warning. *)
  ...
  WITH bar = foo DO     (* This will perhaps generate a warning *)
    bar := <some value> (* or else perhaps this will. *)
  END

Is there something else that you expect will be detected?

yours,

David Chase


======================================================================= 127 ===
Date:    23 Mar 1995 19:03:06 -0500
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: Re: SRC Modula-3 release 3.5.2

>>>>> On 23 Mar 1995 22:26:22 GMT, Andrew Brown <brown> said:

>> Release 3.5.2 of SRC Modula-3 is now on gatekeeper.
>> 
>> Here are the differences that I can remember:
>> 
>> + m3browser contains the enhancements contributed by Peter Klein
>> + the FreeBsd bootstrap uses the new Ustat and Udir interfaces
>> + the HPPA bootstrap was built with m3cc-2.5.7
>> + m3zume is shipped properly
>> + miscellaneous bug fixes
>> 
>> We still don't have the HPPA platform working with the backend based
>> on gcc 2.6.3.  You must use the m3cc-2.5.7.tar.gz archive with HPPA.

Andrew> What kind of errors are to be expected if it is compiled with
Andrew> gcc 2.6.3?  Also, what is m3cc for and why does it include a
Andrew> version of gcc?

m3cc is the code-generation backend for the compiler, which is based
on gcc.  It is this that must be based on gcc 2.5.7.  I tried using
one based on 2.6.3 and one based on the 2.6.3-u6 release for the HPPA
from utah, both of which failed ... the generated modula3 code does
not work.

It's not important which version of gcc you use to actually _build_ the
compiler.  (well, that may not be true, but I used the latest gcc
without problem.)


======================================================================= 128 ===
Date:    24 Mar 1995 01:16:51 GMT
From:    joringer@cs.sunysb.edu (Jonathan Oringer)
Subject: HP/UX vs LINUX


	How come the Interfaces in the HP/UX distrib are different
from the Interfaces in the LINUX distributions?  LINUX does not
have Filename.i3 or FileStream.i3.  Instead it has WrFile.i3 and
RdFile.i3.  Are they different versions?

	Is there a way to make them completely compatable?

please respond via email: joringer@mathlab.sunysb.edu

	Thanks in advance!

-Jon Oringer



======================================================================= 129 ===
Date:    24 Mar 1995 16:34:21 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: HP/UX vs LINUX

In article <3kt6i3$h1e@adam.cc.sunysb.edu>, joringer@cs.sunysb.edu (Jonathan Or
inger) writes:
> 	How come the Interfaces in the HP/UX distrib are different
> from the Interfaces in the LINUX distributions?  LINUX does not
> have Filename.i3 or FileStream.i3.  Instead it has WrFile.i3 and
> RdFile.i3.  Are they different versions?

Filename and FileStream are quite old.  FileWr and FileRd are
the current interfaces.

> 	Is there a way to make them completely compatable?

Yes, upgrade your HP/UX version to something more recent.

 - Bill


======================================================================= 130 ===
Date:    24 Mar 95 12:41:27 EST
From:    PJENSEN@CSI.compuserve.com
Subject: NT binary?

I was disappointed to find that the "bootstrap" compile process for NT involved
running "cl".  I strenuously avoid giving money to Bill G wherever possible
(I have to use NT for work - left to myself I'd be Linux all the way).  Does
anyone have an NT binary available for ftp?

Thanks.

Phil Jensen :: pjensen@csi.compuserve.com



======================================================================= 131 ===
Date:    Fri, 24 Mar 1995 10:28:17 GMT
From:    gildeam@dcs.glasgow.ac.uk (Martin Gildea, MG,,,,JUN95, )
Subject: The Zeus Animation Package

Zeus but I am having a few problems with it.

On all of the sample animations I have managed to get my hands on, the user ent
ers

input by sliding a bar up and down to a certain value and then the program gene
rates

the appropriate amount of random numbers. What I wish to do is to allow the use
r

to enter their own sequence of numbers, but I don't have any idea how to modify

the Zeus input panel to allow the user to do this.

Any help would be appreciated.

Cheers
Martin.




======================================================================= 132 ===
Date:    Fri, 24 Mar 95 12:36:32 -0800
From:    mhb@pa.dec.com ("Marc H. Brown")
Subject: Re: The Zeus Animation Package


Martin,

Zeus is domain-independent, and is not involved in providing "input" 
to any of the algorithms. Each algorithm specifies some way to get 
input, usually using a FormsVBT expression, and then interprets the 
data provided int he FormsVBT expression in some way. 

Which animation ("Session" name) are you interested in? I'll show 
you how to change that algorthm's input panel.

Also, I just added a link on the Zeus home page 

    http://www.research.digital.com/SRC/zeus/home.html
  
to a Zeus tutorial that Marc Najork (with some help from me) did. 
It isn't complete, but it gives a good picture of what's happening 
and it's very readable. 

 


======================================================================= 133 ===
Date:    Sun, 26 Mar 1995 12:56:28 -0500
From:    Jonathan Oringer <joringer@CS.SunySB.EDU>
Subject: Re: HP/UX vs LINUX

In article <3kusad$j00@src-news.pa.dec.com> you wrote:
: In article <3kt6i3$h1e@adam.cc.sunysb.edu>, joringer@cs.sunysb.edu (Jonathan 
Oringer) writes:
: > 	How come the Interfaces in the HP/UX distrib are different
: > from the Interfaces in the LINUX distributions?  LINUX does not
: > have Filename.i3 or FileStream.i3.  Instead it has WrFile.i3 and
: > RdFile.i3.  Are they different versions?

: Filename and FileStream are quite old.  FileWr and FileRd are
: the current interfaces.

: > 	Is there a way to make them completely compatable?

: Yes, upgrade your HP/UX version to something more recent.

:  - Bill

	Is there any way I can get an old version of Modula-3 for
my linux system?  I am not root at my school and I cannot just 
update their version even though it would be helpful for everybody :)

-Jon Oringer



======================================================================= 134 ===
Date:    26 Mar 1995 20:40:00 +0100
From:    kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Problems building 3.5.1/boot-LINUX

rrw1000@cus.cam.ac.uk wrote on 22.03.95 in <3kp8ei$662@lyra.csx.cam.ac.uk>:

> In article <5hmz4B0EcsB@khms.westfalen.de>,
> Kai Henningsen <kai@khms.westfalen.de> wrote:

> >I think after I'm through, I'll make my version of tools 2.16 available
> >somewhere.

Well, I am sort-of through. Made some more changes, including some to the  
M3 stuff (for example, no getdirentries() on Linux - trivially fixed by  
calling libm3 instead of re-inventing the wheel).

I've still to find some time to diff and package the patches.

>  :-))). Thanks ! :-). I, for one, would be grateful for some purposeful
> patches (I just hacked Michel Dagenais' patches into 2.16).

Well, I'm not so certain mine are that much "purposeful" :-)

In the main part, it's make-all-the-arrays-a-lot-larger and correct-the- 
identifier-character-set.


Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}

## CrossPoint v3.02 ##


======================================================================= 135 ===
Date:    Mon, 27 Mar 95 09:31:23 -0800
From:    najork@pa.dec.com (Marc Najork)
Subject: Re: NT binary?


> I was disappointed to find that the "bootstrap" compile process for NT involv
ed
> running "cl".  I strenuously avoid giving money to Bill G wherever possible
> (I have to use NT for work - left to myself I'd be Linux all the way).  Does
> anyone have an NT binary available for ftp?
> 
> Thanks.
> 
> Phil Jensen :: pjensen@csi.compuserve.com

Phil,

unfortunately, "cl", "link", and "lib" are needed for every compile, 
not only for bootstrapping the compiler.  This means that you have 
to buy Microsoft Visual C++ 2.0, or another 32-bit C compiler, linker, 
and librarian.

We would like to make the Modula-3 compiler completely stand-alone, 
but given our resource-constraints, it is not clear if we will actually 
be able to do so.

-- Marc


----- Marc Najork ---- najork@src.dec.com ---- (415) 853-2153 -----
DEC Systems Research Center, 130 Lytton Avenue, Palo Alto, CA 94301
-------- http://www.research.digital.com/SRC/people/najork --------


======================================================================= 136 ===
Date:    27 Mar 1995 22:08:18 GMT
From:    gabrius@riker.cig.mot.com (David M. Gabrius)
Subject: Sample animation source w/Trestle?

I'm working on an application (for a model railroad) that's going to require
moving graphics.  Is there any source code available that shows how to do
moving graphics under Trestle?  

(One of the applications is sort of dispatcher's board, and I'm going to want
to show the trains as they're moving around, states of switches, etc.)

Thanks!
-- 
 David Gabrius -- Motorola Cellular \\ gabrius@cig.mot.com \\ 708-632-5944
 Software Engineer \\"You miss too much these days if you stop to think" -U2 
 "And you can find/Your own way out/You can build/And I can will..." -U2 
 "Some days take less but most days take more" \\ #include<stddisclaimer.h>


======================================================================= 137 ===
Date:    Sun, 26 Mar 1995 20:42:57 GMT
From:    lalbers@hrz.uni-bielefeld.de ( Leif Albers)
Subject: Q: Command-line Parameters, how?

Hello out there,
 can anyone tell me how to reach command line parameters my
(own) program was called with?

Thanks in advance...

Leif



======================================================================= 138 ===
Date:    Tue, 28 Mar 95 09:02:41 GMT
From:    I.C.A.Buckner@ukc.ac.uk (Ian Buckner)
Subject: Calling Modula3 from C

Hi, can anyone out there help me?

If I have some module that declares some operation such as (excuse
the over-used names):

Foo.Bar()

How can this be called from a C program?

I have tried using a header file defining:

extern void Foo__Bar();

then #including as usual but the linker comes back with an unknown
symbol error; I've even dumped out the symbols in the object files
but still can't get anywhere.

Any help gratefully received.

Ian 
University of Kent
Canterbury, England

p.s. I don't suppose there are any Distributed Systems people out there 
who have looked at the Modula3 ANSAware implementation?


======================================================================= 139 ===
Date:    28 Mar 1995 01:32:47 GMT
From:    dsims@don.ece.uc.edu (David Sims (Hensgen))
Subject: Error instantiating a generic with a generic parameter :-(

I'm trying to use the Table and SortedTable generic interfaces without
much success.  I'm trying to create a SortedTable, one of whose
generic parameters is a Table.  I'd appreciate a pointer on what I'm
doing wrong.

First, I instantiate a generic Table like so:


(* this is in the file 'MyTable.i3' *)
INTERFACE MyTable = Table(Integer, Integer)
END MyTable.


(* this is in the file 'MyTable.m3' *)
MODULE MyTable = Table(Integer, Integer)
END Table_Database.



** All of this compiles just fine.  Next, I try to instantiate a
** generic SortedTable like so:


(* this is in the file 'MySortedTable.i3' *)
INTERFACE MySortedTable = SortedTable(Integer, MyTable)
END MySortedTable.

** This one compiles fine too.


(* this is in the file 'MySortedTable.m3' *)
MODULE MySortedTable = SortedTable(Integer, MyTable)
END MySortedTable.


** I get a compilation error on this one.  It says:

line 1: number of actuals doesn't match number of generic formals



*** So ... I can't figure this one out.  What am I doing wrong?

thanks for the help,
dave sims

-- 
Dave Sims                     I'm an anarchist, and I vote.
sims@usa.acsys.com            Don't tread on me.
http://www.acsys.com/~sims/   Finger or WWW for PGP key.
KC5JKN


======================================================================= 140 ===
Date:    28 Mar 1995 10:06:22 GMT
From:    pr@cl.cam.ac.uk (Peter Robinson)
Subject: Re: Calling Modula3 from C

Calling Modula-3 from C is tricky because M3 has a more elaborate run-time
environment.  The simplest solution is to make the main program M3 and then
call C via EXTERNAL routines.  Calling back into M3 is then relatively
straightforward.

Here's an example.  It calls the C code to lodge the identity of the M3
procedure to be called back which avoids having to know the actual name used
by the linker.

First a little M3 module to be called from C:

(* M3code.i3 *)

INTERFACE M3code;

IMPORT Ctypes;

PROCEDURE put (a: Ctypes.char_star);

END M3code.

(* M3code.m3 *)

UNSAFE MODULE M3code;

IMPORT Ctypes, IO, M3toC;

PROCEDURE put (a: Ctypes.char_star) =
  BEGIN
    IO.Put (M3toC.StoT (a) & "\n");
  END put;

BEGIN
END M3code.

Now a C "module" to be called from M3:

(* Ccode.i3 *)

<*EXTERNAL*> INTERFACE Ccode;

IMPORT Ctypes;

PROCEDURE set (p: PROCEDURE (a: Ctypes.char_star));

PROCEDURE act (a: Ctypes.char_star);

END Ccode.

/* Ccode.c */

typedef void (*PROC)();

static PROC action;

void set (p)
  PROC p;
  {
    action = p;
  }

void act (a)
  char *a;
  {   
    action (a);
  };

Finally, a main program:

(* Main.m3 *)

UNSAFE MODULE Main;

IMPORT Ccode, M3code, M3toC;

BEGIN
  Ccode.set (M3code.put);
  Ccode.act (M3toC.TtoS ("Hello world"));

END Main.

Tie it all together with an m3makefile:

m3_option("-commands")

import(libm3)

interface ("Ccode")
c_source ("Ccode")

module ("M3code")

implementation("Main")

program("mixed")

Build and run.

> p.s. I don't suppose there are any Distributed Systems people out there 
> who have looked at the Modula3 ANSAware implementation?

Sure, it was written here.  Mind you, we tend to use network objects now.

-- 
  Peter Robinson                                 Telephone: +44 1223 334637
  University of Cambridge Computer Laboratory    Facsimile: +44 1223 334678
  New Museums Site   Pembroke Street              Telex: via 81240 CAMSPL-G
  Cambridge  CB2 3QG  England                       E-mail: pr@cl.cam.ac.uk


======================================================================= 141 ===
Date:    28 Mar 95 09:07:52
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Q: Command-line Parameters, how?

In article <D62EvL.1Dt@hermes.hrz.uni-bielefeld.de> lalbers@hrz.uni-bielefeld.d
e ( Leif Albers) writes:

   Hello out there,
    can anyone tell me how to reach command line parameters my
   (own) program was called with?

Look at the Params.i3 interface.
--

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



======================================================================= 142 ===
Date:    28 Mar 95 09:06:01
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Sample animation source w/Trestle?


   I'm working on an application (for a model railroad) that's going to require
   moving graphics.  Is there any source code available that shows how to do
   moving graphics under Trestle?  

GraphVBT, used mostly in Zeus/Mentor applications is pretty neat for moving
graphics. You can use it from Obliq too for rapid prototyping. Examples
are provided in the mentor subtree or in my cache memory animation program
(ftp.vlsi.polymtl.ca:pub/m3/cache-anim-1.1.tar.gz.
--

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



======================================================================= 143 ===
Date:    Tue, 28 Mar 1995 11:48:00 -0500
From:    Dick Orgass <orgass+@CMU.EDU>
Subject: Re: Q: Command-line Parameters, how?

In addition to the library described by Spencer Allain, there's another
interface, ParseParams which is libm3parseparams.a which does much more
of the parsing work than you get in a typical C program.  It also deals
with lots of error messages, etc.

It's trivial to learn to use the interface.  Once learned, it's very
easy to write command line parsing code that's much simpler and more
reliable than the C like code that one writes with Params.

I strongly recommend ParseParams over Params.

Dick


======================================================================= 144 ===
Date:    28 Mar 95 09:07:52
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Q: Command-line Parameters, how?

In article <D62EvL.1Dt@hermes.hrz.uni-bielefeld.de> lalbers@hrz.uni-bielefeld.d
e ( Leif Albers) writes:

   Hello out there,
    can anyone tell me how to reach command line parameters my
   (own) program was called with?

Look at the Params.i3 interface.
--

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



======================================================================= 145 ===
Date:    28 Mar 1995 14:39:27 GMT
From:    sims@linux.acsys.com (dave sims)
Subject: Error instantiating a generic with a generic parameter :-(

I'm trying to use the Table and SortedTable generic interfaces without
much success.  I'm trying to create a SortedTable, one of whose
generic parameters is a Table.  I'd appreciate a pointer on what I'm
doing wrong.

First, I instantiate a generic Table like so:


(* this is in the file 'MyTable.i3' *)
INTERFACE MyTable = Table(Integer, Integer)
END MyTable.


(* this is in the file 'MyTable.m3' *)
MODULE MyTable = Table(Integer, Integer)
END Table_Database.



** All of this compiles just fine.  Next, I try to instantiate a
** generic SortedTable like so:


(* this is in the file 'MySortedTable.i3' *)
INTERFACE MySortedTable = SortedTable(Integer, MyTable)
END MySortedTable.

** This one compiles fine too.


(* this is in the file 'MySortedTable.m3' *)
MODULE MySortedTable = SortedTable(Integer, MyTable)
END MySortedTable.


** I get a compilation error on this one.  It says:

line 1: number of actuals doesn't match number of generic formals



*** So ... I can't figure this one out.  What am I doing wrong?

thanks for the help,
dave sims
-- 
Dave Sims                     I'm an anarchist, and I vote.
sims@usa.acsys.com            Don't tread on me.
http://www.acsys.com/~sims/   Finger or WWW for PGP key.
KC5JKN


======================================================================= 146 ===
Date:    Tue, 28 Mar 1995 14:49:43 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: Q: Command-line Parameters, how?

In article <D62EvL.1Dt@hermes.hrz.uni-bielefeld.de> lalbers@hrz.uni-bielefeld.d
e ( Leif Albers) writes:


>   Hello out there,
>    can anyone tell me how to reach command line parameters my
>   (own) program was called with?
>
>   Thanks in advance...
>
>   Leif

Unless things have changed, there should be a module called "Params", that
is part of libm3, designed to grab command line parameters.

There is a CARDINAL variable called "Params.Count", that will tell you the
number of parameters, including the name used to invoke the program.  The
only procedure is "Params.Get(CARDINAL)" that simply returns the nth
parameter.

NOTE:  parameters run from 0 .. Params.Count - 1, where 0 is the program name.

Hope this helps.


======================================================================= 147 ===
Date:    Tue, 28 Mar 1995 16:18:56 GMT
From:    shang@corp.mot.com (David L. Shang)
Subject: Re: Undefined number of arguments

In article <3kbstf$lc0@lyra.csx.cam.ac.uk> pbm1001@cam.ac.uk (Paul Menage)  
writes:
> In article <9543@merlin.ukc.ac.uk>, ic4@ukc.ac.uk (I.Chatzigiannakis) writes:
> >
> >Do you have any idea how I can make a procedure that accepts many
> >arguments without a preset number.
> >I know how to code it in c++ (void myfunc(char *format,...)) but
> >what about modula-3?
> 

In Cluster-2, variable number of argumnets is provided, but unlike C++, it is  
safe. No low-level byte-wise coding (e.g. va_start, va_args ...) is required.  
The variable number of argumnets will be composed into a heterogeneous list  
without losing type information. For a simple print with default format, you  
are not necessary to provide a format at all.

David


======================================================================= 148 ===
Date:    30 Mar 1995 16:11:46 -0500
From:    hosking@cs.purdue.edu (Tony Hosking)
Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS

>>>>> "Guido" == Guido Muesch <odiug@manray.informatik.rwth-aachen.de> writes:

    Guido> I tried compiling Modula-3 on a Solaris 2.3 machine with gcc
    Guido> (SOLgnu release).  I get the follwoing error: ---- building m3 ----
    Guido> gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o
    Guido> Arg_i.o Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o
    Guido> Unit_m.o Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o
    Guido> ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a
    Guido> ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a
    Guido> ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS
    Guido> -lsocket -lnsl -lm ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS:
    Guido> not found ld: fatal: File processing errors.  No output written to
    Guido> m3 *** error code 1
    Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line
    Guido> 58: command execute failed *** call stack ***
    Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line
    Guido> 58: call to built-in exec "./make.boot", line 31: call to procedure
    Guido> boot_prog

    Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to
    Guido> gcc.  Well, I installed gcc 2.6.3 hoping this will solve the
    Guido> problem, but it doesn't. I installed it using Sun's as and ld.

Just delete the line:

	boot_import ("-lDYNAMIC_LINKING_AFTER_THIS")

from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be away and
laughing.
-- 
Tony Hosking				Voice:	(317) 494-6001
Department of Computer Sciences		Fax:	(317) 494-0739
Purdue University			Email:	hosking@cs.purdue.edu
West Lafayette, IN 47907URL:		http://www.cs.purdue.edu/people/hosking


======================================================================= 149 ===
Date:    Thu, 30 Mar 95 13:43:04 -0800
From:    mcjones@pa.dec.com
Subject: Re: Error instantiating a generic with a generic parameter :-(

Dave,

You say:

    (* this is in the file 'MySortedTable.m3' *)
    MODULE MySortedTable = SortedTable(Integer, MyTable)
    END MySortedTable.

    ** I get a compilation error on this one.  It says:

    line 1: number of actuals doesn't match number of generic formals

Your problem is caused by the fact that SortedTable.mg takes 3 parameters 
instead of 2: 

    GENERIC MODULE SortedTable (Key, Value, Tbl);
    (* Where "Key.T" and "Value.T" are types, "Tbl=Table(Key, Value)", and
       "Key.Compare(READONLY k1, k2: Key.T): [-1..1]" is a total order. *)



So write:

    MODULE MySortedTable = SortedTable(Integer, Integer, MyTable)
    END MySortedTable.

(It would have been good for us to mention this in SortedTable.ig 
and "Some Useful Modula-3 Interfaces".)


Paul McJones
DEC Systems Research Center
mcjones@pa.dec.com


======================================================================= 150 ===
Date:    Wed, 29 Mar 1995 20:05:04 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: help wanted converting code from m3 v2.11 to v3.x


I'm trying to bring a large application into the modern world, and I
noticed some things missing from the old version 2.11 libm3.  First of
all, the functionality of
  Filename.FileIsReadable
  Filename.SearchPath
  Filename.RdFromPath
seems to be missing.  Not a big problem since I can write that stuff
myself.  The showstopper is that
  RTHeap.Duplicate
is gone.

Does anybody know how to copy a heap object in m3 v3.x?
(The version I actually have is Michel Dagenais's Linux version 3.3.)

Norman
--
Norman Ramsey
norman@bellcore.com


======================================================================= 151 ===
Date:    29 Mar 1995 14:49:13 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Opinions on M3->C interface "consistency"

I'd like some other opinions on a good way to deal with the following
somewhat trivial issue.

In making an interface to a C library (OpenGL, in particular), there
is a tradeoff between "consistency" with the original C
constant/variable names and consistency with the way typical .i3 files
are written, as illustrated here:

GL.h:

#define GL_ACCUM 	0x0100

GL.i3:

CONST GL_ACCUM: INTEGER = 16_0100;

But, then to reference the constants, we write GL.GL_ACCUM, which is
long (writing GL.ACCUM would be nicer, I'd think).

The problem is, when the GL_ prefixes are stripped, we end up with
invalid identifiers, such as 2_BYTES, or reserved words, such as
RETURN.  Of course, these can just have something prepended to them
(which has to be done in some cases anyway).

The advantage of blind conversion (as shown above) is that users of
the package have a well defined way of converting C
examples/documentation they read (just stick the GL. on the front).

But, some people here complain it's too wordy. :-)  Anybody have any
other arguments one way or the other?
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

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


======================================================================= 152 ===
Date:    29 Mar 1995 21:15:42 GMT
From:    7231780@mcimail.com
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In <3536sa$5se@cantaloupe.srv.cs.cmu.edu>, rwh@cs.cmu.edu (Robert Harper) write
s:
>For example, one cannot tell
>by the bit pattern whether the value in a variable represents a "set"
>or a "time of day" or a "favorite color of the author of the program". 
>Nor can one check at run-time properties of, say, functions that can be
>enforced by a static type discipline.

In a dynamically typed system such as Smalltalk (or, untyped), I don't have to 
examine the bit pattern to determine the value.  The class lookup mechanism kno
ws the value representation and invokes the class that will process the variabl
e.  (polymorphism).  This increases programmer productivity factorially over st
atically typed compilers.

Therefore, the argument is flawed by the response "I, the programmer, do not ca
re."  Also, dynamically typed languages also have "isKindOf" queries to determi
ne type if they have to.

Your argument is flawed.



======================================================================= 153 ===
Date:    30 Mar 1995 17:43:27 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS

>>>>> On 30 Mar 1995 13:16:18 GMT,
>>>>> odiug@manray.informatik.rwth-aachen.de (Guido Muesch) said:

Guido> I tried compiling Modula-3 on a Solaris 2.3 machine with gcc
Guido> (SOLgnu release).  I get the follwoing error:

Guido> ---- building m3 ----
Guido> gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o Ar
g_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o Utils_i.o Utils_m
.o WebFile_i.o WebFile_m.o Main_m.o ../../m3front/SOLgnu/libm3front.a ../../m3l
inker/SOLgnu/libm3link.a ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu
/libm3.a ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS -lsocket 
-lnsl -lm
Guido> ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS: not found
Guido> ld: fatal: File processing errors.  No output written to m3
Guido> *** error code 1
Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: 
command execute failed
Guido> *** call stack ***
Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: 
call to built-in exec
Guido> "./make.boot", line 31: call to procedure boot_prog

Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to gcc.
Guido> Well, I installed gcc 2.6.3 hoping this will solve the problem, but it 
Guido> doesn't. I installed it using Sun's as and ld.

Guido> Or is this just a bug in the templates file?

Might be.  First, the compile command up there should not have been
gcc, but m3-gcc.  
m3-gcc should be something like the following shell script:
-------------------------------
#!/bin/sh

CMD="gcc "
for x do
	if [ "-lDYNAMIC_LINKING_AFTER_THIS" = "$x" ]; then
		CMD="$CMD -Xlinker -Bdynamic "
	else
		CMD="$CMD $x "
	fi
done
exec $CMD
-------------------------------

The purpose of this is to get around a shortcoming in m3 and the
Solaris libraries, namely that you can't entirely statically link on
Solaris (there are name conflicts libbsd.a and libc.a, and no libaio.a
at all!)

Check that the build_standalone entry in the SOLgnu template looks
like this:

proc build_standalone() is
   % --- reset the linker to avoid shared libraries.

   % In SOLgnu we cannot do this completely, because the -lbsd and -lc
   % libraries clash when linked statically, and there is no static -laio.
   % So we link try to do it, and fail miserably.  Finish by hand.  Sigh.
   M3_CONFIG += "-Y2@m3-gcc@-compat-bsd@-Xlinker@-dy@-Xlinker@-Bstatic@"
   M3_CONFIG += "-z2@-lDYNAMIC_LINKING_AFTER_THIS@-lsocket@-lnsl@-lm@"
   M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1@-quiet@"
   M3_CONFIG += "-Y7@/usr/ccs/bin/as@-s@"
end

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

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


======================================================================= 154 ===
Date:    30 Mar 1995 16:48:00 GMT
From:    odiug@manray.informatik.rwth-aachen.de (Guido Muesch)
Subject: Solaris 2.3: more fun building m3

Still have some more Problems with SOLgnu:

---------------------- building netobjd ----------------------

mkdir SOLgnu
--- building in SOLgnu ---
m3 -w1 -why -g -o netobjd -F/tmp/qkAAAa004IC 
new source -> compiling ../src/NMonRegistrySvr.i3
new source -> compiling ../src/NMonRegistrySvr.m3
new source -> compiling ../src/NetObjDaemon.m3
 -> linking netobjd
ld: fatal: library -laio: not found
ld: fatal: symbol `_mkarglst' is multiply defined:
        (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o)
);
ld: fatal: symbol `_doprnt' is multiply defined:
        (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o)
);
ld: fatal: symbol `_getarg' is multiply defined:
        (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o)
);
ld: fatal: File processing errors.  No output written to netobjd

Fatal Error: program "/opt/m3/lib/m3/SOLgnu/m3-gcc" failed, exit status = 256


Why does it need -laio?
And why does it want to link with /usr/ucblib/libucb.a?

Can anybody give me any hints on compiling Modula-3 on a Solaris machine
with gcc?

Ciao
  Guido "just wanted to install M3, fast"



======================================================================= 155 ===
Date:    30 Mar 1995 13:16:18 GMT
From:    odiug@manray.informatik.rwth-aachen.de (Guido Muesch)
Subject: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS

I tried compiling Modula-3 on a Solaris 2.3 machine with gcc (SOLgnu release).
I get the follwoing error:
---- building m3 ----
gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o Arg_m.o M
sg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o Utils_i.o Utils_m.o WebF
ile_i.o WebFile_m.o Main_m.o ../../m3front/SOLgnu/libm3front.a ../../m3linker/S
OLgnu/libm3link.a ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.
a ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS -lsocket -lnsl -
lm
ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS: not found
ld: fatal: File processing errors.  No output written to m3
*** error code 1
"/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: command
 execute failed
*** call stack ***
"/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: call to
 built-in exec
"./make.boot", line 31: call to procedure boot_prog

Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to gcc.
Well, I installed gcc 2.6.3 hoping this will solve the problem, but it 
doesn't. I installed it using Sun's as and ld.

Or is this just a bug in the templates file?

Can somebody enlighten me?

Thanx
  Guido



======================================================================= 156 ===
Date:    30 Mar 1995 12:05:31 -0600
From:    beede@gateway.sctc.com (Mike Beede)
Subject: Modula-3 on LINUX reresolving DLLs

Well, I was happy that the distribution finally installed (with the
patched DLL tools) and would compile and linke m3 programs.

Now I find I was premature in my celebration.

I wrote a little "hello, world" program and it works fine.  As I
recall it depended on Wr and Stdio.  I add an object definition and
try to print one of the internal values (this means importing Fmt,
too), and I suddenly get

: can't find libm3.so.3.5

When I run it under strace, I find odd things happening.  First, it
_finds_ libm3 and several other libraries (libm, libc, and another one
that escapes me).  It does some things that look initialization-like
(allocates memory, gets the time of day, some fstats, etc.) and
suddenly starts looking for shared libraries again (starting with the
first one)!  Apparently it isn't using LD_LIBRARY_PATH, because it
doesn't look in the directory that the bootstrap installed the library
in this time.

I ran BadBricks under strace and it looked the same, except it never
called uselib() again.  However, I notice an odd thing about
BadBricks--one in a while it dies suddenly and emits the error message

: can't find libm3ui.so (or something like that -- it had "ui" in it).
Thing was, it found ui earlier if it behaved the same as the straced
version of itself.  

It seems that something makes an m3 program lose its mind and begin
the dynamic linking process over again.  Anyone have a suggestion on
how I should proceed?  I guess one possibility is waiting for the ELF
tools and hoping that rectifies the problem....

Thanks,

	Mike Beede


-- 
Mike Beede - (612) 628-2720
SCC
beede@sctc.com


======================================================================= 157 ===
Date:    30 Mar 95 08:45:29
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: help wanted converting code from m3 v2.11 to v3.x


   The showstopper is that
     RTHeap.Duplicate
   is gone.

   Does anybody know how to copy a heap object in m3 v3.x?
   (The version I actually have is Michel Dagenais's Linux version 3.3.)

Well, you can Pickle in and out of a TEXT or Pipe.
--

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



======================================================================= 158 ===
Date:    Fri, 31 Mar 95 15:48:53 -0800
From:    heydon@pa.dec.com
Subject: Re: Error instantiating a generic with a generic parameter :-(

Dave,

Paul is right, you weren't providing enough parameters to the
instantiation of the generic module. The easiest way to instantiate
generics --- and one that would have helped you to avoid this problem
--- is to use the quake template that comes with the generic package.
To do this, you would write something like:

  table("IntInt", "Integer", "Integer")
  sorted_table("IntIntIntTbl", "Integer", "IntIntTbl")

in your m3makefile. Each of the quake procedures "table" and
"sorted_table" takes as a first parameter a string that is used to
construct the name of the table. If we use "<nm>" to denote the first
parameter, then the names for each of the tables is:

  table:        <nm>Tbl
  sorted_table: Sorted<nm>Tbl

Hence, the two lines above will create the following four files in the
*derived* directory and compile them automatically:

  IntIntTbl.i3, IntIntTbl.m3,
  SortedIntIntIntTblTbl.i3, SortedIntIntIntTblTbl.m3

[Note: The type "IntIntTbl" is pre-instantiated in libm3, so your type
"MyTable.T" is actually equivalent to "IntIntTbl.T" and could be
omitted. The "table" line in the m3makefile to instantiate an
"IntIntTbl" would also have to be omitted, or else an error would
probably occur at link-time.]

The quake templates are included in the packages of their
corresponding generic interfaces. For example, the template files for
the "Table" and "SortedTable" interfaces are:

  table/src/table.tmpl
  sortedtable/src/sortedtable.tmpl

Most of the quake templates in the Modula-3 distribution could stand 
to be better documented. 

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 159 ===
Date:    31 Mar 1995 16:27:00 GMT
From:    bm@shadow.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS

>>>>> On 30 Mar 1995 16:11:46 -0500, hosking@cs.purdue.edu (Tony
>>>>> Hosking) said:

Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to
Guido> gcc.  Well, I installed gcc 2.6.3 hoping this will solve the
Guido> problem, but it doesn't. I installed it using Sun's as and ld.

Tony> Just delete the line:

Tony> 	boot_import ("-lDYNAMIC_LINKING_AFTER_THIS")

Tony> from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be away and
Tony> laughing.

Well, laughing might not be the right word.  You cannot statically
link an m3 binary on solaris without this option and without using the
m3-gcc script (or something like it).

If you remove it, remove all "build_standalone()" commands from your
m3makefiles. 
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

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


======================================================================= 160 ===
Date:    31 Mar 1995 11:25:03 -0500
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: Solaris 2.3: more fun building m3

>>>>> On 30 Mar 1995 16:48:00 GMT,
>>>>> odiug@manray.informatik.rwth-aachen.de (Guido Muesch) said:

Guido> Still have some more Problems with SOLgnu:

Guido> ---------------------- building netobjd ----------------------

Guido> mkdir SOLgnu
Guido> --- building in SOLgnu ---
Guido> m3 -w1 -why -g -o netobjd -F/tmp/qkAAAa004IC 
Guido> new source -> compiling ../src/NMonRegistrySvr.i3
Guido> new source -> compiling ../src/NMonRegistrySvr.m3
Guido> new source -> compiling ../src/NetObjDaemon.m3
-> linking netobjd
Guido> ld: fatal: library -laio: not found
Guido> ld: fatal: symbol `_mkarglst' is multiply defined:
Guido>         (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do
prnt.o));
Guido> ld: fatal: symbol `_doprnt' is multiply defined:
Guido>         (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do
prnt.o));
Guido> ld: fatal: symbol `_getarg' is multiply defined:
Guido>         (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do
prnt.o));
Guido> ld: fatal: File processing errors.  No output written to netobjd

Guido> Fatal Error: program "/opt/m3/lib/m3/SOLgnu/m3-gcc" failed, exit status 
= 256

Guido> Why does it need -laio?  And why does it want to link with
Guido> /usr/ucblib/libucb.a?

The problems you see there are exactly the problems that the m3-gcc
script (with the -lDYNAMIC_LINKING_AFTER_HERE in the template) are
designed to solve.

As I said before, there is no libaio.a (only libaio.so), and libucb
and libc have name conflicts.  That is why I set up the scripts to
link those 3 libraries dynamically.

Did you remove the -lDYNAMIC_LINKING_AFTER_HERE flag and not use
m3-gcc??  Add m3_option("-commands") to your m3makefile and make sure
it is using m3-gcc ...

	Blair


======================================================================= 161 ===
Date:    31 Mar 1995 22:07:26 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: help wanted converting code from m3 v2.11 to v3.x

In article <D67x4H.3Ey@walter.bellcore.com>, norman@flaubert.bellcore.com (Norm
an Ramsey) writes:
> 
> Does anybody know how to copy a heap object in m3 v3.x?
> (The version I actually have is Michel Dagenais's Linux version 3.3.)

I don't remember exactly what RTHeap.Duplicate did, but the following
code should produce a shallow copy of any traced reference:

   PROCEDURE Duplicate (r: REFANY): REFANY =
     VAR
       tc     := TYPECODE (r);
       n_dims : INTEGER;
       res    : REFANY;
       shape  : RTHeapRep.ArrayShape;
     BEGIN
       IF (r = NIL) THEN RETURN NIL END;
   
       (* allocate a new object of the same type (and shape) as the old one *)
       RTHeapRep.UnsafeGetShape (r, n_dims, shape);
       IF (n_dims <= 0)
         THEN res := RTAllocator.NewTraced (tc);
         ELSE res := RTAllocator.NewTracedArray (tc, SUBARRAY(shape^, 0, n_dims
));
       END;
   
       (* copy the old data into the new object *)
       RTMisc.Copy (RTHeap.GetDataAdr (r), RTHeap.GetDataAdr (res),
                    RTHeap.GetDataSize (r));
   
       RETURN res;
     END Duplicate;


Of course, you can use Pickle to produce deep copies.

  - Bill Kalsow



======================================================================= 162 ===
Date:    Wed, 29 Mar 1995 09:23:41 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: SRC M3 3.5.1 on AIX 3.1 with gcc 2.6.0

>Farshad Nayeri wrote:
>I am trying to compile SRC Modula-3 3.5.1 on AIX 3.1. I have gcc 2.6.0
>for AIX, and /bin/cc
> ...
>I will be happy to make the binary release available on the net once I
>get it working.
>

I'd be interested in knowing how the AIX port of m3 3.5.1 to AIX goes.

It's beginning to look as if I have to get around to installing m3 on our
RS6000s. We have AIX 3.2.5 but it looks like we will be seeing  AIX 4.1 in
the not too distant future.

Thanks for any information.

Mike Douglass





======================================================================= 163 ===
Date:    31 Mar 95 15:14:54
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 on LINUX reresolving DLLs

In article <3lertb$8l7@gateway.sctc.com> beede@gateway.sctc.com (Mike Beede) wr
ites:

   Well, I was happy that the distribution finally installed (with the
   patched DLL tools) and would compile and linke m3 programs.

Humm, did you compile it yourself, which patches did you apply to the
DLL tools...

   Now I find I was premature in my celebration.
...
   When I run it under strace, I find odd things happening.  First, it
   _finds_ libm3 and several other libraries (libm, libc, and another one
   that escapes me).  It does some things that look initialization-like
   (allocates memory, gets the time of day, some fstats, etc.) and
   suddenly starts looking for shared libraries again (starting with the
   first one)!  Apparently it isn't using LD_LIBRARY_PATH, because it
   doesn't look in the directory that the bootstrap installed the library
   in this time.

If the addresses you reserved for shared libraries do overlap, all sorts
of strange things may happen.

   how I should proceed?  I guess one possibility is waiting for the ELF
   tools and hoping that rectifies the problem....

ELF is definitely a huge improvement over the current DLLs. It is working
now and well. They have started planning the great LINUX switch to ELF.
These things take time though until popular LINUX distributions get 
everything recompiled under ELF.
--

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



======================================================================= 164 ===
Date:    31 Mar 1995 21:51:50 GMT
From:    umesh@fugue.lcs.mit.edu (Umesh Maheshwari)
Subject: need font-lock support for modula3 mode in lemacs


Does anyone have a nice "modula3-font-lock-keywords" to color modula-3
programs in lucid emacs?

umesh
-- 
==================================================================
  umesh@lcs.mit.edu                     Umesh Maheshwari
  Office: 545 Tech Square, #527         Home: 341 Hurley St, #3
  Cambridge, MA 02139                   Cambridge, MA 02141
  Phone 617-253-6015                    Phone 617-492-3717
==================================================================



======================================================================= 165 ===
Date:    31 Mar 1995 10:42:14 GMT
From:    michael seitz <seitz@sonne.tachemie.uni-leipzig.de>
Subject: what is modula 3

Hi,

 i  often writing programs in an Modula 2 Environment (DOs)
 can you help me what is modula 3 ?

micha  


======================================================================= 166 ===
Date:    Fri, 31 Mar 1995 21:20:46 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Quake/m3build question -- installing resources


I'd like to make ``resources'' (arbitrary binary files) available in a
standard place for an application that needs them.  (A location
analogous to /proj/pkg/foo-rsrc/src would be just fine.)
Unfortunately, I don't see any way to do this with m3build and quake
(I have version 3.3).  Note well that I do *not* want to use m3bundle
to turn the resources into a module; I expect the resources to change
more rapidly than the program that uses them, so I want to get them
out of the file system dynamically.

Suggestions appreciated.

Norman
--
Norman Ramsey
norman@bellcore.com


======================================================================= 167 ===
Date:    29 Mar 1995 06:49:07 GMT
From:    Horst Stenzel <hstl@birke.gm.fh-koeln.de>
Subject: Problem with Random Integers w/M3 3.3 / LINUX 1.0.9

We are faced with false results from Random`s 
"rand.integer(min,max)" when running under LINUX: 
Instead of yielding results in the range (min,max), the
results are produced in the range (0,max-min). 
There seems to bee some erroneous bit tweeking involved.
Is it worth while getting a newer version, or do we 
have to look at the internals of the package?

Please respond directly to : 
isa009@advs2.gm.fh-koeln.de (Martina Rothkamp-Schriefl)


