======================================================================== 1 === Date: 2 Jan 92 15:10:26 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 News #2 appears Happy new year! Issue 2 of the newsletter "Modula-3 News" was sent out to subscribers on Tuesday (12/31). It will arrive after normal First Class (foreign Airmail) delays, plus any holiday delay. The main topic is "Modula-3 in Academia," with feature articles on the Univ. of Cambridge, Univ. of New South Wales, and Queen Mary & Westfield College. It is interesting that Cambridge, which has adopted Modula-3 as its main imperative language in the Computer Science course, is where Maurice Wilkes built the first practical electronic stored-program computer in 1949. 47 years later, Wilkes proposed what became the Modula-3 language definition effort. The newsletter is free. An electronic copy will be posted in a week or so. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 2 === Date: 2 Jan 92 15:12:17 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: Modula-3 News #2 appears Well, perhaps 37 years later... ======================================================================== 3 === Date: Thu, 2 Jan 92 14:30:50 PST From: muller@src.dec.com (Eric Muller) Subject: Modula-3 Frequently Asked Questions (FAQ) Archive-name: Modula-3-faq Last-modified: Fri Nov 1 1991 MODULA-3 FAQ ============ What is Modula-3 ? The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. There is an overview article "Modula-3", by Sam Harbison, in Byte, Vol. 15, Number 12, October 1990, p 385. Is Modula-3 a superset of Modula-2 ? No; valid Modula-2 programs are not valid Modula-3 programs. Where can I get a definition of Modula-3 ? The definition of Modula-3 is contained in: System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 Previous definitions were published as SRC Reports # 31 and 52 and can be obtained on paper from SRC by sending a message to src-report@src.dec.com. Report # 52 is also available in PostScript format via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/report. Where can I get information on Modula-3 ? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. The messages sent to comp.lang.modula3 are relayed to a mailing list; send a message to m3-request@src.dec.com to be added to it. Also, Pine Creek Software publishes a free newsletter and various announcements about Modula-3 products and activities. To be added to their mailing list, send email or US mail to: Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213 Phone & Fax: [1] (412) 681 9811 Email: modula3@bert.pinecreek.com Where can I get an implementation ? There is only one implementation available today. It has been built by SRC and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/m3-1.6. The current version, 1.6, implements the language defined in the SRC report # 52. Version 2.0 is in the works and will implement the latest definition. Version 1.6 runs on: Acorn R260 running RISC iX 1.21 Apollo DN4500 running Domain/OS, DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 Encore Multimax running UMAX 4.3 (R4.1.1) HP 9000/300 running HP-UX 8.0 IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, VAX running Ultrix 3.1 SPARCstation running SunOS 4.1.x SUN3 running SunOS SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. What if I don't have ftp access ? You can contact Pine Creek Software (see the address above). -- Eric. ======================================================================== 4 === Date: Thu, 2 Jan 92 13:51:20 PST From: muller@src.dec.com (Eric Muller) Subject: archive of comp.lang.modula3 for December 1991 The archive of the messages sent to comp.lang.modula3 in December 1991 is now available in: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/91-12.Z Achives for the previous months are available in the same directory. Happy New Year ! Eric. ======================================================================== 5 === Date: Fri, 3 Jan 1992 12:44:23 -0600 From: Paul Pomes - UofIllinois CSO Subject: Re: Modula-3 Frequently Asked Questions (FAQ) Is anyone working on a Sequent Symmetry with Dynix (not ptx) port? If not, what are the tasks involved if I want to do it myself? Thanks. /pbp ======================================================================== 6 === Date: 3 Jan 92 20:42:26 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: FTP access to Pine Creek available I am pleased to announce that Pine Creek Software is now permitting anonymous FTP access to its vast computing facilities and extensive archives of Modula-3 related information. [Translation: I have a couple of things you might like, but if more than one person tries to access it at the same time my workstation may catch fire.] Site: bert.pinecreek.com. Login: anonymous Password: your name and host. Directory: the interesting stuff is in the 'pub' subdirectory of the root Here is what's available so you won't be in suspense. pub/BIBLIO Modula-3 books and articles pub/CHANGES change history for all directories pub/FTP instructions for using ftp pub/INDEX Index to stuff at this site (see below) pub/NEWSFLASH What's happening when pub/ORDERS Ordering T-shirts and sweatshirts pub/README General organization of the directories pub/m3news/README what's in this directory pub/m3news/m3news1.txt Issue 1 of Modula-3 News (text) pub/m3news/m3news1.ps.Z Issue 1 of Modula-3 News (PostScript(tm)) pub/m3news/m3news2.txt Issue 2 of Modula-3 News (text) pub/m3news/m3news2.ps.Z Issue 2 of Modula-3 News (PostScript) pub/doc/README what's in this directory pub/doc/m3lang.ps.Z 4-page M3 language description pub/doc/m3lang.txt (text version) pub/doc/twelvechanges.txt changes to M3 after SRC report, before books pub/doc/m3brochure.ps.Z 1-page general brochure on M3 pub/doc/m3brochure.txt (text version) pub/doc/m3forcpp.ps.Z 1-page (legal-size) brochure on M3 for C++ users pub/doc/m3forcpp.txt (text version) pub/lib/README what's in this directory pub/lib/fl-1.0.tar.Z FieldList library module pub/usenet/README what's in this directory pub/usenet/FAQ answers to frequently-asked questions [The following are threads excerpted from the comp.lang.modula3 discussions and edited.] pub/usenet/divmod.txt discussion of DIV and MOD pub/usenet/equiv.txt type equivalence in presence of initializers pub/usenet/except.txt discussion of exceptions and parameters pub/usenet/generic.txt discussion of generics pub/usenet/initial.txt providing and enforcing initialization pub/usenet/inline.txt discussion of inlining pub/usenet/macros.txt discussion of extensibility and macros pub/usenet/opaque.txt using and compiling opaque types pub/usenet/productivity.txt discussion of productivity of type-safe lang's Here's the INDEX file: TOPIC SEE ----------------- ---------------------------------------------------- books & articles /pub/BIBLIO brochures /pub/doc/README bulletin boards /pub/usenet/README C++ /pub/doc/m3forcpp.txt changes to files /pub/CHANGES comp.lang.modula3 /pub/usenet/README, /pub/usenet/FAQ compilers /pub/usenet/FAQ, /pub/usenet/opaque.txt DEC SRC /pub/FTP, /pub/usenet/FAQ DIV /pub/usenet/divmod.txt exceptions /pub/usenet/exceptions.txt FAQ (frequently asked questions) /pub/usenet/FAQ features of M3 /pub/doc/m3lang.txt ftp instructions /pub/FTP generics /pub/usenet/generic.txt, /pub/doc/twelvechanges.txt initialization /pub/usenet/initial.txt inline expansion /pub/usenet/inline.txt macros /pub/usenet/macros.txt MOD /pub/usenet/divmod.txt Modula-3 language /pub/BIBLIO, /pub/doc/README, /pub/doc/twelvechanges.txt Modula-3 News /pub/m3news/README newsgroups /pub/usenet/README newsletter /pub/m3news/README opaque types /pub/usenet/opaque.txt ordering stuff /pub/ORDERS Pine Creek Software /pub/README Prentice Hall /pub/BIBLIO productivity /pub/usenet/productivity.txt Real Time Associates /pub/BIBLIO SRC Modula-3 /pub/FTP, /pub/usenet/FAQ sweatshirts /pub/ORDERS Systems Programming with Modula-3 /pub/BIBLIO t-shirts /pub/ORDERS type equivalence /pub/usenet/equiv.txt Total Information /pub/BIBLIO USENET /pub/usenet/README Let me know if there are problems. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 7 === Date: 5 Jan 92 18:47:53 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: M3 books - int'l phone In Modula-3 News #2 I included an 800 number for obtaining copies of the Modula-3 books. This number is not useful to people outside the US; the number they should use is listed below, with the company's address: Total Information 844 Dewey Avenue Rochester, NY 14613 USA Phone: +1 (716) 254-0621 in US: 1 (800) 876-4636 FAX: +1 (716) 254-0153 Sorry for the omission. ======================================================================== 8 === Date: Wed, 8 Jan 92 09:46:56 EST From: wyant@saber.com Subject: 2.0 Release ? Any word on when the 2.0 release will occur ? Christmas has come and gone, with no presents under the tree ;-) Geoff Wyant ======================================================================== 9 === Date: 8 Jan 92 17:09:31 GMT From: dme@cl.cam.ac.uk (David Evers) Subject: 1.6 s-l-o-w to compile many revelations? I'm currently working on a stub generator for Modula-3, and have come across what I think may be a performance problem with the SRC 1.6 compiler's handling of succcessive revelations. The stub generator is organised as a front-end and several back-ends around a central abstract syntax tree. The AST node types are not defined all in one go; rather, each component of the stub generator defines its own `view' of each AST node type. The components are arranged into a linear order, and each defines its view of a node by REVEALing the total node type to be an opaque subtype of this component's view of that node type, which is itself a (concrete) subtype of the previous view's (concrete) view of the node type. I pinched this organisation from the late Olivetti M3 compiler (aka. m3tk these days). It is described in more detail in a paper by Mick Jordan in (I think) one of the recent ACM Symposia on Practical Software Development Environments; sorry I don't have the full reference handy. To make this clearer, here's a picture (arrows mean IMPORT): AST.i3 ^ TYPE Node <: NodeP; | NodeP = OBJECT END; | ............................. |<--------------------------------.-View1.m3 . | . . |<- View1.i3 . . | ^ REVEAL AST.Node <: Node; . REVEAL Node = AST.NodeP . | | TYPE Node <: AST.NodeP; . BRANDED OBJECT (*extras*). | | . END; . | | ............................. | |<----------------------------.-View2.m3 . | | . . |<- View2.i3 . . | ^ REVEAL AST.Node <: Node; . REVEAL Node = View1.Node . | | TYPE Node <: View1.Node; . BRANDED OBJECT (*extras*). | | . END; . | ... ............................. | ^ | | ............................. | |<----------------------------.-ViewN.m3 . | | . . |<- ViewN.i3 . . | ^ REVEAL AST.Node <: Node; . REVEAL Node = ViewN-1.Node. | | TYPE Node <: ViewN-1.Node; . BRANDED OBJECT (*extras*). | | . END; . | | ............................. |<- ASTTotal.i3 REVEAL AST.Node = ViewN.Node BRANDED OBJECT END; In my stub generator, N is about 9, and there are about 30 node types (things like AST.Node in the picture). Of course, not every view needs to refine all the node types; those that a view does not refine are passed through ViewN.i3 by saying something like REVEAL AST.UnchangedNode <: UnchangedNode; TYPE UnchangedNode = ViewN-1.UnchangedNode; The interfaces View[1..N].i3 compile in a perfectly reasonable time. However, the modules View[1..N].m3 take ages. On a Sun 4 with 32Mb of real memory, going flat out at >90% user states with nothing else running, they take from about 4 minutes for View1 to over 30 minutes for View9. What's worse, when I ill-advisedly added initialisation procedures to the interfaces View[5..N].i3 and imported them into my main module in order to guarantee a particular initialisation order, the main module (about 30 lines in itself) took over 2 hours to compile! Needless to say, I scrapped that idea, and relied on the module-initialisation sequencing rules of the language itself, which in fact did the right thing. At first I assumed that the fact that I was doing a lot of partial revelations of the AST node types was hitting a less-than-perfect compiler implementation of this language feature. Now I'm not so sure, given that (a) the interfaces don't take too long, whereas the modules do, and that (b) the main module (which imported five or so of the view interfaces, but made no revelations itself) took so much longer. I wonder if the compiler is just doing an exhaustive depth-first traversal of the IMPORT graph rather than `pruning' when it sees an interface it has already parsed (notice that each ViewN.m3 depends explicitly on ViewN-1.i3 and implicitly on ViewN.i3, whereas each ViewN.i3 depends only on its predecessor and AST.i3). Anybody know why this happens? Is it better in 2.0? I quite like the view structure above (the alternative being property lists on the AST nodes which each view can put its private data on), but it's barely practical with the current M3 compiler. ---- Dave [David Evers Janet: dme@uk.ac.cam.cl U. Cambridge Computer Lab (T76) Inet: dme%cl.cam.ac.uk@nsfnet-relay.ac.uk Corn Exchange Street UUnet: ...!uunet!mcvax!ukc!cam-cl!dme Cambridge CB2 3QG U.K. Phone: +44 223 334639 ] ======================================================================== 10 === Date: Wed, 8 Jan 92 12:19:37 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: 1.6 s-l-o-w to compile many revelations? Yes, this is a known problem in 1.6, for which there is no (easy) workaround. It is why 'm3tk' is shipped with 1.6 using flattened ASTs containing a fixed set of views. The good news is that everything is fixed in 2.0, The bad news is that you dont have it yet! Since you are running on DECstations, it should be easy for you to get 2.0 up and running very soon. Perhaps you could persuade Bill and Eric to give you a pre-beta-release? Mick PS My 'fix' was to write a tool (based on the Modula-3 AST) which took a set of views and flattened them out into a single type declaration which, in your example, was stored in a different version of ASTTotal.i3. I then used conditional compilation in the clients, e.g. #ifdef VIEWS IMPORT View1, View2,...; #lse IMPORT ASTTotal #endif PPS What AST are you specifying and what is the stub-generator? Just curious. ======================================================================== 11 === Date: 8 Jan 92 17:11:06 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Modula 3 newsletter I just received the Modula 3 newsletter from Sam Harbinson (alias Pine Creek Software). Looks very professional with pictures and everything. After reading it i placed it in front of my office to give Modula 3 some needed exposure. The Pine Creek archive announced last week also contains valuable information. I enjoyed the M3 for C++ programmers document. Thanks for the good work! -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 12 === Date: 9 Jan 92 15:56:20 GMT From: dme@cl.cam.ac.uk (David Evers) Subject: Re: 1.6 s-l-o-w to compile many revelations? In article <1992Jan8.121937.17739@src.dec.com>, mjordan@src.dec.com (Mick Jordan) writes: |> |> What AST are you specifying and what is the stub-generator? Just curious. The AST is for the ANSA IDL RPC interface definition language, which is based on Xerox's Courier IDL. The stub-generator converts an IDL interface into a Modula-3 interface containing a Modula-3 object type definition for the service. It also generates server- and client-side stub modules. These implement a second interface containing procedures to export instances of the service object type to the outside world, and import remote Ansa services as Modula-3 objects of the corresponding service type. ---- Dave [David Evers Janet: dme@uk.ac.cam.cl U. Cambridge Computer Lab (T76) Inet: dme%cl.cam.ac.uk@nsfnet-relay.ac.uk Corn Exchange Street UUnet: ...!uunet!mcvax!ukc!cam-cl!dme Cambridge CB2 3QG U.K. Phone: +44 223 334639 ] ======================================================================== 13 === Date: 11 Jan 92 16:37:47 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 t-shirts & sweatshirts; get orders in Repeating a previous post, Modula-3 t-shirts and sweatshirts are now available. Many people responded to an earlier poll about wanting t-shirts, but have not followed up with an order! So, mail me a check ASAP. I'll be mailing out the shirts next Wednesday; if I don't have your order by then, you'll have to wait until I return from Uniforum and mail the next batch on 1/27. Modula-3 T-shirt, 100% cotton, ash with maroon logo size L or XL $6.00 XXL 7.00 Modula-3 Sweatshirt (heavy), ash with maroon logo size L or XL 18.00 XXL 21.00 Shipping & handling (per sweatshirt, or for up to 3 tees) US 4.00 (priority mail) Canada 5.00 Other 8.00 (surface) Sam Harbison Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213-3706 USA harbison@bert.pinecreek.com +1 (412) 681-9811 ======================================================================== 14 === Date: 13 Jan 92 21:37:29 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: They're here... Well, the mailman brought a copy of my new book, "Modula-3", today. Hot off the presses, as they say, two days before the scheduled in-stock date. So, I declare that the book officially exists. Ordering info was posted earlier. ======================================================================== 15 === Date: 14 Jan 92 21:47:15 GMT From: nayeri@cs.umass.edu (Farshad Nayeri) Subject: Compiling Modula-3 2.0 on SPARCstations Can someone please let me know what modifications I have to make to the SPARC distribution of Modula-3 to make it work on the SPARCstations? The compilation process bombs because "includes/dota.base" needs a file "float.h" that does not exist on (our) SPARCstations. Thank you in Advance, Farshad Nayeri GTE Laboratories -- -- Farshad Nayeri Object Oriented Systems Group nayeri@cs.umass.edu Dept. of Computer and Information Science (413)545-0256 University of Massachusetts at Amherst ======================================================================== 16 === Date: 14 Jan 92 17:07:43 GMT From: mjl@cs.rit.edu (Michael J Lutz) Subject: Review of Nelson book in IEEE Software The January 1992 issue of IEEE Software contains a glowing review of "Systems Programming with Modula-3". I should know: I wrote it! A helpful bit of publicity for Modula-3, I hope. If you read the review, let me know what you think. Positive responses can be posted here; negative ones can be sent to me privately :-) Michael Lutz Department of Computer Science Rochester Institute of Technology Rochester, NY 14623-0887 USA +1 (716) 475-2472 mjl@cs.rit.edu ======================================================================== 17 === Date: Wed, 15 Jan 92 09:37:05 EST From: wyant@saber.com Subject: Official status of 2.0 area ? What is the "official" status of the m3-2.0 directory on gatekeeper. I've put off getting and building it until some public announcement was made. cheers, geoff ======================================================================== 18 === Date: Wed, 15 Jan 92 08:37:47 PST From: Subject: Official status of 2.0 area There is a preliminary copy of version 2.0 on gatekeeper. It's there so that a few brave and friendly people can try installing it on their systems. We've tested the DECstation and VAX versions. Others are testing the SPARC and Multimax versions. As far as we know, nobody has tried the AIX/386, Apollo, ARM, HP300, IBM R2, IBM RT or SUN 3 versions. If you do try installing the system, expect problems. It's impossible for us to get everything right without testing on real systems. We'll send another message when we believe that the release is stable enough for the masses. - Bill Kalsow ======================================================================== 19 === Date: Thu, 16 Jan 1992 00:22:32 GMT From: bill@cs.columbia.edu (Bill Schilit) Subject: testers needed... I just wrote some functions to interface GNU emacs to the release 2.0 m3pp program (thanks for the improvements Dave!). I'm looking for people interested in shaking it out for bugs before I post it here. It helps if you know elisp. A description is below. I've managed to use m3pp to do line at a time indentation (replacing leading spaces) or pretty printing (replacing the current line). ;; Modula-3 pretty printer (m3pp) interface for GNU Emacs. ;; Interactive functions (put these on keys): ;; ;; m3pp-declaration ;; Replace region starting at previous top-level declaration, BEGIN block, ;; or beginning of buffer with 'm3pp' version. ;; ;; m3pp-indent-line ;; Indent current line using 'm3pp'. ;; ;; User settable variables: ;; ;; m3pp-program-name ;; Program invoked by 'm3pp' commands. ;; ;; m3pp-program-switches ;; Program switches for 'm3pp'. ;; ;; m3pp-indent-prettily ;; When indenting, replace current line with 'm3pp' version. ;; - Bill -- Bill Schilit Columbia University Computer Science Department bill@cs.columbia.edu ======================================================================== 20 === Date: Wed, 15 Jan 1992 19:31:48 GMT From: nr@cs.Princeton.EDU (Norman Ramsey) Subject: Proposed addition to the UnsafeRd interface To speed up lexical analysis, I am using the UnsafeRd interface, so that I lock the reader at every token instead of at every character. I added a new procedure, FastUnGetChar, to the UnsafeRd interface, because otherwise I would have had to break the lock before calling Rd.UnGetChar. I suggest that many users of the UnsafeRd interface may find themselves in similar situations, and I propose that UnsafeRd.FastUnGetChar be added to the distribution, even though it's not considered a ``performance-critical'' operation. -- Norman Ramsey nr@princeton.edu ======================================================================== 21 === Date: Wed, 15 Jan 92 18:39:44 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 2.01 (beta version) available SRC Modula-3 2.01 (a beta version) is available from gatekeeper.dec.com in pub/DEC/Modula-3/m3-2.0. This version has been successfully installed on a DECstation and on a VAX. We have integrated bug fixes for the SPARC installation and we believe it should work ok. Other machines have not been tested (as far as we know). You need to start with boot.-2.01.tar.Z and libm3-2.01.tar.Z (see the README file in pub/DEC/Modula-3/m3-2.0). Look at the top level README in the boot. archive to know what the expected problems are. Expect some problems with this version. If you are willing to spend some time, please try to install it and tell us what the problems are. If you don't have time, you may prefer waiting for a future, more stable release. Thanks for your help. -- Eric. ======================================================================== 22 === Date: 16 Jan 92 17:26:29 GMT From: loverde@ux1.cso.uiuc.edu (AstralWolf) Subject: PC Compiler needed... A course at my school recently changed to Modula-3, and I am desparately looking for a PC version of Modula3 Does anyone know of either a commercial version (if so could you mail me the name) or a pd or shareware version, and preferably an FTP site where I can get it? It would be greatly appreciated.... -- ------------------------------------------------------------------------------- ! "Those who THINK they know it all ! AstralWolf ! ! are very annoying to those of us ! aka Jim LoVerde ! ======================================================================== 23 === Date: Thu, 16 Jan 92 11:37:10 PST From: muller@src.dec.com (Eric Muller) Subject: 2.01 fix for libm3 for SPARC In the archive libm3, the file Csupport/src/SPARC/m3makefile has a wrong line: PGM_SOURCES ++= -X1_-I##SOURCE_DIR##Csupport/src/SPARC_ This line should be: PGM_SOURCES ++= -X1_-I##SOURCE_DIR##_ -- Eric. ======================================================================== 24 === Date: 17 Jan 92 01:52:54 GMT From: do12+@andrew.cmu.edu (Dick Orgass) Subject: Simple fixes for 2.01 on IBMR2 My compliments to Eric for a job well done! Building the compiler, driver and core library was the easiest so far. I ran into a few minor problems when building both boot.IBMR2 and libm3.a. They're trivial except for the first one: Declaration of _M3__handlers and _M3__stackLimit in M3Runtime.h When compiling ThreadF_i.c, RTException_m.c and Thread_m.c, the C compiler for the RISC 6000 complains that one or both of the above symbols are redeclared when compared to the declarations in M3Runtime.h. This is also true when the Modula-3 core library is compiled from the Modula-3 source. As a temporary work around, I worked as follows. First I compiled boot.IBMR2 allowing the compiles of these files to fail. Next, I commented out these two declarations while compiling the offending files. Then I restored the declarations. I repeated the same steps when building the core library. This is a work around to get going but I would hope that there is a better solution for the "production" version of the compiler/library. Unfortuantely, I don't have any good ideas at the moment. Declarations in M3Machine.h The C compiler for RISC 6000 does not accept declarations of static volatile, extern volatile and volatile for functions. Accordingly, the declarations of _PRIVATE, _IMPORT and _EXPORT in M3Machine.h must be changed as shown in this code fragment. The commented text is replaced with the uncommented text. /*define _PRIVATE static volatile*/ #define _PRIVATE static /*define _IMPORT extern volatile*/ #define _IMPORT extern /*define _EXPORT volatile*/ #define _EXPORT Defining -z3 for config.c For some reason, the config.c generated by the build process leaves the text "-z3" in config.c causing m3 to complain about an invalid option whenever it is invoked. Here is the change that I made to this source file; your library directory will be different. "-z3@/u/decsrc/lib/m3/report_coverage.o@" I suspect that this is a problem with the AIX 3.1 version of sed. Use of awk when building The product version of awk emits error messages when modifying some C source file. I didn't take the time to do a major amount of work to find out the name of the source file. Instead, I simply changed to GNU awk, gawk and all went well. I'll report further when I've run the tests and built the library. Dick ======================================================================== 25 === Date: 17 Jan 92 14:03:10 GMT From: stabl@fmi.uni-passau.de (Robert Stabl) Subject: Modula3 for NeXT Is there any version of Modula3 for NeXT? If not are there any plans of porting it to this computer? Regards Robert Stabl. -- >>>>>>>> Robert Stabl <<<<<<<>>>>>>>>> stabl@fmi.uni-passau.de <<<<<<<< > Dept. of Computer Science <>>>>>>>>>>>> (NeXTmail welcome) <<<<<<<<<< >>>> University of Passau <<<>>>>>>>>> Phone: +(49)851/509-711 <<<<<<<< >>> D-8390 Passau, Germany <<>>>>>>>>>> Fax: +(49)851/509-497 <<<<<<<<< ======================================================================== 26 === Date: 17 Jan 92 17:14:31 GMT From: do12+@andrew.cmu.edu (Dick Orgass) Subject: Missing object file for IBMR2 For version 2.01, the Modula-3 core library, libm3.a, must include a special version of setjmp.o which was distributed with version 1.6 because the product version prohibits long jumps other than back into the current stack. As a quick fix, copy .ROOT/system/corelib/coreos/setjmp.o from the 1.6 distribution into libm3/IBMR2 and then execute the command ar ru libm3.a setjmp.o in that directory. This should be done after the library is built and before it is installed. Eric or Bill -- Would you be willing to add this file to your distribution and modify m3makefile so that it's built correctly? I'll be glad to send you another copy of the file if you don't have the 1.6 distribution available. Thanks! Dick ======================================================================== 27 === Date: Fri, 17 Jan 92 17:02:00 -0500 From: Norman Ramsey Subject: RTMisc.RaisesFault Would be a hell of a lot more helpful if it gave the name of the procedure that doesn't have an exception on its raises list. Norman ======================================================================== 28 === Date: 18 Jan 92 03:40:31 GMT From: PNCSPPC@CCVAX1.CC.NCSU.EDU Subject: Test (of ucbvax mail server) Sorry! Just a test message. ======================================================================== 29 === Date: 20 Jan 92 19:36:06 GMT From: paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) Subject: porting to a new host I'm installing Modula-3 on a Sequent Symmetry running Dynix 3.1. I've already got it running on a VAX-3500 with 4.3 BSD-reno. As I understand it, I need to create a Target.i3 file for the Sequent (done), and then generate a cross-compiler, followed by using that cross-compiler to create C code of the driver and compiler to compile on the Sequent. Can anyone provide explicit directions for the last two steps? I'm not all that familiar with Modula-3 as I'm installing it for use by a CS class here. All help is appreciated. /pbp -- Paul Pomes, Univ of Illinois | Necessity is the argument of tyrants, it is Email to Paul-Pomes@uiuc.edu | the creed of slaves. --William Pitt (1783) ======================================================================== 30 === Date: 21 Jan 92 16:19:08 GMT From: charon@opal.cs.tu-berlin.de (Sebastian Mix) Subject: Re: Modula3 for NeXT stabl@fmi.uni-passau.de (Robert Stabl) writes: >Is there any version of Modula3 for NeXT? If not are there any plans of portin g >it to this computer? > >Regards > Robert Stabl. I'd be very interested, too (although M2 or Oberon would do it, too). -- ------------------------------------------------------------------------------- - Sebastian Mix, Eichhornstr.5-6 Apt.222, D-1000 Berlin 30, T: (030) 262 1811 /(a \ charon@cs.tu-berlin.de | charabib@w250zrz.zrz.tu-berlin.de (no NeXTmail) \p) / ------------------------------------------------------------------------------- - ======================================================================== 31 === Date: 22 Jan 92 15:21:54 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: SRC 2.0 library Looking at the content of the libraries that come with Modula 3 SRC 2.0, i have a few questions. - the library seems to include all the goodies found in other libraries (like libg++ or nihcl in the C++ world) and then some (Pickles, Threads, Geometry...). I have not seen anything on regular expressions (only stuff to recognize standard tokens like ints, floats...), often found in other libraries, did i miss anything? - is the only documentation the comments in the interface files? Although it is sufficient for simple modules, it is hard to grasp for larger systems like Trestle. Are there other sources of documentation? I noticed TeX commands within the Trestle comments, is that part of some kind of simple "litterate programming" package? -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 32 === Date: Wed, 22 Jan 92 17:14:26 PST From: muller@src.dec.com (Eric Muller) Subject: m3-request dead ? no, simply sick I was sick during the past week. If you have sent a message to m3-request, chances are that nobody answered. Don't despair, I am back again behind my keyboard. -- Eric. ======================================================================== 33 === Date: Wed, 22 Jan 92 11:28:07 PST From: Subject: Re: SRC 2.0 library Michel Dagenais is correct that the TeX commands in the Trestle interfaces shipped with SRC Modula-3 version 2.0 are part of a simple literate programming package. The typeset output of the package is now being printed as the Trestle Reference Manual; I will post a message when it comes back from the printer. I expect we will make the literate programming package available to others, after we get a bit more experience with it at SRC. Greg Nelson ======================================================================== 34 === Date: Wed, 22 Jan 92 14:41:03 EST From: wyant@saber.com Subject: SRC 2.0 library For Trestle, at least, there is a DEC SRC Technical Report in progress. There is an early (but useful&mostly complete) version that is in the 1.6 Trestle sources under the m3 directory on gatekeeper (trestle.tar.Z). You might FTP that and then throw away everything but the Doc directory. I don't know if there are plans to write any extensive documentation on the provided libraries. I would doubt it as the SRC people are probably busy enough getting the full 2.0 release into shape (from the 'checklist' section of doc provided with 2.0, it seems that there are a number of libraries yet to come). cheers, geoff ======================================================================== 35 === Date: Wed, 22 Jan 1992 23:59:03 GMT From: nr@cs.Princeton.EDU () Subject: Pragmas I would like to see TYPE <*CLASS*> Object = OBJECT ... END; Instance1 = Object OBJECT ... END; Instance2 = Object OBJECT ... END; ... InstanceN = Object OBJECT ... END; The <*CLASS*> pragma should have two effects: -- The compiler bitches if anyone writes NEW(Object, ...) -- The compiler does not bitch if Object is the only alternative missing from a TYPECASE, e.g. VAR o : Object; BEGIN TYPECASE o OF | Instance1, Instance2, ... InstanceN => ... END; END; should draw no warnings. -- Norman Ramsey nr@princeton.edu ======================================================================== 36 === Date: Wed, 22 Jan 1992 20:26:16 GMT From: andru@electron.LCS.MIT.EDU (Andrew Myers) Subject: inline methods? How do I get the effect of C++ inline methods in Modula-3? I want to be able to package up a set of operations in an interface, but have any usage of some operations be inlined. This is clearly a violation of the interface/implementation separation, yet such a useful one... Andrew ======================================================================== 37 === Date: Wed, 22 Jan 92 13:15:00 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: inline methods? There is no compiler support for the INLINE pragma at present, but see article 624 in this newsgroup for an alternative approach. Mick Jordan ======================================================================== 38 === Date: Wed, 22 Jan 92 19:31:30 PST From: msm@src.dec.com (Mark S. Manasse) Subject: Re: Pragmas I would like to see You also want to prohibit other occurrences of Object OBJECT ... END, or else you can't be sure that you have exhausted the list of subtypes. Mark ======================================================================== 39 === Date: 23 Jan 92 16:55:30 GMT From: prj@gamba.lcs.mit.edu (Paul R. Johnson) Subject: Runtime errors Another SRC Modula-3, 2.0, question. How are "checked runtime errors" reported? ---Paul ======================================================================== 40 === Date: 23 Jan 92 15:46:42 GMT From: prj@gamba.lcs.mit.edu (Paul R. Johnson) Subject: Exception semantics In section 5.4 ("Language restrictions") of the SRC Modula-3, Version 2.0, documentation manual, it is said that the setjmp/longjmp mechanism used to implement exception handling can lead to assignments being undone. This I understand. What I don't understand is how Modula-3 programmers cope with this. Is it necessary to always keep this in mind when using TRY ... EXCEPT ... END; ? Are there special tricks to help cope? ---Paul R. Johnson ======================================================================== 41 === Date: 23 Jan 92 16:00:12 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Object browser for inspection/debugging I am looking at the possibility of implementing a simple object browser to help in debugging. Here is one way to go which would not be too complex but i am not really satisfied with it. Suggestions? - start a separate thread that opens a window, maintains a list of displayed objects, updates the displayed objects every second or so and awaits user input. - through the debugger, references of type ANY can be added to the list of displayed objects. - for each object to display, ask for the type code and call the associated PrintProc. Get the printed version as TEXT, parse it to detect the position/rank of nested references to other objects, and finally display the object. - if the user clicks on the position of a nested reference to another object, the rank of this reference within the object is noted and the VisitProc is called to access all the nested objects and add to the display list the desired object (determined by its rank). Obviously some contorsions are due to the limited number of procedures available to access type information. If one could know the list of data members in the object and their type (and name), it would be much easier to know which nested object the user wants to display. Maybe this information is there waiting for me and i have missed it ? -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 42 === Date: 22 Jan 92 15:47:03 GMT From: lilleyc@cs.man.ac.uk (Chris Lilley) Subject: Re: Modula-3 In article dagenais@vlsi.polymt l.ca (Michel Dagenais) writes: >I would presume that switching from Modula 2 to Modula 3 would be a more >natural path but i dont see many people discussing this issue in this >newsgroup. Are many Modula 2 users considering the switch? Is the lack of a >PC Modula 3 compiler the major obstacle? On the nail. *THE* major obstacle, I would say. I note that some universities are now teaching M3. That should help. Oh - btw I have redirected followups to comp.lang.modula3 Chris ======================================================================== 43 === Date: Thu, 23 Jan 92 14:02:15 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Object browser for inspection/debugging In article , dagenais@vlsi.polym tl.ca (Michel Dagenais) writes: > I am looking at the possibility of implementing a simple object browser to > help in debugging. Here is one way to go which would not be too complex but > i am not really satisfied with it. Suggestions? > - for each object to display, ask for the type code and call the > associated PrintProc. Get the printed version as TEXT, parse it to > detect the position/rank of nested references to other objects, and finally > display the object. > One problem is that in 2.0 the printprocs have gone away - they were a consider able component in the large image sizes. In the Olivetti implementation we handled t his a different way and it might be the basis of something you could work on. Since we had the abstract syntax tree around at pre-link time (at least for declarations and types), we were able to generate an encoding of a type, including the record/object/enumeration field names, as a TEXT, and store it in a global tabl e, indexed by typecode. We then had a module which interpreted this information to display the values from the debugger. I have occasionally considered running th e AST based pre-linker to generate this information and link it in to code genera ted by the SRC compiler. There needs to be a map between the typecodes generated by the two systems, since they are not the same. However, I have some plans to do this any way as part of another project. If you would like to pursue this, I would be happy to help out (especially with the lack of documentation on m3tk). On the latter issue I can say that there is a 2 .0 version of m3tk that will ship soon and there will be documentation coming in the first half of the year. Mick Jordan ======================================================================== 44 === Date: Thu, 23 Jan 92 15:16:38 EST From: wyant@centerline.com Subject: Object browser for inspection/debugging You might be able to build something interesting with 'm3tk', the Modula-3 AST toolkit written by Mick Jordan (this formerly the guts of the Olivetti M3 compiler). The only drawback is the lack of documentation. The only information directly available at runtime is type information through typecodes. You could look at the Pkl code to get a feel for traversing type structures. This won't give you names of fields though. A very crude hack would be to see if an object had a method defined that yield up field names. If the instance had such a method, call it to get field names. Otherwise, label the fields numerically... --Geoff Wyant ======================================================================== 45 === Date: Fri, 24 Jan 1992 01:03:28 GMT From: nr@cs.Princeton.EDU () Subject: Reducing garbage collection overhead in SRC M3 1.6 My interpreter was slow and was spending much too much of its time (over 40%) garbage collecting. prof(1) reported: %time seconds cum % cum sec procedure (file) 12.7 50.1200 12.7 50.12 _RTMath__IDiv (007079000_m.c) 10.1 40.0900 22.8 90.21 _RTHeap__Move (007058000_m.c) 7.1 27.9600 29.9 118.17 _RTHeap__ReferentSize (007058000_m.c) 6.0 23.6400 35.9 141.81 _RTHeap__ReferentToPage (007058000_m.c) 4.8 18.9300 40.7 160.74 _RTHeap__Collect (007058000_m.c) (The RTHeap module contains several instances where integers are divided by 2048. These divisions require calls to RTMath.IDiv because the integers are not known to be non-negative.) I first did some code tuning of RTHeap, trying to replace divisions by shifts when possible. Tuning increased execution time by only a few percent. I turned to a paper by Appel that discusses copying garbage collection. Appel defines *gamma* to be the ratio of heap size to live data. His garbage collector has a parameter gamma_0, which is the desired value of gamma. I modified RTHeap.LongGcalloc and RTHeap.GrowHeap to ensure that gamma >= gamma_0 whenever the heap has to grow. gamma_0 = 3.0 by default (the default value used by Appel), but I added a procedure RTHeapRep.SetGamma to change its value. Here are the execution times required by my program using the original and modified collectors. All times are elapsed time on a lightly loaded DS3100 with 16M of physical memory: original 152.44 +/- 4.27 sec (n = 10, stddev = 13.49) 1.92 gamma_0 = 3.0 93.59 +/- 1.22 sec (n = 10, stddev = 3.86) 1.18 gamma_0 = 4.0 88.08 +/- 3.01 sec (n = 5, stddev = 6.72) 1.11 gamma_0 = 5.0 79.24 +/- 0.55 sec (n = 5, stddev = 1.24) 1.00 To estimate the amount of ``wasted'' memory, I ran with gamma_0 = 5.0 and (at the end) queried the GC status, which reported allocated = 5000, active = 1430, gamma = 3.5, gamma0 = 5.0 Indicating that 2140 pages or about 4.2 MB were ``wasted'' over the bare minimum gamma = 2.0. But, of course, the whole point of copying collection is to trade large heap size for faster execution, so I'm happy. With gamma_0 = 5.0, garbage collection is relatively unimportant; prof(1) indictates 8.3 16.3900 8.3 16.39 _InterpScan__Token (InterpScan.nw) 7.7 15.2600 16.0 31.65 _UnsafeRd__FastGetChar (0095e000_m.c) 6.3 12.4800 22.3 44.13 _RTType__IsSubtype (00704a000_m.c) 5.6 11.0200 27.9 55.15 _UnsafeWr__FastPutChar (00727d000_m.c) 5.1 10.1600 33.1 65.31 _RTMath__IDiv (007079000_m.c) 4.7 9.3000 37.8 74.61 _InterpDict__DoAtom (InterpDict.nw) InterpScan.Token is my lexical analyzer, and InterpDict.DoAtom looks up a value in a hash table. I append to this posting a reference to Appel's article and the diffs for RTHeap.m3 and RTHeapRep.m3 (which include code tuning I shouldn't have wasted my time on). Norman Ramsey nr@princeton.edu @article{appel:simple, author = "Andrew W. Appel", title = "Simple Generational Garbage Collection and Fast Allocation", journal = "Software---Practice/Experience", year=1989, month="February", volume="19", number="2", pages="171--183"} *** RTHeapRep.i3.orig Wed Mar 27 11:45:07 1991 --- RTHeapRep.i3 Thu Jan 23 16:07:47 1992 *************** *** 161,162 **** --- 161,165 ---- + PROCEDURE SetGamma (gamma0 : REAL); + (* the desired minimum ratio of heap size to live data; default 3.0 *) + (* Appel recommend 3 to 7 for SML/NJ *) *** RTHeap.m3.orig Wed Mar 27 11:45:10 1991 --- RTHeap.m3 Thu Jan 23 19:03:17 1992 *************** *** 8,10 **** ! IMPORT RTType, RTTypeRep, RTMisc, ThreadF, RTLink, ThreadF, Cstdlib, CoreOS; FROM RTType IMPORT Typecode; --- 8,10 ---- ! IMPORT RTType, RTTypeRep, RTMisc, ThreadF, RTLink, ThreadF, Cstdlib, CoreOS, W ord; FROM RTType IMPORT Typecode; *************** *** 88,90 **** BEGIN ! RETURN (s + 1) MOD MaxSpace; END NextSpace; --- 88,93 ---- BEGIN ! IF s + 1 = MaxSpace THEN ! RETURN 0; ! ELSE ! RETURN s + 1; END; END NextSpace; *************** *** 209,211 **** PROCEDURE ReferentSize (h: RefHeader): CARDINAL = ! VAR def: RTTypeRep.Definition; res: INTEGER; BEGIN --- 212,214 ---- PROCEDURE ReferentSize (h: RefHeader): CARDINAL = ! VAR def: RTTypeRep.Definition; BEGIN *************** *** 215,218 **** IF h^ = FillHeaderN THEN ! res := LOOPHOLE (h + ADRSIZE (Header), UNTRACED REF INTEGER)^; ! RETURN res - BYTESIZE (Header); END; --- 218,221 ---- IF h^ = FillHeaderN THEN ! RETURN Word.Minus(LOOPHOLE(h + ADRSIZE (Header), UNTRACED REF INTEGER)^ , BYTESIZE(Header)); (* compiler rejects `-' ?! *) ! END; *************** *** 234,244 **** + ADRSIZE (UNTRACED REF INTEGER), (* elt pointer * ) ! UNTRACED REF INTEGER); BEGIN ! ! res := 1; FOR i := 0 TO def.nDimensions - 1 DO ! res := res * sizes^; INC (sizes, ADRSIZE (INTEGER)); END; ! res := res * def.elementSize; END; ! ! res := Upper (res + def.dataSize, BYTESIZE (Header)); ELSE --- 237,251 ---- + ADRSIZE (UNTRACED REF INTEGER), (* elt pointer * ) ! UNTRACED REF INTEGER); ! tempres : INTEGER := 1; (* suppress check for res >= 0 *) ! BEGIN FOR i := 0 TO def.nDimensions - 1 DO ! tempres := tempres * sizes^; INC (sizes, ADRSIZE (INTEGER)); END; ! tempres := tempres * def.elementSize; ! IF tempres < 0 THEN ! RETURN -1; (* cause fault *) ! ELSIF BYTESIZE(Header) = 4 THEN (*true in current implementation, but play safe*) ! RETURN Word.And(tempres + def.dataSize + 3, Word.Not(3)); ! ELSE ! RETURN Upper (tempres + def.dataSize, BYTESIZE (Header)); END; END; ELSE *************** *** 245,249 **** (* the typecell datasize tells the truth *) ! res := def.dataSize; END; - RETURN res; END ReferentSize; --- 252,255 ---- (* the typecell datasize tells the truth *) ! RETURN def.dataSize; END; END ReferentSize; *************** *** 270,275 **** PROCEDURE ReferentToPage (r: RefReferent): Page = ! VAR p: Page; BEGIN - p := LOOPHOLE (r, INTEGER) DIV BytesPerPage; - IF p < firstAllocatedPage --- 276,279 ---- PROCEDURE ReferentToPage (r: RefReferent): Page = ! VAR p: Page := LOOPHOLE (r, INTEGER) DIV BytesPerPage; BEGIN IF p < firstAllocatedPage *************** *** 283,288 **** PROCEDURE HeaderToPage (r: RefHeader): Page = ! VAR p: Page; BEGIN - p := LOOPHOLE (r, INTEGER) DIV BytesPerPage; - IF p < firstAllocatedPage --- 287,290 ---- PROCEDURE HeaderToPage (r: RefHeader): Page = ! VAR p: Page := LOOPHOLE (r, INTEGER) DIV BytesPerPage; BEGIN IF p < firstAllocatedPage *************** *** 485,488 **** VAR ! actualInc := MAX (ROUND (FLOAT (allocatedPages) * 0.2), ! MAX (HeapMinIncrement, minInc)); newChunk := Cstdlib.malloc ((actualInc + 1) * BytesPerPage) ; --- 487,490 ---- VAR ! actualInc := MAX (CEILING(gamma0*FLOAT(activePages))-allocat e dPages, ! MAX (HeapMinIncrement, minInc)); newChunk := Cstdlib.malloc ((actualInc + 1) * BytesPerPage) ; *************** *** 744,747 **** we want to have some room for the next allocation *) ! IF previousActivePages - activePages < HeapMinIncrement DIV 2 THE N ! EVAL GrowHeap (0); END; --- 746,750 ---- we want to have some room for the next allocation *) ! IF ROUND(FLOAT(activePages)*gamma0) > allocatedPages ! OR previousActivePages - activePages < HeapMinIncrement DIV 2 THE N ! EVAL GrowHeap(0); END; *************** *** 1352,1353 **** --- 1355,1365 ---- PutInt (stderr, activePages); + PutText (stderr, ", gamma = "); + PutInt (stderr, allocatedPages DIV activePages); + PutText (stderr, "."); + PutInt (stderr, ((20 * allocatedPages + activePages) DIV (2*activePages ) ) - + 10 * (allocatedPages DIV activePages)); + PutText (stderr, ", gamma0 = "); + PutInt (stderr, TRUNC(gamma0)); + PutText (stderr, "."); + PutInt (stderr, TRUNC(10.0*gamma0+0.5)-10*TRUNC(gamma0)); PutText (stderr, "\n"); *************** *** 1411,1412 **** --- 1423,1429 ---- END VisitAllRefs; + + VAR + gamma0 := 3.0; (* desired ratio of heap size to live data *) + + PROCEDURE SetGamma(gamma:REAL) = BEGIN gamma0 := MAX(gamma,2.1); END SetGamma ; -- Norman Ramsey nr@princeton.edu ======================================================================== 46 === Date: 24 Jan 92 15:39:46 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Object browser for inspection/debugging Our GNU M3 system is expected to support of TYPEOF operator that will return a data structure describing the type of the argument to TYPEOF. This would let you write browsers fairly easily. However, this feature is not a required part of M3, so would not necessarily work in other implementations. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 47 === Date: 24 Jan 92 19:04:59 GMT From: nr@cs.Princeton.EDU Subject: Three language changes I would like to see I don't know whether the language committee will consider any more changes, but here are three changes I would like to see. 1) If p is a reference to an array, then permit expressions FIRST(p) (* == FIRST(p^) *) LAST(p) (* == LAST(p^) *) 2) Promote ASSERT from a pragma to a statement, so that ASSERT e causes a runtime error when e is FALSE. Don't permit implementations to ignore ASSERT. 3) Make Word.T a type distinct from INTEGER and require explicit conversions from one to the other, perhaps using ORD and VAL. (It may be best to add a new builtin type, WORD.) Permit the usual arithmetic notation +, -, * DIV, MOD, and so on, with the same meanings as the procedures in the Word interface. I have two justifications for this proposal. First, I would like the type system to protect me from inadvertently using signed arithmetic on a variable that is meant to be unsigned. Second, the infix notation would improve the readability of my programs that do unsigned arithmetic. -- Norman Ramsey nr@princeton.edu ======================================================================== 48 === Date: 25 Jan 92 02:28:53 GMT From: sharon@lcs.mit.edu (Sharon Perl) Subject: Problems with Fmt interface It would be nice if the REALs printed by the Fmt interface were valid Modula-3 literals. Currently, using the AltSci format or the Mix format, the real number "0.0001" might print as "1.D-4", for example, which is invalid Modula-3 because a digit must follow the decimal point. Fmt should provide a mode that produces valid Modula-3 literals, giving as much precision as possible when printing REALs (or LONGREALs) without producing lots of trailing zeros for numbers that don't require many digits. Now, this is not as inconvenient as it could be at the moment, because apparently, the compiler (and the Convert module) accepts input of the form "1.D-4" as a valid LONGREAL. But this is a bug because the M3 reference manual clearly states that there must be a non-empty sequence of digits following the decimal point (p. 51 of Greg Nelson's book). Also, I noticed a bug in Fmt.m3. Fmt.LongReal and Fmt.Real use a buffer of 101 CHARS ([0..100]), but never check whether their "precision" argument will cause the buffer to overflow. Calling Fmt.LongReal with Style.Flo and a precision of 100 causes a runtime error. Sharon Perl sharon@lcs.mit.edu ======================================================================== 49 === Date: 25 Jan 92 08:33:46 GMT From: andru@electron.lcs.mit.edu (Andrew Myers) Subject: Modula-3 difficulties In trying to understand how the current Modula-3 implementation handles objects, I generated the following interface and module. The compiler reports that the RHS of TYPE a = .... assignment should be a branded type. I don't understand why this is the case. "t1.m3", line 5: right-hand side must be a branded type expression (a) What I was trying to investigate was how Modula-3 handles subtyping off an opaque type which is known to be an object type. From my reading of the language definition, this should be legal, though I can easily imagine reasons why it might have trouble doing what I asked for... ------------ interface ------------- INTERFACE t1; TYPE a <: ROOT; TYPE b = a OBJECT f,g: INTEGER; METHODS print(); END; END t1. -------------- implementation ---------------- MODULE t1; FROM Wr IMPORT PutText; FROM Stdio IMPORT stdout; REVEAL a = OBJECT e: INTEGER; END; (*** This is the line the error is on ***) TYPE b2 = b OBJECT f,g: INTEGER; OVERRIDES print := print_; END; PROCEDURE print_(bobj: b2) = BEGIN PutText(stdout, "printing a b\n"); END print_; BEGIN END t1. ======================================================================== 50 === Date: 25 Jan 92 00:25:26 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Object browser for inspection/debugging In article moss@cs.umass.edu (Eliot Moss ) writes: Our GNU M3 system is expected to support of TYPEOF operator that will return a data structure describing the type of the argument to TYPEOF. This would let you write browsers fairly easily. However, this feature is not a required pa rt of M3, so would not necessarily work in other implementations. I should have pointed out that I am describing functionality, not its packaging. The type-of feature will be nicely tucked away in an interface, not an extension to the language. In fact, I like Greg Nelson's idea that it should be called Type.Of (i.e., Type is the interface for the type descriptor stuff, and Of is a name declared therein that accepts a REFANY and returns a type descriptor object for the referent). -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 51 === Date: Sat, 25 Jan 92 07:58:05 PST From: msm@src.dec.com (Mark S. Manasse) Subject: Re: Modula-3 difficulties To make it harder to accidentally have opaque types do the wrong thing in a TYPECASE statement, the language requires that the concrete revelation of an opaque type be branded. Just REVEAL a = BRANDED OBJECT ... and all will be well. Mark ======================================================================== 52 === Date: 26 Jan 92 00:08:45 GMT From: sharon@lcs.mit.edu (Sharon Perl) Subject: Generics in SRC M3 2.0 The handling of generics in SRC Modula-3 v.2.0 seems to be undocumented magic. Greg told me that if I put my generic interfaces in ".ig" files and generic modules in ".mg" files it would work. It sort of works, except that m3make doesn't seem to notice if I change a ".mg" file. Also, I can find nothing in the m3 man page or release notes about ".ig" or ".mg" files. Am I missing something? Sharon ======================================================================== 53 === Date: 25 Jan 92 22:50:43 GMT From: patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: Porting 2.01 to a new OS Once again, it looks like I might be able to squeeze out a little time to work with Modula-3. So, instead of writing something in m3, I decided to build the latest compiler... :-) I built a version for SPARC under SunOS 4.1.1 with no problems. (Congratulations and hartfelt thanks to all involved the the restructuring of the distribution - it is a major improvement over the earlier releases.) In a fit of insanity I decided that my next step should be to port it to SVr4 ... err, SunOS5 ... oops, I mean Solaris-2... :-) The new layout gives me warm feelings about how easy this probably is, but I could use some concrete instructions on how to set up a cross-compiler, and how to use it to build a native compiler for the new system. (And which files/ directories I'm likely to have to touch.) I'm also open to suggestion on what to call the target, since SPARC is taken... Thanks, -Pat --- PMLashley plashley@Sun.COM SunSoft:NeWS Tools & Services "I haven't lost my mind -- it's backed up on tape somewhere..." ======================================================================== 54 === Date: 26 Jan 92 05:44:27 GMT From: johnh@wheaton.EDU (John (Doc) Hayward) Subject: Re: Three language changes I would like to see In article <1992Jan24.190459.25994@newross.Princeton.EDU> nr@cs.Princeton.EDU w rites: >I don't know whether the language committee will consider any more >changes, but here are three changes I would like to see. ... Here is one which I would like to see. The facility to declare in an interface module a READONLY set of variables. This would function much like the READONLY parameter in procedures and would guarentee that any module using these variables would only look at them. I know it is possible to write functions which return the values of module variables not viewable in the interface which the module wants to protect from outside changes but this proposal would allow for easier coding on the part of the programmer and better code on the part of the compiler. An example might be the error variable for a set of procedures in a module which clients should be to view but not change. johnh... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b ======================================================================== 55 === Date: 27 Jan 92 14:21:31 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Object browser for inspection/debugging > One problem is that in 2.0 the printprocs have gone away - > they were a considerable component in the large image sizes. ... > However, I have some plans to do this anyway as part of another project. > If you would like to pursue this, I would be happy to help out > (especially with the lack of documentation on m3tk). On the latter issue > I can say that there is a 2.0 version of m3tk that will ship soon... Thanks for the info. It is always enlightening to hear what projects are going on. In fact it may be interesting to probe the newsgroup a few times a year to know what is going on at DEC/SRC (Trestle, Libraries, SRC M3 2.X...) at GNU (GNU/M3 with persistent objects)and elsewhere. For the browser i guess i will wait for things to get more stable, there is no point in duplicating work. Even though it is not a "required component", run-time information about types cannot be added easily as an "optional library" on just any compiler. Thus, it would be nice if the DEC/SRC/M3 and GNU/M3 could agree on such an interface. In the mean time i will get back at what i am probably most useful at for the moment: disseminating Modula 3 among colleagues and students. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 56 === Date: Mon, 27 Jan 92 10:15:38 PST From: Subject: Re: Exception semantics I believe that most programmers ignore the potential bug. Few exception handlers depend on the exact assignments done within the TRY body and few C compilers are agressive enough to keep variables in registers across procedure calls. In the end, the bug doesn't seem to bite. Thanks for reading the documentation so carefully! - Bill Kalsow ======================================================================== 57 === Date: Mon, 27 Jan 92 10:16:52 PST From: Subject: Re: Runtime errors > Another SRC Modula-3, 2.0, question. How are "checked runtime errors" > reported? We write a message on stderr and then crash. - Bill Kalsow ======================================================================== 58 === Date: Mon, 27 Jan 1992 21:14:48 PST From: David Goldberg Subject: Re: Problems with Fmt interface I also have been bothered by limitations in the Fmt interface for printing REALs. I'd like to float (ha, ha) the following proposal: David Goldberg goldberg@parc.xerox.com ====================== I find the behavior of Fmt.Real hard to control using the current parameters. For example, if I want to print a number in Mix mode, but in a form suitable as an M3 REAL literal (i.e. 34.0, not 34.), there's no simple way to do that. Or if I want to round to 4 places in Flo mode, making 123456789 come out as 123400000, there's no simple way to do that, either. Here's an alternate proposal: TYPE Style = {Sci, Flo, FloRnd} Real(x: REAL; style: Style := FloRnd; maxFraction: CARDINAL := 6; (* max places right of decimal point *) minFraction: CARDINAL := 0; (* min places right of decimal point *) forcePt := FALSE; (* always print decimal point *) roundDigits := 7; (* for FloRnd mode *) shorten := FALSE; (* use Sci if it would be shorter *) ); The algorithm is (1) For Style = Sci, use prevailing rounding mode to round to form x.xxxxEnn, with maxFraction digits right of decimal point. If minFraction < maxFraction, then trim trailing zeros (if any), keeping at least minFraction digits right of the decimal point. If minFraction = 0 and all digits right of decimal point are zero, then forcePt controls whether there is a decimal point. The parameter shorten is ignored. (2) For Style = Flo, use prevailing rounding mode to round to xxxx.xxxxx (or .0000xxxx), with maxFraction digits right of decimal point. Possibly trim trailing zeros, using minFraction, forcePt. If shorten is TRUE, recompute with style := Sci, and use this result if it is shorter. (3) For Style = FloatRnd, use prevailing rounding mode to convert to number of form xxxx.xxxxx with rndDigit significant digits and at least minFraction digits right of decimal place. Apply forcePt as before. The parameter maxFraction is not used. If shorten is TRUE, recompute with style := Sci and maxFraction := roundDigits-1 (to keep the same precision), and use this result if shorter. Examples: Real(987654321.0, Style.Sci) 9.876543E9 Real(987654321.0, Style.Flo) 987654321 Real(987654321.0, Style.Flo, minFraction := 1) 987654321.0 Real(987654321.0, Style.Flo, forcePt := TRUE) 987654321. Real(987654321.0, Style.FloRnd) 987654300 Real(987654321.0, Style.FloRnd, minFraction := 1) 987654300.0 Real(.0000987654321, Style.FloRnd) .00009876543 Real(.000987654321, Style.FloRnd, shorten := TRUE) 9.876543E-5 ======================================================================== 59 === Date: Mon, 27 Jan 92 16:56:02 PST From: Subject: Re: Reducing garbage collection overhead in SRC M3 1.6 Norman, Thanks for the detailed information. Here at SRC we're using a slightly newer version of RTHeap than is available on gatekeeper. (We'll remedy that problem soon.) Our version exports the policy parameters of RTHeap as variables that a programmer can set. Here's the key pieces of the allocator/collector that use those parameters: VAR activePages: INTEGER; (* the number of pages holding allocated objects *) VAR allocatedPages: INTEGER; (* the number of pages allocated to the heap ("from" + "to" spaces) *) VAR availPages == allocatedPages DIV 2. (* the number of pages in the current space *) PROCEDURE Alloc () = VAR neededPages := << # pages needed to satisfy current allocation >> IF <> THEN << allocate the object from the current page >> ELSIF (activePages + neededPages <= availPages) THEN Collect (A * neededPages) << recursively call the allocator >> ELSE p := FindPages (neededPages) << allocate the object beginning at page p >> END; PROCEDURE Collect (neededPages) = << do the collection, adjusting activePages accordingly >> VAR freePages := availPages - activePages; VAR needed := MAX (recoveryRatio * availPages, minRecovery, neededPages ) IF (freePages < neededPages) THEN GrowHeap (neededPages) END; PROCEDURE FindPages (neededPages): Page = << search for a contiguous list of pages >> IF << there's no contiguous chunk that's big enough >> THEN GrowHeap (neededPages); END; << return the next free page >> PROCEDURE GrowHeap (neededPages) = VAR nPages := MAX (allocatedPages * growthRate, minIncrement, B * neededPages) << extend the heap by nPages pages (split between "from" and "to" spaces) >> And here's the settings of those parameters: version: 2.0 Norman's SRC's latest A 0 0 1 B 1 1 2 recoveryRatio 0 1/gamma 0.3 minRecovery 64 32 128 growthRate 0.2 gamma * %active - 1 0.3 minIncrement 64 64 128 In SRC's latest version "recoveryRatio", "minRecovery", "growthRate" and "minIncrement" are settable variables. - Bill Kalsow ======================================================================== 60 === Date: Tue, 28 Jan 92 08:30:03 PST From: Subject: Re: Generics in SRC M3 2.0 You're right. We forgot to document the file conventions and m3make rules for generics. SRC's version of the 'm3' driver detects when a generic source changes and recompiles the instantiations. We'll ship the fixed documentation and driver asap. - Bill Kalsow ======================================================================== 61 === Date: Tue, 28 Jan 1992 19:00:02 GMT From: nr@cs.Princeton.EDU () Subject: More about garbage collection Bill, This table gave me a misleading impression that SRC's latest garbage collector is using Appel's heap growth algorithm (which is what I implemented): > And here's the settings of those parameters: > > version: 2.0 Norman's SRC's latest > A 0 0 1 > B 1 1 2 > recoveryRatio 0 1/gamma0 0.3 > minRecovery 64 32 128 > growthRate 0.2 gamma0 * %active - 1 0.3 > minIncrement 64 64 128 > > In SRC's latest version "recoveryRatio", "minRecovery", > "growthRate" and "minIncrement" are settable variables. To recapitulate Appel's model, gamma is the ratio of heap size to live data, and gamma0, the desired value of gamma, is the single settable parameter. The garbage collector knows the amount of live data (and hence gamma) only right after a (major) collection. Applications that do lots of allocations can increase gamma0 to reduce GC overhead by using more memory. I have changed gamma to gamma0 in the table. My algebra comes out different from yours: mine src's latest heap size allocatedPages live data activePages (right after collection only) heap/2 - live freePages heap/2 availPages gamma = heap/live ? The criterion for deciding when the heap should grow is the same as Appel's, in your units freePages < recoveryRatio * availPages but in Appel's units heap size < live data * gamma0 and these criteria are the same provided that gamma0 = 2 / (1 - recoveryRatio) recoveryRatio = 1 - (2 / gamma0) which perversely works out the same as yours when gamma0 = 3! On the other hand, when you do grow the heap, your increment size is allocatedPages * growthRate so that the growth increment doesn't depend on the amount of live data. I'm not sure how much difference this makes since the decision on whether to grow is made based on the amount of live data, but the difference and the extra parameter seem gratuitous. I'm troubled by a garbage collector which applies two different sets of criteria to decide when to grow the heap. I'm troubled by a garbage collector with six parameters, four of which are settable by users. What criteria do I use to decide how to tune the collector for my application? If I naively set recoveryRatio too high and growthRate too low, I'm going to get bitten. What advantages does the multiparameter model offer? Wouldn't it be worthwhile trying to find a simpler model? -- Norman Ramsey nr@princeton.edu ======================================================================== 62 === Date: 28 Jan 92 22:07:43 GMT From: rdubey@yoda.eecs.wsu.edu (Rakesh Dubey - grad student) Subject: Problem in compiling with m3 The program Main.m3 in the directory shown below does not compile and I get this intermittent error. /tests/m3tests/ptests/p001 $ m3 Main.m3 (ccom): (null), line 1: ccom: Internal: build_tables out of memory Sometimes it works all right, and sometimes it does not. Is there something wrong with my implementation. This is on a DEC3100. Thanks a lot, Rakesh -- Rakesh Dubey rdubey@yoda.eecs.wsu.edu ======================================================================== 63 === Date: Wed, 29 Jan 1992 04:51:27 GMT From: andru@electron.LCS.MIT.EDU (Andrew Myers) Subject: Placing dynamically created types in the heap I'd like to be able to dynamically create "new types" which are understood by the garbage collector. A brief scan through RTHeapRep and RTTypeRep suggests that this is possible. However, the Typecell.dataSize field prevents the creation of variable-sized objects. It's also unclear to me how to add new Typecodes/Typecells to the system (or even if it's possible). Any thoughts on this? Thanks, Andrew ======================================================================== 64 === Date: Wed, 29 Jan 1992 09:34:20 PST From: dhinz@wbst845e.xerox.com (Daniel W. Hinz) Subject: Does this indicate more than it says? I'm new to m3 and have been just trying some things out. I was able to get all the compilations to work until I tried to use an interface not in the core interfaces. I get the following: linden% m3 -v -o ex1 -lm3math example1.m3 /usr/local/lib/m3/m3compiler -D/usr/local/lib/m3/Xaw -D/usr/local/lib/m3/Xt -D/usr/local/lib/m3/X11 -D/usr/local/lib/m3/io -D/usr/local/lib/m3/data -D/usr/local/lib/m3/math -D/usr/local/lib/m3/misc -D/usr/local/lib/m3/ultrix-3-1 -D/usr/local/lib/m3/core -D. -w3 -o 55412d372cf2000_m.c example1.m3 /bin/cc -I/usr/local/lib/m3 -c 55412d372cf2000_m.c unlinking 55412d372cf2000_m.c ... done nm -op 55412d372cf2000_m.o unlinking 55412d372cf2000_m.o ... done interface Interval needed but not found linden% This program uses Thread, Fmt, Wr, and Stdio without a problem. When I tried adding Random or Interval I get the above message. The interface modules for Random and Interval are in misc and math directories, respectively. I added the -v option just for verification purposes. If I add /usr/local/lib/m3/math/Interval.i3 to the command line the compiler works but the linker of course complains about multiply defined symbols. I'm running 1.6 on a Sparc2. I have a symbolic link from usr to local, which have discounted because the core interfaces work on that path. The installation went smoothly with no errors and no warnings. Have I fallen prey to a common misunderstanding? Any help will be appreciated. Thanks. -dwh- ======================================================================== 65 === Date: 27 Jan 92 19:09:00 GMT From: srobyns@hpcupt3.cup.hp.com (Serge Robyns) Subject: info on Modula3 Hi everybody, I've read about modula2 several years ago, now I see that there is a modula3 language which seems to support OO. I would like to have some info about modula3. I'm currently a C programmer. Can you send me: - References - Lex/Yacc definitions - Info where I can get one, free is liked most as I don't know if I would use the language. Platforms (Mac, MSDOS, HP-UX) Thanks in advance, Serge Robyns (srobyns@hpcupt3.cup.hp.com) ======================================================================== 66 === Date: Wed, 29 Jan 1992 17:57:12 GMT From: nr@cs.Princeton.EDU () Subject: Supporting fast lexical analysis in Modula-3 I've written an interpreter which spends 25% of its time in two routines: UnsafeRd.FastGetChar and UnsafeWr.FastPutChar. This is happening during lexical analysis, mostly during scanning of identifiers and string literals, e. g. roughly VAR token := TextWr.New(); c : CHAR; BEGIN (* ... *) REPEAT (* read a name *) UnsafeWr.FastPutChar(token, c); c := UnsafeRd.FastGetChar(rd); UNTIL flags[c].stop; RETURN TextWr.ToText(token); (* ... *) END; Lexical analysis is a common bottleneck in compilers, so others are likely to encounter similar problems. I would like to find a solution that others can use. I propose an extension to the reader abstraction that will permit the use of some of the techniques described by William Waite in ``The Cost of Lexical Analysis,'' Software---Practice & Experience 16(5), 473--488 (May 1986). These techniques (1) avoid copying characters out of the read buffer unless necessary (2) scan very quickly through common character sequences, like white space, identifiers, and string literals To achieve (1) I suggest making it possible to ask a reader to remember a subsequence of characters in its buffer, then produce them later. Most of the time the characters would be in the buffer and could be produced quickly using SUBARRAY. To achieve (2) I suggest a procedure that scans through the reader looking for a ``stop character.'' The implementation would use the unsafe features of Modula-3 to construct a tight inner loop using pointers in registers. Here are a proposed interface and a sample use of that interface. I would like comments. Here is the interface, RdLex: INTERFACE RdLex; FROM Rd IMPORT T, Error, Failure, EndOfFile, Alerted; (* Supports fast lexical analysis by reducing copying and by providing fast character search *) (* Add to the reader abstraction the following two values: tokset(r) a Boolean tok(r) an integer in the range [0..cur(r)-1] If tokset(r) is TRUE, then r must ``remember'' the character sequence src(r)[tok(r)..cur(r)-1]. Seeking causes an error if tokset(r) is TRUE. *) PROCEDURE SetToken(r:T; offset:[-1..0]) RAISES {Error}; (* IF cur(r) + offset < 0 THEN RAISE Error; ELSE tokset(r) := TRUE; tok(r) := cur(r) + offset; END; *) PROCEDURE ForgetToken(r:T) RAISES {}; (* tokset(r) := FALSE; *) TYPE TokenClosure = OBJECT METHODS apply(READONLY a: ARRAY OF CHAR) RAISES {} END; PROCEDURE GetToken(r:T; offset:[-1..0]; cl:TokenClosure):TokenClosure RAISES {Error}; (* IF NOT tokset(r) OR cur(r)+offset < 0 THEN RAISE Error; ELSE tokset(r) := FALSE; cl.apply(SUBARRAY(src(r),tok(r),cur(r)+offset-tok(r))); RETURN cl; END; *) TYPE FlagSet = SET OF [0..7]; PROCEDURE Search(r:T; READONLY flags: ARRAY CHAR OF FlagSet; stopflags: FlagSet; sentinel:CHAR):CHAR RAISES {Error, Failure, EndOfFile, Alerted}; (* raises like GetChar *) (* IF stopflags * flags[sentinel] = FlagSet {} THEN RAISE Error; ELSE REPEAT c := GetC(r); UNTIL stopflags * flags[c] # FlagSet {}; RETURN c; END; N. B. the purpose of the sentinel is to make it possible to implement the inner loop without having to check for overflow past the buffer. *) END RdLex. I think the implementation of RdLex need not be too different from the existing RdMove implementation. It can certainly be made to work with the existing class methods. Here is an example for the use of these procedures, drawn loosely from the lexical analyzer for my PostScript interpreter. I have compiled the example against the RdLex interface. Atom.FromChars is a procedure that looks up a sequence of characters in a ``unique string table.'' If the sequence is already in the table, it returns an Atom.T (containing a TEXT) that is already allocated. Thus, in the common case of reading an identifier that is already known, the lexical analyzer doesn't do any allocation or any copying. MODULE SampleLex EXPORTS Main; IMPORT Atom, Rd, RdLex; VAR flags := ARRAY CHAR OF RdLex.FlagSet { RdLex.FlagSet {NonWhite}, .. }; CONST NonWhite = 0; (* set for non-white space characters *) StopCharacters = 1; (* set for chars that end a name token *) StringSpecials = 2; (* set for '(', ')', '\\' *) EXCEPTION Unmatched; (* unmatched ( or { in input *) PROCEDURE NextToken(rd:Rd.T) RAISES {Rd.EndOfFile, Unmatched} = VAR c : CHAR; depth : INTEGER; result : Atom.T; BEGIN c := RdLex.Search(rd, flags, RdLex.FlagSet {NonWhite}, 'x'); CASE c OF | '0'..'9' => (* read and return a number *) | ')' => RAISE Unmatched; | '(' => RdLex.SetToken(rd,0); (* read a string *) depth := 1; WHILE depth > 0 DO c := RdLex.Search(rd, flags, RdLex.FlagSet{StringSpecials},')'); CASE c OF | '(' => INC(depth); | ')' => DEC(depth); | '\\' => (* RETURN SlowString(rd); -- ugly case! *) END; END; result := NARROW(RdLex.GetToken(rd, -1, atomcl), AtomClosure).a; (* RETURN AtomProperties.StringOf(result); *) ELSE (* read a name *) RdLex.SetToken(rd, -1); TRY EVAL RdLex.Search(rd, flags, RdLex.FlagSet {StopCharacters}, ' '); result := NARROW(RdLex.GetToken(rd, -1, atomcl), AtomClosure).a; EXCEPT Rd.EndOfFile => result := NARROW(RdLex.GetToken(rd, 0, atomcl), AtomClosure).a; END; (* RETURN AtomProperties.NameOf(result); *) END; END NextToken; TYPE AtomClosure = RdLex.TokenClosure OBJECT a : Atom.T; METHODS (*OVERRIDES*) apply := SetAtom; END; VAR atomcl := NEW(AtomClosure); PROCEDURE SetAtom(cl:AtomClosure; READONLY a: ARRAY OF CHAR) RAISES {} = BEGIN cl.a := Atom.FromChars(a); END SetAtom; BEGIN flags[' '] := flags[' '] - RdLex.FlagSet { NonWhite }; flags['\n'] := flags['\n'] - RdLex.FlagSet { NonWhite }; flags['\t'] := flags['\t'] - RdLex.FlagSet { NonWhite }; flags['('] := flags['('] + RdLex.FlagSet { StringSpecials }; flags[')'] := flags[')'] + RdLex.FlagSet { StringSpecials }; flags['\\'] := flags['\\'] + RdLex.FlagSet { StringSpecials }; (* and so on ... *) END SampleLex. -- Norman Ramsey nr@princeton.edu ======================================================================== 67 === Date: 29 Jan 92 14:24:46 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Placing dynamically created types in the heap In article <1992Jan29.045127.15647@mintaka.lcs.mit.edu> andru@electron.LCS.MIT.EDU (Andrew Myers) writes: I'd like to be able to dynamically create "new types" which are understood by the garbage collector. A brief scan through RTHeapRep and RTTypeRep suggests that this is possible. However, the Typecell.dataSize field prevents the creation of variable-sized objects. It's also unclear to me how to add new Typecodes/Typecells to the system (or even if it's possible). Umm, gee, how would they work w.r.t. TYPECASE and stuff like that? What is it that you're *really* trying to do? Maybe we can give more hints. I'm also interested because our GNU Modula-3 implementation does types in a different way from the SRC system (but still compatible with the language spec). -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 68 === Date: 29 Jan 92 21:33:53 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: EXTENDED support coming? In version 2.0, the floating type EXTENDED uses the same representation as LONGREAL on the DS3100 (and maybe everywhere). I hope we will soon be able to take advantage of the EXTENDED type. What are the plans? On a related note, does anyone have software routines for the basic math functions on IEEE extended types? Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 69 === Date: 30 Jan 92 07:08:19 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Placing dynamically created types in the heap In article <1992Jan30.015730.2206@mintaka.lcs.mit.edu> andru@electron.LCS.MIT.E DU (Andrew Myers) writes: >I want to implement the runtime system for a new language. I have two >choices: > > - I manage my own heap, and write my own garbage collection. > > - I insert language objects into the Modula-3 heap, and let > Modula-3 handle the garbage collection. > >Is the second choice feasible? Could be, but it means that you are depending upon the DEC M-3 GC not changing in the future. If all you want is GC, go nab a collector from either Hans Boehm and Mark Weiser (of Xerox PARC) or Joel Bartlett (of DEC-WRL) or from Daniel Edelson (was of UC Santa Cruz). As for the question of adding types on the fly -- it's a semi-solved problem, and the guys at SRC should know how to do it, because we've discussed it in the past. There was a recent letter in TOPLAS detailing one method of answering the "is_subtype_of" question that I think can be incrementally updated, and there is another method based on an paper by Paul Dietz that uses pre and post-order traversal numbers. I think there was another semi-recent paper in either TOPLAS or JACM on operations on lattices that might subsume this problem (i.e., handle the multiple inheritance case). TYPECASE presents a bit of a problem if you want to do concurrent updating of the data structures. An additional thing to explore would be the use of Dietz-Sleator numbers for the pre and post order numbers. David Chase Sun ======================================================================== 70 === Date: 30 Jan 92 00:36:20 GMT From: woolsey@mri.uucp (Jeff Woolsey) Subject: Re: Runtime errors In article <9201271817.AA18601@jumbo.pa.dec.com> kalsow (Bill Kalsow) writes: >> Another SRC Modula-3, 2.0, question. How are "checked runtime errors" >> reported? > >We write a message on stderr and then crash. Yeah, but you still don't say where the error occurred. Big fun finding it in 10000 lines of code. So I whipped up this kludge for 1.5, and finally converted it to 2.0 beta today (guess why). It does the trick for SPARC. Apply the diff, compile the .c module, and explicitly mention the .o on the m3 command line when linking. I don't have the disk space or patience to add it to libm3.a (and don't know what effect it would have on libm3.ax). *** lib/m3/M3RuntimeDecls.h Wed Jan 29 16:12:39 1992 --- lib/m3/M3RuntimeDecls.h% Wed Jan 29 16:10:18 1992 *************** *** 266,277 **** #define _NARROW(e,tc) if (!_ISSUBTYPE(_TYPECODE(e),tc)) _NARROWFAULT ! #define _ASSERTFAULT _jlwRuntime__AssertFault (__FILE__, __LINE__) ! #define _RETURNFAULT _jlwRuntime__ReturnFault (__FILE__, __LINE__) ! #define _CASEFAULT _jlwRuntime__CaseFault (__FILE__, __LINE__) ! #define _TYPECASEFAULT _jlwRuntime__TypecaseFault (__FILE__, __LINE__) ! #define _RANGEFAULT _jlwRuntime__RangeFault (__FILE__, __LINE__) ! #define _NARROWFAULT _jlwRuntime__NarrowFault (__FILE__, __LINE__) #define _CVTIF(x) ((float) x) #define _CVTLF(x) ((float) x) --- 266,277 ---- #define _NARROW(e,tc) if (!_ISSUBTYPE(_TYPECODE(e),tc)) _NARROWFAULT ! #define _ASSERTFAULT RTMisc__AssertFault () ! #define _RETURNFAULT RTMisc__ReturnFault () ! #define _CASEFAULT RTMisc__CaseFault () ! #define _TYPECASEFAULT RTMisc__TypecaseFault () ! #define _RANGEFAULT RTMisc__RangeFault () ! #define _NARROWFAULT RTMisc__NarrowFault () #define _CVTIF(x) ((float) x) #define _CVTLF(x) ((float) x) ========= jlwrun.c: ========= #include void _jlwRuntime__AssertFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__AssertFault (); } void _jlwRuntime__ReturnFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__ReturnFault (); } void _jlwRuntime__CaseFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__CaseFault (); } void _jlwRuntime__TypecaseFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__TypecaseFault (); } void _jlwRuntime__RangeFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__RangeFault (); } void _jlwRuntime__NarrowFault (file, line) char *file; int line; { fprintf(stderr, "\n\"%s\", line %d: ", file, line); RTMisc__NarrowFault (); } -- -- Jeff Woolsey 800 950 5554 woolsey@mri.COM Microtec Research, Inc. +1 408 980 1300 woolsey@netcom.COM Nothing like a three-address mailer.... woolsey@folderol.UUCP ======================================================================== 71 === Date: Thu, 30 Jan 92 01:19:57 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Problem in compiling with m3 In article <1992Jan28.220743.16543@serval.net.wsu.edu>, rdubey@yoda.eecs.wsu.ed u (Rakesh Dubey - grad student) writes: > > The program Main.m3 in the directory shown below does not compile and I > get this intermittent error. > /tests/m3tests/ptests/p001 > $ m3 Main.m3 > (ccom): (null), line 1: ccom: Internal: build_tables out of memory > > Sometimes it works all right, and sometimes it does not. > Is there something wrong with my implementation. This is on > a DEC3100. We tend to have large programs around here, and the C code that comes out of the compiler can be very large. To make the C compiler happy, we add to increase the size of some internal tables, by passing some arguments to CC. If you look in your config file, you will see: PASS1 = @$(CC)@-G@4@-Wf,-XNp200000@-Wf,-XNd150000@ What is most likely to happens is that your system does not always have enough memory (physical+swap) to accomodate the allocation of such large tables. As this depend on the current load of the machine, you get intermittent errors. We haven't tried to adjust the parameters to the smalllest values that will work for the distributed programs; you can try to do that. The simplest is give commands of the form: m3 -Y1@cc@-G@4@-Wf,-XNp200000@-Wf,-XNd150000@ ... changing the 200000 and the 150000. There is a little problem however. If you overflow the table, the result is not predictable: the objects produced by the C compiler can be plain wrong, and you don't get any warning (if course, if the C compiler had been written in Modula-3...). If you don't use Trestle, I believe that you can use the default values of cc, by giving commands of the form: m3 -Y1@cc@-G@4@ ... -- Eric. ======================================================================== 72 === Date: Thu, 30 Jan 92 01:33:48 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Porting 2.01 to a new OS In article , patl@bodacia.Eng.Sun.COM (Pat Las hley [MtV NeWStech Eng.]) writes: > In a fit of insanity I decided that my next step should be to port it to > SVr4 ... err, SunOS5 ... oops, I mean Solaris-2... :-) The new layout > gives me warm feelings about how easy this probably is, but I could use > some concrete instructions on how to set up a cross-compiler, and how to > use it to build a native compiler for the new system. (And which files/ > directories I'm likely to have to touch.) > > I'm also open to suggestion on what to call the target, since SPARC is > taken... I am putting the final touches to a new release, that will make ports much easier. It's almost there. Really. I took some notes for what needs to be done; they are below. The first part lists the places in the sources that have machine dependencies today; if the system you are porting too is sort of bsd, it is very likely that this is enough. This certainly needs to be rewritten, but you may start to investigate the amount of work you will have to do. I haven't included the second part that give all the details about building the cross-compiler and cross-compiling, as it may change, and you don't need them right now since you don't have the properly organized sources and tools. When the release will be made you will have to start from that release. -- Eric. =============================================================================== Adapt the libm3 sources to your target system: Some the Modula-3 code (as well as very little pieces of C) are architecture dependant. Of course, it may be that some code we thought to be machine independant will turn to have to be changed for your NEW architecture, so we cannot guarentee that the list of things to fix below is exhaustive. In general, look at what is done for the other machines, and find the most similar as a starting point. Go in the libm3 archive. Here are the components that are machine dependant. Csupport/src. Add a directory NEW, and put in it: - m3makefile: to describe the contents of the directory - M3Machine.h: is included in every C file generated by the Modula-3 compiler. - dtoa.c: this piece of code just configures generic/dtoa.base; look at that file for the things to configure. - float.h: you need this file if your system does not provide one. You can build it using a program called enquire, which can be found on the net. We included a copy of it in boot archives, in the directory misc. C/src. Add a directory NEW, and put in it: - m3makefile - Csetjmp.i3: describes the interface to the setjmp and longjmp routines. Be careful to get the size of the jmp_buf right. - Cstdio.i3: describes the stdio stuff thread/src. Add a directory NEW, and put in it: - m3makefile - WildJmp.i3: this interface provide functions that are similar to setjmp and longjmp, but these functions should not impose any restriction on what is possible. For example, the VAX version requires that longjmp call actually pop the stack (remember that "longjmp botch" message ?), which is not good enough for our use of Wildjmp. Instead the VAX version provides its own assembly code to do the work. The IBMR2 is similar, but here we included the object in the distribution and use it rather than the source (and the m3makefile reflects that). The DS3100 version is the simplest, because there are no restrictions on the uses of setjmp. runtime/src. The dependency described there is for the benefit of the garbage collector. At the beginning of a collection, the collector must find all the roots, that is all the heap objects that are pointed to from outside the heap itself. The stacks contain such pointers, and the collector scans them to find roots. However, the collector does not know the full structure of the stacks (frames, argument lists and so on); rather, it just looks at the values that are there and make conservative decisions by interpreting these values as possible pointers. For each stack, the collector initializes a pointer P to the bottom of the stack; then it repeatedly tries to interpret the bits pointed by P as a pointer in the heap, marks the root if the interpretation is succesful and advances P. The question is by how much P should be advanced; if all entries in the stack are aligned at a n-bytes boundary, it is sufficient to increment P by n bytes; a smaller value would be an overkill. We have found that some machines require n to be 2, and that 4 is enough for others. If one of these two values is good for you, just remember it. Otherwise, create a subdirectory StackInc-, fill it like StackInc-2 (don't forget to modify StackInc.i3 with your value of n), and remember your value of n. float/src. Add a new directory NEW, and copy into it the files of the subdirectory MODEL. The routines in these modules provides access the floating point control (set exceptions and so on). The version in MODEL is a template, and most of the routines will fail (because of an <*ASSERT FALSE*>) if executed. The DS3100 directory is an example of implementation for an IEEE machine, the VAX directory is an example for non-IEEE machines. It is not essential that you implement the proper procedures right now: the compiler and the driver do not depend on these interfaces (more precisely, the template in MODEL is good enough). But you will have to take care of them at some point. random/src. This also contains code that depends on the representation of floating point numbers. There are three models in there: IEE-be (big endian), IEEE-le (little endian), VAX. If one of these is good for you, just remember which one it is; otherwise, create your own. unix/src. That one is big. The interfaces in this component provide access to the routines of section 2 and of section 3 (read, close, etc). Not everything is needed to boot the driver and the compiler. You may want to use the version for another achitecture that is not too distant from yours and fix it as you discover problems. Remember the name of the one you want to use for the bootstrap purpose, or of the copy you made for your system. Finally, you need to fix the src/m3makefile to include a bunch of lines of the form: #ifdef TARGET_NEW ... #endif similar to the ones that are already there, using the version of StackInc you have selected or created (same for unix, ...). ======================================================================== 73 === Date: Wed, 29 Jan 92 23:06:19 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Runtime errors In article <1992Jan30.003620.8177@mri.uucp>, woolsey@mri.uucp (Jeff Woolsey) wr ites: > In article <9201271817.AA18601@jumbo.pa.dec.com> kalsow (Bill Kalsow) writes: > >> Another SRC Modula-3, 2.0, question. How are "checked runtime errors" > >> reported? > > > >We write a message on stderr and then crash. > > Yeah, but you still don't say where the error occurred. Big fun > finding it in 10000 lines of code. > > So I whipped up this kludge for 1.5, and finally converted it to 2.0 > beta today (guess why). It does the trick for SPARC. Funny. I have written similar code for 1.6; the main difference was that the compiler generated the appropriate strings (as Text.Ts) instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could handle that. I liked it very much, because more often that not, this is enough info to find out what the problem is. However, it makes the code significantly bigger (the string was unique in each file, of course) and was therefore removed. What I do today is just to run the program under debug and wait for the crash to occur to see where the failed check is. -- Eric. ======================================================================== 74 === Date: Thu, 30 Jan 92 01:04:42 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Does this indicate more than it says? In article <9201291734.AA11531@linden>, dhinz@wbst845e.xerox.com (Daniel W. Hin z) writes: > linden% m3 -v -o ex1 -lm3math example1.m3 > ... > interface Interval needed but not found > ... > Have I fallen prey to a common misunderstanding? Any help will be > appreciated. Yes. The order of arguments is important (in 1.6; the rules are slightly different for 2.0), just as they are for C programs. In that case, the library m3math is searched for resolutions of undefined symbols before example1.m3 is linked in. At that point, nobody asked for "Interval", so it is not loaded from the library. Then example1.m3 comes along, and Interval is now needed, but there is no longer anybody to provide it. Try: m3 -o ex1 example1.m3 -lm3math -- Eric. ======================================================================== 75 === Date: Thu, 30 Jan 1992 01:57:30 GMT From: andru@electron.LCS.MIT.EDU (Andrew Myers) Subject: Re: Placing dynamically created types in the heap I want to implement the runtime system for a new language. I have two choices: - I manage my own heap, and write my own garbage collection. - I insert language objects into the Modula-3 heap, and let Modula-3 handle the garbage collection. Is the second choice feasible? It seems to require that I be able to specify new types to the Modula-3 runtime, since it is through types that the SRC-2.0 garbage collector decides where the references are. I'm not interested in doing a TYPECASE on these types, obviously; just in allowing GC to grok them. Any more thoughts? ======================================================================== 76 === Date: Thu, 30 Jan 92 01:09:55 PST From: muller@src.dec.com (Eric Muller) Subject: Re: info on Modula3 In article <47090001@hpcupt3.cup.hp.com>, srobyns@hpcupt3.cup.hp.com (Serge Rob yns) writes: > Can you send me: > - References @techreport (m3-BN89, author = "Mark R. Brown and Greg Nelson", title = "{IO} Streams: Abstract Types, Real Programs", number = "53", type = "SRC report", institution = "System Research Center, Digital Equipment Corporation", address = "Palo Alto", month = nov, year = 1989, howtoget = "On paper, by sending a mail to src-report@src.dec.com.", what = "Shows how to use objects in a real program. Also defines the de facto standard input/output functions." ) @article (m3-Har90, author = "Sam Harbison", title = "Modula-3", journal = "Byte", volume = 15, number = 12, pages = "385--392", month = nov, year = 1990, what = "A survey article." ) @book (m3-Nel91, title = "System Programming with Modula-3", editor = "Greg Nelson", publisher = "Prentice Hall", year = 1991 ) The last one contains the definition of the language. Sam, is your book on the shelves now ? > - Lex/Yacc definitions See below. > - Info where I can get one, free is liked most as I don't know if I > would use the language. Platforms (Mac, MSDOS, HP-UX) Look on gatekeeper.dec.com, in pub/DEC/Modula-3; there is a version for HP-UX. The distribution includes a pretty-printer which uses a lex/yacc parser. The compiler has its own recursive descent parser. -- Eric. ======================================================================== 77 === Date: Thu, 30 Jan 92 16:13:43 +0100 From: Piet van Oostrum Subject: Re: info on Modula3 >>>>> muller@src.dec.com (Eric Muller) (EM) writes: EM> Look on gatekeeper.dec.com, in pub/DEC/Modula-3; there is a version EM> for HP-UX. The distribution includes a pretty-printer which uses a EM> lex/yacc parser. The compiler has its own recursive descent parser. The HP-UX version has a couple of smaal problems. I have solved most but not all (lack of time being the biggest reason). ======================================================================== 78 === Date: Thu, 30 Jan 92 08:38:09 -0800 From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: info on Modula3 Eric, Please add my book to your bibliography database. Also, does the IO Streams tech report have anything in it that the chapter in SPwM3 does not? I noticed that you apparently dropped the Modula-3 report from your list, presumably because it is now out of date. Sam "Looking out for #1" Harbison ======================================================================== 79 === Date: 30 Jan 92 17:42:20 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: Runtime errors In article <1992Jan29.230619.27814@src.dec.com> Eric Muller writes: >... >Funny. I have written similar code for 1.6; the main difference was >that the compiler generated the appropriate strings (as Text.Ts) >instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could >handle that. > >I liked it very much, because more often that not, this is enough info >to find out what the problem is. However, it makes the code >significantly bigger (the string was unique in each file, of course) >and was therefore removed. >... I urge you to revert to the 1.6 behavior as the default, so that checked run-time errors print a message with the location of the error. Most programmers trip over run-time errors. It is a specific benefit of Modula-3 that such errors are caught and do not have to be tracked down with a debugger. However, under the current behavior you DO have to use a debugger to locate the errors. Seems wrong to me. It may be reasonable to add a compile-time option to "minimize" the runtime checking overhead in specific cases. Experience indicates some people will even ask for an option to eliminate checking entirely, although the wisdom of that choice is debatable. Sam ======================================================================== 80 === Date: 30 Jan 92 14:14:41 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: info on Modula3 Just to add to Eric's info, the Revised Report on Modula-3 is available on gatekeeper.dec.com in pub/DEC/Modula-3. It is a little out of date w.r.t. a few topics (the Nelson book is the best reference on the language definition). In addition to the SRC implementation, we are working on a GNU implementation. We don't use lex; we do use bison (the GNU yacc clone) and could send you our bison defs if you *really* need them .... Eliot Moss -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 81 === Date: 29 Jan 92 20:03:13 GMT From: johnh@wheaton.EDU (John (Doc) Hayward) Subject: m3make documentation missing? In section 5.3 of SRC Modula-3 version 2.0 it talks about m3make. This is a great facility for which my students can easily write m3makefiles. I could not find the manual page which it mentioned for more details. Did I miss it or was it left out? If someone has a copy could they e-mail it to me. Thanks in advance. johnh... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b ======================================================================== 82 === Date: 30 Jan 92 14:20:05 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Problem in compiling with m3 Perhaps gcc would be more friendly than cc?? -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 83 === Date: 30 Jan 92 14:22:47 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Supporting fast lexical analysis in Modula-3 I guess my reaction is that if you want a buffer oriented interface (which is what fast lexical analysis seems to need) rather than a character oriented one, then build/use it, rather than hacking up a character oriented interface to act like a buffer oriented one. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 84 === Date: 30 Jan 92 14:18:42 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Placing dynamically created types in the heap Something else you might be interested in is the UMass garbage collector toolkit we have under development. It is specifically designed to help language implementors supply gc. It is based on copying collection and requires accurate location of all pointers in the stack, globals, and registers, and assumes that, given a pointer to (the base of) a heap object, you can find the pointers inside it. But it supplies a lot of generational collection mechanism in return for that. Perhaps you should correspond with me privately for more details ... Eliot Moss -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 85 === Date: Thu, 30 Jan 92 12:18:07 PST From: muller@src.dec.com (Eric Muller) Subject: Re: info on Modula3 In article , moss@cs.umass.edu (Eliot Mos s) writes: > Just to add to Eric's info, the Revised Report on Modula-3 is available on > gatekeeper.dec.com in pub/DEC/Modula-3. It is a little out of date w.r.t. a > few topics (the Nelson book is the best reference on the language definition) If you are using 2.x, it's enough out of date to get you in trouble. Besides, Greg's book is *really* worth the $25 or so; the other chapters are also very good. Here is a small update of the bibliographic info: @book (m3-Nel91, title = "System Programming with Modula-3", editor = "Greg Nelson", publisher = "Prentice Hall", isbn = "0-13-590464-1", year = 1991, what = "The bible for Modula-3. Includes the language reference manual and papers on the I/O library, threads, and the Trestle window system." ) @book (m3-Har92, title = "Modula-3", author = "Samuel P. Harbison", publisher = "Prentice Hall", isbn = "0-13-596396-6", year = 1992, what = "A complete Modula-3 testbook covering the full language, with examples and exercises. Includes a style manual and a user's guide for SRC Modula-3." ) -- Eric. ======================================================================== 86 === Date: Thu, 30 Jan 92 12:00:02 PST From: muller@src.dec.com (Eric Muller) Subject: Re: m3make documentation missing? In article <1992Jan29.200313.6581@wheaton.EDU>, johnh@wheaton.EDU (John (Doc) H ayward) writes: > In section 5.3 of SRC Modula-3 version 2.0 it talks about m3make. This is > a great facility for which my students can easily write m3makefiles. I could > not find the manual page which it mentioned for more details. Did I miss it > or was it left out? If someone has a copy could they e-mail it to me. Here is what we have today. It's bad, but it's there. We hope it will be more useful than confusing. Some the words may apply to SRC only. We are rewritting it. Eric. M3MAKE(1) NAME m3make - Modula-3 make SYNTAX m3make [-s] target ... DESCRIPTION m3make is a slightly enhanced version of plain make(1). The primary benefit of m3make is that the operational description found in most makefiles is replaced by a more declarative one. The result is that makefiles are smaller, simpler, and more portable. m3make is essentially a combination of cpp and make; don't be afraid, the interface to the combination is usually simpler than that of make. When started, m3make looks for a file named 'm3makefile' in the current directory. This file describes what goes into a particular piece of the system, but not how to construct it. The operational aspects of the system are confined to templates that are configured when SRC Modula-3 is installed (see the m3make package). The language recognized by m3make is described below. To process an m3makefile, just type 'm3make'. It accepts the same options as make. By default, m3make defines the following targets: all constructs this package's program or library install installs the result in a public directory tidy deletes temporary files scratch deletes all derived files The default target is 'all'. If you want additional things done with these targets, you can extend them with make's double-colon rules. For example, suppose that the file lex.yy.c is a derived file that you want to be able to 'scratch', add the following to your m3makefile: scratch:: ; /bin/rm -f lex.yy.c Note the two colons after the target name. m3makefiles follow the C convention for comments; that is, they are enclosed by /* and */. A comment can cross line boundaries. Note that the full power of make is available in m3make since the last step of m3make is to invoke make. Most m3makefiles don't need this extra generality. If you have trouble with m3make, it may help to examine the actual input to make. The final file created by m3make and passed to make is named .makefile. Modula-3 packages SRC Modula-3 is distributed as a set of packages. A 'package' is a directory of files including an m3makefile, README, COPYRIGHT, and usually a collection of Modula-3 source files. Packages are located in a fixed location in the file system that is determined at configuration time (e.g. /proj/m3/pkg). There are three basic types of packages: source, program, and library. A 'source package' contains a collection of Modula-3 sources, it builds nothing. A 'program package' constructs a single executable program (an 'a.out' file) by compiling and linking the contents of a set of source packages. Similarly, a 'library package' constructs a single library (a '.a' file) from a set of source packages. Source packages The m3makefile for a source package simply lists the pieces of source that are to be included in programs or libraries that name this package. The following entries are allowed in a source package's m3makefile: interface(X) the file 'X.i3 contains an interface. implementation(X) the file 'X.m3' contains a module. module(X) the files 'X.i3' and 'X.m3' contain an interface and its implementation. generic_interface(X) the file 'X.ig' conatins a generic interface. generic_implementation(X) the file 'X.mg' contains a generic module. generic_module(X) the files 'X.ig' and 'X.mg' contain a generic interface and its generic implementation h_source(X) the file 'X.h' contains a C include file. c_source(X) the file 'X.c' contains a C module. s_source(X) the file 'X.s' contains an assembly module. pgm_source(X) the file 'X' contains compilable source (eg. .ic, .mc, .is or .ms files). source(X) the file 'X' contains non-compilable source. source_dir(D) recursively include the sources named in the m3makefile in directory D. package(P) include the sources named in package P. The capitalized forms of interface, module, generic_interface, generic_implementation, generic_module, and h_source (i.e. Interface, Module, Generic_interface, Generic_implementation, Generic_module, and H_source) are also allowed. They mean the same as their lower-case counterparts, but they cause their interfaces (X.i3, X.ig, X.mg and X.h) to be exported to the public include repository (e.g. /proj/m3/pub.mips). Program packages The m3makefile for a program package names the sources needed to build the program with any of the source package entries named above. A program package may also include any of the following: program(X) constructs an executable program named 'X' from the given sources. Program(X) like 'program' but also exports the contructed program to the public /bin directory. import_lib(X) include '-lX' in the final link command. Exactly one 'program' or 'Program' entry must be present in a program package's m3makefile. In addition to the entries above, a program or library package may define any of the following {\tt make} variables: name default meaning ------------- -------------- ----------------------------- M3 m3 the Modula-3 compiler M3FLAGS -w1 -make -why compilation flags M3OPT -g debug/optimization flags M3DEFPATH search path for imported interfaces M3LIBPATH search path for libraries See the m3(1) man page for full details on the flags it recognizes. Library packages The m3makefile for a library package names the sources to be included in the library with any of the source package entries named above. A library package may also include either one of the following: library(X) constructs a library named 'X.a' and its linker file 'X.ax' from the given sources. Library(X) like 'library' but also exports the library and its linker file to the public /lib directory. Exactly one 'library' or 'Library' entry must be present in a library package's m3makefile. Machine dependencies Generally, each version of a machine-dependent program or library is described by a separate m3makefile that references the particular source packages needed for that version. Machine-dependencies may also be encoded with cpp #if's and #ifdef's. For example, the piece of the base library's m3makefile that includes the random number generator looks like this: package(random/generic) #ifdef TARGET_VAX package(random/VAX) #endif #ifdef TARGET_DS3100 package(random/IEEE-le) #endif #ifdef TARGET_SPARC package(random/IEEE-be) #endif Examples The following packages from /proj/m3/pkg should be good starting points for writing your own m3makefiles: text - a source package that implements Text.T's sx - a small, self-contained library package libm3 - a larger library package that imports several source packages ui/apps - a custom makefile to build several test programs compiler/mips - a large program (the compiler itself) See Also m3(1) make(1) cpp(1) Author Of Object Bill Kalsow Author Of Documentation Bill Kalsow ======================================================================== 87 === Date: Thu, 30 Jan 92 12:11:34 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Problem in compiling with m3 In article , moss@cs.umass.edu (Eliot Mos s) writes: > Perhaps gcc would be more friendly than cc?? May be. It certainly is on VAX Ultrix 3.1, where cc is broken with respect to the void type. But you need the -traditional flag, that is: PASS1 = @gcc@-traditional@ in the config file. Otherwise, gcc defines some additional keywords (non KR and non ANSI C) that conflict with some variable names. -- Eric. ======================================================================== 88 === Date: Thu, 30 Jan 1992 18:01:24 GMT From: nr@elan (Norman Ramsey) Subject: Re: Runtime errors In article <1992Jan29.230619.27814@src.dec.com> muller@src.dec.com (Eric Muller) writes: >Funny. I have written similar code for 1.6; the main difference was >that the compiler generated the appropriate strings (as Text.Ts) >instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could >handle that. > >I liked it very much, because more often that not, this is enough info >to find out what the problem is. However, it makes the code >significantly bigger (the string was unique in each file, of course) ^^^^^^^^^^^^^ >and was therefore removed. How much bigger? I'm just a curmudgeonly old 1.6 user, but I want *more* information from the failure messages (e.g., please tell me which procedures RAISES list won't pass my exception), not less. Those file names and line numbers are incredibly useful for me to find errors in my 10,000-line program. I cannot believe that putting one instance of a TEXT with the source file name increases the code size by more than 1%. Seems to me like there must be better ways to reduce code size. >What I do today is just to run the program under debug and wait for >the crash to occur to see where the failed check is. One can't always run under the debugger. One can't always duplicate in inputs of a 20-minute run that ends in failure. If one is, like me, stupid enough to write concurrent programs that don't synchronize properly, one can't ever duplicate the sequence of context switches caused by the virtual timer interrupt. If you absolutely can't afford to print source file names and line numbers, alter the macros to call abort() inline, and provide a signal handler that catches the abort and writes the PC on stderr. ======================================================================== 89 === Date: Fri, 31 Jan 1992 00:03:08 GMT From: contrct2@cheops.qld.tne.oz.au (Contract_2_login) Subject: Porting SRC to SYSV4_386 I've been hammering away (at my previous job, using a MIPS 6280 as a cross compiler) trying to port this to a 386 running V.4. Alas, no matter what combination of setjmp or sigsetjmp I try, I always come up with a runtime error when switching threads. I am strongly considering rewriting Thread.m3 to use the getcontext/swapcontext co-routineing interface in V.4. (PS location 0 in the jmpbuf was the only one that did not give me an assertion failure about SP & oldSP being equal, it bombed later on with a possible NIL dereference). Using the {get,swap}context stuff would make that part portable across all V.4 implementations. I've used it when handtranslating Modula2 to C as a substitute for TRANSFER. Anybody else doing this? Cheers Stephen Hocking -- ------------------------------------------------------------------------------ "We are but truffles before the pigs of fate..." Telecom does not know I'm saying this. Stephen Hocking contrct2@cheops.qld.tne.oz.au ======================================================================== 90 === Date: Fri, 31 Jan 92 01:10:18 -0600 From: johnh%rachel@uunet.UU.NET (John (Doc) Hayward) Subject: Re: m3make documentation missing? Thanks so much. This is much better than looking at how it was used and trying to abstract the rules. Both me and my Data Structures students thank you. johnh... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b ======================================================================== 91 === Date: Fri, 31 Jan 1992 03:16:20 GMT From: nr@atomic (Norman Ramsey) Subject: Re: Problems with Fmt interface I like David Goldberg's proposal, although I'm not sure I understand it precisely enough to be able to implement it :-). It would be pleasant to have an interface that would format a floating-point number with just enough decimal digits to recover the original floating point value on input, but no more (a la Clinger/Steele). But that's probably an orthogonal issue... ======================================================================== 92 === Date: 31 Jan 92 03:20:37 GMT From: nr@atomic (Norman Ramsey) Subject: Re: Supporting fast lexical analysis in Modula-3 In article moss@cs.umass.edu writes: >I guess my reaction is that if you want a buffer oriented interface (which is >what fast lexical analysis seems to need) rather than a character oriented >one, then build/use it, rather than hacking up a character oriented interface >to act like a buffer oriented one. I don't have any objection to a buffer-oriented interface, and it would get rid of the grotesque closure in my interface. I do want an interface that will apply to all readers, not to a specialized abstraction usable only for lexical analysis, and I want fast (unsafe) scanning hidden behind a safe interface. I will think about a buffer-oriented interface and see if I can come up with a clean one. ======================================================================== 93 === Date: Fri, 31 Jan 92 11:09:25 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Problems with Fmt interface In article <1992Jan31.031620.28010@newross.Princeton.EDU>, nr@atomic (Norman Ra msey) writes: > > It would be > pleasant to have an interface that would format a floating-point > number with just enough decimal digits to recover the original > floating point value on input, but no more (a la Clinger/Steele). > But that's probably an orthogonal issue... Should not be too difficult. The current distribution uses dtoa.c from David M. Gay from AT&T Bell Labs, which does just that. We have in the pipe the rewritting of this code in Modula-3, so that we can avoid the unnecessary allocations that take place now. Also, we would have a better integration with the Convert/Fmt interface. -- Eric. ======================================================================== 94 === Date: 31 Jan 92 16:20:55 GMT From: johnh@wheaton.EDU (John (Doc) Hayward) Subject: bug fix request for m3pp Dear People, I and my students are just starting to use the pretty printer tool m3pp. It appears that in addition to "closing delimiters" that the last identifier and possible semicolon can cause the pretty-printer to exceed the margin limit. The example below with an offeset of 4 will not fit in an 80 column display unless the margin is set to 67 or less. This is more than "a little lower" than what I want. ... -margin n Set the margin to n. The margin is the maximum width of an output line. The pretty-printer occasionally exceeds this maximum, so it's usually wise to set it a little lower than you want. If this option is not specified, a margin of 75 is used. ... BUGS The pretty-printer sometimes exceeds the margin limits due to details of the formatting algorithm. The text that exceeds the limit usually consists of closing delimiters, such as right parens and right brackets. Setting the margin a little lower than you want usually does the trick. Last modified on Mon Dec 23 10:36:17 PST 1991 by muller modified on Mon Nov 25 18:14:36 PST 1991 by meehan ... Example: INTERFACE StackMod; TYPE StackType = T2 OBJECT METHODS BrandStack(Brand : INTEGER) RAISES {StackAlreadyBranded} := MBrandStack END; END StackMod. m3pp -o 4 -m 68 or larger causes MBrandStack to extend past 80 while m3pp -o 4 -m 67 or smaller does not cause MBrandStack to extend past column 80 It seems from the comments that the correction may not be trivial but it would be nice to have this fixed. johnh... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b