======================================================================= 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@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 , Jorge Stolfi 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 , Farshad Nayeri 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 , 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@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 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 , Jorge Stolfi 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 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!) (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 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 /|) 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 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 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 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 wgsteven@undergrad.math.uwa terloo.ca (Warren Stevens) writes: In article <2sursg$fl7@lyra.csx.cam.ac.uk>, Quentin Stafford-Fraser 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 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@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 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 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 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 ----------------------------------------------------------- SRC Modula-3: bugs and patches

Bugs and patches: version 3.3

Listed below are the known bugs and patches or workarounds for version 3.3 of SRC Modula-3:

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 m3-request@src.dec.com.

PIC vs. pic (SPARC)

The default SPARC templates generate "pic" code, but when built standalone the network objects stub generator is too big.

Workaround:

Change "pic" to "PIC" throughout boot-SPARC/m3build/templates/SPARC and rebuild the system.

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

m3ship: cannot locate a .M3SHIP file, run m3build first

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

The driver package should export "m3". Add 

    LibdExport ("m3")
at the end of its m3makefile. Patch:

Near line 1120 of boot-XYZ/m3build/templates/COMMON, change 

    if defined("_all")
      delete_file(M3SHIP_FILE)
      delete_file(M3OVERRIDES)
    end
to 
    if defined("_all")
      delete_file(M3SHIP_FILE)
      delete_file(M3OVERRIDES)
      > M3SHIP_FILE in write (CR) end % let m3ship know we've been here
    end
This change will cause m3build to always create a .M3SHIP file.

libm3: struct_tm (SPARC)

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

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

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

ld: Undefined symbol _getmnt (SPARC)

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

Patch: 

Date: Fri, 03 Jun 94 18:30:23 +0100
From: Quentin <Quentin.Stafford-Fraser@cl.cam.ac.uk>

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

m3gdb: Memory corruption

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.

Patch:

In m3gdb/gdb/gdb/m3-lang.c, in procedure m3_demangle (lines 899-966) make the following changes:

  • Change the declaration of demangled from "static char demangled[100];" to "char demangled[100]".
  • Change each occurance (5 of them) of "return demangled" to "return strsave (demangled)".

mentor build fails

The mentor m3makefile doesn't evaluate properly.

Patch:

Replace include_dir(pqueue) with include_dir("pqueue") in mentor/src/m3makefile.

DPS.m3 doesn't compile

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

Patch: 

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

Wrong socket types on Solaris

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.

Patch:

Edit libm3/src/unix/solaris-2-x/Usocket.i3 to match this: 

  (*
   * 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 *)
[Modula-3 home page]

m3-request@src.dec.com
Last modified on Wed Jun  8 09:19:54 PDT 1994 by kalsow
======================================================================= 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 , Craig Kingston wrote: >In article <196*/S=Preschern/O=edvz/PRMD=uni-klagenfurt/ADMD=ada/C=at/@mhs>, >Klaus Preschern 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 , 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 , Donald Lindsay wrote: >>In article <2sh6vn$nuc@electra.saaf.se>, >>Paul Schlyter 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@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 , 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 , 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 , Carl Laurence Gonsalves 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 , John Kominek wrote: >In article <2tim2s$9bi@trondviggo.nvg.unit.no>, agulbra@nvg.unit.no (Arnt Gulb randsen) writes: >> Carl Laurence Gonsalves 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 , > Carl Laurence Gonsalves 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 ======================================================================= 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 /|) 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 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: 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: 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 Beckmann wrote: >>>>>> "agulbra" == Arnt Gulbrandsen 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 , Carl Laurence Gonsalves wrote: >In article <2tj2rr$lt4@fnnews.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 ======================================================================= 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>, 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: > > 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 , Paul A Vixie 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 , Carsten Whimster wrote: >In article , >Carl Laurence Gonsalves wrote: >>In article <2tj2rr$lt4@fnnews.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@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 , QUSAY H. MAHMOUD 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, 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: my home page ======================================================================= 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: my home page ======================================================================= 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: my home page