======================================================================= 1 ===
Date:    1 Jun 94 05:13:38
From:    rundle@degas.jrc.flinders.edu.au (Richard Rundle)
Subject: Have dynamic, want statically linked executables

I am working on 2 projects involving modula-3.

One requires the use of dynamically linked libraries, and this is working
fine.

The other requires that I build an executable which can be shipped without
needing the dynamic libraries.

Adding the line:
M3OPT = -X2@-Bstatic@ 

to my m3makefile, results in the following error when linking:
cc: Fatal error in ld: Segmentation fault

Can someone offer some guidance on what I am doing wrong?

Thanks

-Richard


======================================================================= 2 ===
Date:    1 Jun 1994 16:57:08 GMT
From:    proussel@pdx144.intel.com (Patrice Roussel)
Subject: Re: Fixed Point vs. Floating Point

In article <STOLFI.94May31032513@cmos.dcc.unicamp.br>, stolfi@cmos.dcc.unicamp.
br (Jorge Stolfi) writes:
|> 
|>     > [Me:] Pardon my ignorance, but I thought that the IEEE standard
|>     > required that the result of A := B * C be correctly rounded in
|>     > all cases.  Does that work correctly on the Pentium?
|> 
|> Well, I have just been told (by e-mail) that the Pentium will indeed
|> round B*C to the nearest extended; and then, if requested, round the

The Pentium (like any member of the x86/87 family) rounds according to its
PC (Precision Control) bits. 

|> result to the nearest single or double.  Which is not in general
|> equivalent to directly rounding B*C to the nearest single double.
|> 
|> If this is true, does it mean that the Pentium does NOT conform
|> to the IEEE FP standard?
|> 

The Pentium (like any member of the x86/87 family) rounds according to its
PC (Precision Control) bits.

The confusion is coming from the fact that most C compilers use the
maximum precision (80 bits) even when data types are defined as, double,
for example. If this case, data are rounded to the requested precision (the
one defined in your C code) only when they are stored to memory.

In fact, if 100% IEEE is required, no intermediate result should be saved
on the stack because overflow/underflow detection on the stack is done
according to double extended thresholds (and not PC based ones). This is
done to allow computations such as:

                   2   2
        z = sqrt (x + y )

to be done correctly if the result is representable in the target format
(even though the square can be out of range). Anyway, this feature which
allows you, for example, to write a very simple "length-of-a-vector" routine
(check the BSD one for a routine which cannot rely on such a feature), has
a cost: not 100% IEEE compatible. For that reason, many compilers provide a
switch which forces pure IEEE compatibility by forcing every result to be
stored to memory (no intermediate result saved on the stack).

|> 
|> Is this the beginning of the end of the IEEE standard?
|> 

Check the fused MUL/ADD that more and more vendors are adding to their
instruction set and which has only one rounding (instead of two).

        Patrice.

-- 

	Patrice L. Roussel
	proussel@ichips.intel.com


======================================================================= 3 ===
Date:    1 Jun 1994 07:40:07 +0200
From:    pausch@electra.saaf.se (Paul Schlyter)
Subject: Re: Fixed Point vs. Floating Point

In article <STOLFI.94May30095540@cmos.dcc.unicamp.br>,
Jorge Stolfi <stolfi@dcc.unicamp.br> wrote:
 
> PS. Pardon my ignorance, but I thought that the IEEE standard required
> that the result of A := B * C be correctly rounded in all cases.  Does
> that work correctly on the Pentium?
 
The Pentium - as well as the 486, 387, 287, 8087 - can be instructed to
round any intermediate result to any selected precision -- single, double,
extended, or any number of bits of your choice.  The normal, and default,
procedure is to keep full 80-bit precision on all internal results.
 
> (i.e. will the Pentium round B*C to the nearest extended,
 
Usually it'll do that -- but it can be told to round it to any user
specified precision.
 
> and then round the result to the nearest double?
 
If intermediate results are kept to 80-bit precision, rounding a result to
double will occur only if the result is stored as a double somewhere in
memory.  If the result is only a partial result, only to be used in a chain
of further calculations, any decent compiler will NOT store the variable
but will keep it in the internal registers of the x87, usually to full
80-bit precision.  Even if this does not conform to requred Modula standards,
it will undoubtedly yield a more accurate final result.
 
> Is that equivalent to rounding B*C to the nearest double?)
 
It's almost the same -- in rare cases it may differ in the least significant
bit, but these cases are rare.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  SAAF (Swedish Amateur Astronomer's Society)
Nybrogatan 75 A,  S-114 40 Stockholm,  Sweden
InterNet:  pausch@saaf.se       psr@ausys.se


======================================================================= 4 ===
Date:    Thu, 2 Jun 1994 00:31:13 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: m3build problem

In article <FN00.94May31225441@tahoe.gte.com>,
Farshad Nayeri <fn00@gte.com> wrote:
>In article <9405311943.AA06958@inet-gw-1.pa.dec.com> BERGINF@PACEVM.DAC.PACE.E
DU (Joseph Bergin) writes:
>
>   Help. I just built m3.3.1. When trying to use m3build I get an
>   error on reading the first line of the first interface file in my
>   src directory to the effect that a) RT0.i3 can't be found and b)
>   RT0.i3 isn't an interface.  Well, RT0.i3 is in my
>   usr/local/m3/include as I expect, but it seems m3build expects
>   otherwise. What did I do wrong? Oh yes, after issuing m3boot and
>   m3ship on my DecStation, I did delete the build directory
>   boot-RS3100. Thanks.
>
>Starting with version 3.?, SRC Modula-3 requires that you include a
>line "import (libm3)" in your m3makefile; this statement was left out
>of the example "m3makefile" in the 3.1 documentation.
>
>To fix, just add "import (libm3)" in your favorite m3makefile.
>
>I believe the documentation error has been fixed for release 3.2, so
>this may not be an FAQ for much longer.

Is 3.2 out yet?
-- 
-------------------------------------------------------------------
Carsten Whimster              --- EDM/2 Associate Editor
bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
                              --- TEAM-OS/2


======================================================================= 5 ===
Date:    2 Jun 1994 06:19:49 GMT
From:    najork@src.dec.com (Marc Najork)
Subject: Re: m3build problem

In article <Cqqus1.8sL@undergrad.math.uwaterloo.ca>, bcrwhims@undergrad.math.uw
aterloo.ca (Carsten Whimster) writes:
|> 
|> Is 3.2 out yet?
|> -- 
|> -------------------------------------------------------------------
|> Carsten Whimster              --- EDM/2 Associate Editor
|> bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
|>                               --- TEAM-OS/2

Yes, it's on gatekeeper.dec.com:/pub/DEC/Modula-3/release-3.2

-- Marc


======================================================================= 6 ===
Date:    1 Jun 1994 22:04:07 -0400
From:    figueroa@cs.nyu.edu (Samuel A. Figueroa)
Subject: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Point)

In <STOLFI.94May31220256@cmos.dcc.unicamp.br> stolfi@cmos.dcc.unicamp.br (Jorge
 Stolfi) writes:
>So the Pentium IS IEEE compliant --- almost.

First of all, given that the IEEE Standard may be implemented by a combination
of hardware or software, one must be careful when making statements such as the
above.  In any case, I am not aware of any feature in the Pentium which goes
against what the IEEE Standard requires.  (I have the impression from recent
discussion in this newsgroup that for most people, whether the Pentium is
compatible with the IEEE Standard depends on whether the results it produces
is identical to the results produced by certain unspecified processors.)

>Why "almost"? Well, there are two little snags.
>(1) Setting the control bits correctly may be quite a hassle.  At the
>    very least, they have to be set between any two consecutive
>    operations with different precisions; and perhaps at other times
>    too, e.g. on procedure boundaries.
>    I don't know how easy that operation is on the Pentium.  I would
>    guess it requires
>      1. storing the FP control register into memory;
>      2. loading that word into an ordinary register;
>      3. masking off the two precision bits;
>      4. setting them to the desired value;
>      5. storing the modified word into memory;
>      6. loading that word into the FP control register;
>      7. performing the operation.
>    Yuck.

As far as I am able to determine, the first six steps above take a minimum of
13-14 clock cycles, depending on whether the desired precision mode is known
statically.  (Ignoring pairing with the FSCH instruction, the Pentium is able
to issue a maximum of one f-p operation per clock cycle.)  Most languages have
such weak floating-point semantics, that it doesn't matter how the precision
mode is set, so the overhead from setting the precision mode is usually
negligible.  Now, if you want to emulate some other processor (whether real or
imaginary), you shouldn't be surprised if there are some inefficiencies in
your program.

>(2) It seems that, in register-to-register operations, the control
>    bits only determine the precision of the *mantissa*, but not the
>    range of the exponent.  So, single- or double-precision
>    intermediate results which would be denormalized or infinite in a
>    strict IEEE machine may retain full precision when computed on the
>    Pentium; and this extra precision may affect the final result.

The IEEE Standard seems to allow this - section 4.3 contains the following
footnote:
  Control of rounding precision is intended to allow systems whose destinations
  are always double or extended to mimic, *in the absence of over/underflow*
  [emphasis mine], the precisions of systems with single and double destina-
  tions....

>    Some of these effects may be avoidable by forcing a store+load of
>    every intermediate result to memory, thus forcing low-exponent
>    values to be denormalized.  However, besides being expensive, this
>    solution will cause those denormals to be rounded twice, which is
>    incorrect.
>Thus, as my informant put it, "the goal of getting the same result
>on any IEEE machine is not likely to be achieved."

Another reason why this is not likely is that the IEEE Standard allows under-
flow to be detected either before or after rounding.  This could lead to
different results on fully IEEE conforming systems, if these systems provide
for traps on IEEE exceptions.
-- 
Sam Figueroa (figueroa@cs.nyu.edu)
This is not a .signature virus.
Do NOT copy me into your .signature file!


======================================================================= 7 ===
Date:    2 Jun 1994 06:17:35 GMT
From:    najork@src.dec.com (Marc Najork)
Subject: Re: Have dynamic, want statically linked executables

> I am working on 2 projects involving modula-3.
> 
> One requires the use of dynamically linked libraries, and this is working
> fine.
> 
> The other requires that I build an executable which can be shipped without
> needing the dynamic libraries.
> 
> Adding the line:
> M3OPT = -X2@-Bstatic@ 
> 
> to my m3makefile, results in the following error when linking:
> cc: Fatal error in ld: Segmentation fault
> 
> Can someone offer some guidance on what I am doing wrong?
> 
> Thanks
> 
> -Richard


Try

  build_standalone ()

instead.

"M3OPT = -X2@-Bstatic@" was the magic incantation you had to utter in 
m3 release 2.x in order to get static linking. "build_standalone ()"
is the (somewhat more readable) form in release 3. 

If you are using Mosaic, you can read about "build_standalone" on
http://www.research.digital.com/SRC/modula-3/html/m3build/progs.html.

You might also want to check out 
  http://www.research.digital.com/SRC/modula-3/html/home.html,
the SRC Modula-3 home page.

-- Marc


======================================================================= 8 ===
Date:    Fri, 03 Jun 94 11:59:42 -0700
From:    kalsow@src.dec.com
Subject: SRC Modula-3 version 3.3

Version 3.3 is now on gatekeeper in /pub/DEC/Modula-3/release-3.3.
The WWW documentation is at:

   http://www.research.digital.com/SRC/modula-3/html/home.html
     
The new features in version 3.3 include:

   - fixes several installation bugs in version 3.2, so it should
     build "out of the box" for at least ALPHA_OSF, DS3100, SPARC,
     and LINUX.

   - Postcard, a combined mail and news reader
 
   - VisualObliq, a system to rapidly prototype distributed
     applications

   - The license agreement is new.  It allows quite liberal
     commercial use of SRC Modula-3.

   - The HTML sources are included for users who wish to
     set up a local copy of the WWW documents.

Please send bug reports to "m3-request@src.dec.com".

Enjoy,
  Bill Kalsow




======================================================================= 9 ===
Date:    Fri, 3 Jun 94 14:42:58 EDT
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Fmt.Ref .... seems to have disappeared ?


in the 3.2 release. Is there a replacement ? I use it mainly for debugging
purposes.

--geoff


======================================================================= 10 ===
Date:    Sat, 4 Jun 1994 01:02:46 GMT
From:    erikhvh@knoware.nl (Erik van Heyningen)
Subject: Ten lines per second??


Am I correct in understanding that, according to the section on m3pc in the 
FAQ article, it takes a fast PC two minutes to build a 2500-line, 5-module 
program?

Before anybody replies `Well, you really need a good UNIX box for this 
advanced compiler', may I point out that Borland Pascal 7.0 can 
compile and link a 40-unit, 15000 line program in 12 seconds on my 
(unremarkable) PC?

It is true that BP 7.0 lacks a few features that m3 has (eg checks on dangling 
pointers), but it's a far more advanced than Standard Pascal: units with 
interface/implementation parts, objects with virtual methods and 'private' 
methods, and what not.




======================================================================= 11 ===
Date:    4 Jun 1994 23:59:01 +0200
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Ten lines per second??

As someone, Ken Olsen perhaps, said, "Faster, better, cheaper.  Pick
two."

In this case, select any two of "portable compiler, fast compiler,
fast compiled code".  GCC (which SRC M3 v3 uses) opts for portable
compiler and fast compiled code, sacrificing speed in the compiler.

So while the features M3 has that TP lacks does play some role, by
far the most important difference is the portability of its compiler.

--Arnt


======================================================================= 12 ===
Date:    Sat, 04 Jun 1994 16:56:57
From:    j_mcarthur@BIX.com (Jeffrey McArthur)
Subject: Re: Ten lines per second??

One reason for the slow speed is the intermediate generation
of C code.  The slow speed is why I am also using Borland 
Pascal and not Modula-3.  I don't have the time.

----
    Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
    a.k.a. Jeffrey McArthur          ATLIS Publishing
    phone: (301) 210-6655            12001 Indian Creek Court
    fax:   (301) 210-4999            Beltsville, MD  20705
    home:  (410) 290-6935            email: j_mcarthur@bix.com

The opinions express are mine and mine alone.  They do not reflect
the opinions of ATLIS Publishing or any part of ATLIS Systems.
ATLIS does NOT pay for my access to the Internet.


======================================================================= 13 ===
Date:    4 Jun 1994 11:35:48 +0200
From:    pausch@electra.saaf.se (Paul Schlyter)
Subject: Re: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Po
int)

In article <2sjemn$hnl@merv.cs.nyu.edu>,
Samuel A. Figueroa <figueroa@cs.nyu.edu> wrote:
 
> The IEEE Standard seems to allow this - section 4.3 contains the following
> footnote:
>   Control of rounding precision is intended to allow systems whose
>   destinations are always double or extended to mimic, *in the absence of
                                      ^^^^^^^^
>   over/underflow* [emphasis mine], the precisions of systems with single
>   and double destinations....
 
What does "extended" refer to here?
 
The reason I'm asking is that it's natural to assume that "extended" means
the 80-bit reals implemented in Intel and Motorola FPU's --- however several
people here has said that 80-bit reals are not part of the IEEE standard.
If this is true, it's unclear what IEEE means when referring to "extended"
precision, as above.
 
Or perhaps 80-bit reals is included in IEEE after all ????
 
-- 
----------------------------------------------------------------
Paul Schlyter,  SAAF (Swedish Amateur Astronomer's Society)
Nybrogatan 75 A,  S-114 40 Stockholm,  Sweden
InterNet:  pausch@saaf.se       psr@ausys.se


======================================================================= 14 ===
Date:    06 Jun 1994 03:35:38 GMT
From:    mike@majestix.cs.uoregon.edu (Mike Haertel)
Subject: Re: Ten lines per second??

In article <1994Jun5.174210.847@tengu.in-berlin.de> lee@tengu.in-berlin.de (Kan
g-Jin Lee) writes:
>I know that comparing GCC with TP isn't fair but even compared to BC++
>TP is very fast.

>What makes that big difference?

The BC++ to TP comparison is quite valid.

The biggest difference is that C and C++ have #include
instead of a real module system.

Depending on the libraries you're using, #include
can cause large expansions in the amount of source
text that must be lexically analyzed and parsed for
each file you compile.


======================================================================= 15 ===
Date:    6 Jun 1994 05:09:50 GMT
From:    jhauser@pine.CS.Berkeley.EDU (A Man Called John)
Subject: Re: Fixed Point vs. Floating Point

In article <STOLFI.94May31032513@cmos.dcc.unicamp.br>,
Jorge Stolfi <stolfi@dcc.unicamp.br> wrote:
>
>    > [Me:] Pardon my ignorance, but I thought that the IEEE standard
>    > required that the result of A := B * C be correctly rounded in
>    > all cases.  Does that work correctly on the Pentium?
>
>Well, I have just been told (by e-mail) that the Pentium will indeed
>round B*C to the nearest extended; and then, if requested, round the
>result to the nearest single or double.  Which is not in general
>equivalent to directly rounding B*C to the nearest single or double.

Actually, it _is_ the same for single precision.  But not for double
precision.  Proof left as an exercise.  (Hint:  The difference has to do
with the fact that extended precision is a _lot_ more accurate than single
precision, but only a _little_ more accurate than double precision.)

This is true not just for multiplication, but also for addition/subtraction,
division, and square root.  However, it is _not_ true if you do more than
a single operation in extended before rounding back to single.  Only one
operation allowed before rounding back.

----------------------------------------------------------------------------
Three Strikes and We're Broke.
John Hauser---jhauser@cs.berkeley.edu


======================================================================= 16 ===
Date:    6 Jun 1994 05:57:01 GMT
From:    jhauser@pine.CS.Berkeley.EDU (A Man Called John)
Subject: Re: Fixed Point vs. Floating Point

In article <2sh6vn$nuc@electra.saaf.se>,
Paul Schlyter <pausch@electra.saaf.se> wrote:
> 
>If intermediate results are kept to 80-bit precision, rounding a result to
>double will occur only if the result is stored as a double somewhere in
>memory.  If the result is only a partial result, only to be used in a chain
>of further calculations, any decent compiler will NOT store the variable
>but will keep it in the internal registers of the x87, usually to full
>80-bit precision.  Even if this does not conform to requred Modula standards,
>it will undoubtedly yield a more accurate final result.
         ^^^^^^^^^^^

I think ``almost certainly'' would be a better characterization.  There are
important numerical ``tricks'' that can be thrown off by this behavior,
possibly leading to _less_ accurate results.  Problems result from the fact
that, for the code

	x := a * b;

	... (lots of intervening code)

	y := a * b;

the values of `x' and `y' can be unequal, if `x' has been rounded to its
appropriate precision while `y' is still in extended precision.  This can
come as a surprise on a machine with supposedly ``good'' IEEE arithmetic.

Prof. Kahan of U.C. Berkeley, who had a big hand in both the IEEE Standards
and the 8087, thought that values would naturally be stored back to memory
on assignments.  (Compilers aren't smarter than that, you know.)  A register
stack was thought to be ideal for expression evaluation, which is why the
8087 treats its f.p. registers as a stack.  And since Kahan likes the idea
of evaluating intermediate expressions to wider precision, the 8087 has
extended-precision-only registers for its expression evaluation register
stack.  (Ahha!  Suddenly it all sort of makes sense!)

<Sigh.>

(And while I'm on the subject, I'm more-or-less honor-bound to inform you
that the _actual_ behavior of the 80x87 regarding f.p. register stack
overflows is not what Kahan intended.  Send a SASE, and I can send you a
monologue with details.)

----------------------------------------------------------------------------
We incarcerate drug users because we have their best interests at heart.
John Hauser---jhauser@cs.berkeley.edu


======================================================================= 17 ===
Date:    6 Jun 1994 09:56:32 GMT
From:    qs101@pelican.cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Re: SRC Modula-3 version 3.3

> Version 3.3 is now on gatekeeper ...

Just as I thought I had almost finished building 3.2 :-(

I've got most of 3.3 now, but would it be possible to provide diffs in
future, at least for very close releases like this.  Downloading a full
release takes a few days when the link's slow.  It would reduce the load on
gatekeeper too.

It would at least be interesting to know whether any packages had not
changed in the new release.

Still, I don't wish to sound negative - keep up the great work!

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


======================================================================= 18 ===
Date:    Sun, 5 Jun 1994 17:42:10 GMT
From:    lee@tengu.in-berlin.de (Kang-Jin Lee)
Subject: Re: Ten lines per second??

j_mcarthur@BIX.com (Jeffrey McArthur) writes:

>One reason for the slow speed is the intermediate generation
>of C code.  The slow speed is why I am also using Borland 
>Pascal and not Modula-3.  I don't have the time.

Today I tried Turbo Pascal 6.0 for the first time. Used to GCC
and Borland C++, I was amazed bye the speed of Pascal. After Pressing
"F9" key to make, one flash of the screen and that was it.

I know that comparing GCC with TP isn't fair but even compared to BC++
TP is very fast.

What makes that big difference?

-- 
Kang-Jin Lee
lee@tengu.in-berlin.de


======================================================================= 19 ===
Date:    6 Jun 1994 00:51:26 -0400
From:    figueroa@cs.nyu.edu (Samuel A. Figueroa)
Subject: Re: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Po
int)

I would add to Norbert Juffa's response about whether extended precision is
part of the IEEE Standard that the IEEE Standard requires only that the single
format be implemented.  So one can say that extended precision is not part of
the IEEE Standard in the sense that the IEEE Standard does not require exten-
ded precision to be implemented, nor does it specify the encoding of extended
precision values.


======================================================================= 20 ===
Date:    Mon, 06 Jun 94 08:37:44 -0700
From:    mcjones@src.dec.com
Subject: Re: Fmt.Ref .... seems to have disappeared ?

Geoff,

The Interface Police removed Fmt.Ref (so it hasn't been there in 
any of the 3.x releases).  How about Fmt.Unsigned(LOOPHOLE(ref, Word.T))?


Paul McJones
DEC Systems Research Center
mcjones@src.dec.com


======================================================================= 21 ===
Date:    Mon, 6 Jun 1994 15:14:09 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Ten lines per second??


   >I know that comparing GCC with TP isn't fair but even compared to BC++
   >TP is very fast.

   >What makes that big difference?

   The BC++ to TP comparison is quite valid.

   The biggest difference is that C and C++ have #include
   instead of a real module system.

Modula-3 with its well defined syntax and module system has the potential
to compile as fast as TP (Pascal). The current compiler does relatively well
on a 8MB 25Mhz 486 LINUX laptop. Of course if you link with the zillions
of great libraries available, the development time is reduced at the
expense of some link time.

The DOS version is a derivative of the original compiler and was not
planned for DOS. I am told that it is very sensitive to the amount of
memory available, among other things.

The 3.x release started about at the point where the more mature 2.11
version left. It thus has more room for optimization.
Comparing the build time of a C++ InterViews application
versus a Modula-3 Trestle application would be very interesting.
--

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


======================================================================= 22 ===
Date:    Mon, 6 Jun 94 14:30:01 EDT
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: bug in 3.3 network objects (on SPARCs)

A call to 'NetObj.Export' never returns. I have localized
it to the following:

  AgentStubs.PutStub calls StubLib.InRef (taking the network object off the wir
e)
  StubLib.InRef      calls StubLib.InObject
  StubLib.InObject   NetObjRT.Find

Somewhere in NetObjRT.Find, it is hanging. I don't believe that this is
a TCP or protocol related problem. If you "handcraft" a endpoint to
a specific port and avoid going through 'NetObj.Export', then these
remote invocations succeed, so it appears to be the implementation of
NetObjRT.Find; it is acting as if it is trying to acquire a lock that
it is already holding, though I haven't verfied this.

--geoff


======================================================================= 23 ===
Date:    6 Jun 1994 13:49:19 GMT
From:    hendrik@CAM.ORG (Hendrik Boom)
Subject: Re: Ten lines per second??

Mike Haertel (mike@majestix.cs.uoregon.edu) wrote:
: In article <1994Jun5.174210.847@tengu.in-berlin.de> lee@tengu.in-berlin.de (K
ang-Jin Lee) writes:
: >I know that comparing GCC with TP isn't fair but even compared to BC++
: >TP is very fast.

: >What makes that big difference?

: The BC++ to TP comparison is quite valid.

: The biggest difference is that C and C++ have #include
: instead of a real module system.

: Depending on the libraries you're using, #include
: can cause large expansions in the amount of source
: text that must be lexically analyzed and parsed for
: each file you compile.

Another difference is that there doesn't seem to be any practical
way of parsing C++ without using backtracking, or an equivalently
time-consuming unbounded lookahead.  And in many cases you have
to try and parse the least likely alternative (such as a declaration
with redundant parentheses around the declarator) first.



======================================================================= 24 ===
Date:    7 Jun 1994 05:34:14 GMT
From:    jhauser@boojum.CS.Berkeley.EDU (A Man Called John)
Subject: Re: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Po
int)

In article <2t003n$82j@news.jf.intel.com>,
Patrice Roussel <proussel@pdx144.intel.com> wrote:
|In article <2sua0e$8nd@porter.cs.nyu.edu>, figueroa@cs.nyu.edu (Samuel A. Figu
eroa) writes:
||> [...]  So one can say that extended precision is not part of
||> the IEEE Standard in the sense that the IEEE Standard does not require
||> extended precision to be implemented, nor does it specify the encoding
||> of extended precision values.
|
|From the IEEE standard:
|
|       [...]
|
|	All implementations conforming to this standard shall support
|	the single format. Implementations should support the extended
|	format corresponding to the widest basic format supported, and
|	need not support any other extended format.
|
|Table 1 specifies that:
|
|	single extended has more than 31 bits for the mantissa
|	double extended has more than 63 bits for the mantissa

Is this supposed to contradict Mr. Figueroa statement?  If so, I'm having
trouble following.

----------------------------------------------------------------------------
Three Strikes!   (What do District Attorneys know about fighting crime?)
John Hauser---jhauser@cs.berkeley.edu


======================================================================= 25 ===
Date:    Tue, 7 Jun 94 08:27:33 GMT
From:    buschman@slsvirt (Andreas Buschmann US/END 60/1/29 Tel.71409)
Subject: Re: Array Assignment

Richard Rundle (rundle@degas.jrc.flinders.edu.au) wrote:
: I have an 8x8 array which I would like to assign values to all at one time,

CONST
 emptyBoard = ARRAY[1..8],[1..8] OF INTEGER 
               {3,4,5, 6, 6, 5, 4,3,
                4,6,7, 9, 9, 7, 6,4,
                5,7,10,11,11,10,7,5,
                6,9,11,15,15,11,9,6,
                6,9,11,15,15,11,9,6,
                5,7,10,11,11,10,7,5,
                4,6,7, 9, 9, 7, 6,4,
                3,4,5, 6, 6, 5, 4,3};

should be ok, but I don't have a textbook at hand to check it.

			Tschuess
				Andreas
-- 
#include <stddisclaimer.h>

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

	buschman@lts.sel.alcatel.de		# we have a new domain address
	buschman@us-es.sel.de			# our old domain address


======================================================================= 26 ===
Date:    5 Jun 94 23:14:23
From:    rundle@degas.jrc.flinders.edu.au (Richard Rundle)
Subject: Array Assignment

I have an 8x8 array which I would like to assign values to all at one time,

I thought something along the lines of:

CONST
 emptyBoard : ARRAY[1..8],[1..8] OF INTEGER = 
               {3,4,5, 6, 6, 5, 4,3,
                4,6,7, 9, 9, 7, 6,4,
                5,7,10,11,11,10,7,5,
                6,9,11,15,15,11,9,6,
                6,9,11,15,15,11,9,6,
                5,7,10,11,11,10,7,5,
                4,6,7, 9, 9, 7, 6,4,
                3,4,5, 6, 6, 5, 4,3};
 
would be legal, but it appears not to be the case. 
Does modula-3 allow array assignment similar to this?

Thanks

-Richard


======================================================================= 27 ===
Date:    7 Jun 1994 09:38:30 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Array Assignment


>I have an 8x8 array which I would like to assign values to all at one time,
>
>I thought something along the lines of:
>
>CONST
> emptyBoard : ARRAY[1..8],[1..8] OF INTEGER = 
>               {3,4,5, 6, 6, 5, 4,3,
>                4,6,7, 9, 9, 7, 6,4,
>                5,7,10,11,11,10,7,5,
>                6,9,11,15,15,11,9,6,
>                6,9,11,15,15,11,9,6,
>                5,7,10,11,11,10,7,5,
>                4,6,7, 9, 9, 7, 6,4,
>                3,4,5, 6, 6, 5, 4,3};
> 
>would be legal, but it appears not to be the case. 
>Does modula-3 allow array assignment similar to this?
>

Try something like:

TYPE
  Row = ARRAY [1 .. 8] OF INTEGER;
  Board = ARRAY [1 .. 8] OF Row;

CONST
  emptyBoard = Board{Row{3, 4, 5, 6, 6, 5, 4, 3},
                     Row{4, 6, 7, 9, 9, 7, 6, 4},
                     ...
                     Row{3, 4, 5, 6, 6, 5, 4, 3}};

Peter
---
Peter Klein                        E-Mail: pk@i3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21311
Ahornstrasse 55                    Fax.: +49/241/8888-218
RWTH Aachen
52074 Aachen
Germany




======================================================================= 28 ===
Date:    6 Jun 1994 20:14:47 GMT
From:    proussel@pdx144.intel.com (Patrice Roussel)
Subject: Re: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Po
int)

In article <2sua0e$8nd@porter.cs.nyu.edu>, figueroa@cs.nyu.edu (Samuel A. Figue
roa) writes:
|> I would add to Norbert Juffa's response about whether extended precision is
|> part of the IEEE Standard that the IEEE Standard requires only that the sing
le
|> format be implemented.  So one can say that extended precision is not part o
f
|> the IEEE Standard in the sense that the IEEE Standard does not require exten
-
|> ded precision to be implemented, nor does it specify the encoding of extende
d
|> precision values.

>From the IEEE standard:

  	3. Formats

	This standard defines four floating-point formats in two groups,
	basic and extended, each having two widths, single and double.

	...

	3.3 Extended Formats.

	The single extended and double extended formats encode in an 
	implementation-dependent way the sets of values in 3.1 subject
	to the constraints of Table 1. This standard allows an imple-
	mentation to encode some values redundantly, provided that 
	redundancy be transparent to the user in the following sense:
	an implementation either shall encode every nonzero value
	uniquely or it shall not distinguish redundant encodings of
	nonzero values... 

	An implementation of this standard is not required to provide
	(and the user should not assume) that single extended have
	greater range than double.

	3.4 Combinations of Formats.

	All implementations conforming to this standard shall support
	the single format. Implementations should support the extended
	format corresponding to the widest basic format supported, and
	need not support any other extended format.
	standard levels

Table 1 specifies that:

	single extended has more than 31 bits for the mantissa
	double extended has more than 63 bits for the mantissa

	Patrice.
-- 

	Patrice L. Roussel
	proussel@ichips.intel.com


======================================================================= 29 ===
Date:    Tue, 7 Jun 1994 16:44:09 GMT
From:    lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: Fixed Point vs. Floating Point


>In article <2sh6vn$nuc@electra.saaf.se>,
>Paul Schlyter <pausch@electra.saaf.se> wrote:
>>If intermediate results are kept to 80-bit precision, rounding a result to
>>double will occur only if the result is stored as a double somewhere in
>>memory.

Hey - what about task switches that flush (and later reload) the FP
register set?  Does that cause nondeterministic rounding?
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science


======================================================================= 30 ===
Date:    Tue, 7 Jun 1994 16:04:41 GMT
From:    wgsteven@undergrad.math.uwaterloo.ca (Warren Stevens)
Subject: Re: SRC Modula-3 version 3.3

In article <2sursg$fl7@lyra.csx.cam.ac.uk>,
Quentin Stafford-Fraser <qs101@pelican.cl.cam.ac.uk> wrote:
>It would at least be interesting to know whether any packages had not
>changed in the new release.

I'd like to second this.  It would be really nice if packages that had
changed could be clearly indicated, and a list of what the changes
are.  (I hate downloading Megs and Megs of software without knowing
what changed... :)

>Still, I don't wish to sound negative - keep up the great work!

Indeed.  Kudos.

Warren
-- 
Warren Stevens <wgstevens@undergrad.math.uwaterloo.ca>
PGP public key availible via finger.  Use it.


======================================================================= 31 ===
Date:    7 Jun 94 15:15:54
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: SRC Modula-3 version 3.3

In article <Cr1BBt.Asr@undergrad.math.uwaterloo.ca> wgsteven@undergrad.math.uwa
terloo.ca (Warren Stevens) writes:

   In article <2sursg$fl7@lyra.csx.cam.ac.uk>,
   Quentin Stafford-Fraser <qs101@pelican.cl.cam.ac.uk> wrote:
   >It would at least be interesting to know whether any packages had not
   >changed in the new release.

   I'd like to second this.  It would be really nice if packages that
   had changed could be clearly indicated, and a list of what the
   changes are.  (I hate downloading Megs and Megs of software without
   knowing what changed... :)

   >Still, I don't wish to sound negative - keep up the great work!

   Indeed.  Kudos.

Having gone through the process of installing SRC Modula-3 several
times, I agree with your comments that such a diff is very useful.

However, Bill doesn't have to be the one who does the diffing. There
is always possibility for someone outside SRC to do the diffing for
their platform and post it to the net or put it for ftp access. My
personal take on this issue is that it is better to let SRC to do what
they do best which is to release new versions of the Modula-3
environment.  Things that can be taken care of by people outside DEC,
should be taken care of by them.

So, everybody who is in charge of Modula-3 installations, feel free to
volunteer to do the diffing for your platform so that others don't
have to download too many files or spend their time re-installing the
system. :-)

But I do think it is a good idea if Bill or some other "authority" can
post a message on comp.lang.modula3 describing the major differences
when a new release comes out.

--farshad
--
  ///                       |
 {@,@}                      | 
 (...)     Farshad Nayeri   |  The average American watches 7 hours
  " "      nayeri@gte.com   |         of television per day.


======================================================================= 32 ===
Date:    Tue, 7 Jun 1994 23:05:51 +0200
From:    Preschern@edvz.uni-klagenfurt.ada.at (Klaus Preschern)
Subject: M3 3.1 for DOS available!

Hi M3 world,

SRC Modula-3 version 3.1 (m3build, m3ship, driver, compiler, library) for
DOS is available from "gatekeeper.dec.com:pub/DEC/Modula-3/contrib/M3forDOS".
Enjoy!

	Klaus Preschern



======================================================================= 33 ===
Date:    7 Jun 1994 15:32:11 GMT
From:    proussel@pdx144.intel.com (Patrice Roussel)
Subject: Re: Pentium and the IEEE Standard (was Re: Fixed Point vs. Floating Po
int)

In article <2t10sm$ron@agate.berkeley.edu>, jhauser@boojum.CS.Berkeley.EDU (A M
an Called John) writes:
|> In article <2t003n$82j@news.jf.intel.com>,
|> Patrice Roussel <proussel@pdx144.intel.com> wrote:
|> |In article <2sua0e$8nd@porter.cs.nyu.edu>, figueroa@cs.nyu.edu (Samuel A. F
igueroa) writes:
|> ||> [...]  So one can say that extended precision is not part of
|> ||> the IEEE Standard in the sense that the IEEE Standard does not require
|> ||> extended precision to be implemented, nor does it specify the encoding
|> ||> of extended precision values.
|> |
|> |From the IEEE standard:
|> |
|> |       [...]
|> |
|> 
|> Is this supposed to contradict Mr. Figueroa statement?  If so, I'm having
|> trouble following.
|> 

Not at all! It is just that many people were talking about the standard and
I thought it might help some of them to see what is effectively written 
concerning this issue.


	Patrice.
-- 

	Patrice L. Roussel
	proussel@ichips.intel.com


======================================================================= 34 ===
Date:    7 Jun 94 23:02:01
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Was: ten lines per second?? Now: too beautiful?


Hi Erik,

In article <erikhvh.3.00151E30@knoware.nl> erikhvh@knoware.nl (Erik van Heyning
en) writes:

   I don't see what portability has to do with compilation speed.
   Higher programming languages are all about shielding the programmer
   from differences in machine architecture and operating systems.

I think the point was that Turbo Pascal is not portable (I believe it
is probably mostly 8086 assembly language). Current compiler
technology which produces fast code while being portable (e.g., gcc)
tends to be resource hungry. 

   A Modula-3 compiler generating code for C brings an advanced
   language to many types of computers. Wonderful. I don't suppose,
   however, that anything requires that this detour be taken: if the
   process can be done 50 x faster by a compiler generating 80x86 code
   directly, then I propose writing such a compiler (but please,
   PLEASE, with strict adherence to the language specification,
   without extensions).  Personally, I'd prefer one running under
   OS/2.

Generatig native code could be pretty slow as well. For example,
although Modula-3 3.1 is going to be generating native code via gcc,
it is still slow compared to Turbo Pascal. 

   There is something that worries me a bit about this newsgroup.
   Everybody seems to work either for DEC or for a Computer Science
   Department somewhere. Is there anyone out there busy writing a
   large application to do some serious floating-point work, and who
   cares about speed, not 64-bit-versus-80-bit-precision? Or is
   Modula-3, like LISP, very beautiful but not quite the language to
   pick for this sort of work?

The overriding concern of Modula-3 designers was to facilitate
development of large programs to do serious programming, and not
necessarily for jazzy prototypes that are hard to ship.  (Someone
qualified (David?) can comment on floating point issue.) I think
Modula-3 _as a language_ has largely succeeded in that goal.  Modula-3
designers were hesitant to add features that compromised efficiency or
simplicity of the language unless there was an overriding concern
about reliability and safety of the code.

However, the SRC Modula-3 implementation is *experimental*, and as
such a very good experimental system, that it reiably works on a
number of platforms without anything unexpected. (Besides, it is free!
:-) It is uncommon path for a research compiler such as SRC Modula-3
to be geared toward a particular platform, as its main goal is to
prove that a reasonable implementation of a language can be built and
to allow it to run on a variety of platforms. However, given the
language definition, nothing is stopping people from writing a fast
environment for PCs or OS/2.

I think you are right that up to now a lot of research institutions
have been participating in this newsgroup, however, many of the
participants are aware and concerned of the "bloat" factor of today's
software systems. Now that Modula-3 is pretty ready for "prime-time"
at least on UNIX environments, many people here hope that "ordinary"
programmers (from places that may not have research goals) can start
to use the system to build serious and large applications.

--farshad
--
  ///                       |
 {@,@}                      | 
 (...)     Farshad Nayeri   |  The average American watches 7 hours
  " "      nayeri@gte.com   |         of television per day.


======================================================================= 35 ===
Date:    Wed, 8 Jun 1994 02:06:56 GMT
From:    erikhvh@knoware.nl (Erik van Heyningen)
Subject: Was: ten lines per second?? Now: too beautiful?

I don't see what portability has to do with compilation speed. Higher 
programming languages are all about shielding the programmer from differences 
in machine architecture and operating systems. 

A Modula-3 compiler generating code for C brings an advanced language to many 
types of computers. Wonderful. I don't suppose, however, that anything 
requires that this detour be taken: if the process can be done 50 x faster by 
a compiler generating 80x86 code directly, then I propose writing such a 
compiler (but please, PLEASE, with strict adherence to the language 
specification, without extensions).  Personally, I'd prefer one running 
under OS/2.

There is something that worries me a bit about this newsgroup. Everybody seems 
to work either for DEC or for a Computer Science Department somewhere. Is 
there anyone out there busy writing a large application to do some 
serious floating-point work, and who cares about speed, not 
64-bit-versus-80-bit-precision? Or is Modula-3,  like LISP, very beautiful but 
not quite the language to pick for this sort of work?




======================================================================= 36 ===
Date:    Wed, 8 Jun 94 08:54:42 EDT
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Was: ten lines per second?? Now: too beautiful?

Erik van Heyningen writes:
 > I don't see what portability has to do with compilation speed. Higher 
 > programming languages are all about shielding the programmer from difference
s 
 > in machine architecture and operating systems. 

 > 
 > A Modula-3 compiler generating code for C brings an advanced language to man
y 
 > types of computers. Wonderful. I don't suppose, however, that anything 
 > requires that this detour be taken: if the process can be done 50 x faster b
y 
 > a compiler generating 80x86 code directly, then I propose writing such a 
 > compiler (but please, PLEASE, with strict adherence to the language 
 > specification, without extensions).  Personally, I'd prefer one running 
 > under OS/2.
 > 

This detour was originally taken to avoid having to write a code generator for
every machinein the world. The goal was to make M3 easily available without
requiring interested people to a write code generator for their platform and
to have access to an already supported platform.

With the 3.X releases, there is now a real code generator interface. The front-
end
generates a tree intermediate representation. The current code generation strat
egy
is to have the GCC backend essentially walk this tree and generate machine code
.
The GCC backend assumes virtual memory machines with an non-neglible amount of 
physical
memory.

However, there is nothing to preclude another backend from being written that w
alked the
IR tree directly and generated 80x86 code directly. This should be somewhat fas
ter than
going through the GCC backend. There is even a prototype code generator for doi
ng this;
it's in the BURs subdirectory of the compiler tree. I'm not sure if it has been
 heavily
exercised.


 > There is something that worries me a bit about this newsgroup. Everybody see
ms 
 > to work either for DEC or for a Computer Science Department somewhere. Is 
 > there anyone out there busy writing a large application to do some 
 > serious floating-point work, and who cares about speed, not 
 > 64-bit-versus-80-bit-precision? Or is Modula-3,  like LISP, very beautiful b
ut 
 > not quite the language to pick for this sort of work?
 >

I don't think M3 falls into the 'beautiful but expensive' camp. The language de
sign arose
after a number of years of experience with its predecessor langauges in buildin
g real
systems. Careful attention was paid to ensuring that it could be used in an eff
icient
manner. One of the overriding goals was that it should be possible to do system
s-level
programming in Modula-3. 

Our group is using Modula-3 as the basis for its research into large-scale dist
ributed
systems. I was the one that pushed for that, partly because I believed (and sti
ll do)
that with Modula-3 you could get an elegant high-level language with reasonable
 efficiency.

I can't comment on floating-point, since our group does little floating point w
ork. I
do know that other groups have done some major amounts of floating point work w
ith it.

--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 37 ===
Date:    8 Jun 94 09:30:08 CDT
From:    billk@cs.ukans.edu (Bill Kinnersley)
Subject: Need help installing 3.3


What am I doing wrong?  I'm trying to install version 3.3 on an ALPHA_OSF
system.  All the installation procedure goes through without a hitch, but
when I try to compile a program, it can't find libm3.

m3makefile: import("libm3")


"/homea/cs400/DFA/src/m3makefile", line 1: unable to read ".M3EXPORTS"
   from directory "ALPHA_OSF" of package "libm3" (/homea/cs400/lib/m3/pkg/libm3
)

*** call stack ***
"/homea/cs400/DFA/src/m3makefile", line 1: call to built-in error
"/homea/cs400/DFA/src/m3makefile", line 539: call to procedure M3include
"/homea/cs400/lib/m3/pkg/m3build/templates/COMMON", line 531: call to procedure
 import_version
"/homea/cs400/DFA/src/m3makefile", line 1: call to procedure import
--- building in ALPHA_OSF ---



libm3.a and libm3.ax are still sitting in boot-ALPHA_OSF/libm3/src, and there 
is no ~/m3/pkg/libm3 directory at all.  Well I could create one and copy those
files over by hand, but there is no .M3EXPORTS anywhere.

-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.


======================================================================= 38 ===
Date:    Wed, 8 Jun 1994 13:29:40 GMT
From:    psu@cs.cmu.edu (Peter Su)
Subject: Re: Was: ten lines per second?? Now: too beautiful?

Systems like TP typically are fast in compilation for several reasons:

1) lousy code generation
2) compile to/from memory instead of through several intermediate
phases.
3) trivial link phase in development mode.  only run a real linker
when you generate the final binary.

Pete


======================================================================= 39 ===
Date:    8 Jun 1994 16:54:01 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Need help installing 3.3

In article <1994Jun8.093009.65465@kuhub.cc.ukans.edu>, billk@cs.ukans.edu (Bill
 Kinnersley) writes:
> 
> What am I doing wrong?  I'm trying to install version 3.3 on an ALPHA_OSF
> system.  All the installation procedure goes through without a hitch, but
> when I try to compile a program, it can't find libm3.

The version of libm3 in the boot-XYZ directories is only usable by
the bootstrap compiler and driver.  You must get and install the
libm3 source archive before you will have a working system.

 - Bill Kalsow


======================================================================= 40 ===
Date:    Wed, 8 Jun 1994 14:29:40 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: M3 3.1 for DOS available!

In article <196*/S=Preschern/O=edvz/PRMD=uni-klagenfurt/ADMD=ada/C=at/@mhs>,
Klaus Preschern <Preschern@edvz.uni-klagenfurt.ada.at> wrote:
>Hi M3 world,
>
>SRC Modula-3 version 3.1 (m3build, m3ship, driver, compiler, library) for
>DOS is available from "gatekeeper.dec.com:pub/DEC/Modula-3/contrib/M3forDOS".
>Enjoy!
>
>	Klaus Preschern

Does this have the shell that m3pc has for translating
filename-length, and does it also require a co-processor? Or is this a
different port? Could you talk about the features a bit?
-- 
-------------------------------------------------------------------
  Carsten Whimster              --- EDM/2 Associate Editor
  bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
-------------------------------------------------------------------


======================================================================= 41 ===
Date:    8 Jun 1994 19:37:20 GMT
From:    stellanl@vaxkab.e.kth.se (Stellan Lagerstroem)
Subject: Trouble building Trestle from 3.1 on ALPHA_OSF




While building X11R4 in Trestle on my DEC 300-800 with OSF/1 1.3A
I see:
..
new source -> compiling ../src/Common/XtR.m3
 -> archiving libm3X11R4.a
s - creating symbol hash table. Wait...
ld -shared -expect_unresolved end -o libm3X11R4.so -all libm3X11R4.a -none -L/u
s
r/local/lib/m3/pkg/libm3/ALPHA_OSF -lm3 -L/usr/lib -lXaw -L/usr/lib -lXmu -L/us
r
/lib -lXext -L/usr/lib -lXt -L/usr/lib -lX11 -ldnet_stub -lm -lc
ld:
Warning: Unresolved:
_end
..
and later after shipping it, building and shipping "ui",
 and "tests/Monster" and trying to run it I see:

zafir>m3build
--- building in ALPHA_OSF ---
m3 -w1 -why -g -o Monster -F/tmp/qkAAA018517
new source -> compiling ../src/Monster.m3
 -> linking Monster
zafir>ALPHA_OSF/Monster
Segmentation fault

gdb says:

Program received signal SIGSEGV, Segmentation fault.
0x3ff80003154 in _end ()

which makes me think that the warning from "ld" was significant.
The same occurs for any program I build that uses Trestle...

Any ideas for debugging this are welcome.


Stellan
-- 
--- Stellan Lagerstrom, VMS system manager, School of E.E.
--- Royal Institute of Technology, Stockholm, Sweden


======================================================================= 42 ===
Date:    Wed, 08 Jun 94 20:52:25 GMT+0100
From:    atverm@ecp541.ecn.nl
Subject: Re: Was: ten lines per second?? Now: too beautiful?

In  <Cr2ytH.Bv6.3@cs.cmu.edu>  psu@cs.cmu.edu (Peter Su) writes:
| Systems like TP typically are fast in compilation for several reasons:
|  
| 1) lousy code generation
| 2) compile to/from memory instead of through several intermediate
| phases.
| 3) trivial link phase in development mode.  only run a real linker
| when you generate the final binary.
|  
| Pete

1) simply not true (have you taken a look at the Modula-3 code?)
2) TP is a single pass compiler, and you can chooses to compile
   units (modules) to disk or store them in memory before linking
3) There is no difference in TP between linking in dev. and final mode,
  the smart linker leaves out unused code and finishes a 30.000 line
  program within several seconds (<5s) on a 486 PC.

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


======================================================================= 43 ===
Date:    Wed, 8 Jun 1994 16:34:05 GMT
From:    ckingsto@undergrad.math.uwaterloo.ca (Craig Kingston)
Subject: Re: M3 3.1 for DOS available!

In article <196*/S=Preschern/O=edvz/PRMD=uni-klagenfurt/ADMD=ada/C=at/@mhs>,
Klaus Preschern <Preschern@edvz.uni-klagenfurt.ada.at> wrote:
>Hi M3 world,
>
>SRC Modula-3 version 3.1 (m3build, m3ship, driver, compiler, library) for
>DOS is available from "gatekeeper.dec.com:pub/DEC/Modula-3/contrib/M3forDOS".
>Enjoy!
>
>	Klaus Preschern
>
What features are -not- available (eg are threads implemented yet?)
CRAIG-



======================================================================= 44 ===
Date:    Wed, 08 Jun 94 13:11:27 -0700
From:    kalsow@src.dec.com
Subject: Version 3.3 bug reports

I added a page of bug reports and patches for version 3.3
to the WWW documentation.  It's at:

   http://www.research.digital.com/SRC/modula-3/html/patches.html

If you want something added to the page, please send mail
to m3-request@src.dec.com.

Attached below is the current HTML.

  - Bill Kalsow

-----------------------------------------------------------
<HTML>
<HEAD>
<TITLE>SRC Modula-3: bugs and patches</TITLE>
</HEAD>
<BODY>

<H2>Bugs and patches: version 3.3</H2>
<P>

Listed below are the known bugs and patches or workarounds for
version 3.3 of SRC Modula-3:
<UL>
<LI><A HREF="#x000">PIC vs. pic (SPARC)</A>
<LI><A HREF="#x001">m3ship: cannot locate a .M3SHIP file, run m3build first</A>
<LI><A HREF="#x002">libm3: struct_tm (SPARC)</A>
<LI><A HREF="#x003">ld: Undefined symbol _getmnt (SPARC)</A>
<LI><A HREF="#x004">m3gdb: Memory corruption</A>
<LI><A HREF="#x005">mentor build fails</A>
<LI><A HREF="#x006">DPS.m3 doesn't compile</A>
<LI><A HREF="#x007">Wrong socket types on Solaris</A>
</UL>
<P>

There is a natural tension between the frequency of new
releases and the number of patches that must be applied
to an old release.  We try to make the right choice.
If you have any wisdom or advice on how this tradeoff
should be made, please send e-mail to
<b>m3-request@src.dec.com</b>.
<P>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x000">
<H2>PIC vs. pic (SPARC)</H2><P>
</A>
The default SPARC templates generate "pic" code, but
when built standalone the network objects stub generator
is too big.
<P>

<EM>Workaround:</EM><P>
Change "pic" to "PIC" throughout
<TT>boot-SPARC/m3build/templates/SPARC</TT>
and rebuild the system.
<P>

To get over the immediate problem with stubgen and not
rebuild the entire world, comment out the "build_standalone()" call in
<TT>netobj/stubgen/src/m3makefile</TT>.
<P>


<!-------------------------------------------------------------------------->
<HR>
<A NAME="x001">
<H2>m3ship: cannot locate a .M3SHIP file, run m3build first</H2><P>
</A>

Some packages (e.g. tools/m3tohtml, compiler/driver, and visualobliq)
don't export anything, so m3ship complains.
<P>

The driver package should export "m3".  Add
<PRE>
    LibdExport ("m3")
</PRE>
at the end of its m3makefile.


<EM>Patch:</EM><P>
Near line 1120 of
<TT>boot-XYZ/m3build/templates/COMMON</TT>,
change
<PRE>
    if defined("_all")
      delete_file(M3SHIP_FILE)
      delete_file(M3OVERRIDES)
    end
</PRE>
to
<PRE>
    if defined("_all")
      delete_file(M3SHIP_FILE)
      delete_file(M3OVERRIDES)
      > M3SHIP_FILE in write (CR) end % let m3ship know we've been here
    end
</PRE>
This change will cause m3build to always create a .M3SHIP file.
<P>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x002">
<H2>libm3: struct_tm (SPARC)</H2><P>
</A>

The order of fields in
<TT>libm3/src/unix/ultrix-3-1.SPARC/Utime.i3</TT>
is incorrect.

<PRE>
Date: Fri, 03 Jun 94 20:34:34 +0100
From: Quentin &lt;Quentin.Stafford-Fraser@cl.cam.ac.uk&gt;

Ah! Fairly important bug in libm3. It was also in 3.1 - I'm surprised nobody 
discovered it. I found it because packageserver died with a strlen error, as 
would anything else which used timezones.

Heaven knows why, but on SunOS 4.1.3 the last 2 elements of a 'struct tm' in 
time.h are
        char    *tm_zone;
        long    tm_gmtoff;

where most other systems have them the other way round - ie:

        long    tm_gmtoff;
        char    *tm_zone;

This means that the M3 equivalent defined in 
  libm3/src/unix/Utime.i3 
is not valid for SunOS.  The proper way to fix it (I think) is as follows:

* copy all of the interfaces and modules of ultrix-3-1.generic into 
ultrix-3-1.SPARC

* update the m3makefile in ultrix-3-1.SPARC to include the new files - you can 
just insert the contents of the ultrix-3-1.generic m3makefile.

* change the m3makefile in the parent directory (libm3/src/unix) so that the 
generic directory is not used for SPARCs. This involves changing the line
  "SPARC"      : [ "ultrix-3-1.generic", "ultrix-3-1.SPARC" ],
to
  "SPARC"      : [ "ultrix-3-1.SPARC" ],

* in the Utime.i3 which is now in the ultrix-3-1.SPARC directory, change the 
definition of struct_tm by swapping the positions of tm_zone and tm_gmtoff.

* rebuild and ship libm3, then rebuild everything everything else to use it.

Quentin
</PRE>


<!-------------------------------------------------------------------------->
<HR>
<A NAME="x003">
<H2>ld: Undefined symbol _getmnt (SPARC)</H2><P>
</A>

Apparrently <EM>getmnt</EM> is not a universal C library
function.  In SunOS there's a function called <EM>getmntent</EM>,
possibly it can be used as a replacement.
<P>

<EM>Patch:</EM>
<PRE>
Date: Fri, 03 Jun 94 18:30:23 +0100
From: Quentin &lt;Quentin.Stafford-Fraser@cl.cam.ac.uk&gt;

Ah! It turns out that SunOS is more osf-like than ultrix-like here.
In pkgtools/pkgobj/src/POSIX/m3makefile there is:

if equal (BUILD_DIR, "AOSF")
   include_dir(osf)
else
   include_dir(ultrix)
end

The ultrix directory uses getmnt(), and the osf directory uses statfs(), which 
exists in SunOS. Changing it to:

if equal (BUILD_DIR, "AOSF") or equal (BUILD_DIR, "SPARC")

allows things to build. PackageServer still dies, but that's a different 
problem. I'm working on it.

Quentin
</PRE>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x004">
<H2>m3gdb: Memory corruption</H2><P>
</A>

On some platforms m3gdb crashes immediately with
"gdb internal error: Memory corruption".  The bug
is in the Modula-3 extensions -- m3_demangle is
not returning the address of a malloc'ed string.
<P>

<EM>Patch:</EM><P>
In <TT>m3gdb/gdb/gdb/m3-lang.c</TT>, in procedure m3_demangle
(lines 899-966) make the following changes:
<UL>
<LI> Change the declaration of demangled from "<B>static char demangled[100];</
B>"
     to "<B>char demangled[100]</B>".
<LI> Change each occurance (5 of them) of "<B>return demangled</B>"
     to "<B>return strsave (demangled)</B>".
</UL>
<P>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x005">
<H2>mentor build fails</H2><P>
</A>

The mentor m3makefile doesn't evaluate properly.
<P>

<EM>Patch:</EM><P>
Replace <B>include_dir(pqueue)</B> with <B>include_dir("pqueue")</B>
in <TT>mentor/src/m3makefile</TT>.
<P>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x006">
<H2>DPS.m3 doesn't compile</H2><P>
</A>

The display postscript package is stale.
<TT>misc/dps/src/DPS.m3</TT> doesn't compile
because it calls <B>SchedulerPosix.IOSelect</B>.
<P>

<EM>Patch:</EM>
<PRE>
Date: Tue, 07 Jun 94 10:53:40 -0700
From: wobber

>>    It seems misc/dps/src/DPS.m3 needs updating; it accesses (in line 897) an
>>    obsolete procedure SchedulerPosix.IOSelect, which has been superseded by
>>    SchedulerPosix.IOWait (or so it seems). How do we change it?

Although I've never looked at this code before, it looks as if the 
DPS code depends on all windows existing on a single display and 
X connection.  Look at the code and comment at line 750 of DPS.m3.
I believe that the "fd" in the variable "displaySource" is the 
only one that the code as written will ever wait upon.  This implies
that replacing the call to WaitForX() near the end of TalkToX() with

       SchedulerPosix.IOWait(displaySource.fd, TRUE)

might do the trick.

Ted Wobber
DEC SRC
</PRE>

<!-------------------------------------------------------------------------->
<HR>
<A NAME="x007">
<H2>Wrong socket types on Solaris</H2><P>
</A>

The wrong values are defined for socket types in Solaris.
Applications using TCP will be adversely affected.
The incorrect values cause a datagram socket to be created when a
stream socket is requested. Later stream oriented operations then
fail.
<P>

<EM>Patch:</EM><P>
Edit <TT>libm3/src/unix/solaris-2-x/Usocket.i3</TT> to
match this:
<PRE>
  (*
   * Types
   *)
  CONST
    SOCK_STREAM    = 2;            (* stream socket *)
    SOCK_DGRAM     = 1;            (* datagram socket *)
    SOCK_RAW       = 4;            (* raw-protocol interface *)
    SOCK_RDM       = 5;            (* reliably-delivered message *)
    SOCK_SEQPACKET = 6;            (* sequenced packet stream *)
</PRE>



<!-------------------------------------------------------------------------->
<HR>
<A HREF="home.html">[Modula-3 home page]</A>
<P>
<ADDRESS>m3-request@src.dec.com</ADDRESS>
<PRE>
Last modified on Wed Jun  8 09:19:54 PDT 1994 by kalsow
</PRE>

</BODY>
</HTML>



======================================================================= 45 ===
Date:    Wed, 8 Jun 1994 17:03:47 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: M3 3.1 for DOS available!

In article <Cr37Ct.EKI@undergrad.math.uwaterloo.ca>,
Craig Kingston <ckingsto@undergrad.math.uwaterloo.ca> wrote:
>In article <196*/S=Preschern/O=edvz/PRMD=uni-klagenfurt/ADMD=ada/C=at/@mhs>,
>Klaus Preschern <Preschern@edvz.uni-klagenfurt.ada.at> wrote:
>>Hi M3 world,
>>
>>SRC Modula-3 version 3.1 (m3build, m3ship, driver, compiler, library) for
>>DOS is available from "gatekeeper.dec.com:pub/DEC/Modula-3/contrib/M3forDOS".
>>Enjoy!
>>
>>	Klaus Preschern
>>
>What features are -not- available (eg are threads implemented yet?)

Threads? DOS? :)
-- 
-------------------------------------------------------------------
  Carsten Whimster              --- EDM/2 Associate Editor
  bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
-------------------------------------------------------------------


======================================================================= 46 ===
Date:    8 Jun 1994 22:40:14 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: M3 3.1 for DOS available!

In article <Cr31LH.6H2@undergrad.math.uwaterloo.ca>, bcrwhims@undergrad.math.uw
aterloo.ca (Carsten Whimster) writes:
> Does this have the shell that m3pc has for translating
> filename-length, and does it also require a co-processor? Or is this a
> different port? Could you talk about the features a bit?

Attached below is the top-level README.

 - Bill Kalsow

-----------------------------------------------------
Copyright (C) 1994, Klaus Preschern.
All rights reserved.
See the file COPYRIGHT.KP for a full description.

This is the file README.1st for the EX32 system Version 1.01.


1) What is the EX32 system ?
============================

EX32 ("A 32-bit Extension of DOS") is a environment for the developement
and execution of 32-bit applications with DOS.

EX32 is a collection of DOS programs (drivers + kernel). It provides
services for applications executed in protected mode. It does process
management, virtual memory management, interprocess communication
via pipes and it offers a file system with 32 character filenames.

EX32 runs on MS-DOS 5.00, 6.00 and 6.02. You need a i386/i387 (coprocessor
required) or upward (i486, Pentium). EX32 supports DOS XMS memory (but not
EMS, VCPI or DPMI). No support for the i286. You should have at least 4 MB
memory (8 MB or more recommended). The whole package occupies unzipped and
untared approximately 44 MB of disk space.

EX32 comes with GNU C++ (version 2.4.5), SRC Modula-3 (version 3.1,
including threads), two C libraries, a graphics library for VGA and a
number of commands (i.e. ls, cp, rm, mkdir, make, ...).

Note:	This is a system for experienced programmers! They should be
	familiar with Unix and DOS.


2) Installation
===============

This package is organized as follows:

a) Disk distribution (5 1.44 MB disks named disk1 ... disk5) or
b) ftp  distribution (5 directories named disk1 ... disk5)

For installation there is a DOS command file named "Ainstall.bat" on disk1
(in directory disk1). The ftp distribution should contain a copy of this file
named "install.bat" and the README.1st (this file) in the directory containing
the disk[1-5] directories.

To install with the *disk* distribution put disk1 in your disk drive and copy
the installation program to the hard disk: "COPY A:Ainstall.bat C:install.bat".
Run it from your hard disk (type: "install") and follow the instructions.
Note: The installation program will not work, if you run it from the floppy
because you have to change disks!

To install with the *ftp* distribution copy the disk[1-5] directories into
a directory named "\ex32dist" on your hard disk. Change into this directory
and type "install" or "disk1\Ainstall".


3) Contents of the Distribution
===============================

After installation you should have the following directories:

\ex32\bin		executeables (i.e. GNU C++ compiler)
\ex32\commands		sources of commands
\ex32\cplusinc		include directory for C++
\ex32\debug		sources of a simple debugger
\ex32\dev		directory for devices
\ex32\drivers		directory for drivers and driver files
\ex32\doc		documentation of the system (read "EX32.DOC")
\ex32\dos		DOS tools (i.e. for environment setup)
\ex32\glibc-1.06	GNU C library sources and include files
\ex32\include		PC library include files
\ex32\lib		directory for libraries, font files, etc.
\ex32\libsrc		PC library sources
\ex32\test		some test programs for Modula-3 and C
\ex32\tmp		directory for temporary files
\ex32\usr		user programs (i.e. Modula-3 compiler and packages)

End of README.1st


======================================================================= 47 ===
Date:    Wed, 08 Jun 1994 19:41:11
From:    j_mcarthur@BIX.com (Jeffrey McArthur)
Subject: Re: Was: ten lines per second?? Now: too beautiful?

I generally use Borland Pascal from the command line.
This does not compile to memory, it only compiles to disk.
This also includes linking.

It is a very fast system.  On another front there is a
new release of the Oberon system for Dos.  Supposedly,
I have not yet downloaded it, it has a very fast code
generation (possibly faster than Borland Pascal).

----
    Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
    a.k.a. Jeffrey McArthur          ATLIS Publishing
    phone: (301) 210-6655            12001 Indian Creek Court
    fax:   (301) 210-4999            Beltsville, MD  20705
    home:  (410) 290-6935            email: j_mcarthur@bix.com

The opinions express are mine and mine alone.  They do not reflect
the opinions of ATLIS Publishing or any part of ATLIS Systems.
ATLIS does NOT pay for my access to the Internet.


======================================================================= 48 ===
Date:    Thu, 9 Jun 1994 04:34:48 GMT
From:    erikhvh@knoware.nl (Erik van Heyningen)
Subject: Any chemists, physicists, or engineers uning M3?

I shouldn't have brought up the issue of what code is being generated. In
fact, you can use Sanscrit as an intermediate language, for all I care: the
point is that my PC is evidently capable of incredible compilation speed,
given software like Borland's.

Borland presumably optimized their product by writing some code in
assembler. Sure, you can't do that for 'all the machines in the world', but if
you do it for the 8086 family, you do it for most of the machines in the
world. If it's a lot of effort, do it only for a few machines (perhaps
offering cross-compilation).

As a programmer, I'm perfectly satisfied with BP running on my PC. However,
I'm also a physicist, and I would like to see my programs (once fully 
developed) run on better hardware.

So far, I haven't had any reactions from people actually using M3 to write
applications with lots of floating-point stuff. Isn't there anybody who, like
me, wanted portability but couldn't bring himself to writing in C or FORTRAN?




======================================================================= 49 ===
Date:    8 Jun 1994 11:56:25 +0200
From:    pausch@electra.saaf.se (Paul Schlyter)
Subject: Re: Fixed Point vs. Floating Point

In article <Cr1D5L.E5u.3@cs.cmu.edu>,
Donald Lindsay <lindsay+@cs.cmu.edu> wrote:
 
>>In article <2sh6vn$nuc@electra.saaf.se>,
>>Paul Schlyter <pausch@electra.saaf.se> wrote:
>>>If intermediate results are kept to 80-bit precision, rounding a result to
>>>double will occur only if the result is stored as a double somewhere in
>>>memory.
> 
> Hey - what about task switches that flush (and later reload) the FP
> register set?  Does that cause nondeterministic rounding?
 
NO!  A flush + later reload of the FPU must work the same way as for
the CPU, i.e. restiring each single bit to its original value!  Otherwise
nasty things will happen.
 
The Intel 80x87 FPU's (including the 486 and Pentium) has two special
FPU instructions:  "Save FPU state" and "Restore FPU state".  They both
take an address - a pointer to the start of RAM where to save/restore the
FPU state.  The area must be a few hundred bytes large, and the instruction
takes some time -- but it's very easy to program.  The entire FPU state
is saved/restored, including flags, precision bits, and the like.  And of
course the internal registers are restored to full 80-bit precision.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  SAAF (Swedish Amateur Astronomer's Society)
Nybrogatan 75 A,  S-114 40 Stockholm,  Sweden
InterNet:  pausch@saaf.se       psr@ausys.se


======================================================================= 50 ===
Date:    Thu, 9 Jun 1994 17:10:43 GMT+1
From:    89200004@vax1.may.ie
Subject: files/directories available on release-3.3

Would some-one have a detailed list of what actually is available on
release-3.3, or could they please inform me of someway of finding out.
Because otherwise I would have to download each file/directory individually, 
and this would take up alot of time and disk space (of which I have a very
limited amount).
Thanks alot,
Sinead Scully,
Computer Science Department,
St. Patrick's College,
maynooth,
Co. Kildare,
Ireland.
e-mail: 89200004@vax1.may.ie


======================================================================= 51 ===
Date:    Thu, 9 Jun 1994 13:13:20 GMT
From:    psu@cs.cmu.edu (Peter Su)
Subject: Re: Was: ten lines per second?? Now: too beautiful?

In article <2t54as$hop@ecnits.ecn.nl> you write:
>
>1) simply not true (have you taken a look at the Modula-3 code?)

How about comparing, say, Think C to gcc.

>2) TP is a single pass compiler, and you can chooses to compile
>   units (modules) to disk or store them in memory before linking

OK, so a single pass compiler compared to the typical UNIX brain
damage wherein you cpp/cc1/as/link in 4 phases with 4 separate
processes.  I stand by my statement.

>3) There is no difference in TP between linking in dev. and final mode,
>  the smart linker leaves out unused code and finishes a 30.000 line
>  program within several seconds (<5s) on a 486 PC.

I'll give you this one.  In Think Pascal/C, a final link phase is done
with all the modules already in memory, which makes it quicker than
the UNIX linker.

This of course begs the question, why hasn't anyone ever done a
better, faster UNIX linker.

Pete


======================================================================= 52 ===
Date:    9 Jun 1994 16:42:08 GMT
From:    barton@cupid.eche.ualberta.ca (Bob Barton)
Subject: M3 3.3 for AIX 3.2.5?

Has anyone been successful in getting Modula3 3.x working on an IBM RS/6000
running AIX 3.2.5? I have been trying off and on for a while now and am
having a problem getting libm3 to build (currently trying 3.3).

--,,,,
 | D |  R.L. Barton                    Department of Chemical Engineering
 | A |  Tel (403) 492-5160             University of Alberta 
 | C |  Fax (403) 492-2881             Edmonton, Alberta, Canada T6G 2G6
 | S |  Internet barton@chopin.eche.ualberta.ca
--''''


======================================================================= 53 ===
Date:    Thu, 9 Jun 1994 06:05:21 GMT
From:    sdame@atl.com (Steve Dame)
Subject: Re: Fixed Point vs. Floating Point

Pardon the intrusion into this discussion but this was the only way I could
figure out how to post to this group via "rn".  

My question is:  Has anyone characterized the Power PC 604 architecture in
terms of its use in doing a floating point DSP DOT product primitive?  By
this I mean the following. The typical DSP chip can perform a multiply-
accumulate, 2 data fetches and two post increments on memory index registers
(not to mention possible hardware circular buffer management) in a single
clock cycle.  Using a ficticious assembly construct:

FPc = FPc + FPa * FPb, FPa = (I0)+, FPb = (I1)+

I understand that the PPC604 can do several "things" in parallel but I can't
seem to nail down from the Motorola literature how many clock cycles it
would take to do the above operations.  If anyone (from Somerset maybe?) could
write down the instruction sequence for the above I would appreciated it as 
well.

Thanks in advance.

Steve Dame
sdame@atl.com



======================================================================= 54 ===
Date:    Fri, 10 Jun 1994 11:49:40 GMT
From:    zstern@adobe.com (Zalman Stern)
Subject: Re: Floating-point dot product on PowerPC (Was: Fixed Point vs. Floati
ng Point)

[This message was originally poseted to comp.arch.arithmetic and  
comp.lang.modula3. It properly belongs in comp.sys.powerpc which is where  
followups have been directed.]

Steve Dame writes
> My question is:  Has anyone characterized the Power PC 604 architecture in
> terms of its use in doing a floating point DSP DOT product primitive?  By
> this I mean the following. The typical DSP chip can perform a multiply-
> accumulate, 2 data fetches and two post increments on memory index  
registers
> (not to mention possible hardware circular buffer management) in a single
> clock cycle.  Using a ficticious assembly construct:
> 
> FPc = FPc + FPa * FPb, FPa = (I0)+, FPb = (I1)+
> 
> I understand that the PPC604 can do several "things" in parallel but I  
can't
> seem to nail down from the Motorola literature how many clock cycles it
> would take to do the above operations.  If anyone (from Somerset maybe?)  
could
> write down the instruction sequence for the above I would appreciated it  
as 
> well.

The base sequence looks something like so (single-precision):

loop:
    lfsu    fp1, 4(r3)
    lfsu    fp2, 4(r4)
    fmadds  fp0, fp2, fp1, fp0
    bdnz    loop

Except that you don't want to do it exactly that way since it will incur a  
load use penalty. With a three way unrolled loop, I was able to get three  
cycles per multiply on an MPC601 for fully in cache operation. (That's  
measured on an IBM RS/6000 model 250.) The MPC604 will let you get a closer  
to two cycles per multiply and will do double-precision without penalty.  
(The 601 takes another cycle to do a double-precision multiply.) The  
unrolled code with timing scaffolding is enclosed below.

For the 604, an extra two integer instructions might be scheduled into the  
loop. I expect the buffer management might be folded in for free.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

 #include "asmdefs.h"

	 .file	"asm_dotprod.s"
 .toc
 .csect .text[PR]
 .toc
 LC..0:
	 .tc FS_0[TC],0
 .csect .text[PR]
	 .align 2
	 .globl asm_dotprod1
	 .globl .asm_dotprod1
 .csect asm_dotprod1[DS]
 asm_dotprod1:
	 .long .asm_dotprod1, TOC[tc0], 0
 .csect .text[PR]

# float asm_dotprod(float *a,
#                   float *b,
#                   unsigned long count,
#                   unsigned long *microseconds)

asm_dotprod1:

	# pre-bias pointers for load-update use
	addi	r3, r3, -4
	addi	r4, r4, -4

	# zero factors to enable arbitrary loop entry
	lfs		fp0,LC..0(2)
	fmr		fp2, fp0
	fmr		fp3, fp0
	fmr		fp4, fp0
	fmr		fp5, fp0
	fmr		fp6, fp0

	# zero accumulators
	fmr		fp1, fp0
	fmr		fp7, fp0
	fmr		fp8, fp0

	# calculate count / 3 and remainder
	addi	r7, 0, 3
	divwu	r7, r5, r7
	addi	r8, r7, 1	# bias count for bdnz instruction
	mtspr	CTR, r8		# load loop count
	mulli	r7, r7, 3	# calculate remainder
	sf		r7, r7, r5

	# case on remainder.
	cmpi	cr6, r7, 1
	cmpi	cr7, r7, 2
	cmpi	cr5, r5, 0

	# get initial time
time_retry1:
	mfspr	r7, FROM_RTCU	# get upper part of RTC
	mfspr	r8, FROM_RTCL	# get lower part of RTC
	mfspr	r9, FROM_RTCU	# get upper part again
	cmp		cr0, r7, r9
	bne		time_retry1

	beq		cr6, remainder1
	beq		cr7, remainder2
	beq		cr5, done
    
loop:
    lfsu    fp0, 4(r3)          # load1
    lfsu    fp2, 4(r4)
    fmadds  fp8, fp3, fp4, fp8  # multiply-add2
remainder2:
    lfsu    fp3, 4(r3)          #load2
    lfsu    fp4, 4(r4)
    fmadds  fp1, fp5, fp6, fp1  # multiply-add3
remainder1:
    lfsu    fp5, 4(r3)          # load3
    lfsu    fp6, 4(r4)
    fmadds  fp7, fp0, fp2, fp7  # multiply-add1
    bdnz    loop

done:

	# get end time
time_retry2:
	mfspr	r9, FROM_RTCU	# get upper part of RTC
	mfspr	r10, FROM_RTCL	# get lower part of RTC
	mfspr	r11, FROM_RTCU	# get upper part again
	cmp		cr0, r9, r11
	bne		time_retry2

	# complete loop
	fmadds	fp8, fp3, fp4, fp8
	fmadds	fp1, fp5, fp6, fp1

	# compute sum, leaving in floating-point return register
	fadds	fp8, fp8, fp7
	fadds	fp1, fp1, fp8

	# compute microseconds value
    # convert nanoseconds to micro first
	sf		r10, r8, r10
    addi    r8, 0, 1000
    divw    r10, r10, r8
    # Now do seconds part
	sf		r11, r7, r11
    addi    r8, 0, 0x4240
    addis   r8, r8, 0xf
    mullw   r11, r11, r8
    add     r11, r11, r10

	# store time delta
	stw		r11, 0(r6)

	br

LT..asm_dotprod1:
	.long 0
	.byte 0,0,32,64,0,0,3,0
	.long 0
	.long LT..asm_dotprod1-.asm_dotprod1
	.short 7
	.byte "asm_dotprod1"
_section_.text:
csect .data[RW]
	.long _section_.text


======================================================================= 55 ===
Date:    Fri, 10 Jun 1994 08:44:01 GMT
From:    simonh@liverpool.ac.uk (Dr S. Hood)
Subject: Re: Any chemists, physicists, or engineers uning M3?

In article <erikhvh.5.00179532@knoware.nl>, erikhvh@knoware.nl (Erik van Heynin
gen) writes:
> 
> As a programmer, I'm perfectly satisfied with BP running on my PC. However,
> I'm also a physicist, and I would like to see my programs (once fully 
> developed) run on better hardware.
> 
> So far, I haven't had any reactions from people actually using M3 to write
> applications with lots of floating-point stuff. Isn't there anybody who, like
> me, wanted portability but couldn't bring himself to writing in C or FORTRAN?
> 

Yes!   I use Modula-2 for such programs.  I can get a free compiler for my
PC (for development at home) and a free compiler for work (on a Sun SPARC
station).  That suits me.

-- 

Simon		simonh@liv.ac.uk

P.S. If you want details of the comilers (ftp addresses etc) I can look them
     up.

Dr S Hood, Oceanography Labs, University of Liverpool, U.K.




======================================================================= 56 ===
Date:    Sat, 11 Jun 1994 03:34:36 GMT
From:    clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves)
Subject: Using X11 from Modula-3

I saw an X interface module for M3, and was trying to make a simple test
program to play with it. I keep getting te error:

> missing compiled interface "X.io" imported by:
>    xTest.m3
> 
> Fatal Error: incomplete program

I used the following options at compile time:

m3 Xtest.m3 -L/var/.software/local/x11/lib -lX11

Where /var/.software/local/x11/lib is the directory containing libX11.a. Am
I doing something obviously wrong here? Could the problem be in the fact
that the module is named "X", while the lib seems to be named "X11"? Am I
linking in the wrong lib?

-- 
  clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/
  Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo


======================================================================= 57 ===
Date:    11 Jun 1994 07:22:15 GMT
From:    elliottm@csulb.edu (Mike Elliott)
Subject: Re: Any chemists, physicists, or engineers uning M3?


   So far, I haven't had any reactions from people actually using M3 to
   write applications with lots of floating-point stuff. Isn't there
   anybody who, like me, wanted portability but couldn't bring himself to
   writing in C or FORTRAN?

Yes, absolutely!  My current work in Modula-3 is quite floating point
intensive.  It's even Physics!  

Although regular readers of this newsgroup are probably getting a bit sick
of hearing about it, I'm doing a trajectory simulation program, which also
includes satellite orbital calculations.

The trajectory simulation is all LongReal (64 bit reals) and involves the
usual Newtonian mechanics equations involving position, velocity and
acceleration.  Additionally I have to maintain the relative angular rate of
the aircraft relative to the earth rotating under it, and apply
accelerations and angular rates of change to the aircraft as it maneuvers
through the dark recesses of my DECStation.  

While a fair bit of floating point is used in this, it's more of an
exercise in linear algebra, as I'm constantly changing values from ECI
(Earth Centered, Inertial) coordinates to ECEF (Earth Centered, Earth
Fixed) to Latitude, Longitude, Altitude, to Local Level, to body
coordinates and back again, usually by multiplying by the requisite
direction cosine matrices (which also have to be maintained).

A typical situation might be the provision of angular rate expressed in
ECEF with respect to Local Level, or some equally obscure calculation.  In
Modula-3 I can provide the object with a method to perform this calculation
(which might be somewhat expensive to perform, so I don't want to do it
every time "just in case") but then one must determine when it should be
done.  

The technique I adopted was to provide a place for the value (it would be a
vector, so I'd use an AngularRateVector object) with a default value of
NIL.  If the method is invoked, it first looks to see if the value is
non-NIL.  If so, it simply returns that value.  If not, it calculates the
value then returns it.  This way I can provide lots of capabilities for
obscure inquiries, and only the ones actually requested are calculated, and
the calculation is done only when absolutely necessary.

Even more floating point intensive is the calculation of satellite position
and velocity from satellite ephemeris data.  Fortunately I was able to port
some legacy code in Ada (which was originally in Fortran) to do these
calculations, but it's just one polynomial after another, page after page.

The porting from Ada was trivial -- I probably spent no more than a couple
of hours moving stuff around and renaming a few things.  No particular
advantage was taken of Modula-3 constructs for the satellite stuff other
than declaring the variables along with their initial (and indeed only)
values, rather than separately declaring the variables, then the equations
which gave them their values as was done in the original Ada.  This sort of
thing could have been done just as easily in Ada as well, though, but I
have no knowledge of why it was not done so in this case.

The only clear advantage that Ada had over Modula-3 in the matrix algebra
stuff was the ability in Ada to overload the * and + operators to perform
matrix multiplication and addition (and a few other tricks involving matrix
transposition), which looked cleaner in the final code than my .mul() and
.add() methods, and the irritating need to put a D0 (that is D zero) on my
floating point literals in order to pass the Modula-3 strong typing
constraints. 

In general, floating point operations were not an issue -- the trig
functions I needed already had interfaces available (an advantage over Ada,
which doesn't even give you square root!), and I noticed a forest of other
higher math functions available which I didn't need this time such as
Bessel functions and hyperbolics and such.


--
======================================================================
Mike Elliott                                        elliottm@csulb.edu
======================================================================


======================================================================= 58 ===
Date:    Sun, 12 Jun 1994 23:48:49 GMT
From:    clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves)
Subject: Bug in SRC Modula-3 compiler

There seems to be a bug in the Modula-3 compiler here. It segfaults on some
simple set operations. Here's a test case:

MODULE test EXPORTS Main;

IMPORT Stdio, Wr;

VAR
    i : INTEGER;
BEGIN
    FOR i := 1 TO 5 DO
	IF i IN SET OF INTEGER { 3, 4 } THEN
	    Wr.PutText( Stdio.stdout, "In 3,4" );
	END
    END
END test.

And the output is:

***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0xeffff918 = LowPerfTool.ParamStartAndWait + 0xb58d6c
***

Quit

My guess is that it's trying to allocate 4 gigabits of space for the set...
That's a bit extreme. Seeing as the set would be incredibly large, and the
number of items I'm placing in it is very small, why doesn't it convert
this code to:

IF i = 3 OR i = 4 THEN

I'm pretty sure I used to do this in Turbo Pascal 4 all the time, and it
wouldn't complain.

-- 
  clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/
  Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo


======================================================================= 59 ===
Date:    13 Jun 1994 17:37:55 GMT
From:    damian@snoopy (Christof Damian)
Subject: SRC-Modula3 Port for AmigaOS ?

Title says it all, is there anybody working on a AmigaOS port of SRC-M3 ?
And were can I get good information on the language definition and perhaps
simple example programms explaining the features of the language. (I would
pregfer some ftp place with printable (ps,tex,txt) files or WWW.

Christof

--
mail  : Christof Damian, Sand 11/Drosselweg 12, 72076 Tuebingen, Germany
e-mail: damian@myplanet.tue.sub.org    adsp:damian@myplanet.adsp.sub.org
                 PGP:1317C8ACD258BC2729BEAE69CA533485

  German TECHNO+HOUSE Mailing List:derave-request@myplanet.tue.sub.org


======================================================================= 60 ===
Date:    13 Jun 1994 17:14:04 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Bug in SRC Modula-3 compiler

In article <CrB65D.M4D@undergrad.math.uwaterloo.ca>, clgonsal@undergrad.math.uw
aterloo.ca (Carl Laurence Gonsalves) writes:
> There seems to be a bug in the Modula-3 compiler here. It segfaults on some
> simple set operations. Here's a test case:
> 
> 	IF i IN SET OF INTEGER { 3, 4 } THEN
> 
> My guess is that it's trying to allocate 4 gigabits of space for the set...
> That's a bit extreme. Seeing as the set would be incredibly large, and the
> number of items I'm placing in it is very small, why doesn't it convert
> this code to:
> 
> IF i = 3 OR i = 4 THEN
> 
> I'm pretty sure I used to do this in Turbo Pascal 4 all the time, and it
> wouldn't complain.

I don't think I'd call this a bug.  See section 2.2.6 of SPwM3,

    Implementations are expected to use the same representation for a
    SET OF T as for an ARRAY T OF BITS 1 FOR BOOLEAN.  Hence, programmers
    should expect SET OF [0..1023] to be practical, but not SET OF INTEGER.

Of course, as is always the case, the compiler could generate better
code.

  - Bill Kalsow











======================================================================= 61 ===
Date:    13 Jun 1994 17:06:24 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Using X11 from Modula-3

In article <Cr7r9o.HLn@undergrad.math.uwaterloo.ca>, clgonsal@undergrad.math.uw
aterloo.ca (Carl Laurence Gonsalves) writes:
> I saw an X interface module for M3, and was trying to make a simple test
> program to play with it. I keep getting te error:
> 
> > missing compiled interface "X.io" imported by:
> >    xTest.m3
> > 
> > Fatal Error: incomplete program
> 
> I used the following options at compile time:
> 
> m3 Xtest.m3 -L/var/.software/local/x11/lib -lX11

Your m3makefile should include the line

    import ("X11R4")

Otherwise, the Modula-3 binding to the C layer is missing.

  - Bill Kalsow












======================================================================= 62 ===
Date:    Mon, 13 Jun 94 16:42:27 GMT
From:    pjb@ukc.ac.uk (P.J.Brown)
Subject: Re: Macros in Modula-3

hendrik@CAM.ORG (Hendrik Boom) writes:

: If you're going to use an off-the-shelf macro processor, you are probably
: better off with ML/1, a portable macro processor written in the 60's
: by P.J. Brown, and distributed through DECUS.  I'm not sure
: what the appropriate source for ML/1 is now, but I hear rumours that
: someone in England, possibly at the University of Canterbury in Kent,
: maintains it and does ports.
: 
: If anyone has better information, please let me know.
: 
Indeed ML/I still exists as a product.  It was designed in the early seventies
and shows it, but still gets orders.

As it happens I have recently written some ML/I macros to do a crude Pascal to
Modula-3 conversion.  The University of Kent is moving from Pascal to Modula-3
as its first undergraduate teaching language from next October.

Peter Brown


======================================================================= 63 ===
Date:    14 Jun 1994 00:20:12 +0200
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Bug in SRC Modula-3 compiler

In article <CrB65D.M4D@undergrad.math.uwaterloo.ca>,
Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>I'm pretty sure I used to do this in Turbo Pascal 4 all the time, and it
>wouldn't complain.

SET OF INTEGER is 4 gigabits in M3, 64 kilobits in TP.

--Arnt


======================================================================= 64 ===
Date:    Mon, 13 Jun 94 13:50:53 -0700
From:    msm@src.dec.com
Subject: Proposed language change


After having been bitten by this several times, I'd like to offer 
this simple proposal.

At present, ADR(x) always returns an ADDRESS.  I propose that ADR(x) 
be made polymorphic, and that it return UNTRACED REF static type 
of x.  

In general, this shouldn't make much difference; ADDRESS and UNTRACED 
REF Y are always compatible.  However UNTRACED REF X and UNTRACED 
REF Y generally aren't compatible.  Thus, a program that passed ADR(intVar 
(* : INTEGER *)) to a routine expecting an UNTRACED REF CHAR would 
currently succeed; under my proposal it would fail.

This will help me detect all of the lurking bugs in the ui module 
that resulted from converting X.i3 to use Ctypes.  In particular, 
I find that lots of code that works just fine when Ctypes.int and 
Ctypes.long coincide (as they do on MIPS, SUN, etc.) sometimmes fails 
then these types aren't equal.  Generally, that failure is due either 
to an incorrectly translated interface, or some code passing ADR(INTEGER) 
where it means ADR(Ctypes.int).

Mark



======================================================================= 65 ===
Date:    14 Jun 1994 01:58:19 GMT
From:    mako@FNALO.FNAL.GOV
Subject: Re: Bug in SRC Modula-3 compiler

> MODULE test EXPORTS Main;
>
> IMPORT Stdio, Wr;
>
> VAR
>     i : INTEGER;
> BEGIN
>     FOR i := 1 TO 5 DO
> 	IF i IN SET OF INTEGER { 3, 4 } THEN
> 	    Wr.PutText( Stdio.stdout, "In 3,4" );
> 	END
>     END
> END test.

The current Modula-3 compiler (V3.3) refuses to compile the above code:

|	"../src/test.m3", line 9: type has too many elements

							mako

PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
    Modula-3? You have got two different variable "i"s here.


======================================================================= 66 ===
Date:    Tue, 14 Jun 1994 08:08:14 GMT
From:    jmd6@unix.brighton.ac.uk (Jonathan Durrant)
Subject: SRC_Modula3 Install problem on LIBM3.

I have been trying to modula 3 on a Sun Sparc 1, with out much sucess:
when I build the libm3 module it just compiles indefinatly soaking the CPU.
I've just run it four 72 hours solid and it hasn't created any files since
30 mins after starting!

So far I have:
	unpacked boot-SPARC
	unpacked m3cc
	compiled these
	unpacked libm3
	tried to compile libm3

Has anyone experianced this and knows the cause.

Thanks

Jon
-- 
-------------------------------------------------------------------------------
				Jonathan Durrant
				Research Programmer 
				Computer Department
				The University of Brighton.


======================================================================= 67 ===
Date:    14 Jun 1994 01:48:09 GMT
From:    mako@FNALO.FNAL.GOV
Subject: Re: Proposed language change

> At present, ADR(x) always returns an ADDRESS.  I propose that ADR(x) 
> be made polymorphic, and that it return UNTRACED REF static type 
> of x.  

How about introducing a new function REF(X) (or something) that returns
UNTRACED REF X, leaving ADR(X) untyped? I find it more useful to have
both typed and untyped address_of functions.

					mako


======================================================================= 68 ===
Date:    14 Jun 1994 19:53:13 +0200
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Bug in SRC Modula-3 compiler

In article <CrEBuz.9r7@undergrad.math.uwaterloo.ca>,
John Kominek <jmkomine@neumann.uwaterloo.ca> wrote:
>In article <2tim2s$9bi@trondviggo.nvg.unit.no>, agulbra@nvg.unit.no (Arnt Gulb
randsen) writes:
>> Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>> >I'm pretty sure I used to do this in Turbo Pascal 4 all the time, and it
>> >wouldn't complain.

>> SET OF INTEGER is 4 gigabits in M3, 64 kilobits in TP.

>Good point. Presumably, it would be 16 exabits (2^64) on a DEC Alpha.

>This type of mistake lends weight to the argument that the size of
>an INTEGER should not equal that of the machine word, but be explicitly
>sized.

No it doesn't, IMHO.

SETs should be implemented in the fastest possible way.  The basic
integer type should be the biggest size the CPU will handle without
performance loss.  Both of these will vary, of course.  The maximum
size should be declared, but not specified completely.

C gets this right, I think.  K&R specifies ``mimimum maxima'' for
all the types.

>That is, replacing INTEGER with a buffet-selection of INTEGER1,
>INTEGER2, INTEGER4, and INTEGER8. Some of this can be done with bit
>packed types, but not so elegantly. 

Replacing?  I could agree with supplementing, but there are good
reasons why you might want bigger numbers on an alpha than on an old
Kaypro CP/M box:  The Alpha can deal with big data sets, the Kaypro
can't.  No reason to slow the Kaypro down with 64-bit ints in its
8-bit accumulator, no reason not to use the Alpha's 64-bit registers.

--Arnt


======================================================================= 69 ===
Date:    14 Jun 94 11:50:46
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: SRC_Modula3 Install problem on LIBM3.


Hi Jon. Nice to see someone trying Modula-3!

> I have been trying to modula 3 on a Sun Sparc 1, with out much
> sucess: when I build the libm3 module it just compiles indefinatly
> soaking the CPU.  I've just run it four 72 hours solid and it hasn't
> created any files since 30 mins after starting!

What release of SRC Modula-3 are you using? (You may want to include
this in your future bug reports, since at the moment there are 3
releases available from gatekeeper.dec.com!)

Modula-3 2.11 should compile ``out of the box'' on SPARCs. 

Modula-3 3.1 had some infinite loops in it, being the first SPARC
release after a major overhaul of the backend to generate native code.
It was primarily released so that people outside SRC can complete the
port to SPARCs. (It looks like you may be using the 3.1 release.)

Modula-3 3.3 fixed many of 3.1's problems. There are a few existing
problems with 3.3, which you can browse by viewing
ftp://ftp.gte.com:/pub/m3/m3-sparc.html. 

Also, there is an effort to make available binary versions of the
SPARC system by people outside DEC SRC, which should make its
installation easier for people trying it out.

Regards,
--

Farshad Nayeri
nayeri@gte.com


======================================================================= 70 ===
Date:    Tue, 14 Jun 1994 16:44:58 GMT
From:    jmkomine@neumann.uwaterloo.ca (John Kominek)
Subject: Re: Bug in SRC Modula-3 compiler

In article <2tim2s$9bi@trondviggo.nvg.unit.no>, agulbra@nvg.unit.no (Arnt Gulbr
andsen) writes:
> In article <CrB65D.M4D@undergrad.math.uwaterloo.ca>,
> Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
> >I'm pretty sure I used to do this in Turbo Pascal 4 all the time, and it
> >wouldn't complain.
> 
> SET OF INTEGER is 4 gigabits in M3, 64 kilobits in TP.
> 
> --Arnt


Good point. Presumably, it would be 16 exabits (2^64) on a DEC Alpha.

This type of mistake lends weight to the argument that the size of
an INTEGER should not equal that of the machine word, but be explicitly
sized. That is, replacing INTEGER with a buffet-selection of INTEGER1,
INTEGER2, INTEGER4, and INTEGER8. Some of this can be done with bit
packed types, but not so elegantly. 

There are other advantages. The following code 

    PROCEDURE DoStuff() =
    VAR
       anInt : INTEGER4;              (* note type *)
    BEGIN
       (* wonderful code here *)
        anInt := 1000000;
       (* more wonderful code *)
    END DoStuff;


would actually port from a DecStation to an AT. 

Moreover, with INTEGER8 types, our national debt could be exactly
manipulated down to the last penny. As it stands, EXTENDED must
be used to mess around with large financial figures -- ugly!

John
 


======================================================================= 71 ===
Date:    14 Jun 1994 21:32:17 GMT
From:    uk9r@rzstud1.rz.uni-karlsruhe.de (Wolfgang Greiner)
Subject: Problem with threads under Linux with SRC 3.1

Hi!

I have a problem with threads under Linux with SRC-Modula-3
Version 3.1:
When I try to start a thread with Thread.Fork
I get the message "Virtual time alarm". What does this 
mean?

Thanks for Your help

  Wolfgang


======================================================================= 72 ===
Date:    15 Jun 94 04:53:12 GMT
From:    kevin@insane.apana.org.au (Kevin O'Neill)
Subject: Where to get the FAQ via ftp

Sorry to ask, but where can I get the FAQ for this news group.

I don't have WWW access so I'd need to FTP it.

Regards,

Kevin

-- 
| Kevin O'Neill                                               |
|-------------------------------------------------------------|
| Internet:  kevin@insane.arpana.org.au  Phone: (03) 245-1264 |
| AppleLink: AUST0299                      Fax: (03) 646-2755 |


======================================================================= 73 ===
Date:    14 Jun 94 19:15:01
From:    vixie@vix.com (Paul A Vixie)
Subject: Re: Bug in SRC Modula-3 compiler

I always hope that an M2 implementation will allow SET OF CHAR since it's
so darn convenient for keeping track of end conditions when parsing text.
If anyone changes M3's SET definitions, please keep this in mind.
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<paul@vix.com>


======================================================================= 74 ===
Date:    Wed, 15 Jun 94 13:12:33 GMT
From:    buschman@slsvirt (Andreas Buschmann US/END 60/1/29 Tel.71409)
Subject: Re: Bug in SRC Modula-3 compiler

John Kominek (jmkomine@neumann.uwaterloo.ca) wrote:

: > SET OF INTEGER is 4 gigabits in M3, 64 kilobits in TP.

: This type of mistake lends weight to the argument that the size of
: an INTEGER should not equal that of the machine word, but be explicitly
: sized. That is, replacing INTEGER with a buffet-selection of INTEGER1,
: INTEGER2, INTEGER4, and INTEGER8. Some of this can be done with bit
: packed types, but not so elegantly. 

INTEGER is not bound to the machine word in Modula3.

It is the largest available integral type for some compiler / machine
Combination. 

If you want a bigger integral type, let's say 128 Bits wide on a sun
sparc, the Language Report wants you to name this one INTEGER, and
_never_ something like LONG INTEGER or LONG LONG INTEGER.

That way all the different integral types can be declared using the
lower bound, upper bound notation, and a _user_ of the integral
datatypes doesn't have to bother with converting to / from LONG LONG
INTEGER. 

It also helps to keep the language definition short and elegant. 

				Tschuess
					Andreas 
-- 
#include <stddisclaimer.h>

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

	buschman@lts.sel.alcatel.de		# we have a new domain address
	buschman@us-es.sel.de			# our old domain address


======================================================================= 75 ===
Date:    Wed, 15 Jun 1994 15:10:10 GMT
From:    bnfb@scs.carleton.ca (Bjorn Freeman-Benson)
Subject: OOPSLA'94 Electronic Information Hotline

    	    OOPSLA'94 ELECTRONIC INFORMATION HOTLINE

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

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

________________ WHAT INFORMATION IS AVAILABLE ____________________

The Hotline is essentially the on-line version of the Advanced Program.
Thus the Hotline includes:
  * Welcome to OOPSLA'94
  * The schedule of the Technical Program (papers, panels, invited talks)
  * Details of the available Tutorials
  * Details of the Workshops being organized
  * Postscript version of the Conference and Hotel Registration Forms
  * Tourist information about Portland
  * etc., etc.

__________ HOW TO RECEIVE MORE INFORMATION ELECTRONICALLY _________

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

                            W W W

http://ursamajor.uvic.ca/oopsla94.html
    -or-
http://142.104.88.151/oopsla94.html
    -or-
http://cui_www.unige.ch/OSG/OOinfo/Conf/OOPSLA/oopsla94.html

                         G O P H E R

gopher ursamajor.uvic.ca
    -or-
gopher 142.104.88.151

                           W A I S

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

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

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

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

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

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

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

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

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

____________________ CONTACT WITH A PERSON ________________________

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

    	    	    	>>> PLEASE <<< 

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


======================================================================= 76 ===
Date:    Wed, 15 Jun 1994 16:18:38 GMT+1
From:    89200004@vax1.may.ie
Subject: warning messages in Modula-3.3

Hi,
I am porting a Modula-3 compiler to CS-Sun network(Solaris 2.3) running
on SPARC Classic machines, architecture Sun4m. I am using the latest
version of the compiler (ie 3.3)
I am however experiencing a few problems....
When I do m3build I experience a large number of warnings of the type
_m3main.c, line 484 initializer does not fit:178
Bill Kalsow said that my _m3main.c files were different than what was
released (suggested might be due to ftp'ing), it included a number
of additional line breaks. In case this was the problem I downloaded
everyting again, and started from the beginning. However when I did m3boot on
boot-SOLsun I got the same warnings (I must point out that these warnings
occur during the linking stage, they also occur at any time I attempt to
compile a program using m3build)
Though I know they are only warnings, they occur in such vast quantities

and so often that I don't like them. I have successfully ported the 
modula-3 compiler to DS3100 and these warnings do not occur.

I am using a compatability compiler (rather than SUNWspro) and gnumake,
could this be the problem ?

I have some errors also(which occur when trying to use trestle, seemingly
this is due to problems with threads. The error I get while trying to 
run Hello eg is
runtime error
segmentation violation-possible attempt to dereference NIL
I got this same error each time I tried to run a program in the trestle
directory and 'badbricks' in the games directory.
has anyone with the same platform as myself managed to successfully port
the M3 compiler to SOLsun
If anyone has any idea about what my problem is I would appreciate
their help.
Thanks again,
Sinead Scully,
Computer Science Department,
St Patrick's College,
Maynooth
Co. Kildare
Ireland.
e-mail : 89200004@vax1.may.ie


======================================================================= 77 ===
Date:    15 Jun 94 10:49:31
From:    gary@odin.dfci.harvard.edu (Gary Beckmann)
Subject: Re: Bug in SRC Modula-3 compiler

>>>>> "agulbra" == Arnt Gulbrandsen <agulbra@nvg.unit.no> writes:

agulbra> SETs should be implemented in the fastest possible way.  The basic
agulbra> integer type should be the biggest size the CPU will handle without
agulbra> performance loss.  Both of these will vary, of course.  The maximum
agulbra> size should be declared, but not specified completely.

agulbra> C gets this right, I think.  K&R specifies ``mimimum maxima'' for
agulbra> all the types.

Sorry, C did not get it right. The type of "integer" should be the
theoretical type that is infinite, and then a series of sub-types
should be offered (though I think the names INTEGER1, etc. remind too
much of FORTRAN for comfort).  But the having a type that varies in
size from machine to machine really shoots down portability.  


agulbra> Replacing?  I could agree with supplementing, but there are good
agulbra> reasons why you might want bigger numbers on an alpha than on an old
agulbra> Kaypro CP/M box:  The Alpha can deal with big data sets, the Kaypro
agulbra> can't.  No reason to slow the Kaypro down with 64-bit ints in its
agulbra> 8-bit accumulator, no reason not to use the Alpha's 64-bit registers.

I don't really use 64-bit ints regularly, but 32-bits seems pretty
stock, and anything smaller would probably break most programs I use.
But, as long as I depend on the compiler writer and HW designer, I set
myself up.  Computer programming is not mathematics, it is dealing
with finite things.  The best way to avoid the "gotchas" is to
explicitly name those finite things, because if you don't, someone
else will.  Having an "amazing expanding and shrinking" type like
INTEGER only allows us to set ourselves up.


--
--
					Gary Beckmann
					gary@gog.dfci.harvard.edu
Joint Center for Radiation Therapy
50 Binney Street			voice: (617)735-8781
Boston, MA 02115			fax:   (617)735-8772	
 
RSA
22 Terry Ave.				voice: (617)238-0600
Burlington, MA 01803			fax:   (617)238-0606


======================================================================= 78 ===
Date:    15 Jun 1994 20:24:46 GMT
From:    jcm@Iswim.Stanford.EDU (John C. Mitchell)
Subject: Collection of Articles




	 Theoretical Aspects of Object-Oriented Programming:
		Types, Semantics, and Language Design

			      edited by
		 Carl A. Gunter and John C. Mitchell


A collection of articles on the above-mentioned subject is now
available from MIT Press.  Even if you don't order a copy, you might
enjoy looiking at the cover illustration by Luca Cardelli.

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

Theoretical Aspects of Object-Oriented Programming: Types, Semantics,
and Language Design, Carl A. Gunter and John C. Mitchell editors, MIT
Press Foundations of Computing Series, x+548 pages.

@book{GUNTER-MITCHELL94,
editor = "C. A. Gunter and J. C. Mitchell",
title = "Theoretical Aspects of Object-Oriented Programming: 
         Types, Semantics, and Language Design",
year = "1994",
publisher = "The {MIT} Press"}

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

CONTENTS

Series Forward							vii

Introduction							  1

  I Objects and Subtypes

  1. User-Defined Types and Procedural Data Structures as
     Complementary Approaches to Data Abstraction		 13
     John C. Reynolds

  2. Using Category Theory to Design Implicit Conversions
     and Generic Operators					 25
     John C. Reynolds

 II Type Inference						 65

  3. Type Inference for Records in a Natural Extension of ML
     Didier Re'my						 67

  4. Type Inference for Objects with Instance Variables and
     Inheritance.
     Mitchell Wand						 97

  5. Static Type Inference for Parametric Classes
     Atsushi Ohori and Peter Buneman				121

III Coherence							149

  6. A Modest Model of Records, Inheritance and
     Bounded Quantification
     Kim Bruce and Guiseppe Longo				151

  7. Inheritance as Implicit Coercion
     Val Breazu-Tannen, Thierry Coquand, Carl A. Gunter,
     and Andre Scedrov						197

  8. Coherence of Subsumption, Minimum Typing and
     Type-Checking in F<=
     Pierre-Louis Curien and Giorgio Ghelli			247

 IV Record Calculi						293

  9. Operations on Records
     Luca Cardelli and John C. Mitchell				295

 10. Typing Record Concatenation for Free
     Didier Re'my						351

 11. Extensible Records in a Pure Calculus of Subtyping
     Luca Cardelli						373

 12. Bounded Quantification is Undecidable
     Benjamin C. Pierce						427

  V Inheritance							461

 13. Two Semantic Models of Object-Oriented Languages
     Sam Kamin and Uday Reddy					463

 14. Inheritance is Not Subtyping
     William R. Cook, Walter L. Hill and Peter S. Canning	497

 15. Toward a Typed Foundation for Method Specialization 
     and Inheritance
     John C. Mitchell						519

Contributors							547

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

ABSTRACT FROM THE INTRODUCTION

This volume comprises fifteen chapters, by selected authors, on
theoretical aspects of object-oriented programming languages.  The
focus is on type systems and semantic models, and how advances in
these areas can contribute to new language designs.  The collection is
divided into five parts: Objects and Subtypes, Type Inference,
Coherence, Record Calculi, Inheritance.  The chapters are organized
approximately in order of increasing complexity of the language
constructs they consider.  Put briefly, the collection begins with
variations on Pascal- and Algol-like languages, develops the theory of
illustrative record object models, and concludes with research
directions for developing a more comprehensive theory of
object-oriented programming languages.

Part I discusses the similarities and differences between OBJECTS and
algebraic-style abstract data types, and address general problems
associated with subtyping (or subclasses) in the presence of
operations that may be applied to objects of more than one type.

Parts II--IV, which form the core of the collection, are concerned
with what may be called the RECORD MODEL of object-oriented
languages. More specifically, these chapters discuss static and
dynamic semantics of languages with simple object models that include
a type or class hierarchy, but do not explicitly provide what is often
called DYNAMIC BINDING or DYNAMIC METHOD LOOKUP.  Part II develops the
record model incrementally, beginning with a simple extension of the
record operations from the language ML.  The denotational semantics of
these languages are considered in Part III, with more elaborate record
object models and more precise connections with object-oriented
methodology developed in Part IV.

Extensions and modifications to record object models are considered in
Part V.  These chapters bring us closer to the full complexity of
practical object-oriented languages.  However, the complete
theoretical underpinnings of the language features discussed in Part V
remain a topic for future research.

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

OBTAINING A COPY

Available from bookstores or directly from The MIT Press.

Price: $45.00 Cloth
ISBN: 0-262-07155-X

For orders in the US, please contact:
     The MIT Press
     55 Hayward Street
     Cambridge, MA  02142-1399
     Phone:  +1 (617) 625-8569
     Fax:    +1 (617) 625-6660
     E-mail: <mitpress-orders@mit.edu>
             <mitpress-orders-inq@mit.edu> for Customer Service

For orders and inquiries in the UK, Eire, and continental Europe, please
contact our London office:
     The MIT Press
     Fitzroy House
     11 Chenies Street
     London WC1E 7ET,  England
     Phone:  +44 (071) 306-0603
     Fax:    +44 (071) 306-0604
     E-mail: <100315.1423@compuserve.com>

In Australia, please contact our distributor:
     Astam Books
     57-61 John Street
     Leichhardt,  NSW 2040
     Phone: (02) 566-4400
     Fax:   (02) 566-4411

In all other countries, please contact:
     International Department
     The MIT Press
     55 Hayward Street
     Cambridge, MA  02142
     Phone: +1 (617) 253-2887
     Fax:   +1 (617) 253-1709
     E-mail: <curtin@mit.edu>

Please note that prices may be higher outside the US.



======================================================================= 79 ===
Date:    16 Jun 1994 01:04:40 +0200
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Bug in SRC Modula-3 compiler

In article <GARY.94Jun15104931@odin.dfci.harvard.edu>,
Gary Beckmann <gary@odin.dfci.harvard.edu> wrote:
>>>>>> "agulbra" == Arnt Gulbrandsen <agulbra@nvg.unit.no> writes:
>agulbra> C gets this right, I think.  K&R specifies ``mimimum maxima'' for
>agulbra> all the types.
>
>Sorry, C did not get it right. The type of "integer" should be the
>theoretical type that is infinite, and then a series of sub-types
>should be offered (though I think the names INTEGER1, etc. remind too
>much of FORTRAN for comfort).  But the having a type that varies in
>size from machine to machine really shoots down portability.  

I disagree.  There probably is a place for bignums, though I can't
recall having needed them personally.  If portability is hurt by
different ints, that's because the machines differ, not because the
language expresses the machine well.  (Last fall we bought a
big-name c++ library, and it didn't handle endianness in user data
files right -- same size types didn't help there.)

But certainly there's a need for fast integer variables.  As you say,

>Computer programming is not mathematics, it is dealing
>with finite things.

I agree completely.

>  The best way to avoid the "gotchas" is to
>explicitly name those finite things, because if you don't, someone
>else will.  Having an "amazing expanding and shrinking" type like
>INTEGER only allows us to set ourselves up.

Uh-huh... I agree, sort of, but let me try again without names.

I think there's a need for an integer type that is:
 - as fast as the machine will allow
 - as big as the machine will allow without slowing down operation

I also think this type should have specified constraints, much like
the constraints C puts on 'int' so programs can stay out of
trouble.  (For example, I fixed RCS recently to get around a
compiler bug, it had problems reading in ASCII numbers from a file
to an int.  That operation needs to compare against something, and I
think that something should be MAX(TYPENAME), not some defined
constant like 4123456789.  If all ints were 32 bits that still
wouldn't help RCS, it would need to check the size in case someone
had edited the data file with an editor.)

Further, I think there is a need for specifically-sized types.  I
even think there's a need for specific-endian types, since even big,
well-debugged C programs keep missing {n,h}to{h,b}{s,l}.

If nobody disagrees with these principles, perhaps we could discuss
whether any new types should be added to M3?

--Arnt


======================================================================= 80 ===
Date:    16 Jun 1994 09:24:00 GMT
From:    jont@ocs.mq.edu.au (Jonathon Earnshaw TIDSWELL)
Subject: Windows-NT (was Re: Ten lines per second??)

In article 94Jun6101409@froh.vlsi.polymtl.ca, dagenais@froh.vlsi.polymtl.ca (Mi
chel Dagenais) wrote:

> The DOS version is a derivative of the original compiler and was not
> planned for DOS. I am told that it is very sensitive to the amount of
> memory available, among other things.

There have been some mentions of a Windows-NT version, given that gcc has been
ported the compiler should be feasible.
However the graphics tools are another matter.
Which brings me to the question: do the m3 graphical libraries use Xlib or Xt ?

---
Jonathon Earnshaw Tidswell

Postgraduate Student, Department of Computing
School of Mathematics, Physics, Computing and Engineering
Macquarie University, NSW Australia 2039
Phone: +61 2 850 9507    Fax: +61 2 850 9551    Internet: jont@mpce.mq.edu.au
---
Research Fellow
Microsoft Institute of Advanced Software Technology
65 Epping Road North Ryde NSW Australia 2062
Phone: +61 2 870 2776    Fax: +61 2 870 2255    Internet: t-jont@microsoft.com
---
Disclaimer: I think my thoughts are my own, and I believe my writings are too.
"These are my opinions, others may have similar ones, but these are MINE."



======================================================================= 81 ===
Date:    Wed, 15 Jun 1994 17:52:21 +0200 (MET DST)
From:    thomas.tensi@fi.sdm.de (Dr. Thomas Tensi)
Subject: Literate Programming in Modula-3

Hello M3-community,


(for those interested in doing literate programming in Modula-3:)

I have done a Spider file for Norman Ramsey's Spiderweb system. The Spiderweb
System is a generator which takes an augmented grammar and produces a WEAVE
and TANGLE for the language specified by the grammar (it is based on Silvio
Levy's CWEB programs).

The m3.spider file is in total about 250 lines; hence I can send it by E-mail
to those interested. To build the WEAVE and TANGLE you need the Spiderweb
system (which is freely distributable), awk and a C compiler.

Currently the m3.spider is in a late beta stage. So if you are really keen on
having it now, you can. But I guess in two weeks from now it's more stable...

Mail me if you're interested.


                       Thomas


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


======================================================================= 82 ===
Date:    Thu, 16 Jun 1994 04:35:27 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: Bug in SRC Modula-3 compiler

In article <CrGw8G.6q6@undergrad.math.uwaterloo.ca>,
Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>In article <2tj2rr$lt4@fnnews.fnal.gov>,  <mako@FNALO.FNAL.GOV> wrote:
>>> MODULE test EXPORTS Main;
>>>
>>> IMPORT Stdio, Wr;
>>>
>>> VAR
>>>     i : INTEGER;
>>> BEGIN
>>>     FOR i := 1 TO 5 DO
>>> 	IF i IN SET OF INTEGER { 3, 4 } THEN
>>> 	    Wr.PutText( Stdio.stdout, "In 3,4" );
>>> 	END
>>>     END
>>> END test.
>>
>>The current Modula-3 compiler (V3.3) refuses to compile the above code:
>>|	"../src/test.m3", line 9: type has too many elements
>
>I'm not completely sure which version of Modula-3 I was using. I didn't
>install it, and m3 doesn't seem to have any option to ask it wat version it
>is. I got not compile or runtime errors. It just segfaulted.

Use which to find out where it is. The directory name has the version
number in it.

>>PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
>>    Modula-3? You have got two different variable "i"s here.
>
>Why is the declaration "VAR i: INTEGER;" unnecessary?

Because the for loop automatically declares an unalterable INTEGER i
for the loop only.

>And no, I've only got one variable i... the above was a test program. It
>wasn't meant to do anything useful. I first found the bug in a much larger
>program, and made the above tiny test case to see if it always segfaulted.
>It did.
-- 
-------------------------------------------------------------------
  Carsten Whimster              --- EDM/2 Associate Editor
  bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
-------------------------------------------------------------------


======================================================================= 83 ===
Date:    16 Jun 94 02:33:32
From:    vixie@vix.com (Paul A Vixie)
Subject: Re: Bug in SRC Modula-3 compiler

> I don't really use 64-bit ints regularly, but 32-bits seems pretty
> stock, and anything smaller would probably break most programs I use.
> But, as long as I depend on the compiler writer and HW designer, I set
> myself up.  Computer programming is not mathematics, it is dealing
> with finite things.  The best way to avoid the "gotchas" is to
> explicitly name those finite things, because if you don't, someone
> else will.  Having an "amazing expanding and shrinking" type like
> INTEGER only allows us to set ourselves up.

My experience in writing portable networking code in C (on the BIND project)
led me to cause to be included in 4.4BSD and subsequent systems a set of types
which specify a size and and encode that size in their names.  I don't think
that a direct mapping of these names into M3 would be possible or useful, but
it's a starting point.  Future versions of the U* interfaces will have to be
able to express these types -- I hope it won't be via subtle system-dependent
uses of various existing names.  

	signed		unsigned

	int8_t		u_int8_t
	int16_t		u_int16_t
	int32_t		u_int32_t
	int64_t		u_int64_t

I'm not totally sure I understand why M3 lacks CARDINAL ("unsigned int") types,
but this is going to become an issue for real world network programming, too.
M3 is definitely at the "grab more market share or die" stage of its growth;
adding a few impure warts to make it more useful to the average programmer (me,
for example) doing average things like protocol implementations where the 
protocol already exists and has many other implementations with which we need
to interoperate, could be the difference between "end-of-life" and "niche".
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<paul@vix.com>


======================================================================= 84 ===
Date:    Wed, 15 Jun 1994 18:22:18 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Problem with threads under Linux with SRC 3.1


   I have a problem with threads under Linux with SRC-Modula-3
   Version 3.1:
   When I try to start a thread with Thread.Fork
   I get the message "Virtual time alarm". What does this 
   mean?

This is a known problem. Release 3.1 was targeted at brave souls
taking care of porting problems. The current release, 3.3,
compiles almost out of the box. I will be announcing binaries and
diffs as soon as things settle. Everything is pretty much
compiled. I am testing applications and awaiting an official
registered address space to build shared libraries. If you need
something sooner, i can make my current binaries available.
--

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


======================================================================= 85 ===
Date:    Thu, 16 Jun 1994 02:00:14 GMT
From:    clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves)
Subject: Re: Bug in SRC Modula-3 compiler

In article <2tj2rr$lt4@fnnews.fnal.gov>,  <mako@FNALO.FNAL.GOV> wrote:
>> MODULE test EXPORTS Main;
>>
>> IMPORT Stdio, Wr;
>>
>> VAR
>>     i : INTEGER;
>> BEGIN
>>     FOR i := 1 TO 5 DO
>> 	IF i IN SET OF INTEGER { 3, 4 } THEN
>> 	    Wr.PutText( Stdio.stdout, "In 3,4" );
>> 	END
>>     END
>> END test.
>
>The current Modula-3 compiler (V3.3) refuses to compile the above code:
>
>|	"../src/test.m3", line 9: type has too many elements

I'm not completely sure which version of Modula-3 I was using. I didn't
install it, and m3 doesn't seem to have any option to ask it wat version it
is. I got not compile or runtime errors. It just segfaulted.

>PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
>    Modula-3? You have got two different variable "i"s here.

Why is the declaration "VAR i: INTEGER;" unnecessary?

And no, I've only got one variable i... the above was a test program. It
wasn't meant to do anything useful. I first found the bug in a much larger
program, and made the above tiny test case to see if it always segfaulted.
It did.

-- 
  clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/
  Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo


======================================================================= 86 ===
Date:    Thu, 16 Jun 94 08:42:14 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: Windows-NT (was Re: Ten lines per second??)


From: jont@ocs.mq.edu.au (Jonathon Earnshaw TIDSWELL)
Date: 16 Jun 1994 09:24:00 GMT
Subject: Windows-NT (was Re: Ten lines per second??)
Newsgroups: comp.lang.modula3
Reply-To: jont@ocs.mq.edu.au
Message-ID: <2tp5ng$1aq@sunb.ocs.mq.edu.au>

> In article 94Jun6101409@froh.vlsi.polymtl.ca, dagenais@froh.vlsi.polymtl.ca (
Michel Dagenais) wrote:
>
>> The DOS version is a derivative of the original compiler and was not
>> planned for DOS. I am told that it is very sensitive to the amount of
>> memory available, among other things.
>
>There have been some mentions of a Windows-NT version, given that gcc has been
> ported the compiler should be feasible.
> However the graphics tools are another matter.
> Which brings me to the question: do the m3 graphical libraries use Xlib or Xt
 ?
>
> ---
> Jonathon Earnshaw Tidswell

The Unix implementation of Trestle (which is the lowest-level graphics 
interface) uses Xlib as its display interface on Unix. The implementation 
is factored so as to make it fairly straightforward to use another 
system as the display interface. Some initial work may have been 
done to use Win32 as a display interface, but I'm not positive. In 
any case, it should be doable without a lot of pain.

--geoff




======================================================================= 87 ===
Date:    16 Jun 1994 13:37:52 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: Problems with SRC Modula-3 Release 3.3 under Linux

Hi all!

If anybody experiences installation problems with package "libm3" of
release 3.3 under Linux they may be due to "non-clean" entries in some
of the makefiles. For me, two minor changes saved the day.


1. In "libm3/src/list/m3makefile" change the two lines

     Generic_module(List)
     Generic_module(ListSort)

   situated at the beginning to

     Generic_module("List")
     Generic_module("ListSort")

   by just inserting the double quotes!


2. Similarly, in "libm3/src/table/m3makefile" change the line

     Generic_module(Table)

   situated at the beginning to

     Generic_module("Table")

   by just inserting the double quotes!


Furthermore, threads still do not seem to work under Linux. Or has anybody
had real success in not only installing and compiling but also running
multi-threaded applications under Linux, e.g. programs using trestle?

Other than that, everything installed smoothly out of the box.

=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!"


======================================================================= 88 ===
Date:    Thu, 16 Jun 1994 16:37:33 GMT
From:    mmeola@cahill (Matt Meola)
Subject: Interfaces in v3.3 ...

Has anyone noticed that in version 3.3, the 'Dir' interface went away?
Same for 'FileStream'...

Where did they go?  Any ideas?



(********************************************************)
(* Matt Meola        mmeola@cahill.ecte.uswc.uswest.com *)
(* NRA Life Member, Militiaman, Libertarian             *)
(* Gun control means using two hands.                   *)
(********************************************************)


======================================================================= 89 ===
Date:    Thu, 16 Jun 94 15:38:21 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: Re: Interfaces in v3.3 ...


> From: mmeola@cahill.pa.dec.com (Matt Meola)
> Date: Thu, 16 Jun 1994 16:37:33 GMT
> Subject: Interfaces in v3.3 ...
> Newsgroups: comp.lang.modula3
> Sender: news@da_vinci.ecte.uswc.uswest.com (IT Netnews)
> Message-ID: <CrI0uL.D8w@da_vinci.ecte.uswc.uswest.com>
> 
> Has anyone noticed that in version 3.3, the 'Dir' interface went away?
> Same for 'FileStream'...
>
> Where did they go?  Any ideas?

Done away by the Interface Police. The replacements should
be

    FS
    File

 --geoff

 


======================================================================= 90 ===
Date:    Thu, 16 Jun 1994 19:18:38 GMT
From:    jmkomine@neumann.uwaterloo.ca (John Kominek)
Subject: Re: Bug in SRC Modula-3 compiler


> >In article <2tim2s$9bi@trondviggo.nvg.unit.no>, agulbra@nvg.unit.no (Arnt Gu
lbrandsen) writes:

> SETs should be implemented in the fastest possible way.  The basic
> integer type should be the biggest size the CPU will handle without
> performance loss.  Both of these will vary, of course.  The maximum
> size should be declared, but not specified completely.

     Your make-it-the-word-size-for-speed argument also applies to
     floating point numbers.  But behold!  M3 has three REAL types
     when most modern FPUs have 64 bit registers. Computer numbers
     are there to serve programmers, not the other way around.

     My main complaint with variable sized INTEGERs is that they
     violate one of the fundamental principles of high level language
     programming: that the semantics of a program should not depend
     on the machine it running on, especially when using the core
     facilities. A simple "VAR Num: INTEGER := 1000000" declaration
     should not compile on one machine but fail to do so on another.

> C gets this right, I think.  K&R specifies ``mimimum maxima'' for
> all the types.

     C seldom gets anything right!
> 
> >That is, replacing INTEGER with a buffet-selection of INTEGER1,
> >INTEGER2, INTEGER4, and INTEGER8. Some of this can be done with bit
> >packed types, but not so elegantly. 
> 
> Replacing?  I could agree with supplementing ...

     I could go along with that.

     The fundamental thing at issue is what set of types should be
     build into a 3GL? This is a controversial question. Observe
     the big furour about adding complex types to ISO Modula-2.
     Given my physics background I'd like to see them, but those
     nerdy systems programmers never do!

     Incidentally, Oberon-2 has three fixed size integer types:
     SHORTINT, INTEGER, and LONGINT.

John


======================================================================= 91 ===
Date:    Thu, 16 Jun 94 15:39:10 -0700
From:    mcjones@src.dec.com
Subject: Re: Interfaces in v3.3 ...

    > Has anyone noticed that in version 3.3, the 'Dir' interface went away?
    > Same for 'FileStream'...
    >
    > Where did they go?  Any ideas?

    Done away by the Interface Police. The replacements should
    be

        FS
        File

Actually, the replacement for FileStream is FileRd and FileWr.


======================================================================= 92 ===
Date:    17 Jun 1994 00:53:52 GMT
From:    mako@FNALF.FNAL.GOV
Subject: Re: Interfaces in v3.3 ...

>> Where did they go?  Any ideas?
>
> Done away by the Interface Police. The replacements should
> be
[...]

Fine, but would it be too much work for the Interface Police to provide
a brief document stating which is superseded by which (and why, too?)
for each new release? I see a few similar inquiries every time a new
version is released...
						mako


======================================================================= 93 ===
Date:    17 Jun 1994 01:08:48 GMT
From:    mako@FNALF.FNAL.GOV
Subject: Re: Proposed language change

> How about introducing a new function REF(X) (or something) that returns
> UNTRACED REF X, leaving ADR(X) untyped? I find it more useful to have
> both typed and untyped address_of functions.

On second thought, maybe there wouldn't be much use in untyped address_of
function if you have a typed address_of function (except perhaps to make it
a bit more clear that you are interested in pure address) since you could
always, as the original proposer said, assign UNTRACED REF to ADDRESS.

						mako


======================================================================= 94 ===
Date:    Fri, 17 Jun 1994 04:41:50 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Re: Bug in SRC Modula-3 compiler

In article <VIXIE.94Jun16023332@office.home.vix.com>,
Paul A Vixie <vixie@vix.com> wrote:
>I'm not totally sure I understand why M3 lacks CARDINAL ("unsigned int") types
,
>but this is going to become an issue for real world network programming, too.

It's an issue for other systems programming, too, like writing a
debugger.  M3 uses a single integer type with different notation for
signed and unsigned operators.  (If you think there's no difference on
a two's complement machine, remember that signed + can overflow, but
unsigned + can't.)  I would much prefer a distinct WORD type with the
usual infix operators overloaded to denote unsigned arithmetic.  I
really want the type system to help keep me form using signed
operators on words that are meant to denote unsigned integers.  I
think I proposed this change at the 1992 M3 users' group meeting, but
doubtless the proposal was lost in the clamor...



======================================================================= 95 ===
Date:    Fri, 17 Jun 1994 06:11:41 GMT
From:    naidu2@che.und.ac.za (Mr Poovenesan Naidu - PG)
Subject: mod 3????

Is Mod3 a later ver of Mod2 or is it a slightly different language.

Does it have similar time slicing capabilities as M2.

Any info appreciated. Thanks.


======================================================================= 96 ===
Date:    16 Jun 94 22:51:54
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Interfaces in v3.3 ...


   Fine, but would it be too much work for the Interface Police to provide
   a brief document stating which is superseded by which (and why, too?)
   for each new release? I see a few similar inquiries every time a new
   version is released...

That's a good point! Here are some answers:

Version 3 was a major release of the SRC compiler and library; one of
the major changes were the interface police changes. Other than that
the "official" Modula-3 libraries have been quite stable over some
time.  The interface police work was a one-time effort for libm3 (as
far as I know); I wouldn't expect the libm3 interfaces to change much
outside of "Some Modula-3 Interfaces" a DEC SRC Research Report
describing the new interfaces (which you can obtain via anonymous ftp
from gatekeeper.dec.com.)

Also, there is a major revision of the FAQ getting ready to be
released which we hope will help with highlighting important
information about SRC Modula-3, and frequently asked questions about
it.

-- Farshad
--

Farshad Nayeri
nayeri@gte.com


======================================================================= 97 ===
Date:    Thu, 16 Jun 1994 13:54:07 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Where to get the FAQ via ftp


The FAQ is available for FTP from ftp.vlsi.polymtl.ca:pub/m3-faq
(.ps for postscript .txt for ASCII).

I will revise the current version to update its status on the 3.3 release
shortly.
--

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


======================================================================= 98 ===
Date:    Fri, 17 Jun 1994 03:06:27 GMT
From:    clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves)
Subject: Re: Bug in SRC Modula-3 compiler

In article <CrH3F4.F3H@undergrad.math.uwaterloo.ca>,
Carsten Whimster <bcrwhims@undergrad.math.uwaterloo.ca> wrote:
>In article <CrGw8G.6q6@undergrad.math.uwaterloo.ca>,
>Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>>In article <2tj2rr$lt4@fnnews.fnal.gov>,  <mako@FNALO.FNAL.GOV> wrote:
>>>> MODULE test EXPORTS Main;
>>>>
>>>> IMPORT Stdio, Wr;
>>>>
>>>> VAR
>>>>     i : INTEGER;
>>>> BEGIN
>>>>     FOR i := 1 TO 5 DO
>>>> 	IF i IN SET OF INTEGER { 3, 4 } THEN
>>>> 	    Wr.PutText( Stdio.stdout, "In 3,4" );
>>>> 	END
>>>>     END
>>>> END test.
>>>
>>>The current Modula-3 compiler (V3.3) refuses to compile the above code:
>>>|	"../src/test.m3", line 9: type has too many elements
>>
>>I'm not completely sure which version of Modula-3 I was using. I didn't
>>install it, and m3 doesn't seem to have any option to ask it wat version it
>>is. I got not compile or runtime errors. It just segfaulted.
>
>Use which to find out where it is. The directory name has the version
>number in it.

Tried it, doesn't work. Hey, you're here too. The dir is:

/.software/local/.admin/bins/bin/m3
(I tried this before my original post, BTW)

>>>PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
>>>    Modula-3? You have got two different variable "i"s here.
>>
>>Why is the declaration "VAR i: INTEGER;" unnecessary?
>
>Because the for loop automatically declares an unalterable INTEGER i
>for the loop only.

Yikes! Never heard of that. That's just plain weird. Oh well...

-- 
  clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/
  Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo


======================================================================= 99 ===
Date:    17 Jun 1994 11:28:27 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Bug in SRC Modula-3 compiler

clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes:

>>>I'm not completely sure which version of Modula-3 I was using. I didn't
>>>install it, and m3 doesn't seem to have any option to ask it wat version it
>>>is. I got not compile or runtime errors. It just segfaulted.

It doesn't have such an option. You can guess from the LinkerMagic constant
in the compiler. Find out where you're m3c executable is located, and try
  strings m3c | grep "M3 v"
M3 v3.3 is release version 3.1, v3.6 is release version 3.3.

>>>>PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
>>>>    Modula-3? You have got two different variable "i"s here.
>>>
>>>Why is the declaration "VAR i: INTEGER;" unnecessary?
>>
>>Because the for loop automatically declares an unalterable INTEGER i
>>for the loop only.
>
>Yikes! Never heard of that. That's just plain weird. Oh well...
>

Not weird at all. The idea is from Ada, which has the same definition of
implicitly declared READONLY loop-variables. It saves typing and prevents
you from doing nasty things with the loop-variable.

Peter
---
Peter Klein                        E-Mail: pk@i3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21311
Ahornstrasse 55                    Fax.: +49/241/8888-218
RWTH Aachen
52074 Aachen
Germany




======================================================================= 100 ===
Date:    17 Jun 94 08:51:29
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: mod 3????

In article <naidu2.3.2E013E9D@che.und.ac.za> naidu2@che.und.ac.za (Mr Poovenesa
n Naidu - PG) writes:

   Is Mod3 a later ver of Mod2 or is it a slightly different language.

You can find out about all this in the new FAQ, which is available for
FTP from ftp.vlsi.polymtl.ca:pub/m3-faq (.ps for postscript .txt for
ASCII). The FAQ describes how Modula-3 is NOT a superset or a later
version of Modula-2, but that it tries to keep the proven features of
Modula-2, such as modules, interfaces, and strong typing while adding
other features which make programming realistic applications easier,
more fun, and safer at the same time.

   Does it have similar time slicing capabilities as M2.

Modula-3 has very good support for Threads (or light-weight
processes). The language and the standard libraries also include some
concurrency control primitives. Standard libraries have been designed
to support multi-threaded code well.

   Any info appreciated. Thanks.

The FAQ also shows other sources of introductory information.

-- Farshad
--

Farshad Nayeri
nayeri@gte.com


======================================================================= 101 ===
Date:    Fri, 17 Jun 1994 06:46:16 GMT
From:    jmkomine@neumann.uwaterloo.ca (John Kominek)
Subject: fixed size vs. variable size INTEGERs

As a 'public service' I'm renaming this thread that I launched. 
--------------------

>I'm not totally sure I understand why M3 lacks CARDINAL ("unsigned int") types
,
>but this is going to become an issue for real world network programming, too.
>M3 is definitely at the "grab more market share or die" stage of its growth;
>adding a few impure warts to make it more useful to the average programmer (me
).

Modula-3 does have a CARDINAL type but it is defined as the non-negative
INTEGER subrange [0..LAST(INTEGER)]. This was done to make them neatly
compatible in expressions. As I painfully learned from Modula-2, mixing
INTEGERs and CARDINALs is a bother. If you really nead that extra bit
then you must resort to the "for low level programming only" Word 
interface.

In parting, I'd be interested in hearing the opinion of Marc and Bill
and the guys at DEC SRC on the fixed size vs. variable sized INTEGERs
debate ... but it's pretty difficult to lure them into a language war.

John

P.S. I'm rooting for the "grab more market share" future.



======================================================================= 102 ===
Date:    Sat, 18 Jun 1994 20:17:39 GMT
From:    jmkomine@neumann.uwaterloo.ca (John Kominek)
Subject: Re: fixed size vs. variable size INTEGERs

As a followup ...

I was poking around the Modula-3 source code an discovered a couple
interesting things.

  1. Internally, in the M3 coder generator, there are 4 fixed sized
     integers called Int_A, Int_B, Int_C, and Int_D. They have sizes
     of 8, 16, 32, and 64 bits respectively. Machine dependent infor-
     mation then maps one of them onto the INTEGER type. 

  2. Even though there are three floating point types, in the SRC
     compiler all EXTENDED types are 64 bits long. That is, they
     are identical to LONGREALs. Even for Linux, which, when the
     x87 coprocessor is present, offers 80 bit precision. A careful
     reading of the Modula-3 documentaton reveals that the size
     of floating point numbers is an implementation option. Heck,
     you could even have 8 bit REALs if you wanted.

John


======================================================================= 103 ===
Date:    20 Jun 1994 08:42:12 GMT
From:    frsg100@cus.cam.ac.uk (F.R.S. Gouget)
Subject: Brand construct





    Recently I reread the excellent book Systems Programming With Modula3. I
particularly appreciate the chapter "How the language got its spots" but there
seems to be a problem with the brand construct.

The construction is BRAND [text literal] where text literal is optional.
(from the syntax charts in Systems Programming p64 and confirmed by the SRC 
Modula3 v2.11 compiler)

Now 
 - We need explicit brands as pointed out by Jo p227. The arguments are :
      + Distributed programming using RPC transmits type information including
        the brand (encoded in some way). With implicit brand we cannot guarante
e 
        that we will get the same brand from one compilation to the other and 
        thus make it impossible to transmit implicitly branded types using RPC.
      + The pickle facility saves a datastructure on disc and does the same kin
d
        of type encoding thus leading to the same problem.

 - We also need implicit brands for generic modules. The brand construct only
   allows text literals for the brand so that with explicit brand a program cou
ld
   not use two different instances of the same generic type. For example it wou
ld
   be impossible to use a hashtable of integers and a hashtable of strings, bot
h
   deriving from the same generic hashtable (Actually I use 4 different types o
f
   hashtables in one program).

>From this we draw the conclusion that it is impossible to do distributed
computing or to use the pickle facility with types that derive from a generic
module.

A solution to this problem would be to allow the brand construct to take a
"constant string" and not just string literal.
We would then write things like this :

GENERIC MODULE HashTable(Element);

REVEAL
  T=BRANDED Element.Brand OBJECT
...

And in an actual instance of Element :

INTERFACE HashInteger;

CONST
  Brand="HashInteger";
...



Fortunately I don't need to do such things but I thought the problem deserved
to be pointed out.

GOUGET


======================================================================= 104 ===
Date:    Mon, 20 Jun 1994 02:52:36 GMT
From:    clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves)
Subject: Re: Bug in SRC Modula-3 compiler

>>>>I'm not completely sure which version of Modula-3 I was using. I didn't
>>>>install it, and m3 doesn't seem to have any option to ask it wat version it
>>>>is. I got not compile or runtime errors. It just segfaulted.
>
>It doesn't have such an option. You can guess from the LinkerMagic constant
>in the compiler. Find out where you're m3c executable is located, and try
>  strings m3c | grep "M3 v"
>M3 v3.3 is release version 3.1, v3.6 is release version 3.3.

Well, doing a "which m3c" returns:

m3c: Command not found.

Now, I can use "find" to find it. Of course, there are multiple versions
online, and I can figure out the version of each simply by looking at the
name of the directory it's in. 

ie: /.software/arch/modula3-3.3/lib/m3/SPARC/m3c

>>>>>PS: Do you realise the declaration "VAR i: INTEGER;" is unnecessary in
>>>>>    Modula-3? You have got two different variable "i"s here.
>>>>
>>>>Why is the declaration "VAR i: INTEGER;" unnecessary?
>>>
>>>Because the for loop automatically declares an unalterable INTEGER i
>>>for the loop only.
>>
>>Yikes! Never heard of that. That's just plain weird. Oh well...
>>
>
>Not weird at all. The idea is from Ada, which has the same definition of
>implicitly declared READONLY loop-variables. It saves typing and prevents
>you from doing nasty things with the loop-variable.

Yeah, I can see how it'd be nice. Never heard of it before though.

-- 
  clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/
  Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo


======================================================================= 105 ===
Date:    20 Jun 1994 11:42:24 GMT
From:    vogler@rzddec2.informatik.uni-hamburg.de (Jens Vogler)
Subject: PANIC with M3 for PCs

Hi out there,
I have one problem starting M3 on my PC. I loaded the actual version
a few day ago down and installed it yesterday on my home PC.
"A few minutes" later I tried to start it (like told in ainstall.bat)
and got only following message:

panic: memory size is not a multiple of the page size (4096)

What is wrong? How can I fix it?
Does anyone know the email addresses of the author, so that I can ask them
directly?

Bye the way, I have the newest version of DJGCC C on my PC, how can
I use it and not the M3 version of this compiler? (I only want one of this
monsters filling my harddisk and I think that the DJGCC is newer ...) 

Thanks in advance.

                                            Yours etc.
                                       Jens "ABert" Vogler
--
 V   V  TTTTT   CCCC  Jens Vogler -- vogler@informatik.uni-hamburg.de
 V   V    T    C      Universitaet Hamburg (BR Deutschland)
  V V     T    C      VirusTestCenter
   V      T     CCCC  Amiga-Gruppe


======================================================================= 106 ===
Date:    20 Jun 1994 15:32:43 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Brand construct

In article <2u3kp4$krn@lyra.csx.cam.ac.uk>, frsg100@cus.cam.ac.uk (F.R.S. Gouge
t) writes:
>     Recently I reread the excellent book Systems Programming With Modula3. I
> particularly appreciate the chapter "How the language got its spots" but ther
e
> seems to be a problem with the brand construct.
> 
> The construction is BRAND [text literal] where text literal is optional.
> (from the syntax charts in Systems Programming p64 and confirmed by the SRC 
> Modula3 v2.11 compiler)

Correct.  Text literals are insufficient for brands.  The syntax
(section 2.8.9) and description of object types (section 2.2.9)
both claim that the brand must be a text literal.  But, section
2.2.7 which describes REF types says that brands are text
constants.  Section 2.2.7 is correct.  The current (v3.3) SRC Modula-3
compiler allows text constants.


  - Bill Kalsow




======================================================================= 107 ===
Date:    20 Jun 1994 16:47:33 GMT
From:    k3is@UNBSJ.CA (QUSAY H. MAHMOUD)
Subject: Modula-3 books!

Hi all, 
	
	Would some please post or send me a msg about what books are 
available on Modula-3....please full details....ISBN and the publishers!

Thanks alot.

Later,

-=end of included msg=-


======================================================================= 108 ===
Date:    Mon, 20 Jun 94 16:38:31 -0700
From:    mcjones@src.dec.com
Subject: Re: File Handles...

Matt Meola (mmeola@cahill) asks:

    In v3.3, how does one test to see if a "file handle" "handles" 
    a writeable file?  The HTML docs make mention of a 'writable(h)' 
    thing, but I can't find anything. 

Right now there is no way to do that: the revelation that a File.T 
contains a field corresponding to the specification fields "writable" 
and "readable" is buried in the implementation module FilePosix.m3.


Paul McJones
DEC Systems Research Center
mcjones@src.dec.com


======================================================================= 109 ===
Date:    20 Jun 1994 18:57:53 GMT
From:    k3is@UNBSJ.CA (QUSAY H. MAHMOUD)
Subject: Shareware implemenation?

Hi all, 

	Is there a shareware implemenation of Modula-3 for DOS, or Sparc 
Station (*running UNIX*)????

	Well, I am a Modula-2 user.......I want to do a project in my final 
year (*next year*), I was thinking of doing it on Oberon.....but a computer 
science professor here didn't really encourage me....he said why Oberon? why 
not Modula-3? Oberon will be definitely popular in Europe but not in North 
America (:  (*that is interesting*)

	Well, thanks for any help or suggestions on materials for Modula-3 
BESIDE THE FAQ!

	Thanks!

Later,

-=end of included msg=-


======================================================================= 110 ===
Date:    Mon, 20 Jun 1994 19:53:36 GMT
From:    mmeola@cahill (Matt Meola)
Subject: File Handles...

In v3.3, how does one test to see if a "file handle" "handles" a
writeable file?  The HTML docs make mention of a 'writable(h)' thing,
but I can't find anything.

Any ideas?



(********************************************************)
(* Matt Meola        mmeola@cahill.ecte.uswc.uswest.com *)
(* NRA Life Member, Militiaman, Libertarian             *)
(* Gun control means using two hands.                   *)
(********************************************************)


======================================================================= 111 ===
Date:    Mon, 20 Jun 1994 21:21:59 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: Modula-3 books!

In article <k3is.5.0@unbsj.ca>, QUSAY H. MAHMOUD <k3is@UNBSJ.CA> wrote:
>Hi all, 
>	
>	Would some please post or send me a msg about what books are 
>available on Modula-3....please full details....ISBN and the publishers!

The best books are listed in the FAQ, which you can pick up at
gatekeeper.dec.com in pub/DEC/Modula-3/???.
-- 
-------------------------------------------------------------------
  Carsten Whimster              --- EDM/2 Associate Editor
  bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
-------------------------------------------------------------------


======================================================================= 112 ===
Date:    Tue, 21 Jun 1994 07:09:41 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Problems with PP and formsvbt under LINUX

Hi, I have managed to updrade from 3.1 to 3.3 fairly painlessly so far, I
have boot-LINUX OK, m3utils, m3cc, and libm3 working fine, misc (excluding
d]ps stuff), m3tk and trestle OK and the games working. vbtkit has now 
installed but I am stuck on the pretty-printer (in tool) and formsvbt.

The pretty printer initialy complained with the message

-> linking m3pp
ld: No such file or directory for libL

and so I edited the m3makefile to comment out the libl line and got the
message

-> linking m3pp
../src/lex.yy.c:353 (y.tab.o): Undefined symbol _yywrap reference from ...

Can anyone help on this one please.

Next I tried formsvbt, I tried m3build in the top level directory, which
did not work, so I tried it in the formsvbt directory and got:

unable to read .M3EXPORTS from directory LINUX of package videovbt

and so I tried m3build in the videovbt directory, and got:

unable to read .M3EXPORTS from directory LINUX of package jvideo

and (guess what) I tried m3build in the jvideo directory. This provided
me with numerous compile errors, in JVBuffer.m3 (2 warnings), JVSink.m3 
(9 errors, 2 warnings) and JvsBuffer.m3 (3 errors and 2 warnings. Has
anyone got this all to work under Linux, and if so how. I have added the 
compiler messages between here and the .sig.

Thanks again.


"../src/generic/JVBuffer.m3", line 9: warning: not used (OSErrorPosix)
"../src/generic/JVBuffer.m3", line 9: warning: not used (Uipc)
"../src/JVSink.m3", line 575: warning: variable has type NULL (vec)
"../src/JVSink.m3", line 575: unknown qualification '.' (struct_sigvec)
"../src/JVSink.m3", line 575: constructor type must be array, record, or set ty
pe
"../src/JVSink.m3", line 576: undefined (Usignal.struct_sigvec)
"../src/JVSink.m3", line 346: warning: potentially unhandled exceptions: Wr.Fai
lure, Thread.Alerted
"../src/JVSink.m3", line 579: unknown qualification '.' (sigvec)
"../src/JVSink.m3", line 579: expression doesn't have a value
"../src/JVSink.m3", line 580: unknown qualification '.' (sv_handler)
"../src/JVSink.m3", line 581: unknown qualification '.' (sv_handler)
"../src/JVSink.m3", line 582: unknown qualification '.' (sigvec)
"../src/JVSink.m3", line 582: expression doesn't have a value
"../src/JVSink.m3", line 14: warning: not used (Fmt)
"../src/JVSink.m3", line 344: warning: not used (Bpt)
"../src/JvsBuffer.m3", line 80: warning: variable has type NULL (addr)
"../src/JvsBuffer.m3", line 80: unknown qualification '.' (shmat)
"../src/JvsBuffer.m3", line 80: types are not assignable
"../src/JvsBuffer.m3", line 82: LOOPHOLE: expression's size differs from type's
"../src/JvsBuffer.m3", line 82: warning: LOOPHOLE: expression's alignment may d
iffer from type's
MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

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


======================================================================= 113 ===
Date:    21 Jun 1994 12:41:07 -0400
From:    braams@cims.nyu.edu (Bastiaan J. Braams)
Subject: Modula-3 calls Fortran-77


In order to use Modula-3 for scientific computation it would be extremely
useful if it were possible to call library routines written in Fortran-77,
a facility that is not supported by M3 release-3.3.  In this post I
attempt to explore the issues, focussing on Unix systems.

First let's agree that some things are to be taken care of by the user
responsible for the Modula-3 code that calls Fortran, and not by the M3
system.
 - The user is responsible for ensuring that the bitsizes of the basic
types (integer, real, boolean) match between the calling program and the
callee.
 - The user is responsible for knowing that in a Modula-3 multidimensional
array the last index varies fastest, whereas in Fortran-77 the first index
varies fastest.  Thus an (m by n) array in Modula-3 should be interpreted
as an (n by m) array in the Fortran-77 routine.  Fortran-77 requires array
dimensions to be passed explicitly (except possibly for the final
dimension), and the user is responsible for doing so.
 - The user is responsible for whatever havoc might result if the Fortran
routine performs external i/o.

The Modula-3 program must contain interface definitions for the external
procedures it calls.  Let us consider a hypothetical interface that has
the name FortLib and that contains a specification for a routine ThisSub,
which is a Fortran-77 subprogram (subroutine or function).  So in the
Modula-3 program, FortLib.ThisSub is to be used like any other Modula-3
routine.

The relevant section of the Modula-3 interface definition may be:
  INTERFACE FortLib;
  <*EXTERNAL : F77*> PROCEDURE ThisSub (...):...;
where the ellipses represent the Modula-3 signature.  If this is the
interface definition then it is the responsibility of the M3 implementer
to ensure that the Fortran routine will be invoked under whatever name the
local Fortran-77 system would use for a Fortran routine ThisSub.  On Unix
systems the usual treatment is to convert to lower case and append an
underscore.  Thus, the M3 system would ensure that an invocation of
ThisSub causes the library to be searched for a routine by the name of
thissub_.

Fortran-77 compilers may supply an option to suppress the case conversion
and/or to suppress appending the underscore, so it must be possible to
override the default treatment in the interface.  If the pragma in the
interface specifies a name, then M3 should respect that.  So if the
relevant section of the interface is
  INTERFACE FortLib;
  <*EXTERNAL ThisSub : F77*> PROCEDURE ThisSub (...):...;
then the system will search the libraries for a routine with the name
ThisSub.

Perhaps systems truncate names to 14 or 31 characters, but that poses no
issue that isn't already present in the Modula-3/C interface.

Now we consider the arguments to the Fortran routine.  Fortran assumes all
arguments are passed by reference, so in the context of the Modula-3
declarations:
  CONST zero: INTEGER = 0;
  VAR i: INTEGER := 0;
and an invocation
  ThisSub(0,zero,i);
the M3 system will have to ensure that the first and second argument are
copied to temporary integer variables that are then used in the call.
Alternatively, such a call could be prohibited, but I don't find that an
attractive option.  It is the responsibility of the user, of course, that
ThisSub will not assign to the first and second argument.

With this in mind, and having agreed that matching the bitsizes of the
basic types is the user's responsibility, scalar arguments of type
integer, real, or boolean pose no difficulty.

In Fortran-77, arrays are passed as a reference to the first element.  The
sizes of the array in each dimension except the last (slowest varying)
must be passed explicitly; passing the size of the last dimension is
optional at the discretion of the author of the Fortran routine.  Also the
location of this size information in the sequence of arguments is up to
the discretion of the author of the Fortran code.  The user is responsible
for knowing the Fortran-77 interface of ThisSub and for supplying the
required dimensioning information.

Consider for example the Modula-3 fragment
  VAR i2d: ARRAY [0:9],[0:99] OF INTEGER;
  ...
  ThisSub(i2d);
It is not the responsibilty of the M3 system to add dimensioning
information for this call.  If dimensioning information were required then
the user should have supplied it, for instance by writing
  ThisSub(99,9,i2d);
if that conforms to the Fortran-77 specification of ThisSub.

The situation where i2d is an open array in a Modula-3 procedure is no
different from the previous case.  Consider next the Modula-3 reference to
open array type.  Say we have
  TYPE Int2D = ARRAY OF ARRAY OF INTEGER;
  VAR r2d := NEW(REF Int2D, 9, 99);
  ...
I believe that a call to ThisSub that passes the array referenced by r2d
should have the form:
  ThisSub(r2d^);
plus dimensioning information as required by the Fortran routine.

An interesting question with perhaps more than one good answer is what to
do with an invocation of the form
  ThisSub(r2d);
in the context of the previous declaration for r2d.  I believe that this
would be an error if the Fortran routine ThisSub expects an array
argument.  Standard Fortran-77 does not have a pointer type, but many
implementations do offer a pointer type.  We should probably decide that
the user knows best and is responsible, so the invocation ThisSub(r2d)
would simply pass the pointer.  An alternative treatment is to prohibit
ThisSub(r2d) if the pragma in the interface specified the language as F77,
but to admit it if the language were specified as, say, F77X or F90.

Character and TEXT arguments pose special problems, and are best avoided
whenever possible.  Say the Fortran routine is
  subroutine thissub (..., cha, ...)
  character cha*(whatever)
Then it expects to find a reference to the first element of cha in the
indicated position in the argument list.  In addition the character length
of the actual argument is passed; on most systems this length is passed as
an extra hidden integer argument at the end of the list of arguments.  One
such additional argument will be passed for each character string argument
in the list.  On the other hand, if the Fortran routine requires not a
character string, but just a single character or an array of character,
then these extra integer arguments are not to be supplied.

M3 could choose one or another strategy to deal with character arguments.
The first strategy is to refer the user to the language guides for Fortran
and C, let the user study carefully the section on interfacing those two
languages, and then require that the user be careful to supply the extra
length arguments just as they are required.  In that case, when the
Modula-3 program invokes ThisSub and passes it either a TEXT argument or
an argument that is an ARRAY OF CHAR, then the M3 system has only to
supply an appropriate address.  I should say that I know too little about
the Modula-3 internals to judge whether perhaps passing a TEXT argument to
Fortran should be completely prohibited.

An M3 strategy that is more convenient for the user is to handle TEXT and
ARRAY OF CHAR differently.  If ThisSub is invoked with an ARRAY OF CHAR
argument then M3 would just pass the address of the first element and not
add any other information; in the case of a TEXT argument M3 would handle
it according to the Fortran-77 convention, adding the length as a hidden
integer argument at the end of the list.

I believe that Fortran functions returning an integer, boolean, or real
type pose no special difficulty. Fortran functions returning a character
string are, I believe, not treated in a uniform manner and allowing them
in a Modula-3 to Fortran-77 interface would have rather low priority.

Some Fortran-77 implementations permit Structure data types; I would say
that a user of such a routine is responsible for ensuring that the Fortran
structure is properly matched to a Modula-3 structure; this is not a
matter for the M3 system to consider.

Finally there is the issue of making a Fortran-77 labelled COMMON block
available to a Modula-3 program.  Such blocks are made available to C
programs by declaring, in C, an appropriate "extern struct".  It would be
useful if something similar could be done in Modula-3.

The possibility of interfacing Modula-3 to Fortran-77 will make a large
body of numerical codes and libraries accessible, and I think it would be
very valuable.

-- Bas Braams (braams@cims.nyu.edu)


======================================================================= 114 ===
Date:    21 Jun 1994 19:54:11 GMT
From:    mbk@inls1.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3 calls Fortran-77

Bastiaan J. Braams (braams@cims.nyu.edu) wrote:

: In order to use Modula-3 for scientific computation it would be extremely
: useful if it were possible to call library routines written in Fortran-77,
: a facility that is not supported by M3 release-3.3.  In this post I
: attempt to explore the issues, focussing on Unix systems.

: First let's agree that some things are to be taken care of by the user
: responsible for the Modula-3 code that calls Fortran, and not by the M3
: system.
:  - The user is responsible for ensuring that the bitsizes of the basic
: types (integer, real, boolean) match between the calling program and the
: callee.
:  - The user is responsible for knowing that in a Modula-3 multidimensional
: array the last index varies fastest, whereas in Fortran-77 the first index
: varies fastest.  Thus an (m by n) array in Modula-3 should be interpreted
: as an (n by m) array in the Fortran-77 routine.  Fortran-77 requires array
: dimensions to be passed explicitly (except possibly for the final
: dimension), and the user is responsible for doing so.

A question:  Why does Modula-3 use the opposite matrix storage layout
from Fortran?

Intrinsically there doesn't seem to be much reason to choose one over
the other, and thus considering the large library of Fortran matrix routines
why not just do it like Fortran?

I don't consider "because C does it the other way" to be a very compelling
reason; akin to deciding to make character strings work like Fortran.

cheers
Matt

: -- Bas Braams (braams@cims.nyu.edu)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 115 ===
Date:    Tue, 21 Jun 1994 14:37:52 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Shareware implemenation?

Previous posting from same author asks about books.

	   Is there a shareware implemenation of Modula-3 for DOS, or Sparc 
   Station (*running UNIX*)????

Yes, there is a free implementation, with source code, for most UNIX
variants (SPARC, LINUX...) and for DOS.

	   Well, I am a Modula-2 user.......I want to do a project in my final 
   year (*next year*), I was thinking of doing it on Oberon.....but a computer 
   science professor here didn't really encourage me....he said why Oberon? why
 
   not Modula-3? Oberon will be definitely popular in Europe but not in North 
   America (:  (*that is interesting*)

Oberon is simple and compiles fast but IMHO it is not as mature and well
suited as Modula-3 for distributed programming and "programming
in the large".

	   Well, thanks for any help or suggestions on materials for Modula-3 
   BESIDE THE FAQ!

Why besides the FAQ? It contains the answers about books, implementations
and more, please e-mail me about anything missing from the FAQ.
The FAQ can be found on ftp.vlsi.polymtl.ca:pub/m3-faq.txt.

--

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


======================================================================= 116 ===
Date:    22 Jun 1994 10:09:07 GMT
From:    mako@FNALO.FNAL.GOV
Subject: Re: Modula-3 calls Fortran-77

Bastiaan J. Braams (braams@cims.nyu.edu) writes (in comp.lang.modula3):
> In order to use Modula-3 for scientific computation it would be extremely
> useful if it were possible to call library routines written in Fortran-77,
> a facility that is not supported by M3 release-3.3.  In this post I
> attempt to explore the issues, focussing on Unix systems.
[...]

To which Matt Kennel (mbk@inls1.ucsd.edu) replies:
> A question:  Why does Modula-3 use the opposite matrix storage layout
> from Fortran?
>
> Intrinsically there doesn't seem to be much reason to choose one over
> the other, and thus considering the large library of Fortran matrix routines
> why not just do it like Fortran?
>
> I don't consider "because C does it the other way" to be a very compelling
> reason; akin to deciding to make character strings work like Fortran.

I thought it was Pascal... The C language only use pointer arithmetic,
where it could have defined it the other way just as well but it didn't.

Wirth's reasoning on the other has some point, as is explicitly stated in
the language definition, and in the Modula-3 definition, too:

	An expression of the form:
		ARRAY Index_1, ..., Index_n OF Element
	is shorthand for
		ARRAY Index_1 OF ... OF ARRAY Index_n OF Element

(extracted from Modula-3's online language definition). I do not know why
FORTRAN chose the other way, so I would rather ask "Why does FORTRAN use
the opposite matrix storage layout from Modula-3 (or Pascal, or...)?"
Does it have any mathematical implications???
						mako


======================================================================= 117 ===
Date:    Wed, 22 Jun 1994 16:12:49 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Another go at M3 for OS2

I'm having another look at porting M3 (3.3) for OS2. Its a big job (but
someons got to do it). I have started with quake, and at the end of this 
are a set of diffs for the quake src directory. Note I have used OS2_2x 
as the target name and OS2 as the OS_TYPE. I have a set of templates which
I can let anyone have if they are interested, but they may change as I
carry on so I wont post them yet. I have had a fair bit of success in 
compiling the boot-LINUX stuff, (LINUX is my base port, I have 3.3 up
and running), and will now start working on the interface glue to compile
an OS2_2x compiler under linux etc etc.

---------- DIFF STARTS HERE !!
diff src/makefile oldsrc/makefile
12c12
< PROGRAM = quake.exe
---
> PROGRAM = quake
67,69d66
< #DSHELL=-DDEFAULT_SHELL="/bin/sh"
< DSHELL=-DDEFAULT_SHELL="e:/emx/bin/sh.exe"
< 
79c76
< DEFINES = -DTARGET_$(TARGET) $(DEBUG_DEFINES) $(DSHELL)
---
> DEFINES = -DTARGET_$(TARGET) $(DEBUG_DEFINES)
81c78
< YACC = byacc -y
---
> YACC = bison -y
diff src/quake.h oldsrc/quake.h
52d51
< #ifndef TARGET_OS2_2x
55d53
< #endif
diff src/system.c oldsrc/system.c
19a20,21
> #define	DEFAULT_SHELL	"/bin/sh"
> 
--------- END OF DIFF !

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

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


======================================================================= 118 ===
Date:    22 Jun 1994 11:02:05 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: M3 3.3: Threads & Trestle under Linux 1.1.12

Hi all!

As soon as I try to run multi-threaded programs, e.g. Trestle applications,
under Linux 1.1.12 they crash due to an unhandled exception
"MachineIdPosix.Failure".

Has anybody experienced similar problems and worked out a fix already?

=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!"


======================================================================= 119 ===
Date:    Wed, 22 Jun 94 15:16:15 -0700
From:    ramshaw@src.dec.com (Lyle Ramshaw)
Subject: Re: Modula-3 calls Fortran-77

In the interests of conceptual simplicity, Wirth's trick of viewing an
n-dimensional array as a 1-dimensional array of (n-1)-dimensional
arrays is quite attractive.  On the other hand, compatibility with
Fortran is nothing to sneeze at.

It is perhaps worth noting that Modula-3 could have achieved both
goals simultaneously, at the price of growing an obvious wart: 

  Define the expression "A[i1, i2, ..., in]" to be shorthand for
  "A[in]...[i2][i1]", with the indices reversed.

Lyle



======================================================================= 120 ===
Date:    23 Jun 1994 00:06:20 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Modula-3 calls Fortran-77

In article <9406222216.AA15159@cedar.pa.dec.com>, ramshaw@src.dec.com (Lyle Ram
shaw) writes:
> It is perhaps worth noting that Modula-3 could have achieved both
> goals simultaneously, at the price of growing an obvious wart: 
> 
>   Define the expression "A[i1, i2, ..., in]" to be shorthand for
>   "A[in]...[i2][i1]", with the indices reversed.

The language also specifies that SUBARRAY returns a slice of the
array in its first index.

The current representation of an open array is a record with a pointer
to the contiguous data and the number of elements in each dimension.
Storing arrays in column-major order would require a different
(slightly more complicated?) representation and access scheme for
open arrays.

  - Bill Kalsow



======================================================================= 121 ===
Date:    22 Jun 1994 20:46:55 GMT
From:    mbk@inls1.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3 calls Fortran-77

mako@FNALO.FNAL.GOV wrote:
: Bastiaan J. Braams (braams@cims.nyu.edu) writes (in comp.lang.modula3):
: To which Matt Kennel (mbk@inls1.ucsd.edu) replies:
: > A question:  Why does Modula-3 use the opposite matrix storage layout
: > from Fortran?
: >

: Wirth's reasoning on the other has some point, as is explicitly stated in
: the language definition, and in the Modula-3 definition, too:

: 	An expression of the form:
: 		ARRAY Index_1, ..., Index_n OF Element
: 	is shorthand for
: 		ARRAY Index_1 OF ... OF ARRAY Index_n OF Element

So? How does that imply any particular memory layout?  Is the memory
layout of M3 arrays even specified?  (In fortran, it is)  If not, it's
just the standard implementation.

: (extracted from Modula-3's online language definition). I do not know why
: FORTRAN chose the other way, so I would rather ask "Why does FORTRAN use
: the opposite matrix storage layout from Modula-3 (or Pascal, or...)?"
: Does it have any mathematical implications???

For Fortran it was a 50/50 chance, no?

But given fortran is stuck with it (all those EQUIVALENCES make it nearly
impossible to change now unfortunately), I see no reason that new
purposely-designed languages ought to be gratuitiously incompatible with a
large base of existing and frequently used software.

(besides most C programs don't even use flat multi-dim arrays, but
 double-pointer indirection {which is slow}, as with Numerical Recipes.)

Another advantage: you could translate many of those Fortran subroutines
reasonably literally to M3.  (they are often designed knowing the memory
layout to avoid cache bashing)

: 						mako

Given this choice,

     1) Easy interface with Fortran
and  2) Easy access to IEEE mode bits/exceptions/stuff like that

I'd wager 98 out of 100 scientific programmers would choose #1.

#2 is nice for a small number of numerical analysts writing 'guaranteed
precision algorithms' (say, a few standard library functions).  Most people
don't really care, and it doesn't even matter.  (if the physical approximation
is good only to 1 part in 50 who cares about that freaking last bit?  Indeed,
if that last bit really does make a difference, most times that means
something's intrinsically 'wrong'.) 

One exception/whine: I want to get a TRAP and an error the first damn time
I get an Inf or NaN!  That means there's a mistake.  I really hate it
when I run my program for hours (of course the NaN's and Inf's cause
CPU exceptions so the program takes much longer already) only to get an
output file of NaNs propagated from who knows where.  *gee, thanks alot!*.

So I think most numerical programmers would like that to be the default.

To be honest, supplying #2 and not #1 screams to the Real World Out There
"Yet Another Computer-Scientist Weenie Moralizing Language".  I'll be a
little more generous, but...

(No those engineers haven't kept on using Fortran forever because they're
 unimaginative or stupid.)

cheers
Matt

PS: my criticism is becuase I like new clean stuff like M3 and Eiffel and
all that, and I want them to succeed.

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 122 ===
Date:    Wed, 22 Jun 1994 16:36:37 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Problems with PP and formsvbt under LINUX


   Hi, I have managed to updrade from 3.1 to 3.3 fairly painlessly so far, I
   have boot-LINUX OK, m3utils, m3cc, and libm3 working fine, misc (excluding
   d]ps stuff), m3tk and trestle OK and the games working. vbtkit has now 
   installed but I am stuck on the pretty-printer (in tool) and formsvbt.
...
   Next I tried formsvbt, I tried m3build in the top level directory, which
   did not work, so I tried it in the formsvbt directory and got:
...
   (9 errors, 2 warnings) and JvsBuffer.m3 (3 errors and 2 warnings. Has
   anyone got this all to work under Linux, and if so how. I have added the 
   compiler messages between here and the .sig.

I am quite further ahead in the LINUX port. Being close to the end
(we always think that there is only one more problem ahead :-),
I was a bit silent lately hoping to be able to package everything
together. I have everything compiled (including problems in jvideo,
pp, gnuemacs, obliq). Most things seem to work properly after
fixing the Uerror codes for LINUX which caused the TCP library
to work improperly (netobjd for example would raise an exception
when started). I have reserved officially an address range for
LINUX shared libraries. The procedure for building shared libraries
is now simplified, easier to use and much faster.

What remains to be done: finish compiling everything for shared libraries,
check why netobjd is taking more CPU time than it should, some testing,
write release notes, make a global diff with virgin sources and make
the whole thing available. I may make the current diffs available sooner
if there is demand for it.

Hope this helps.

--

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


======================================================================= 123 ===
Date:    Wed, 22 Jun 94 16:46:01 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: (none)

The shared memory interface is incorrect for solaris-2.x. Below are 
the diffs to fix it:

Changes to 

    libm3/src/unix/solaris-2.x/Ushm.i3
 
9c9
< FROM Ctypes IMPORT char, short, int, void_star;
---
> FROM Ctypes IMPORT char, short, int;
192c192
< <*EXTERNAL*> PROCEDURE shmat (shmid: int; shmaddr: ADDRESS; shmflg: int): voi
d_star; 
---
> <*EXTERNAL*> PROCEDURE shmat (shmid: int; shmaddr: ADDRESS; shmflg: int): int
;


======================================================================= 124 ===
Date:    23 Jun 1994 11:55:04 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Modula-3 books!

"Modula-3" by Sam Harbison 
Prentice-Hall, 1992
ISBN 0-13-596396-6

"Algorithms in Modula-3" by Robert Sedgewick
Addison-Weseley
ISBN 0-201-53351-0

"Systems Programming with Modula-3" edited by Greg Nelson
Prentice-Hall, 1991
ISBN 0-13-590464-1


In preparation (to appear at Springe Verlag)
L. Boszormenyi, R. Mittermeir, C. Weich
Programming in Style
An introduction into Programming - with Modula-3


======================================================================= 125 ===
Date:    Thu, 23 Jun 94 09:41:07 EDT
From:    BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin)
Subject: Modula-3 Books

I am also at work on a Modula-3 college level textbook.  It will cover the
data structures course and will stress data abstraction.  It will be
similar to my current book: Data Abstraction: The Object-Oriented Approach
using C++, published by McGraw Hill. Status: The software has been built and
I am currently writing the text itself.
Joe Bergin, berginf@pacevm.dac.pace.edu, Pace University


======================================================================= 126 ===
Date:    Thu, 23 Jun 1994 10:26:16
From:    k3is@UNBSJ.CA (QUSAY H. MAHMOUD)
Subject: Re: Evaluating Modula-3

In article <01HDVU0ZREMA000YHJ@vax1.may.ie> 89200004@vax1.may.ie writes:
>From: 89200004@vax1.may.ie
>Subject: Evaluating Modula-3
>Date: 23 Jun 1994 14:02:04 +0000 (WET)

>Hi,
>I'm in the middle of a thesis where I want to evaluate the effectiveness of
>Modula-3 as a teaching language. But part of my evaluation is to compare
>Modula-3 with other programming languages(especially ones similiar to it).

>Does anyone know where I could get a detailed comparison between Modula-3
>and C, C++, Pascal but in particular Oberon. (I have read Sam Harbison's
>article "Systems programming in Modula-3" but I am looking for something
>a little more detailed).

>I would appreciate any help given
>Sinead Scully
>Computer Science Department
>St Patrick's College
>Maynooth
>Co. Kildare
>Ireland
>e-mail:89200004@vax1.may.ie
Hi, 
	I am interested in that too!
Later,

-=end of included msg=-


======================================================================= 127 ===
Date:    23 Jun 1994 14:02:04 +0000 (WET)
From:    89200004@vax1.may.ie
Subject: Evaluating Modula-3

Hi,
I'm in the middle of a thesis where I want to evaluate the effectiveness of
Modula-3 as a teaching language. But part of my evaluation is to compare
Modula-3 with other programming languages(especially ones similiar to it).

Does anyone know where I could get a detailed comparison between Modula-3
and C, C++, Pascal but in particular Oberon. (I have read Sam Harbison's
article "Systems programming in Modula-3" but I am looking for something
a little more detailed).

I would appreciate any help given
Sinead Scully
Computer Science Department
St Patrick's College
Maynooth
Co. Kildare
Ireland
e-mail:89200004@vax1.may.ie


======================================================================= 128 ===
Date:    Thu, 23 Jun 94 15:29:07 EDT
From:    BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin)
Subject: Evaluating Modula-3

Since Modula-3 and Standard ML are my "ideal" teaching languages, I have
written a comparison of these with Pascal, C++, Scheme...  It isn't very
substantial, but takes a typical CS2 problem and develops a solution in each
of the languages.  I will try to put together an #EMailable# package for
those who might be interested. It is long, so I'd rather not post it. I will
also probably need to compress it.
Joe Bergin, berginf@pacevm.dac.pace.edu.


======================================================================= 129 ===
Date:    Thu, 23 Jun 1994 18:14:05 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: LINUX port diffs available


My current set of diffs is now available for ftp on
ftp.vlsi.polymtl.ca:pub/m3/m3-diff. There you will find
the diffs in "diffs" and all the new/modified files in
"src". The shared lib scripts are not there yet.
--

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


======================================================================= 130 ===
Date:    Thu, 23 Jun 1994 23:12:37 GMT
From:    contest@netcom.com (Barnum Lives!)
Subject: FREE CONTEST\enter & win Cyber Sabres now

There's an old saying about contests- "if you can't give away really cool 
prizes don't even bother." So before starting this Internet contest a group 
of Ohioans in pursuit of excellence invented the only prize that would be 
totally new, extremely cyber, and absolutely cutting edge. And now you can 
win it!

Introducing the Cyber Sabre-the only cutting edge product ever designed to 
be given away in cyberspace. Cyber Sabres are beautiful limited-edition 
versions of the world famous Christy sliding-blade pocket knife. Like all 
Christy knives, Cyber Sabres are handmade at the 104 year-old Christy Co. 
in Fremont, Ohio USA.

Even with hundreds of Cyber Sabres up for grabs there's still no time to 
waste. Quickly turn the page and enter now by filling in all the fields 
including the number of knives [from one to 1 million] that you'd like to 
see the Christy Company sell during 1994. Then send your entry to: 
contest@netcom.com. Good luck!

To get a picture of the Cyber Sabre, do an anonymous FTP to ftp.netcom.com
(/pub/contest). You can also find it in alt.binaries.pictures.misc

              --- Official Cyber Sabre Contest Entry Form ---

name:
address:
city:
state:
zip code:
country:
phone:
e-mail:
# of knives:

This is a contest not a commercial. It is void where prohibited, taxed, or 
otherwise restricted. The decision of the judges is final.


======================================================================= 131 ===
Date:    Thu, 23 Jun 1994 19:43:13 PDT
From:    janssen@parc.xerox.com (Bill Janssen)
Subject: Thread vars in M3?

I'd like to set up a association table (property list) for each thread
in my application.  Preferably an empy table would be created
automatically by the action of forking a thread.  Any thread would be
able to find a value in its table by calling some procedure Foo.Find()
with the result of Thread.Self() and a key.

Any thoughts on how to do this?

Bill


======================================================================= 132 ===
Date:    24 Jun 94 07:35:20
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Evaluating Modula-3

In article <01HDVU0ZREMA000YHJ@vax1.may.ie> 89200004@vax1.may.ie writes:

   Does anyone know where I could get a detailed comparison between Modula-3
   and C, C++, Pascal but in particular Oberon. (I have read Sam Harbison's
   article "Systems programming in Modula-3" but I am looking for something
   a little more detailed).

Sinead,

Here is a TR that you may want to look at. Please do let Michel,
<dagenais@froh.vlsi.polymtl.ca> the Modula-3 FAQ keeper, know of the
list of all articles you find (and your own findings as well). Good
luck! -- Farshad

---- extracts from cs.colorado.edu:/pub/techreport/tr.index ----

%A Robert Henderson
%A Benjamin Zorn
%T A Comparison of Object-Oriented Programming in Four Modern Languages
%I Department of Computer Science, University of Colorado, Boulder,
Colorado
%R Technical Report CU-CS-641-93
%K object-oriented programming, self, modula-3, sather, oberon
%X Available by anonymous FTP and e-mail from ftp.cs.colorado.edu in the
   file pub/cs/techreports/zorn/CU-CS-641-93.ps.Z 
%X "The paper evaluates Oberon, Modula-3, Sather, and Self in the 
context of object-oriented programming.  While each of these 
programming languages provide support for classes with inheritance, 
dynamic dispatch, code reuse, and information hiding, they do so in 
very different ways and with varying levels of efficiency and simplicity.
A single application was coded in each language and the experience
gained forms the foundation on which the subjective critique is based.
By comparing the actual run-times of the various implementations it is
also possible to present an objective analysis of the efficiency of
the languages.  Furthermore, by coding the application using both
explicit dynamic dispatch and static method binding, it is possible to
evaluate the cost of dynamic dispatch in each language.  The
application was also coded in C++, thereby providing a well-known
baseline against which the execution times can be compared.  "


--

Farshad Nayeri
nayeri@gte.com


======================================================================= 133 ===
Date:    24 Jun 1994 08:45:54 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Evaluating Modula-3

> Does anyone know where I could get a detailed comparison between Modula-3
> and C, C++, Pascal but in particular Oberon. 

Hi,

Maybe it helps you:
"A Comparison of Modula-3 and Oberon-2"
by myself in
"Structured Programming" 1993, 14:15-22

Cheers
L. Boszormenyi


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


======================================================================= 134 ===
Date:    24 Jun 1994 18:09:30 GMT
From:    goldberg@parc.xerox.com (David Goldberg)
Subject: Joe Bergin's Modula-3 comparisons

I have put Joe Bergin's comparison of Modula-3 with other languages
on parcftp.xerox.com in /pub/m3/Lang.tar.Z 

	David Goldberg
	goldberg@parc.xerox.com


======================================================================= 135 ===
Date:    27 Jun 1994 16:54:48 GMT
From:    and1000@cus.cam.ac.uk (Austin Donnelly)
Subject: bug in 3.1 .../ui/src/split/HVBar.i3

It's either inconsistent interfaces, or, its 
the compiler thats being too lenient.

Take a look at this:

[in .../pkg/ui/src/split/HVBar.i3]
------------------------
PROCEDURE New(
    size := DefaultSize;
    op := PaintOp.BgFg;
    txt := Pixmap.Gray): T; <* LL.sup <= VBT.mu *>
(* "New(...)" is equivalent to "NEW(T).init(...)". *)
------------------------

***but,

[in .../pkg/ui/src/split/HVBar.m3]
------------------------
PROCEDURE New(
    size: REAL;
    op: PaintOp.T := PaintOp.BgFg;
    texture: Pixmap.T := Pixmap.Gray)
    : T =
  BEGIN
    RETURN Be(NEW(T), size, op, texture)
  END New;
------------------------

ie, look at the argument "texture"   - in Greg Nelson's book, he uses 
"texture:= xxx", but the .i3 file here specifies to use "txt:= xxx"

Also, the .m3 file doesn't match up with the .i3 file - the names (not 
the types) are different - is that OK ??

Note that code which uses HVBar does actually compile correctly!

Should I change HVBar.i3 to use "texture" ?

Or, is the problem more subtle, in that the compiler is being too
lenient, and should have pointed out the differing names.

Just a thought,

Austin



======================================================================= 136 ===
Date:    27 Jun 1994 16:14:10 GMT
From:    qs101@pelican.cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Shared libraries on SPARCs (& others?)

The current SPARC distribution always builds shared libraries with version
number "1.1". eg libfoo.so.1.1.

If you change a library and then re-ship it, all programs that depend on
it will break, unless they too are recompiled. If you are foolish like
me, and build the compiler to depend on a shared libm3, then change
the libm3, you can't recompile anything, because the compiler breaks.
(I couldn't even fetch the boot archive from gatekeeper again, because
the compiler I killed was a 3.1 version and gatekeeper was on 3.3 by
then).

The change to the SPARC m3build template listed below looks at the
installation directory and tries libfoo.so.1.1, libfoo.so.1.2 etc
until it finds a version number not in use. It then builds the shared
library with that name, so you can m3ship it without breaking
anything.  The price you pay for this is the disk space required to
store more than one library, until you get around to tidying up the
old ones. I find this preferable to the alternatives.

Thanks to Bill Kalsow for assistance with this, in particular for
pointing out that you can test for a file's existence using 
'not stale (x, x)'.

Quentin Stafford-Fraser

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

To use:

Replace the library_hooks() procedure in /pkg/m3build/templates/SPARC
with the one below. Note that the highest version number used will be
1.20 after which m3build will stop with an error. Change the
definition of 'versions' if you need more.


proc library_hooks(x) is

  readonly versions = [ "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", 
                        "11","12","13","14","15","16", "17","18","19","20" ]

  proc next_version (root, major) is
    local dest = format ("%s%s%s%s%s", PKG_INSTALL, SL, BUILD_PACKAGE,
                                                  SL, BUILD_DIR)
    foreach v in versions
      local lib_so = format ("lib%s.so.%s.%s", root, major, v)
      if stale (dest & SL & lib_so, dest & SL & lib_so)
        return lib_so
      end
    end
    error ("cannot find free version for library " & root & CR)
    return ""
  end

  local lib_a  = format ("lib%s.a", x)
  local major = "1"
  local minor = "1"
  local lib_so = next_version(x, major)
  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 ("/bin/ld -assert pure-text -o", lib_so, COMPILE_OBJECTS)
      end
      %% _install_file (lib_so, LIB_INSTALL, "0644", "T")
      install_derived (lib_so)
    end
  end
  deriveds (format("lib%s.so.*",x), no_extension)
end

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


======================================================================= 137 ===
Date:    Mon, 27 Jun 94 18:41:59 -0700
From:    heydon@src.dec.com
Subject: Re: bug in 3.1 .../ui/src/split/HVBar.i3

Austin Donnelly points out that the names of the parameters to HVBar.New 
do not agree in the interface and the module: 

> Also, the .m3 file doesn't match up with the .i3 file - the names (not 
> the types) are different - is that OK ??

Yes, it is legal. The Modula-3 book (SPwM3) states (pg 43) that the
signature in the interface must *cover* the signature in the
module. Page 20 states that a signature IntSig covers the signature
ModSig if:

  1) They have the same number of parameters, and corresponding
  parameters have the same type and mode [notice that they do not
  have to have the same name].

  2) They have the same result type, or neither has a result type.

  3) The raises set of ModSig is a subset of that of IntSig.

So, the names in the module signature can be different from those 
in the interface signature so long has they have the same types and 
mode. 

> in Greg Nelson's book, he uses "texture:= xxx", but the .i3 file here
> specifies to use "txt:= xxx" 

The Trestle interfaces changed somewhat after the book went to press, 
so there are several places in chapter 7 (the Trestle Tutorial) where 
"txt" should be used instead of "texture". I believe these mistakes 
have been fixed in the on-line Trestle Tutorial that ships with the 
compiler. 

> Note that code which uses HVBar does actually compile correctly!

Can you be more specific? There shouldn't be a problem compiling 
clients of the HVBar interface. 

> Should I change HVBar.i3 to use "texture" ?
>
> Or, is the problem more subtle, in that the compiler is being too
> lenient, and should have pointed out the differing names.

No, the interface is correct, and since this is legal with respect 
to the language definition, the compiler had no reason to report 
an error. 

- Allan

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



======================================================================= 138 ===
Date:    28 Jun 1994 14:41:28 -0600
From:    sims@usa.acsys.com (dave sims)
Subject: sockets bad; Obliq good ???

Hi M3'ers, I managed to convince my employer to allow me to write one
of our applications in Modula-3.  This applications needs network
communication.

The problem is that my old code that used sockets doesn't compile with
the new v3.3 compiler.  Basically, I want a Modula-3 process on a
Linux box to communicate with a Windows 3.1 application on a Windows
box.  I thought sockets would have worked.

What is the new, preferred way to do this network communcation?
Obliq?

Thanks for helping me get Modula-3 into the commercial workplace.

dave sims
-- 
Dave Sims                                       PGP encryption key available
Internet:  sims@usa.acsys.com                   on my home page.
WWW:       <A HREF="http://cnn.acsys.com:5050/dave.html">my home page</A>


======================================================================= 139 ===
Date:    28 Jun 1994 21:44:33 -0600
From:    sims@usa.acsys.com (dave sims)
Subject: Re: sockets bad; Obliq good ???

(e#eek! i'm following up to my own post.)

I wrote> Hi M3'ers, I managed to convince my employer to allow me to
I wrote> write one of our applications in Modula-3.  This applications
I wrote> needs network communication.

I wrote> The problem is that my old code that used sockets doesn't
I wrote> compile with the new v3.3 compiler.  Basically, I want a
I wrote> Modula-3 process on a Linux box to communicate with a Windows
I wrote> 3.1 application on a Windows box.  I thought sockets would
I wrote> have worked.

Well, I guess I was too quick to post.  I just needed to port my old
code to the new M3 library interface created by the Interface Police.
It's all working now.

For your information, M3 threads and sockets seem to be working fine
under Linux.

I wrote> What is the new, preferred way to do this network
I wrote> communcation?  Obliq?

For now, I'm happy using sockets but one person suggested I use
something called "ILU", which provides a language-independent version
of network objects, with support for M3.  The URL for information on
ILU is ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html.

I wrote> Thanks for helping me get Modula-3 into the commercial
I wrote> workplace.

With my first success at M3 on Linux, I hope to further convince my
employer to use M3 in our applications.  So far so good.

cheers,
dave sims
-- 
Dave Sims                                       PGP encryption key available
Internet:  sims@usa.acsys.com                   on my home page.
WWW:       <A HREF="http://cnn.acsys.com:5050/dave.html">my home page</A>


======================================================================= 140 ===
Date:    Wed, 29 Jun 1994 09:51:25 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Need Windows like combobox from formsVBT

How can I make a Windows like combobox from a formsVBT script. I want
a box which displays a text until the button is pressed and then displays
a list of texts to choose from like:

  ,----------------,,---,              ,----------------,,---,
  | Default text   || V | user pressed | Default text |#|| V |
  '----------------''---' down arrow   | Another text |#|'---'
                                       | Text string2 |#|
                                       | Third text   |#|
                                       '----------------'

When the user presses the down arrow button (V) next to the Text box
then a list box (Browser) is displayed (with scroll bar) and the user 
selects a new string. When a string is selected the display returns to
its original form. This sort of thing is quite important in the 
application I am working on. Can anyone help on this, or suggest another
way of doing it. I want this application to look and feel like a 'Windows'
or OS2PM program (I may port it one day).


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

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


======================================================================= 141 ===
Date:    Wed, 29 Jun 94 07:22:23 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: Re: sockets bad; Obliq good ???


From: sims@usa.acsys.com (dave sims)
Date: 28 Jun 1994 14:41:28 -0600
Subject: sockets bad; Obliq good ???
Newsgroups: comp.lang.modula3
Message-ID: <2uq1to$o82@cnn.acsys.com>

> Hi M3'ers, I managed to convince my employer to allow me to write one
> of our applications in Modula-3.  This applications needs network
> communication.
> 
> The problem is that my old code that used sockets doesn't compile with
> the new v3.3 compiler.  Basically, I want a Modula-3 process on a
> Linux box to communicate with a Windows 3.1 application on a Windows
> box.  I thought sockets would have worked.

> What is the new, preferred way to do this network communcation?
> Obliq?

Great news !

Sockets should work, though you don't need to use them directly. 
Check out the new TCP interfaces (right now they are buried in the
trestle and network objects packages, but they are still accessible). 
They provide readers and writers for TCP.

Under other circumstances, I'd advise using Network Objects. But 
that would mean porting M3 Win 3.1, which I'm sure you don't want 
to undertake. 



======================================================================= 142 ===
Date:    29 Jun 94 05:53:44
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: sockets bad; Obliq good ???


In article <2uqqn1$p4d@cnn.acsys.com> sims@usa.acsys.com (dave sims) writes:

   I wrote> Hi M3'ers, I managed to convince my employer to allow me to
   I wrote> write one of our applications in Modula-3.  This applications
   I wrote> needs network communication.

   I wrote> The problem is that my old code that used sockets doesn't
   I wrote> compile with the new v3.3 compiler.  Basically, I want a
   I wrote> Modula-3 process on a Linux box to communicate with a Windows
   I wrote> 3.1 application on a Windows box.  I thought sockets would
   I wrote> have worked.

   Well, I guess I was too quick to post.  I just needed to port my old
   code to the new M3 library interface created by the Interface Police.
   It's all working now.

   For your information, M3 threads and sockets seem to be working fine
   under Linux.

Dave, 

FYI, we have used sockets and threads over the past two years to
connect Modula-3 programs with programs written in non-Modula-3
languages (C,C++, Common Lisp, CLIPS) over the past two years. We
actually built a home-grown object system on top of the old Usocket
interface.  Earlier this year we ported our code to use the TCP
interface, which made our code cleaner (less dependencies on OS
pecularities of sockets), safer (TCP interface is safe), and more
robust (SRC's TCP interface seems to be able to clean up after a
shutdown of a socket better than our implementation).

Modula-3 network objects are meant to be used to connect Modula-3
programs, however, I don't think it'd be that difficult to make Obliq
(running on Linux) access Windows programs (via sockets, ILU or
whatever trasport). This way you can use Obliq as your scripting
language. The primary work would be to create obliq "proxies"
corresponding to your Windows processes, and turning an Obliq message
to a proxy into a socket call to the Windows counterpart. We did quite
a similar thing with our home-grown scripting language, which worked
out rather nicely.

--

Farshad Nayeri
nayeri@gte.com


======================================================================= 143 ===
Date:    Wed, 29 Jun 1994 13:24:04 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Re: sockets bad; Obliq good ???

dave sims (sims@usa.acsys.com) wrote:
: (e#eek! i'm following up to my own post.)

: Well, I guess I was too quick to post.  I just needed to port my old
: code to the new M3 library interface created by the Interface Police.
: It's all working now.

Which interfaces do you use now ?, which package etc as I would like
to start doing something similar.

: With my first success at M3 on Linux, I hope to further convince my
: employer to use M3 in our applications.  So far so good.

Yes !!

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

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


======================================================================= 144 ===
Date:    Wed, 29 Jun 94 08:47:58 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: Re: Need Windows like combobox from formsVBT


>
> How can I make a Windows like combobox from a formsVBT script. I want
> a box which displays a text until the button is pressed and then displays
> a list of texts to choose from like:
>
>  ,----------------,,---,              ,----------------,,---,
>  | Default text   || V | user pressed | Default text |#|| V |
>  '----------------''---' down arrow   | Another text |#|'---'
>                                      | Text string2 |#|
>                                       | Third text   |#|
 >                                      '----------------'
>
> When the user presses the down arrow button (V) next to the Text box
> then a list box (Browser) is displayed (with scroll bar) and the user 
> selects a new string. When a string is selected the display returns to
> its original form. This sort of thing is quite important in the 
> application I am working on. Can anyone help on this, or suggest another
> way of doing it. I want this application to look and feel like a 'Windows'
> or OS2PM program (I may port it one day).

Take a look at VisualObliq.  Visually its interface uses something similiar 
to what you want.  While not a perfect analogue  of the WIndows
Combo box, it might be close enough for what you want. If so, then 
I imagine the FormsVBT code could be lifted almost directly.

--geoff



======================================================================= 145 ===
Date:    Thu, 30 Jun 1994 20:30:35 GMT
From:    88-19600@shaddam.usb.ve (Rolando Jose Carrillo Pallares)
Subject: looking for shareware modula-3

Does anyone knows where can I find one shareware version of
any modula-3 compiler (DOS) ?

Thanks a lot.



======================================================================= 146 ===
Date:    30 Jun 1994 14:42:43 -0600
From:    sims@usa.acsys.com (dave sims)
Subject: ASSERT run time errors need more info

I'm preparing a commercial application in Modula-3 on Linux.  While
everything is working pretty well so far, I have one suggestion
regarding assertions.

At run time, when an assertion fails, the system prints the message:

"ASSERT failed"

or something similar.  Well, it's nice to know that an assertion
failed; however, it would be nicer if I were told where the assertion
was (file, line number) and possibly the expression that actually
failed (e.g. "i = 0").

Just a suggestion for the next version...
-- 
Dave Sims                                       PGP encryption key available
Internet:  sims@usa.acsys.com                   on my home page.
WWW:       <A HREF="http://cnn.acsys.com:5050/dave.html">my home page</A>


