======================================================================= 1 === Date: 02 Feb 1994 15:31:50 GMT From: sims@gehrig.ucr.edu (david sims) Subject: A more recent Alpha release for M3? I've noticed that the Alpha release of version 3.0 of the DEC SRC Modula-3 compiler dates back to September 27, 1993. How about a more recent snapshot of the 3.0 system? Could someone install the latest release on gatekeeper in the alpha-3.0 directory? I'm specifically interested in the Linux port. I'd really like to give it a shot on my Linux box, but I'd rather start with the latest release rather than the September 27, 1993 release. Thanks for the help! -- David L. Sims Department of Computer Science sims@cs.ucr.edu University of California +1 (909) 787-6437 Riverside CA 92521-0304 PGP encryption key available on request. USA -- David L. Sims Department of Computer Science sims@cs.ucr.edu University of California +1 (909) 787-6437 Riverside CA 92521-0304 PGP encryption key available on request. USA ======================================================================= 2 === Date: 3 Feb 1994 12:52:10 GMT From: vogler@rzddec2.informatik.uni-hamburg.de (Jens Vogler) Subject: Re: New version of Modula-3/PC Carsten WEICH (carsten@post.ifi.uni-klu.ac.at) wrote: > NEW VERSION OF M3-PC > -------------------- ..... >The necessary files are available at "gatekeeper.dec.com" in >/pub/DEC/Modula-3/contrib/m3pc: > Install.txt please read this first! > djgpp.tar the DJGPP-gnu-C-compiler > m3.tar compiler binaries > m3src.tar sources of the compiler (optional) > tar.exe program to unpack these files Hello, is it possible to cut the archieves into smaller pieces? I have only a disk quota of 3 Megs here ... Yours ABert -- /* ************************************************************* */ /* Wir waren zusammen, den Rest habe ich vergessen. */ /* We were together, I have forgotten the rest. */ /* Eravamo insieme, tutto il resto del tempo l'ho scordato. */ /* Nous etions eusemble, le reste je l'ai oublie. */ /* Estabamos juntos, el otro lo he olvidado. */ /* (Walt Whitman) */ /* */ /* \\\|||/// */ /* o o Yours ... */ /* | Jens Vogler */ /* \_/ vogler@informatik.uni-hamburg.de */ /* Amiga Gruppe - Virus Test Center - Uni Hamburg */ /* ************************************************************* */ ======================================================================= 3 === Date: Fri, 04 Feb 1994 08:47:06 +0100 From: a.vermeulen@ECN.NL (Vermeulen A.T.) Subject: m3pc distribution In <2iqs1q$3b9@rzsun02.rrz.uni-hamburg.de>, vogler@rzddec2.informatik.uni-hambu rg.de (Jens Vogler) writes: >Carsten WEICH (carsten@post.ifi.uni-klu.ac.at) wrote: > >> NEW VERSION OF M3-PC >> -------------------- > >...... > >>The necessary files are available at "gatekeeper.dec.com" in >>/pub/DEC/Modula-3/contrib/m3pc: > >> Install.txt please read this first! >> djgpp.tar the DJGPP-gnu-C-compiler >> m3.tar compiler binaries >> m3src.tar sources of the compiler (optional) >> tar.exe program to unpack these files > > Hello, > is it possible to cut the archieves into smaller pieces? > I have only a disk quota of 3 Megs here ... > Yours > ABert >-- Compressing the files would be nice using compress, gzip or zip. It would reduce the src-file to 25% of its current size! Getting the files compressed automatically doesn't work on gatekeeper! ====================================================================== A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194) Energy Research Foundation, PO Box 1, 1755 ZG Petten, The Netherlands ======================================================================= 4 === Date: 4 Feb 1994 18:48:37 GMT From: Eric Muller Subject: Modula-3 Frequently Asked Questions (FAQ) Archive-name: Modula-3-faq Last-modified: Feb 3 1994 Modula-3 Frequently Asked Questions =================================== 1. The language 1.1 What is Modula-3? 1.2 Is Modula-3 a superset of Modula-2? 2. The documentation 2.1 Where can I get a description of Modula-3? 2.2 Where can I get other information on Modula-3? 3. The implementations 3.1 Where can I get an implementation? 3.2 What is SRC Modula-3? 3.3 What is m3pc? 3.4 What is GNU Modula-3? 4. Some specific questions 4.1 Why is "Hello World" so large? 4.2 Why objects and interfaces? 4.3 What is the story with Trestle and OpenWindows? 4.4 When is the next release of SRC Modula-3 ? 5. FTP 5.1 What if I don't have ftp access? 6. Contributing 6.1 Can I contribute Modula-3 software? 1.1. What is Modula-3? Modula-3 is a systems programming language that descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. 1.2. Is Modula-3 a superset of Modula-2? No; valid Modula-2 programs are not valid Modula-3 programs. However, there is a tool to help convert Modula-2 programs to Modula-3. 2.1. Where can I get a description of Modula-3? The definition of Modula-3 is contained in: System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 also known as SPwM3. Here is the table of contents: 1. Introduction 2. Language Definition 3. Standard Interfaces 4. An Introduction to Programming with Threads 5. Thread Synchronization: A Formal Specification 6. I/O Streams: Abstract Types, Real Programs 7. Trestle Window System Tutorial 8. How the Language Got its Spots Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27, Number 8, August 1992, pp 15-42. Sam Harbison has written a more tutorial book about Modula3: Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 The errata sheet is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/errata. 2.2. Where can I get other information on Modula-3? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. If you do not have access to Usenet, there is a relay mailing list; send a message to m3-request@src.dec.com to be added to it. There are a couple high-level overview articles available: "Modula-3", Sam Harbison, Byte, Vol. 15, No. 12, November 1990, pp 385+. "Safe Programming with Modula-3", Sam Harbison, Dr. Dobb's Journal, Vol. 17, No. 10, October 1992, pp 88+. A description of the Modula-3 type system is in "The Modula-3 Type System", Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages (POPL), Austin Texas, January 11-13 1989, pp 202-212. The Trestle window system toolkit, higher-level FormsVBT toolkit, and Zeus animation system available with Modula-3, are documented in the following reports: "Trestle Reference Manual", Mark S. Manasse and Greg Nelson, SRC Research Report 68, December 1991. "Trestle Tutorial", Mark S. Manasse and Greg Nelson, SRC Research Report 69, May 1, 1992. "VBTkit Reference Manual: A toolkit for Trestle", edited by Marc H. Brown and James R. Meehan. (soon to be a SRC Research Report) A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z. "The FormsVBT Reference Manual", Marc H. Brown and James R. Meehan, (soon to be a SRC Research Report). A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z. "Zeus: A System for Algorithm Animation and Multi-View Editing", Marc H. Brown, SRC Research Report 75, February 28, 1992. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-075*.ps.Z. "Color and Sound in Algorithm Animation", Marc H. Brown and John Hershberger, SRC Research Report 76a, August 30, 1991. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-076a*.ps.Z. "The 1992 SRC Algorithm Animation Festival", Marc H. Brown, SRC Research Report 98, March 27, 1993. Available via anonymous ftp from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-098*.ps.Z. Hardcopy versions of these reports can be ordered by e-mail; send your request including a postal mail address to src-reports@src.dec.com. Sedgewick's classic text on computer algorithms is presented in Modula-3 in: Alogorithms in Modula-3 Robert Sedgewick Addison-Wesley, 1993 ISBN 0-201-53351-0 3.1. Where can I get an implementation? Two implementations are available, SRC Modula-3 and a PC version of it (m3pc). Work is also progressing on GNU Modula-3. As far as we know, implementations are not available for VMS, Macintosh, or Alpha AXP/OSF. 3.2. What is SRC Modula-3? SRC Modula-3 was built by the DEC Systems Reseach Center and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/release. The current version, 2.11, implements the language defined in SPwM3. There are versions for the following machines: AIX386 IBM PC running AIX/PS2, AP3000 Apollo DN4500 running Domain/OS ARM Acorn R260 running RISC iX 1.21 DS3100 DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 HP300 HP 9000/300 running HP-UX 8.0 HPPA HP 700/800 running HP-UX 8.0 IBMR2 IBM R6000 running AIX 3.1, IBMRT IBM RT running IBM/4.3, NEXT NeXT running ?? OKI Okidata 7300 (i860) running AT&T SVR4.0 SPARC SPARCstation running SunOS 4.1.x SUN3 SUN3 running SunOS SUN386 Sun 386i running SunOS 4.0.1 UMAX Encore Multimax running UMAX 4.3 (R4.1.1) VAX VAX running Ultrix 3.1 SRC Modula-3 includes a user manual, compiler, runtime library, some libraries and a few other goodies (see below). The compiler generates C as an intermediate language and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. 3.3. What is m3pc? m3pc is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/m3pc. From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI) Subject: M3 pn PC The Modula-3 system ported by us on the PC and available on the gatekeeper, runs with MSDOS, gnu c compiler and djgpp memory manager (detailed description in the read me file). The first version was ported by Klaus Preschern. Carsten Weich rewrote the handling of long filenames for the second version. You may compile, link and run Modula-3 programs, without threads. From the library modules only those are tested which are used by the compiler. We are using the actual version for our beginners-course and we are working on "student-friendly" programming environmnents and a simple windowing graphic-library. From: carsten@post.ifi.uni-klu.ac.at (Carsten WEICH) Subject: New version of Modula-3/PC Date: 28 Jan 1994 13:25:28 GMT We have built a new version of Modula-3 running on a PC. You will need a PC: * 80486 or 80386 with floatingpoint-coprocessor, * at least 4 but preferable 8 MByte of RAM, * 20 MByte discspace free at least. You can run a modified Modula-3 version 2.09 without thread- support. Our version features: * support for Unix-like long filenames * automatic compilation (to substitute the lack of m3make) * library to access DOS-files and directories. We have built a little shell which translates the long filenames you type in into DOS-filenames. It has a unix-lookalike "ls"-command. There are commands to teach the system new long filenames. You can savely move such files around through DOS-directories (which was not possible with the first version). This version accesses DOS-files significantly faster than the first version. Especially linking large Modula-3 programs is much faster now. On a 50 MHz 80486 with 16 MByte of RAM we measured a turn-around time of 2 minutes for a 5 module, 500 lines program. If you want to compile only one module you will have to wait about one minute. The necessary files are available at "gatekeeper.dec.com" in /pub/DEC/Modula-3/contrib/m3pc: Install.txt please read this first! djgpp.tar the DJGPP-gnu-C-compiler m3.tar compiler binaries m3src.tar sources of the compiler (optional) tar.exe program to unpack these files 3.4. What is GNU Modula-3? From: moss@cs.cmu.edu (Eliot Moss) Subject: GNU Modula-3 alpha release status Date: 25 Mar 93 17:53:12 GMT We said we'd try to get the initial (alpha) release of GNU Modula-3 out some time this month (March), and we're in the process of figuring out what to release and how to package it up. We expect to have something in roughly two weeks (watch this space for a notice). What would this be? First, it is a compiler for the VAX (only) under Ultrix (only), definitely without threads, and probably still failing a small number of the tests in the SRC test suite (which implies that not all of libm3 is likely to work either). The actual release information will detail more about what's working and what's not at that time. We DO currently pass all the compiler tests that the SRC compiler did when it was first released (i.e., the ones we fail are more obscure things that users uncovered over time). Second, the release itself will be a compressed tar file including sources and executables. The executables will probably work only if you put libraries, etc., in the expected places (otherwise, you'll need to rebuild from sources).The compiler is written in C and should be compiled with a recent version of gcc (so you'll need gcc installed). The system also uses gld (the GNU linker). This release should be most useful to people undertaking ports to other machines and operating systems, since it will give them a head start on understanding the compiler and getting the full system ready. It may be of some use for ordinary programming, but it really depends on whether you tend to use features that tickle the remaining bugs. We are indeed interested in alpha test reports, but only if they tell us something new (i.e., we'll provide a list of known deficiencies). When the release is made, we'll also start email discussions with the various parties who have indicated they might undertake ports, to help sort out who will do what. Regards, and thanks for your continued interest and encouragement -- EM From: moss@cs.cmu.edu (Eliot Moss) Subject: GNU Modula-3 pre-release Date: Wed, 5 May 1993 23:49:33 GMT At long last, the GNU Modula-3 project has a pre-release ready, for the VAX/Ultrix platform ONLY. Various folks had notified us of their interest in doing ports or alpha testing, and they have already been sent email with particulars on how to obtain the tar file, etc. There are a number of known bugs; I'll see about making a list available by ftp or something, for interested parties. It is our opinion that the prerelease is not mature enough for general use, but we wished to give a head start to those folks attempting ports, and we will make periodic patches available. If you want to use this compiler for serious program development or need something solid with debugging support for classroom use, you should wait until we've fixed more of the problems. (But to give a sense of what we HAVE accomplished, as I recall, all but 3 of the SRC compiler tests compile (there are 137 of them).) We hope to do a more general release, and support more platforms, in the summer. If you're interested in helping and have not previously contacted us, please send email to me and/or Rick Hudson (hudson@cs.umass.edu). Thanks to Digital and SRC for supporting us, and to Rick Hudson, Amer Diwan, and Norm Walsh, the guys who do all the hard work! 4.1. Why is "Hello World" so large? Modula-3 programs are larger than C programs for the following reasons: 1) The fixed runtime is substantially larger. It contains a garbage collector, a thread runtime, and exception support. Note that "Hello World" is virtually all runtime. For larger programs the runtime is not an issue. 2) The generated code includes runtime checks for out-of-bound array references and NIL pointer. Many of these checks could be removed by a better compiler. The current compiler is only a research prototype. 3) The compiler generates C code as its intermediate language consequently the final machine code suffers. For example, the compiler is constantly storing single-precision floating point values into memory to get around C's predisposition for double precision. 4.2. Why objects and interfaces? Allan Heydon on comp.lang.modula3, May 4th 1993: Modula-3 provides two separate mechanisms for data-hiding: one for hiding details about how interfaces are implemented, and the other for hiding details about how objects are implemented. The first data-hiding mechanism is realized by the distinction between interfaces and modules. Clients can only import interfaces, so the names declared in the modules implementing those interfaces are hidden from clients. Note that this mechanism has only two levels; a name is either declared in an interface, or it isn't. If a name is only declared in a module, it can't be used by a client. The second data-hiding mechanism is realized by opaque types and revelations. A Modula-3 interface may declare an object type to be opaque, in which case only a subset of the fields and methods of that object are revealed to clients importing the interface. Furthermore, the Modula-3 revelation mechanism allows a designer to reveal successively more fields and methods of an object in a series of interfaces. The fields and methods visible to a client then depends on which interfaces the client imports. The latter mechanism is quite flexible. As opposed to the interface/module data-hiding mechanism, opaque types allow you to define an arbitrary number of levels at which more and more information about the implementation of your object is revealed. See Sections 2.2.10, 2.4.6, and 2.4.7 of "Systems Programming with Modula-3" for more information about opaque types and about partial and complete revelations. 4.3. What is the story with Trestle and OpenWindows? Mark Manasse says: I think that the OpenWindows release should be enough (no need to get the MIT X release], although there are a few things in Trestle that trigger devastating bugs in OpenWindows. But the only library we depend on is Xlib, R4 or later. The main thing I know that crashes OW 2.0 is the code where we call GrabKey specifying AnyKey. You can either loop over all of the keys, or you can just comment out the call; programs won't run exactly the same, but you probably won't notice the difference. 4.4 When is the next release of SRC Modula-3 ? The next release will be 3.1. Here are some of the new things you will find in it: 1. the compiler has a new internal interface between the front-end and the back-end, M3CG. This interface is supposed to be easy to implement. 2. the front-end can compute in the target arithmetic system; in particular it is possible to cross-compile to machines with larger integers than the host. 3. one back-end has been implemented on top of gcc. The implementation of M3CG interface generates the tree representation used internally in gcc. From the gcc point of view, this back-end looks like a new front-end. Using this back-end, we have cross-compiled solitaire for mips, alpha and 386 processors; there is no reason to believe that there would be a problem for the other architectures supported by gcc. 4. Dave Hanson wrote another implementation of the M3CG that is self-contained. He is currently working on the 386 code generation (he has done the mips code generation already). 5. gdb has been modified to understand Modula-3 debugging information produced by the back-ends. gdb can now parse Modula-3 expressions, print Modula-3 values and evaluate some of the Modula-3 built-in operations. There is also a little bit of support for multi-threaded programs (you can look at the stacks of other threads). 6. there is a replacement for m3make, m3build, that does not rely on cpp/awk/sed/make and what not, and removes some of the limitations of m3make. m3makefiles are very similar. 7. libm3 has been significantly changed by the Interface Police, mostly in the area of OS interfaces and data structures. 8. for the OS interfaces, we still have the U* interfaces, but applications are not supposed to use those. Instead they should use a new set of interfaces that are os-independent; for example, there is a Pathname interface that manipulates file names; there is a Process interface that manipulate child processes. These interfaces enabled a prototype port of the C based version to Windows NT machines. 9. for the data structures, generics have been introduced and the various data structures are more consistent. 10. because of 6 and 8, we can think about going to different os than Unix. In particular a Windows NT port will be available at some point (may not be in 3.0). 11. the runtime has been improved quite a bit. 12. new platforms: Alpha running OSF/1, 386 running Linux. We will pay more attention to the porting instructions and support. 13. I am not sure about all the changes in the libraries other than libm3. I suspect that there will be few changes in trestle, but that mentor changed quite a bit. 14. The Windows NT port uses native threads. This should be a good model for other implementations of Thread using native threads. The current status is: . the front-end is very stable . the gcc-based back-end has been stable for 4 months . the gdb extensions are brand new and need some test . the interface police work is very stable . we are working on bringing the system up on the machines we have in the building, and building the export machinery. We don't have a date for the 3.1 release. Given the amount of changes introduced by 3.1, I suspect that the first few releases will not work out of the box for any machine but the ones for which we can test (decstations [mips and alpha], linux). Consequently, I expect a high rate of releases for a while. We will try to post accurate information about the status of each machine, but we can only rely what you tell us. At this point, I would not encourage anybody to start a new port. If you have a new port, or are close to complete one, you can send us your bits, we will try to put them in 3.1. 5.1. What if I don't have ftp access? Unfortunately, we cannot deliver Modula-3 other than by anonymous ftp. Fortunately, Prime Time Freeware (PTF) includes Modula-3. PTF is a set of two ISO-9660 CDroms filled with 3GB of freeware, issued semi-annually. The latest issue, Volume 1, Number 2, July 1992, contains SRC Modula-3 2.07. PTF is distributed via bookstores and mail. You can reach PTF using: Email: ptf@cfcl.com Fax: [1] (408) 738 2050 Voice: [1] (408) 738 4832 Mail: Prime Time Freeware 415-112 N. Mary Ave., Suite 50 Sunnyvale, CA 94086 USA 6.1. Can I contribute Modula-3 software? Certainly. Send us what you are willing to share, be it programs, libraries or other things. We'll put them in the distribution. Right now, the pub/DEC/Modula-3/contrib directory contains: m3rpc an rpc system from Xerox Parc M2toM3 a translator from Modula-2 to Modula-3 m3pc an implementation of Modula-3 for PCs. ---- Eric. -- Eric. ======================================================================= 5 === Date: Fri, 4 Feb 1994 18:35:28 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: Reading Integer In article <2itrke$eh5@nic.lth.se> dat93lma@ludat.lth.se (Lars Malmborg) writes : I have a problem I can't figure out how to solve. It should be quite easy, but I am quite fresh on the language... The problem is that I want to read from an ASCII-file containing numbers, possibly many on each row, and place them in an array of integers. -Lars I am not sure if there is an interface that supports specifically what you are asking, but two interfaces come to mind that may help: INTERFACE FieldList; (* Breaks text lines into fields that can be processed individually as text or numbers. *) or INTERFACE Lex; (* Sifting through a reader for booleans, integers, reals, and text strings. *) You can take a peek at the implementation of Lex to see how it works. --farshad -- /// | {@,@} | "He's so unhip that when you (...) Farshad Nayeri | say Dylan, he thinks you're " " nayeri@gte.com | talking about Dylan Thomas." ======================================================================= 6 === Date: 4 Feb 1994 16:03:26 GMT From: dat93lma@ludat.lth.se (Lars Malmborg) Subject: Reading Integer I have a problem I can't figure out how to solve. It should be quite easy, but I am quite fresh on the language... The problem is that I want to read from an ASCII-file containing numbers, possi bly many on each row, and place them in an array of integers. -Lars ======================================================================= 7 === Date: Fri, 4 Feb 1994 19:28:32 GMT From: kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner) Subject: Re: Reading Integer dat93lma@ludat.lth.se (Lars Malmborg) writes: >I have a problem I can't figure out how to solve. It should be quite easy, but I am quite fresh on the language... >The problem is that I want to read from an ASCII-file containing numbers, poss ibly many on each row, and place them in an array of integers. Hey Lars, here's one quick and dirty way using the FieldList interface to approach your problem: MODULE Main; IMPORT Stdio, Wr, FieldList, Fmt; VAR fl := NEW(FieldList.T).init(); MyLine: TEXT; Ints : ARRAY [1 .. 4] OF INTEGER; Char : CHAR; BEGIN fl.getLine(Stdio.stdin); FOR i := FIRST(Ints) TO LAST(Ints) DO Ints[i] := fl.integer(i - 1); END; Char := fl.char(4, 0); MyLine := fl.line(); Wr.PutText(Stdio.stdout, Fmt.F("%s\n", MyLine)); (* print original line as is *) Wr.PutText( Stdio.stdout, Fmt.F("%2s %2s %2s %2s %s\n", Fmt.Int(Ints[1]), Fmt.Int(Ints[2]), Fmt.Int(Ints[3]), Fmt.Int(Ints[4]), Fmt.Char(Char))); (* print what the Fieldlist Reader found *) END Main. It can be fed with lines like these, that are also trailed by a char.: 12 54 88 5 A 33 10 9 4 Q The FieldList package can handle a variable number of elements in each line, etc. etc. The FieldList interface documentation ca also be found on the WorldWideWeb as http://file01.mpipf-muenchen.mpg.de:8001/~torki/FieldList.ps as well as on gatekeeper.dec.com, but in a directory I do not remember. Moreover, the FieldList.i3 file gives sufficient information on how to use the interface. Look for /usr/local/include/m3/FieldList.i3, or wherever your public interfaces are stored. You do not need the source code for the FieldList package, it has been incorporated into the standard libm3. I hope this helps you, Torsten -- Torsten R. Kirschner Torsten.R.Kirschner@Informatik.TU-Muenchen.DE [PGP 2.1 1024-bit key, Key ID 8A3F97, created 1993/11/14 available via finger] Torsten ======================================================================= 8 === Date: Fri, 4 Feb 1994 21:22:42 GMT From: bnfb@scs.carleton.ca (Bjorn Freeman-Benson) Subject: OOPSLA'94 Paper Deadline is NOT flexible! J. Eliot B. Moss, Program Chair for OOPSLA'94, asked me to remind potential OOPSLA'94 authors that the deadline for submitting papers really is the 15th of February -- there is no hidden later deadline... An abstract of how to submit papers is: Authors should send six copies of the full paper, in English, to the program chair (address below), to be received no later than 15 FEBRUARY 1994. Papers must not exceed 18 PAGES, double-spaced, exclusive of figures and bibliographic references. Electronic submissions will not be accepted. Each copy must contain CONTACT INFORMATION (contact name, postal address, telephone number, fax number, and electronic mail address), a 100 word ABSTRACT, indication of the CATEGORY (research or experience), and TOPIC AREA(S) as follows: language design and implementation, tools and environments, components and frameworks, user interfaces, principles and theory, databases and persistence, reflection and meta-level architectures, concurrent and distributed systems, design methods and software engineering practices. If none of the topic areas seem to apply, please contact the Program Chair for advice, preferably by electronic mail. The submission deadline is rigid; late submissions will NOT be processed. Program Chair J. Eliot B. Moss Computer Science Department, University of Massachusetts Box 34610, Amherst MA 01003-4610 USA (phone) +1-413-545-4206 (fax) +1-413-545-1249 (email) moss@cs.umass.edu For more complete details, feel free to use the OOPSLA'94 Electronic Hotline: OOPSLA'94 ELECTRONIC INFORMATION HOTLINE Ninth Annual ACM Conference on Object-Oriented Programming Systems, Languages and Applications CONFERENCE CHAIR JEFF McKENNA 23-27 October 1994 PROGRAM CHAIR J. ELIOT B. MOSS Portland, OR, USA The Ninth Annual ACM-SIGPLAN Conference on Object- Oriented Systems, Languages, and Applications is returning to the site of its birth, Portland, Oregon. Much has changed since that first meeting! The success of OOPSLA is due to the quality and variety of offerings in the conference programs. In the spirit of all prior OOPSLA conferences, we invite you, the researcher or practitioner, to participate. ________________ WHAT INFORMATION IS AVAILABLE ____________________ The CALL FOR PARTICIPATION is available, as well as some general information about the conference and some advice and guidelines on how to submit a winning paper/panel/workshop/tutorial/etc. In the months to come, other information will become available including: the technical program, the full conference schedule, registration forms, paper abstracts, how to enjoy your trip to Portland, ... just about anything that you might want to know about OOPSLA'94! __________ HOW TO RECEIVE MORE INFORMATION ELECTRONICALLY _________ There are five mechanisms for receiving further information electronically: WWW, gopher, WAIS, anonymous ftp, and e-mail list server. W W W http://ursamajor.uvic.ca/oopsla94.html -or- http://128.189.88.151/oopsla94.html G O P H E R gopher ursamajor.uvic.ca -or- gopher 128.189.88.151 W A I S (:source :version 3 :ip-name "ursamajor.uvic.ca" :tcp-port 210 :database-name "oopsla94" :cost 0.00 :cost-unit :free :maintainer "bnfb@cs.uvic.ca" :description "Registration and attendance information for the 1994 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'94). This server will be maintained through October 1994. Created with xwais by bnfb@ursamajor on May 31 16:57:27 1993." ) A N O N Y M O U S F T P Host name: godot.uvic.ca Host id: 128.189.88.101 FTP directory: pub/oopsla-94 E - M A I L L I S T S E R V E R E-mail address: listserv@csr.uvic.ca In the BODY of the message (not in the subject line), include keyword such as: help or: index oopsla-94 or: get oopsla-94 call.for.participation.text Our list server is very fragile, so please treat it kindly. Specifically, please do not include ANY extra text in the body of your message (no pleasantries, no signatures, etc.) -- just the keywords. Also, the keywords must be in the *body* of the message not the subject line. Please note that due to internet mail delays, the file may take a day or so to reach you. Example (using the very simple Unix mail program): % mail listserv@csr.uvic.ca <-- you type the command Subject: <-- you type return for "no subject" help <-- you type "help" ^D <-- you send the message Another example: % mail listserv@csr.uvic.ca <-- you type the command Subject: <-- you type return for "no subject" get oopsla-94 call.for.participation.text <-- you type ^D <-- you send the message ____________________ CONTACT WITH A PERSON ________________________ This Hotline is automatic - your e-mail has been processed by auto-answer program. No human has read your message. If you are having trouble with the Hotline, or need to communicate with an OOPSLA'94 representative about some issue that the Hotline does not provide an answer for, you can contact bnfb@ursamajor.uvic.ca (for Hotline Problems), oopsla94@applelink.apple.com (for OOPSLA'94 Administration). >>> PLEASE <<< Please do not contact the administration or registration people if your problem can be answered by files on the Hotline. OOPSLA is a big conference and it is staffed by unpaid volunteers - we give our time to make it happen. This Hotline has been set up to provide answers to Frequently Asked Questions and to reduce the administrative load on us... Thank you. (Also, the Hotline is automatic and thus available 24 hours a day, whereas the administration is a 9am-5pm West Coast time operation.) ======================================================================= 9 === Date: Sun, 6 Feb 1994 00:41:42 GMT From: torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner) Subject: Q: M3 3.0 alpha and libm3 installation Hello folks, fortunately I just got M3 3.0 alpha to install on my DECstation. Now I want to install libm3, but I get this error message that leaves me without a clou what to do: file01:/tmp/torki/boot-DS3100/libm3 > m3build --- building in DS3100 --- m3 -w1 -why -g -times -a libm3.a -F/usr/tmp/aaaa15954 Fatal Error: missing link info file: ./src/runtime/32BITS/RTBuiltin.ix: errno=2 seconds #times operation 0.07 1 inhaling library link info 0.01 1 merging new link info 0.20 2 garbage collection 0.09 other--------------------------------------------------- 0.37 TOTAL *** error code 1 (ignored) file01:/tmp/torki/boot-DS3100/libm3 > ls -l ./src/runtime/32BITS/RTBuiltin.ix -rw-r--r-- 1 torki system 3232 Jun 9 1993 ./src/runtime/32BITS/RTB uiltin.ix Can anybody help me, please? Thanks in advance, Torsten -- Torsten R. Kirschner (EDV) torki@mpipf-muenchen.mpg.de MPI f. Psychologische Forschung tel: ++49 89 38602258 Leopoldstr. 24 fax: ++49 89 342473 80802 Muenchen Germany X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki" [PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner ] Torsten -- Torsten R. Kirschner (EDV) torki@mpipf-muenchen.mpg.de MPI f. Psychologische Forschung tel: ++49 89 38602258 Leopoldstr. 24 fax: ++49 89 342473 80802 Muenchen Germany X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki" [PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner ] Torsten ======================================================================= 10 === Date: Sun, 6 Feb 1994 02:46:14 GMT From: torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner) Subject: Q: libm3 3.0 alpha on ALPHA_OSF version stamp mismatch Hello, I got a little further with my attempts to get Modula-3.0 alpha running on an ALPHA_OSF machine. The compiler seems to work as far as I can tell, but when I try to compile libm3, I get this: axposf.pa.dec.com:/scratch/kirschnt/boot-ALPHA_OSF/libm3 > m3build --- building in ALPHA_OSF --- m3 -w1 -why -g -times -a libm3.a -F/tmp/aaa011756 new source -> compiling ../src/float/Common/LongFloat.i3 new source -> compiling ../src/float/Common/ExtendedFloat.i3 new source -> compiling ../src/float/IEEE/LongReal.i3 new source -> compiling ../src/float/IEEE/Extended.i3 missing version stamps -> compiling ../src/text/TextF.i3 version stamp mismatch: M3_BUILTIN.TEXT <036d35197f13b642> => TextF.i3 <3a93efbb9d13c2d0> => M3_BUILTIN.i3 Fatal Error: bad version stamps: TextF seconds #times operation 0.35 126 checking object timestamps 2.96 116 checking old link info 0.07 2 merging new link info 9.08 5 compiling Modula-3 -> IL 0.27 1 compiling IL -> assembly 0.63 1 compiling assembly -> object 0.24 14 removing temporary files 1.29 6 garbage collection 0.09 other --------------------------------------------------- 14.99 TOTAL *** error code 1 (ignored) axposf.pa.dec.com:/scratch/kirschnt/boot-ALPHA_OSF/libm3 > Since I am not familiar with how the new compiler works (the M3_BUILTIN.i3 interface seems to be generated at compile time, as I cannot find it anywhere in the source tree), I am asking for some advice on how to correct this version stamp mismatch. Any help is appreciated. Thanks in advance! Torsten ps. The axposf.pa.dec.com:/scratch/kirschnt tree is world readable/executable. It contains the status quo of what I have accomplished so far with M3 3.0 alpha. It's not much, but maybe more than what works on other platforms. I'd be more than happy to find other users who are also eager to see a working port. As far as I can tell, the new compiler is a lot faster than the old one, especially on such a machine. -- Torsten R. Kirschner (EDV) torki@mpipf-muenchen.mpg.de MPI f. Psychologische Forschung tel: ++49 89 38602258 Leopoldstr. 24 fax: ++49 89 342473 80802 Muenchen Germany X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki" [PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner ] Torsten ======================================================================= 11 === Date: 6 Feb 1994 20:22:42 GMT From: mako@FNALA.FNAL.GOV Subject: Re: Modula-3 Frequently Asked Questions (FAQ) > 4.4 When is the next release of SRC Modula-3 ? > > The next release will be 3.1. So the alpha-3.0 is the 3.0 we will ever get... Perhaps, we could have an alpha-3.1 sometime before you increment the version number again? mako ======================================================================= 12 === Date: Sun, 6 Feb 1994 19:44:14 GMT From: 890930g@dragon.acadiau.ca (D. Aaron Gallagher) Subject: Trestle: VBT default sizes Hi, I'm just starting out in Mod3 and I seem to have run into a brick wall in Trestle. I'm trying to open a VBT and when it appears on the screen it is always the minimum size, which is as small as it can make the menu bar. I then have to manually increase the window size. I've been going through .i3 libraries for a few days now, and I've seen lots of references to getting the min, pref and max values, and what to do after you change them, but I can't find any way of actually changing these values. I don't know if I'm looking in the wrong places or just not reading something correctly. Any help would be greatly appreciated. BTW, are there any reference guide type things out there for Trestle? The books I have on Mod-3 don't really do more than touch on the subject. -- ------------------------------------------------------------------------------- Aaron Gallagher, aka 890930g@dragon.acadiau.ca Go ahead and flame. Just remember, I'm on a Dragon. +++++++++++++++++++++++++E-mail at 890930g@acadiau.ca++++++++++++++++++++++++++ ======================================================================= 13 === Date: Tue, 08 Feb 94 10:28:53 -0800 From: msm@src.dec.com Subject: Re: Trestle: VBT default sizes You can get copies of the Trestle Reference Manual (report #68) and the Trestle tutorial (report #69) by sending mail to src-report@src.dec.com. You change the window size for a top-level window by having that top-level window report a preference in its shape method. The standard methods for splits often do the wrong thing for a top-level window, so you'll need to override the method, or wrap your top-level window in a filter that does the right thing. Be sure to call VBT.NewShape whenever you change your mind, to prevent old cached results from being used. Mark ======================================================================= 14 === Date: 7 Feb 1994 22:14:17 GMT From: salomon@silver.cs.umanitoba.ca (Daniel J. Salomon) Subject: Question for Modula-3 Designers: Why no null stmts? While experimenting with a grammar for Modula-3 we found that the YACC's error recovery mechanism works much better if we change the grammar to allow empty statements. So according to our grammar a sequence of semicolons would be accepted. We then issue a warning about empty statements as part of semantic analysis instead of syntactic analysis. My question is: Is there some deep philosophical reason why Modula-3 disallows empty statements? In other words, should I really bother to issue warnings for empty statements? Perhaps the Modula-3 grammar should be changed to explicitly allow empty statements. In addition to improving YACC error recovery, it might also make it easier for programs that generate Modula-3 code automatically. In the same vein, perhaps Modula-3 should allow constructor lists to end with a comma. C allows this in order to make automatic code generation easier. Just as the SRC Modula-3 compiler now translates to C, Modula-3 may become a common target language in the future. Why not facilitate that task? -- Daniel J. Salomon -- salomon@cs.UManitoba.CA Dept. of Computer Science / University of Manitoba Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687 ======================================================================= 15 === Date: Tue, 8 Feb 1994 23:16:31 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: Question for Modula-3 Designers: Why no null stmts? A generalization of Daniel's a null statement question is whether the language designer should sacrifice "human interface" issues to make the "programming interface" for the language easier to use (either for the program that implements a language or a program that generates a language.) In the case of C, it seems to me that more care was spent on making things easier for the language designers, compiler writers, and so on than improving the human interface. Decisions like = vs. ==, empty statements, or type declarations reflect this point of view. Though this policy works for the minority of programmers (today) who are dilligent enough to not make mistakes, "the average programmer" suffers from this. For an example, let's take a look at a C fragment: len = read_number (fp); returnval = MakeVector (len); for ( i=0; i < len; i++ ); SetElement (returnval, i, ReadObject (fp)); printf ("%d\n", i); My impression of Modula is that it came from a different perspective. There is more emphasis on how the "the average programmer" -- or even a beginner -- is going to use the language. Modula-3 has retained most of its predecessor's philosophy about syntax (though I would not want to teach partially opaque types to someone who just started prorgamming). As a consequence, I think it is possible to teach programming to early programmers with (a subset of) Modula-3, while it is much harder to do the same with C. Other than the fact that it is portable and lightweight, I can't imagine why C is a particularly good target language _these days_, especially since it lacks things such as memory management, good namespace management, nested procedures, and overflow detection. I seem to recall some gripes about C as a target language in some documentation relating to SRC Modula-3. Maybe some of the implementors can elaborate. Modula-3 on the other hand, makes a pretty nice target language for the most part, if you are willing to live with the "little" extra overhead. So my guess is that there is a philosophical difference between the way the Modula-3 language designers work from the C language designers. This not only affects the null statement, but also things such as the MOD and DIV operators, etc. As to how one can support both the "beginners" and the "advanced" progammers and/or other tools generating code, I can think of a couple of ways: One possible direction is to use "open implementation" techniques which allow the programmer to change the language implementation (in both syntactic and semantic ways) using things such as Metaobject Protocols (MOPs). This way, the language designers don't have to guess "what the user may wish for" ahead of time. You, as a programmer, can change it to allow empty statements and comma-ended constructors. However, this would probably go against the design goal of Modula-3's which was to put together safe and proven set of features. (MOPs and open implementations are not yet considered "safe" or "proven".) Another alternative may be to provide a toolkit that allows you to create abstract syntax trees for the language and manipulate them instead of generating text. (I think the Modula-3 Toolkit allows you to do all this.) If the compiler is available "as a library" then, you should be able to use it to compile your valid ASTs using its backend. Maybe at that level, the AST definition in the compiler implementation can be relaxed to allow for empty statements, since the "human" interface is not an issue at that level. [I am hoping that this would spark a religious programming language design debate that will keep this group busy while we await the 3.1 release. But previous such attempts have not been too successful, except when it had to do with uppercase/lowercase issues. We'll see.] --farshad ...Disclaimer: I am not a language designer, but I play one at work... -- /// | {@,@} | "He's so unhip that when you (...) Farshad Nayeri | say Dylan, he thinks you're " " nayeri@gte.com | talking about Dylan Thomas." ======================================================================= 16 === Date: Wed, 9 Feb 94 16:55:31 GMT From: rjohnson@titan.rdd.lmsc.lockheed.com (Ray Johnson) Subject: Re: Question for Modula-3 Designers: Why no null stmts? In article fn00@gte.com (Farshad Nayeri) writ es: > >A generalization of Daniel's a null statement question is whether the >language designer should sacrifice "human interface" issues to make >the "programming interface" for the language easier to use (either for >the program that implements a language or a program that generates a >language.) > >In the case of C, it seems to me that more care was spent on >making things easier for the language designers, compiler writers, and >so on than improving the human interface. Decisions like = vs. ==, ... >My impression of Modula is that it came from a different perspective. >There is more emphasis on how the "the average programmer" -- or even >a beginner -- is going to use the language. Modula-3 has retained most >of its predecessor's philosophy about syntax (though I would not want >to teach partially opaque types to someone who just started >prorgamming). As a consequence, I think it is possible to teach >programming to early programmers with (a subset of) Modula-3, while it >is much harder to do the same with C. I agree with this last point. However, that doesn't mean you should ignore implementation issues or how the language design effects a code generator etc. Designing a language ONLY from the programers point of view can be a mistake if for example you desing a language that is so difficult to write a compilier for that no one can pass a standard test suite. Rather, proposed changes for implementational purposes should be weighed against the impact on the user interface. As for null statements, what harm is there? In fact, from a user interface perspective I think it would be BETTER if an extra semicolon was treated as a semantical warning rather than a syntactically error. >Other than the fact that it is portable and lightweight, I can't >imagine why C is a particularly good target language _these days_, >especially since it lacks things such as memory management, good >namespace management, nested procedures, and overflow detection. I >seem to recall some gripes about C as a target language in some >documentation relating to SRC Modula-3. Maybe some of the >implementors can elaborate. Modula-3 on the other hand, makes a pretty >nice target language for the most part, if you are willing to live >with the "little" extra overhead. I thought the reason C was often used as a target language was because thier compiliers were common and highly optimized. Ray -- _____________________________________ Ray Johnson Lockheed Artifical Intelligence Center ======================================================================= 17 === Date: 9 Feb 1994 19:58:18 GMT From: Eric Muller Subject: comp.lang.modula3 archive I have update the archive on gatekeeper. It now includes all the messages sent through January 94 (one file per month), together with a kwic index of the subject lines. -- Eric. ======================================================================= 18 === Date: Wed, 9 Feb 1994 12:31:18 +0100 (MET) From: thomas.tensi@fi.sdm.de (Dr. Thomas Tensi) Subject: Did anybody do a M3-Spiderweb? Hello M3 community, I would like to know if anybody did a description of MODULA-3 for the spiderweb literate programming system of Norman Ramsey. (For those not familiar with this concept: Literate programming is method for combining programs and their documentation into one document. This document is filtered. Result of this filtering process is a prettyprinted documentation (normally in TeX) and a source file for a programming language compiler.) So: Has anyone done a m3.spider? Thanks ------------------------------------------------------------------------- Dr. Thomas Tensi |s |d &|m | software design & management GmbH | | | | Thomas-Dehler-Str. 18 thomas.tensi@sdm.de | | | | 81737 M"unchen, Germany. ======================================================================= 19 === Date: Thu, 10 Feb 1994 11:24:11 GMT From: hws@csis.dit.csiro.au (Heinz Schmidt) Subject: New OO benchmark TR The following technical report can now be obtained by anon ftp from csis.dit.csiro.au /pub/sather/papers. We describe initial benchmark results obtained for some basic runtime system primitives including array accesses, attribute accesses and dynamic dispatch for Sather and C++ with a variety of different approaches to object layout and dispatch implementation. Our schemes are a marriage of C++ virtual function tables and Sather dispatch mechanisms, including a new technique based on custom dispatch tables containing assembler instructions. The schemes are described in detail and partly make Sather faster, in raw execution speed of these primitives, tham current C++ implementations. While we have written the benchmarks in C and Sather, there is no reason why some of these schemes could not be used in other OO languages. It is interesting to note that we have not yet optimized the underlying C code sequence produced by Sather and/or used in part of the runtime system. Nevertheless Sather can obtain a speed very close and partly faster to that of C++. While many believe that typesafe and higher-level OO languages such as Modula-3, Eiffel or Sather have other advantages over C++, our benchmarks indicate that there is still room for efficiency improvements at the runtimes level and further optimization may be possible beyond that. We are submitting an improved version of the TR including refined benchmarks and additional architectures and would be most happy to collect critique, feedback etc. File: TR-CS-94-02.ps.Z @techreport{Milton-Schmidt-94, author = {S. Milton and H.W. Schmidt}, institution = {Department of Computer Science, The Australian National Univ ersity}, month = jan, number = {TR-CS-94-02}, title = {Dynamic Dispatch in Object-Oriented Languages} year = {1994} } \begin{abstract} Dynamic binding in object-oriented languages is perhaps the most important semantic aspect of these languages. At the same time it can contribute to inefficiency and lack of robustness because it incurs lookup overheads on function calls and hinders the compiler determining the exact type of objects held in variables or returned by functions. This may, for instance, preclude inlining of small functions or attribute offset computation at compile time. Yet attribute accesses are the most frequently executed operations. As a result, to regain lost performance, OO programmers are tempted to break the encapsulation of classes or want explicit control over dynamic dispatch, trading off extensibility. In the implementation of parallel object-oriented languages the additional complication arises that object accesses may require more expensive remote memory accesses. Lookup at the call may be inappropriate if the code has to be executed on a different processor and there perhaps has a different address. This paper summarizes dispatching as addressed in several modern object-oriented languages. We then describe and benchmark fast and flexible dispatch schemes that we are currently implementing on SPARC based workstations and multi-processors. These involve elements of \cplusplus\ virtual function tables and Eiffel's and Sather's ability to redefine abstract functions as attributes. Initial benchmarks seem to promise improved efficiency on a range of modern RISC based architectures. \end{abstract} ,-------------------------------------------------------------------. ,--_|\ |Heinz.Schmidt@csis.dit.csiro.au | CSIRO Div Information Technology| / \ |CSIRO DIT, POBox 664 | ANU Dept Computer Science | \_,--_*/ |Canberra ACT 2601, Australia | include STD_DISCLAIMER{CSIRO}; | v |Tel: +61-6-275-0974 Fax: 257-1052| include STD_DISCLAIMER{ANU}; | `-------------------------------------------------------------------' ======================================================================= 20 === Date: 10 Feb 94 12:56:20 From: mday@note.lcs.mit.edu (Mark Day) Subject: Re: Question for Modula-3 Designers: Why no null stmts? rjohnson@titan.rdd.lmsc.lockheed.com (Ray Johnson) writes: In fact, from a user interface perspective I think it would be BETTER if an extra semicolon was treated as a semantical warning rather than a syntactically error. Actually, from a user interface perspective *all* semicolons are annoying and should be exterminated. Especially because you can write nice quasi-Modula-3 programs without the semicolons, upper case keywords, and other syntactic glitches marring an otherwise very nice language. Just pick up Andrew Myers's m3process preprocessor, which transforms m3su (a dialect of Modula-3 without semicolons and upper-case keywords) to standard Modula-3. The man page and sources are available by anonymous ftp in the directory pion.lcs.mit.edu:/pub/m3su (Pion's internet address is 18.26.0.64). --Mark Day mday@lcs.mit.edu ======================================================================= 21 === Date: 10 Feb 94 16:22:32 GMT From: tj@lamar.ColoState.EDU (Tamera Joice) Subject: Modula-3 Compiler for PC Does anyone know if there is a Modula-3 compiler for the PC that does not use djgpp? Are there any planned in the future? Are there any currently available? (Besides the one currently available from gatekeeper) Email tj@lamar.ColoState.edu ======================================================================= 22 === Date: 10 Feb 1994 23:07:22 GMT From: salomon@silver.cs.umanitoba.ca (Daniel J. Salomon) Subject: Re: Question for Modula-3 Designers: Why no null stmts? In article fn00@gte.com (Farshad Nayeri) writ es: > > A generalization of Daniel's a null statement question is whether the > language designer should sacrifice "human interface" issues to make > the "programming interface" for the language easier to use (either for > the program that implements a language or a program that generates a > language.) Orienting a language toward the user rather than the implementor is a good philosophy in general, but I believe that Modula-3 has already made compromises along this line. For instance, I believe that the reason that GOTO statements were left out of BLISS, Modula-2, and Modula-3 was not due entirely to programming fashion alone. An additional consideration was that the absence of GOTOs permitted improved code optimization since a code block cannot be interrupted by random jumps in or out. After all, if one is against GOTOs, one can leave them out of programs, but if they impede optimization, or complicate compilation, then one is forced to ban them from the language instead. Once you have made compromises for the implementor, the question becomes where to stop compromising. -- Daniel J. Salomon -- salomon@cs.UManitoba.CA Dept. of Computer Science / University of Manitoba Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687 ======================================================================= 23 === Date: 10 Feb 1994 23:10:38 GMT From: spreitze@parc.xerox.com (Mike Spreitzer) Subject: C header file to language-X transliterator? Does anybody know of any programs that will transliterate ANSI C header files (ie, ".h" files that declare --- but not define --- things) into other language s? In order to invoke C procedures, and reference C variables, from another langua ge one typically needs to write some sort of "external declaration" to describe those procedures and variables in the other language (assuming they can be described at all in that language). I'm looking for programs that take a C header file as input and produce the required external declarations in any of a variety of languages. Note that I'm not asking for something that will generate glue code that will transform the representations into something more natural for the language in question; that's a harder problem. Note also that I'm not being picky about the language in which the transliterator itself is written. Please reply by mail to me; I don't follow all of these newsgroups. I'll post a summary of the responses. Thanks, Mike Spreitzer spreitze@parc.xerox.com ======================================================================= 24 === Date: Thu, 10 Feb 1994 15:39:43 GMT From: tgt@lanl.gov (Thierry G. Thelliez) Subject: Re: OOPSLA'94 Paper Deadline is NOT flexible! In article bnfb@scs.carleton.ca (Bjorn Freeman-Benson) writes: > > Authors should send six copies of the full paper, in English, to the > program chair (address below), to be received no later than 15 FEBRUARY > 1994. Papers must not exceed 18 PAGES, double-spaced, exclusive of figures > and bibliographic references. Not very clear. Can we send a camera-ready paper ? 18 Pages and double-spaced are the only constraints ? Thierry ======================================================================= 25 === Date: Sun, 13 Feb 94 21:41:25 EST From: vidya!mohan@vigyan.ernet.in Subject: Hello Friends, Is there a more detailed documentation on the internals of the Modula-3 compiler and runtime system than that in the DEC SRC Document on Modula-3 (Chapter 6 details a little, I wish it was more ). This is the document present in the modula-3 distribution in gatekeeper.pa.dec.com Thanks in advance Mohan ------------------------------------------------------------------------- Mohan T S Supercomputer Education and Research Centre Indian Institute of Science mohan@vidya.iisc.ernet.in Bangalore 560 012 INDIA mohan@vigyan.ernet.in ------------------------------------------------------------------------- ======================================================================= 26 === Date: 16 Feb 1994 18:08:21 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Why no 'use of unset value' run-time error in M-3? M-3 is defined so that it is not a run-time error to use an unset variable; an uninitialized variable assumes an arbitrary value of its type. I don't think this is ideal. At CenterLine (Saber) we found that 'use of unset variable' is a common run-time error, and that it's very nice to have a language implementation that catches it. I realize that there are tradeoffs here between safety, language complexity, and run-time cost. Does anyone remember what alternatives the language design committee considered? Release 3 doesn't have any unset variable run-time checking, does it? ---- Sam Kendall Sun Microsystems Labs BOS ======================================================================= 27 === Date: Wed, 16 Feb 1994 15:47:53 +0000 From: conference@rtal.demon.co.uk ("S.T.Q. Conference") Subject: CONFERENCE:'Safety Through Quality' (June 94, UK) ******************************************************************************* * * 'SAFETY THROUGH QUALITY' conference * ******************************************************************************* * Monday 6th and Tuesday 7th June 1994 Beaumont Conference Centre, Old Windsor, Berks., UK ******************************************************************************* * *********************** PROSPECTUS AND CALL FOR PAPERS ********************** * ******************************************************************************* * Real Time Associates Ltd., in conjunction with the British Computer Society Modular Languages SIG announce a major 2 day International Conference - `Safety Through Quality'. With the increasing use of modular programming languages for safety critical applications, the event is organised to embrace these, and the wider issues of designing and building safe systems through attention to quality. The conference has been carefully arranged to contrast and encourage debate through comparing practical approaches that have been adopted - or are being contemplated - by the speakers for real world applications. Although this prospectus constitutes an outline of the agenda, we are pleased to say that all companies and organisations mentioned in the provisional progr- amme have confirmed that they will be presenting their papers and we thank them for their support and encouragement. The call for papers is designed to solicit further contributions in the theme o f the conference. The organisers acknowledge the co-operation of the `Safety-Critical Systems Clu b' (UK). ******************************************************************************* * *********************************** THEME *********************************** * ******************************************************************************* * Approaches ... * Language design & compiler verification * The place and importance of Formal Methods * Automated testing of application code * Weak links - the software / hardware interface. * Neural networks - a different approach to the same goal Implementation ... * Case tools for safe design * The place of reverse engineering * The safety & quality of modern OOPs languages * Parallel processing - too complex to be safe? * The role of basic support tools - debuggers etc. Psychological Issues... * Are system designers and programmers trained in quality and safety issues? * Quality assurance in project management - bargaining for safety testing * The burgeoning of 'FATWARE' operating systems, compilers and utilities to achieve safe results - is this possible? Legal Issues ... * The need for accountability * Standards * Current Legislation * Civil Liabilities ******************************************************************************* * *************************** PROVISIONAL PROGRAMME *************************** * ******************************************************************************* * Computer based systems effect all aspects of our lives, and so they should be safe. But are they? The presentations are designed to contrast and encourage debate in the quality approach and safety considerations adopted by different companies and organis- ations involved in areas such as those shown below. We hope that by comparing alternative approaches, the conference and debate will be synergetic to safer systems development. * Military & Aerospace Speakers from Russian Military, NASA * Nuclear Reactor Control Speakers from LDRA Ltd. (UK), Atomic Energy of Canada Ltd (AECL) * Accounting & Finance (integrity in accounting systems) Speakers from Coopers&Lybrand, KPMG. * Neural Networks (The Alternative Approach) Speakers from CalTech(USA) - hybrid neural network / expert system for telephone network management. University of Exeter - new theories and practices * Virtual Reality (As an aid to Fire Fighting) Speakers from Human Engineering Technologies Ltd. * Automobile Control Systems Ford Motor Co, Rover Group Ltd. * Railway Control HM Railway Inspectorate (UK), Matra Transport (France) * Quality Control Mechanisms & Law Lloyds Register, Exxel consultants - R.J. McQuaker (Vice President of BCS) ** KEYNOTE PAPER Brian Wichmann of National Physical Laboratory (UK) Modularisation for Assurance (and how we gauge safety & quality). ******************************************************************************* * ****************************** CALL FOR PAPERS ****************************** * ******************************************************************************* * Papers in accordance with the Conference theme are invited from any source. Please send max. 500 word abstract to the programme committee not later than March 14th 1994. Notification of accepted papers will be given to the authors before April 15th 1994,where upon full papers will be expected by May 6th 1994. Both abstracts and full papers should be submitted in machine readable form - either by disk (pref. 3.5", IBM PC format or Unix TAR) or by email - in ASCII or any popular word or desk top publishing format. All submissions must be accompanied by a hard copy as an aid to setting the proceedings. Submissions to : The Programme Committee c/o Real Time Associates Ltd. Canning House 59 Canning Road Tel : (+44)(0)81 656 7333/4/5 Croydon Fax : (+44)(0)81 655 0401 Surrey CRO 6QF Internet : conference@rtal.demon.co.uk UK CompuServe: 71333,2346 The working language of the conference is English, and will be used for all presentations and printed material. The proceedings are likely to be post published by Oxford University Press and we hope that selected papers will be published in the new, peer reviewed, international journal `High Integrity Systems' also published by Oxford University Press. The Programme Committee will hold copyright on the Proceeding s material for this and the duration of the Conference. Any exceptions to this copyright scheme should be clearly indicated at the time of the submission. The programme committee will not unreasonably withhold transfer of copyright, which, after this period, will reside with the authors or their organisations. ******************************************************************************* * ******************************* THE CONFERENCE ****************************** * ******************************************************************************* * Beaumont Conference Centre at Old Windsor is situated close to the River Thames and is adjacent to both Runnymede (Magna Carta & Kennedy Memorial) and Windsor Castle. Heathrow airport is just 10 miles away and Central London a 30 minute train journey. A short walk over Windsor Bridge to Eton allows you to browse antique shops, ar t galleries and soak up the atmosphere of this historic town. The Eighteenth Century Georgian house is set within fifty acres of gardens and park lands and overall provides a combination of traditional elegance and moder n comforts. Recreational facilities include heated swimming pool, squash & tennis courts, a nine hole pitch & putt golf course and croquet on the garden lawn. For those that prefer the less physical sports, snooker, pool, darts and various board games are also available. Residential accommodation will be split between Beaumont itself and the adjacen t Heathrow Marriott Hotel. All rooms are equipped with en-suite bathrooms, telephone, TV, etc. and are charged at the same rate. A courtesy coach service is provided between Beaumont and the Marriott Hotel, and from all four Heathrow Airport terminals to/from the Marriott. The larger Marriott accommodation is more suitable should you wish to bring a partner. Depending upon uptake, the organising committee will arrange a social programme for partners, to be run in parallel with the conference. ******************************************************************************* * ********************************* REGISTRATION ****************************** * ******************************************************************************* * The residential fee for the two day Conference is GBP#420 to include conference attendance, proceedings, two nights accommodation at Beaumont (Sunday 5th, Monday 6th June) and all meals (breakfast, lunch & dinner) and usual coffee & tea refreshments. The non-residential fee is GBP#220 to include conference attendance, proceed- ings, lunch and coffee & tea refreshments. Tickets for the Conference banquet on the evening of Monday 6th June are available for residential delegates at GBP#35 and for non-residential at GBP#45. After dinner speech by the entertain- ing Mr Michael Bailey - 'Quality is No Illusion'. Arrangements have been made to book supplementary accommodation for residential delegates at a concessionary rate prior to, and after the Conference. This will be charged at the special rate of 80 per day for dinner bed and breakfast. Partners sharing a delegates room will be charged a supplement of GBP#20 /day for bed and breakfast accomodation. Members of the BCS Modular Languages SIG may attend the conference at a 10% discount on the conference fee (residential or non-residential). This discount will not apply to supplementary or partner rates. The above rates are subject to the addition of UK VAT at 17.5%. A full VAT invoice will be issued. Monies are accepted in USD. The conference is limited to a maximum of 100 attendees, so please book early t o secure your place. Pre-payment is required before attendance is possible. ******************************************************************************* * ***************************** BOOKING DETAILS ******************************* * ******************************************************************************* * To Book, please contact Real Time Associates Ltd (See 'Call For Papers' above f or details), stating address. You will be sent details and a booking form by retur n post. ******************************************************************************* * ********************************** CALENDAR *********************************** * ******************************************************************************* * +----------------------------+-----------------+ | Abstracts by | March 14th 1994 | +----------------------------+-----------------+ | Acceptance Notification | April 15th 1994 | +----------------------------+-----------------+ | Full Papers by | May 6th 1994 | +----------------------------+-----------------+ | Final Conference Programme | May 16th 1994 | +----------------------------+-----------------+ | Registration Deadline | May 27th 1994 | +----------------------------+-----------------+ | Conference | 6-7th June 1994 | +----------------------------+-----------------+ -- ---------------------------------------------------------------------------- 'Safety Through Quality' Conference conference@rtal.demon.co.uk ---------------------------------------------------------------------------- c/o Real Time Associates Ltd Canning House Tel: (+44)(0)81 656 7333/4/5 59 Canning Road Fax: (+44)(0)81 655 0401 Croydon, Surrey CR0 6QF, UK ----------------------------------------------------------------------------- ======================================================================= 28 === Date: 16 Feb 1994 14:34:17 -0500 From: smiale@copper.ucs.indiana.edu (Steven Miale) Subject: 2nd RFD: comp.lang.python Second Request For Discussion: comp.lang.python Purpose ------- The newsgroup will be for discussion on the Python computer language. Possible topics include requests for information, general programming, development, and bug reports. The group will be unmoderated. What is Python? --------------- Python is a relatively new very-high-level language developed in Amsterdam. Python is a simple, object-oriented procedural language, with features taken from ABC, Icon, Modula-3, and C/C++. Its central goal is to provide the best of both worlds: the dynamic nature of scripting languages like Perl/TCL/REXX, but also support for general programming found in the more traditional languages like Icon, C, Modula,... Python may be FTP'd from the following sites: ftp.cwi.nl in directory /pub/python (its "home site", also has a FAQ) ftp.uu.net in directory /languages/python gatekeeper.dec.com in directory /pub/plan/python/cwi Rationale --------- Currently there is a mailing list with over 130 subscribers. The activity of this list is high, and to make handling the traffic more reasonable, a newsgroup is being proposed. We also feel that comp.lang.misc would not be a suitable forum for this volume of discussion on a particular language. Charter ------- Comp.lang.python is an unmoderated newsgroup which will serve as a forum for discussing the Python computer language. The group will serve both those who just program in Python and those who work on developing the language. Topics that may be discussed include: - announcements of new versions of the language and applications written in Python. - discussion on the internals of the Python language. - general information about the language. - discussion on programming in Python. Discussion ---------- Any objections to this RFD will be considered and, if determined to be appropriate, will be incorporated. The discussion period will be for a period of 21 days after which the first CFV will be issued. ======================================================================= 29 === Date: Wed, 16 Feb 94 12:27:14 PST From: frode@toaster.SFSU.EDU (Frode Odegard) Subject: uninitialized variables and looseness Yeah, it would seem reasonable - from a formal specification point of view (read: VDM) - that the result of an expression f(x) is undefined if x is undefined. But would that not require some special value representing 'undefined' ? This might be expensive and complicated. The M-3 approach is such that VAR x: T; BEGIN f(x) END corresponds to the VDM-SL let x in set T in f(x) In VDM-SL this is called "looseness", x is said to be some T but can be *any* T. A demand is laid upon f(x) such that it is defined for any value of x as long as it is a member of T. The above Modula-3 construct allows "looseness" in a formal specification to be echoed to some degree in the implementation. The looseness in Modula-3 is not as general as in VDM-SL, however. As an example, look at the following VDM-SL function to find the largest element in a set: S = set of Element; max-element: S --> Element max-element (s: S) r: Element pre s <> {} post r in set s and not exists x in set s . x > r max-element (s: S) == let q in set s in if exists x in set s . x > q then max-element (s - {q}) else q The Modula-3 type system restrictions (types and sets are not generalized) reflect the fact that the language is an implementation language. While VDM-SL makes it easy to write non-executable specifications, this would not make sense in a programming language. But at least Modula-3 lets us express "some T, any T." Frode Odegard ======================================================================= 30 === Date: Thu, 17 Feb 94 02:04:59 -0600 From: demo.next.com!ggf@jsoft.com (Gary Frederick) Subject: VDM tools (Was: Re: uninitialized variables and looseness) frode@toaster.SFSU.EDU (Frode Odegard) gave some interesting info that mentione d VDM: Frode, I remember someone telling me there were some tools for VDM coming out. Do you know anything about such tools? Gary ======================================================================= 31 === Date: Thu, 17 Feb 94 07:51:18 PST From: frode@toaster.SFSU.EDU (Frode Odegard) Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness) > Do you know anything about such tools? Um, yes, I am a NAFTA-area distributor for one of them, the IFAD VDM-SL Toolbox. It contains an interpreter, a type-checker, a LaTeX pretty-printer and a test coverage analyzer. Presently runs on SPARC machines only. The system is fully integrated with emacs, which is wonderful if you're already an emacs user. (If not there's also a stand-alone mode.) There's a new release coming out any day now, watch comp.specification for the announcement. A demo version is available by ftp. There's also a product called SpecBox from Adelaide in the UK; IFAD is based in Denmark. Frode Odegard (frode@odegard.com) PS: I hope this isn't too blatant an advertisement, but somebody did ask.. ======================================================================= 32 === Date: Thu, 17 Feb 94 10:13:52 -0800 From: gnelson@src.dec.com Subject: Re: Why no 'use of unset value' run-time error in M-3? We didn't want to require a runtime check for using an uninitialized variable, since this seemed like it could be too slow. We considered ways to change the language that would make it a static error to use an uninitialized variable, but we couldn't find one that was simple enough. (Consider arrays that are initialized by passing them as a VAR OUT to a procedure.) Many of us concluded that the best approach was to build a lint-like tool to catch and statically warn the programmer about the use of uninitialized variables. Indeed, we are working on an extended static checker at the moment, one of whose checks will be for use of uninitialized variables. But the checker is Research with a capital R, so for the moment, you just have to program carefully. Greg Nelson ======================================================================= 33 === Date: Thu, 17 Feb 1994 17:29:37 GMT From: jbpn1@hermes.cam.ac.uk (J.B.P. Naylon) Subject: Errors in m3pp? Recently I attempted to pretty-print a Modula-3 program, outputting to PostScript in portrait orientation, and on one occasion received the message: *** *** runtime error: *** ASSERT failed *** file "FBEPostScript.m3", line 225 *** On trying again, I was rewarded with: *** *** runtime error: *** NARROW failed *** file "NewFormatter.m3", line 860 *** In both cases the command line was: m3pp -ps -portrait SubMaster.m3 >../../ps/SM.ps Any suggestions as to why this happened? Incidentally, SubMaster.m3 is not even that large: wc SubMaster.m3 358 1682 15633 SubMaster.m3 I believe that this m3pp is the version distributed with version 2.11 of the compiler. -- John Naylon ======================================================================= 34 === Date: Fri, 18 Feb 1994 13:24:07 GMT From: marcel@dutcu15.tudelft.nl (Marcel Verhoef) Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness) This is what I wrote to the comp.compilers group a while ago: The institute of applied computer science IFAD at Odense, Denmark has a toolset (compiler, interpreter, debugger) for the development of VDM-SL specifications. All the tools used, are formally defined in VDM-SL itself (syntax, abstract syntax, operational and static semantics) and implemented in C++. I have worked on part of the toolset for my MSc thesis and the general development approach taken was as follows: 1) specify the tool in a VDM-SL, beginning at a high level of abstraction and lowering the level of abstraction until you have a fully explicit formal definition of your program 2) test the specification with the debugger, develop a test-suite (the debugger can be used in on-line and batch mode) 3) implement the program (e.g. in C++) 4) re-use the test-suite to "validate" the program. Of course, this is not a single-in-line operation, the power of this approach is that you can re-iterate ideas by trying out specification styles in an early stage with the debugging environment and taking design decisions along the way. Second advantage is that the coding in (e.g.) C++ is quite easy and the time used on actually writing code is reduced *dramatically*. Actually, much of this work could be automated (and what I hear is that IFAD is going to built such a code-generator). I wrote a 2500 line specification of a prototype staic semantics analysis tool (which took me 3 months to complete, including testing) and I coded 7500 lines of C++ code in less than one month, implementing the specification. This is including the "learning"-curve (I had reasonable knowledge of VDM, but never programmed anything big in C++). Although it was a price-to-win approach (ever tried to complete your MSc in time?) comparable results from industry are there. So, I would urge everyone interested in implementing formal specifications to have a very close look at what is going on in the Formal Methods world. There are several companies with industry-proof toolsets available. Apart from IFAD I can think of Adelard and BP research in GB and CRI in DK. You can get info about the IFAD VDM toolbox by emailing toolbox@ifad.dk, I don't know about the others. Good entry-points are the proceedings of the VDM and FME conferences which are published as lecture notes in computer science by Springer. Greetings, Marcel ======================================================================= 35 === Date: Fri, 18 Feb 1994 17:09:47 GMT From: pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) Subject: Acos ?? Hello, My question is probably not so hard, at least that's what I hope: I need to switch between the carthesian and polar coordinates of a 2D-vector. Which in itself isn't a problem since I can use the rule: a.b = |a| |b| cos(c) --> angle = acos (a.b / |a| |b|) Although I still have to make sure that the angle will be between 0-360 degrees and not 0-180 all in all it's not so hard. But I'm using Oberon which doesn't have an acos, asin funtion. Basically my question is: 1] If I can't use acos or asin how do get polar coordinates 2] How can I define my own acos function easily 3] This is more of a general question: Oberon, but also the original Modula-2 (see Wirth Report) have a Math librarie which is very simple, things like acos, asin etc are 'missing'. Obviously this was done with a purpose but why?? Thanks in advance Paul ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- DELPHI PROJECT Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England tel: (44) (0)223-333416 fax: (44) (0)223-334871 email: pgs1002@esc.cam.ac.uk --------------------------------------------------------------------- Clinton Ft. Bragg Soviet Nazi Rule Psix supercomputer colonel NSA AK-47 Semtex smuggle fissionable Noriega assassination domestic disruption -- ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England fax: (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk --------------------------------------------------------------------- ======================================================================= 36 === Date: Fri, 18 Feb 1994 13:16:21 GMT From: c2car@dmu.ac.uk (CA Randall) Subject: Shareware Does anyone know if a modula 3 system exists in the shareware for a pc. if so w here can i get it ftp sites etc.. thanks in advance chris. ======================================================================= 37 === Date: Fri, 18 Feb 1994 15:42:39 GMT From: Darren New Subject: Re: Why no 'use of unset value' run-time error in M-3? > We considered ways to change the language that would > make it a static error to use an uninitialized variable, > but we couldn't find one that was simple enough. The Hermes language does this. > (Consider > arrays that are initialized by passing them as a VAR OUT to > a procedure.) All you need to do is to have keywords or whatever that say "this parameter can be passed uninitialized and is returned initialized". Course, this has to be checked when compiling the implementation, but that isn't any harder than checking that you don't use uninitialized variables. -- Darren ======================================================================= 38 === Date: Fri, 18 Feb 94 01:58:27 -0600 From: demo.next.com!ggf@jsoft.com (Gary Frederick) Subject: Re: VDM tools (Was: Re: uninitialized variables and looseness) >PS: I hope this isn't too blatant an advertisement, but somebody did ask.. I did not find it blatant, then again, I am the person that asked (-: Are you using VDM on any projects that also use M3? Is anyone using M3 commercially? Gary ======================================================================= 39 === Date: Sun, 20 Feb 1994 02:44:39 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: 3.1 I downloaded the Linux version of Modula-3 v3.1 from gatekeeper. It seems to install smoothly, but when I run m3build (as in the tiny example at the front of DOC.dvi) m3c cannot find the standard interfaces. They ARE there, and seemingly in the right place. Has anyone gotten this to work? Do I have to change the templates? Is there some DIRECT way to get m3c to look in some particular place for interfaces? -mike ======================================================================= 40 === Date: Mon, 21 Feb 1994 00:20:52 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: 3.1 In article mhcoffin@tolstoy.uwaterloo.ca (Mi chael Coffin) writes: I downloaded the Linux version of Modula-3 v3.1 from gatekeeper. It seems to install smoothly, but when I run m3build (as in the tiny example at the front of DOC.dvi) m3c cannot find the standard interfaces. They ARE there, and seemingly in the right place. Has anyone gotten this to work? Do I have to change the templates? Is there some DIRECT way to get m3c to look in some particular place for interfaces? I run into a similar situation (with testing 3.1 on the SPARCs) which I got rid of by adding the statement "import(libm3)" in the m3makefile. I am not sure why libm3 is not imported automatically as it used to be. I figured out that I need to do this by looking at other m3makefiles in the distribution. Hope this helps... --farshad -- /// | {@,@} | "He's so unhip that when you (...) Farshad Nayeri | say Dylan, he thinks you're " " nayeri@gte.com | talking about Dylan Thomas." ======================================================================= 41 === Date: 21 Feb 94 20:42:04 GMT From: kazmier@CS.ColoState.EDU (michael kazmier) Subject: Modula-3 and NeXT computers Hey, just a quick question for all of you modula buffs, I am currently running on NeXTStep 3.2 for Intel, does anyone know if there is a release of the lang for my system and where I could find it. If there is not one, does anyone know of any planned release (such as the GNU release) Feel free to e-mail me at kazmier@cs.colostate.edu Thanks in advance...Mike Kazmier (kaz) ======================================================================= 42 === Date: 21 Feb 1994 14:55:20 -0600 From: johnh@wheaton (John C. Hayward) Subject: Missing Version Stamps for TEXT, MUTEX while making a boot-able I am trying to make a bootstrap distribution of Modula-3-2.11 for NetBSD. I have a working environment. I have been having my students do some trestle and formsVBT programming under NetBSD, XFree2.0 and Modula-3-2.11. I have forgotten the steps I used to port it (its a long story but I originally ported from Sun to 386BSD and then to NetBSD with the help of DecStation). I have Modula-3-2.11 under a DecStation and attempting to create a bootstrap_driver produces the following script. scr> csh> m3make -f m3makefile.compiler bootstrap_driver NEW=NETBSD scr> mkdir driver/boot-NETBSD scr> Mon Feb 21 13:23:14 CST 1994 ===================== bootstrap driver for NE TBSD scr> cp ../src/m3.1 . scr> /usr/local/bin/m3 -w1 -make -why -boot -times -g -Y0@../../compiler/cross -NETBSD/m3compiler@ -o m3 -F.PGM_SOURCES scr> new source -> recreating ../../libm3/Csupport/src/generic/M3Runtime.h scr> ... lots of new source -> recreating ... scr> new source -> recreating ../../libm3/unix/src/ultrix-3-1.NETBSD/Uin.m3 scr> new objects -> linking m3 scr> undefined version stamp: TEXT scr> TextF.i3 scr> undefined version stamp: MUTEX <1f9d4e89391ab815> scr> Thread.m3 scr> scr> seconds #times operation scr> 1.34 1 flattening search path scr> 3.66 271 checking object timestamps scr> 1231.16 261 compiling Modula-3 -> C scr> 14.91 261 merging new link info scr> 0.94 1 checking global consistency scr> 0.12 11 removing temporary files scr> 3.50 10 copying files scr> 6.76 10 garbage collection scr> 1.09 other scr> --------------------------------------------------- scr> 1263.48 TOTAL scr> scr> scr> Fatal Error: incomplete program scr> scr> *** Error code 255 scr> scr> Stop. scr> *** Error code 1 scr> scr> Stop. scr> csh> exit scr> csh> scr> script done on Mon Feb 21 14:09:17 1994 The resultant directory has almost everything it needs except m3makefile.objs and _m3main.c. There are comments in both Thread.m3 and TextF.i3 which indicate that MUTEX and THREAD are special in that they are declared REFANY while these modules define them as something else. Any suggestions would be appreciated. I think our postmailer is broken so pleas reply to johnh@wheaton.edu Thanks in advance. ======================================================================= 43 === Date: Tue, 22 Feb 94 04:55:34 -0600 From: demo.next.com!ggf@jsoft.com (Gary Frederick) Subject: Re: Modula-3 and NeXT computers I did the version of M3 for the 68K. I may have both time and resources to get a "fat" (Motorola and Intel) version up soon. I have not heard of anyone getting an Intel version up . The notes with the Motorola version at the ftp site in Oregon would be helpful. E-mail me if you do the Intel version. Good luck Gary ======================================================================= 44 === Date: 22 Feb 1994 17:50:44 +1100 From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Subject: Re: Acos ?? pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) writes: >My question is probably not so hard, at least that's what I hope: >I need to switch between the carthesian and polar coordinates of a >2D-vector. Which in itself isn't a problem since I can use the rule: >a.b = |a| |b| cos(c) --> angle = acos (a.b / |a| |b|) This is a very odd way to do it. That conversion is precisely what the very common two-argument arctangent function is supposed to do. Diagram: . /| / | r >= 0 is length of hypotenuse r/ |y 0 <= a < 2pi is the angle /a | x is horizontal, could have either sign /____. y is vertical, could have either sign x In the UNIX C environment, we have x = r*cos(a) r = hypot(y, x) y = r*sin(a) a = atan2(y, x) >But I'm using Oberon which doesn't have an acos, asin funtion. Does Oberon have an atan function? If it has a two-argument arctangent, then the conversion is as easy as I have shown, and will give you the right answers for all four quadrants (all angles 0 <= a < 2pi, all values of x and y). If it has a one-argument arctangent, you will have to look at the angle yourself to find out which quadrant (sign of x, y) you want. *Mathematically*, hypot(y, x) = sqrt(y*y + x*x). A good *mplementation* will avoid overflow and underflow, typically by doing something like ax <- abs(x) ay <- abs(y) if ax > ay then p <- ax t <- ay/ax else p <- ay t <- ax/ay end if if t > EPS then # precalculated so that EPS*EPS+1.0 == 1.0 return sqrt(t*t+1.0) * p else return p end if Something you want to watch out for is that (x=0.0,y=0.0) is a perfectly good point in Cartesian coordinates, but atan2(0.0, 0.0) is not well defined (when the radius r = 0.0, the angle is genuinely undefined). So you want if abs(x) = 0 and abs(y) = 0 then r <- 0 a <- 0 # or anything else you fancy else r <- hypot(y, x) # computed as above a <- atan2(y, x) end if ======================================================================= 45 === Date: 22 Feb 1994 18:05:16 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Q: netobj/stubgen on DS3100? In article , torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner) writes: > My only problem is occurs during > the stubgen build phase: > > *** > *** runtime error: > *** checked runtime error: range fault, value too small > *** pc = 0x4aff78 = EmitArg + 0x240 in ../src/values/Formal.m3 > *** The compiler chokes when it's generating code to pass an open array by value. In this case the easiest workaround is to modify stubgen/src/CodeForType.AugmentImportList to take a READONLY ARRAY OF Atom.T. - Bill Kalsow ======================================================================= 46 === Date: 22 Feb 94 16:44:54 GMT From: rro@CS.ColoState.EDU (Rod Oldehoeft) Subject: Redefined procedures from generic module In working up to generics, I have a generic interface/module implementing a list type and associated operations. There are 8 procedures here. I have two data types, INTEGER and TEXT, defined by two more pairs of interface/module. I have two instantiations (two more pairs) of the generic list, defining integer lists and text lists. I have a main module that imports both instantiations, and declares some variables of each list type. The m3 compiler complains to me that 4 of the 8 procedures in the generic module are redefined. Any instant help out there? I can be lots more specific, but I hoped there was a "Hey, dummy ... " response. Thanks in advance. ======================================================================= 47 === Date: Tue, 22 Feb 1994 15:09:45 GMT From: torki@mpipf-muenchen.mpg.de (Torsten R. Kirschner) Subject: Q: netobj/stubgen on DS3100? Hello, I just successfully compiled and installed Modula-3 3.1 out of the box. It works fine as a DS3100 port. Of course I would like to play with DO, so I tried to compile the netobj package. My only problem is occurs during the stubgen build phase: --- building in DS3100 --- rm -f stubgenv1 ln -s stubgen stubgenv1 m3 -w1 -why -g -o stubgen -F/usr/tmp/aaaa23402 new source -> compiling ../src/StubCode.m3 *** *** runtime error: *** checked runtime error: range fault, value too small *** pc = 0x4aff78 = EmitArg + 0x240 in ../src/values/Formal.m3 *** ------------------------- STACK DUMP --------------------------- ----PC---- ----SP---- 0x4d4268 0x7fffb2f0 Crash + 0x9c 0x4d93c8 0x7fffb310 EndError + 0x44 [0x4d90ac..0x4d929c] RAISES {} 0x4d9298 0x7fffb328 FatalErrorPC + 0x218 0x504ee0 0x7fffb358 CRE + 0x40 [0x504c10..0x504e88] RAISES {} 0x504d04 0x7fffb370 BusError + 0x114 0x533580 0x7fffb390 [sigvec] 0x4aff74 0x7fffb4e8 EmitArg + 0x240 [0x4a3c44..0x4a4564] RAISES {} 0x4a41ac 0x7fffb530 Prep + 0x594 0x424c20 0x7fffb5b0 Prep + 0x40 [0x41bc94..0x41bd24] RAISES {} 0x41bd20 0x7fffb5d0 Prep + 0xa8 0x4795d0 0x7fffb5f0 Compile + 0x38 0x475aa0 0x7fffb610 Compile + 0xb4 0x4792c8 0x7fffb648 Compile + 0x134 0x475aa0 0x7fffb678 Compile + 0xb4 0x4ba284 0x7fffb6b0 GenBody + 0x1c8 0x4ba0a0 0x7fffb6f0 EmitBody + 0x68 [0x462db8..0x462f28] RAISES {} 0x462e50 0x7fffb710 EmitBody + 0xb4 [0x46208c..0x462bd0] RAISES {} 0x462124 0x7fffb740 EmitAll + 0xd4 0x4b64a0 0x7fffb7f8 CompileModule + 0x150 [0x4b5e04..0x4b60dc] RAISES {} 0x4b6014 0x7fffb830 Compile + 0x234 0x44c7e0 0x7fffb870 DoCompile + 0x1f0 [0x44c0f0..0x44c278] LOCK mutex = 0x1007b4c0 0x44c264 0x7fffb8b8 Compile + 0x1c8 0x4c6850 0x7fffb8e0 DoCompile + 0x3d8 0x4c644c 0x7fffb930 DoIt + 0x30 0x4c78e0 0x7fffb950 _INITM_Main + 0x16c [0x4d436c..0x4d4444] RAISES {} 0x4d4404 0x7fffb970 RunInitPhase + 0xb8 0x4d4630 0x7fffb9a0 _INITM_RTLinker + 0x1cc 0x40042c 0x7fffb9c0 [main] 0x400334 0x7fffb9e8 [__start] ---------------------------------------------------------------- "../src/StubCode.m3", line 118: warning: potentially unhandled exception (OSErr or.E) "../src/StubCode.m3", line 119: warning: potentially unhandled exception (OSErr or.E) compilation failed => not building program "stubgen" *** error code 1 (ignored) I apologize for the long quote, but maybe someone can interpret it. Unfortunately, I cannot. However, stubgen is essential for building DO applications. Has anyone got a quick hint for me how I can fix this? Thanks in advance! Torsten ps. I would like to add that I ftp'd th release-3.1 from the very well sorted ftp.informatik.tu-muenchen.de:/pub/comp/programming/languages/Modula-3. That's a German site and might be a little faster for most European fellows than gatekeeper.dec.com directly. -- Torsten R. Kirschner (EDV) torki@mpipf-muenchen.mpg.de MPI f. Psychologische Forschung tel: ++49 89 38602258 Leopoldstr. 24 fax: ++49 89 342473 80802 Muenchen Germany X.400: /C=de/ADMD=d400/PRMD=mpg/O=mpipf-muenchen/s="torki" [PGP 2.3A 35AABD 1993/12/15 Torsten R. Kirschner ] Torsten ======================================================================= 48 === Date: 22 Feb 1994 23:23:09 -0600 From: johnh@wheaton (John C. Hayward) Subject: troubles with 3.1 with libm3 imports I have installed 3.1 on a decstation and have tried to build the simple hello program. I did change the default directories for bin, lib (/usr/local/new/bin and /usr/local/new/lib) so installing 3.1 would not clobber the current 2.11 version. There seems to be a file in topdir/libm3/DS3100/.M3IMPTAB with all of the information for the compiler(driver) to locate the include files for libm3. When I do a m3ship for the library I do not see that file being installed. I think the compiler(driver) does not see this file when I attempt to m3build the hello program and as a result cannot find the include files from the library. Where is the proper place for the .M3IMPTAB describing libm3 when it is installed and do I have to do anything special to get the driver(compiler) to see it? Below is a script of my unsuccessful attempt: >Script started on Tue Feb 22 23:02:23 1994 >csh> m3build >--- building in DS3100 --- >m3 -w2 -why -g -o foo -T.M3IMPTAB ../src/Main.m3 ../src/A.i3 ../src/A.m3 >new source -> compiling ../src/A.i3 >"../src/A.i3", line 1: unable to find interface (RT0) >"../src/A.i3", line 1: imported object is not an interface (RT0) >"../src/A.i3", line 1: unable to find interface (RTHooks) >"../src/A.i3", line 1: imported object is not an interface (RTHooks) >4 errors encountered >... other errors for A.m3 and Main.m3 >compilation failed => not building program "foo" >*** error code 1 (ignored) >csh> ^D >script done on Tue Feb 22 23:02:40 1994 Thanks in advance for any help. Our news poster may be broken please e-mail to: johnh@wheaton.edu johnh... ======================================================================= 49 === Date: Wed, 23 Feb 1994 18:04:52 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Modula-3 3.1 on a SPARC Quentin asked me for hints to bring up Modula-3 3.1 on the SPARCs, so I am releasing a log of bug reports and fixes that I know of. You can find these as a tar file: ftp.gte.com:/pub/m3/m3-3.1-on-a-SPARC.tar and its expanded version, the directory: ftp.gte.com:/pub/m3/m3-3.1-on-a-SPARC This includes fixes to formsvbt, netobj, and obliq. (All but the last one are working fine for me; obliq still gives me a weird run-time crash.) Many thanks to m3-request (whoever you are), Bill Kalsow, Geoff Wyant, Marc H. Brown, and Luca Cardelli for their input. Let me know if you find other fixes that I should include in this directory until the next release comes out. (I haven't gotten Michel's post about the binary archive, but I think some of these patches here are complementary to his patches.) --farshad -- /// | {@,@} | "He's so unhip that when you (...) Farshad Nayeri | say Dylan, he thinks you're " " nayeri@gte.com | talking about Dylan Thomas." ======================================================================= 50 === Date: Wed, 23 Feb 1994 14:30:22 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Release 3.1 compiled for SPARC available I have successfully compiled most of the release 3.1 for SPARC. This includes the compiler, libm3, m3gdb, trestle, vbtkit, formsvbt/formsedit, m3tk. Zeus, netobj and obliq are missing. New binaries will be generated with better optimization, dynamic librairies and the missing parts whenever things settle down a bit. This is available from: ftp.vlsi.polymtl.ca:pub/lude/modula3-3.1/run/poly/sun4.1_sparc To use it you simply have to put this in /usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc and make links from /usr/local/bin/* to /usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc/bin/* A first set of LINUX binaries will be available shortly in pub/lude/modula3-3.1/run/linux.tar.Z and must be put in /usr/local/soft/modula3-3.1. Then, links should be made from /usr/local/bin/* to /usr/local/soft/modula3-3.1/run/bin/* Enjoy! -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 51 === Date: Wed, 23 Feb 1994 14:18:46 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: troubles with 3.1 with libm3 imports Below is a script of my unsuccessful attempt: >Script started on Tue Feb 22 23:02:23 1994 >csh> m3build >--- building in DS3100 --- >m3 -w2 -why -g -o foo -T.M3IMPTAB ../src/Main.m3 ../src/A.i3 ../src/A.m3 >new source -> compiling ../src/A.i3 >"../src/A.i3", line 1: unable to find interface (RT0) >"../src/A.i3", line 1: imported object is not an interface (RT0) You can put "import(libm3)" in your m3makefile. It fixed my problem. However, i agree that normally the driver/compiler should not need it. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 52 === Date: 24 Feb 1994 17:06:06 GMT From: sims@ucrengr.ucr.edu (david sims) Subject: Re: 3.1 mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes: Michael> I downloaded the Linux version of Modula-3 v3.1 from Michael> gatekeeper. It seems to install smoothly, but when I run Michael> m3build (as in the tiny example at the front of DOC.dvi) m3c Michael> cannot find the standard interfaces. I just did the same thing and got the same problem. Argh! I tried putting "import(libm3)" in the m3makefile, but that didn't help a bit. Has anyone been able to get it working with Linux? If so, what did you do? Please help! thanks, dave sims -- David L. Sims Department of Computer Science sims@cs.ucr.edu University of California +1 (909) 787-6437 Riverside CA 92521-0304 PGP encryption key available on request. USA ======================================================================= 53 === Date: Thu, 24 Feb 1994 16:33:48 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula-3 3.1 on a SPARC Let me know if you find other fixes that I should include in this directory until the next release comes out. (I haven't gotten Michel's post about the binary archive, but I think some of these patches here are complementary to his patches.) In ftp.vlsi.polymtl.ca:lude/modula3-3.1 (my previous post said pub/lude by mistake) you will not only find the SPARC and LINUX binaries under run but also the unmodified source code under src/orig and the local modifs under src/poly. Indeed, i use a translucent mount when modifying and compiling packages. Thus, all my patches are readily available by looking at src/poly. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 54 === Date: Fri, 25 Feb 1994 00:09:18 GMT From: aselkirk@leibniz.uwaterloo.ca (Andrew Selkirk) Subject: v3.1 libm3 G'Day.... I've been able to successfully install v3.1 on my Linux system... On top of having to include the "import (libm3)" in your m3makefile, I also installed the libm3.tar.gz package (which installs into ../m3/pkg/libm3) which seemed to do the trick. But sure was tedious having to recompile the libm3 library which was originally done to create the m3 executables...Argh! NOTE: The debugging option "-g" (M3OPTIONS in ../m3build/templates/LINUX) is set and well... the difference between a 4M and 2M library. (I just copied the libm3.a from the initial install after installing libm3 package...There's probably a better solution but it worked) Hope this helps.... --------------------------- Andrew Selkirk University of Waterloo 2A Honours Computer Science ======================================================================= 55 === Date: 25 Feb 1994 05:46:40 GMT From: sims@ucrengr.ucr.edu (david sims) Subject: Re: 3.1 [problem fixed] I wrote> mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes: Michael> I downloaded the Linux version of Modula-3 v3.1 from Michael> gatekeeper. It seems to install smoothly, but when I run Michael> m3build (as in the tiny example at the front of DOC.dvi) m3c Michael> cannot find the standard interfaces. I wrote> I just did the same thing and got the same problem. Argh! Well, in case y'all were sitting on the edge of your seats, my problem's been fixed. Seems I neglected to build and install libm3. I was fooled into thinking I didn't need it since m3boot had already built it. Thanks to everyone for helping me out. Cheers, dave -- David L. Sims Department of Computer Science sims@cs.ucr.edu University of California +1 (909) 787-6437 Riverside CA 92521-0304 PGP encryption key available on request. USA ======================================================================= 56 === Date: Sat, 26 Feb 1994 12:51:21 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Trestle problems under Linux 0.99pl15 Hello everyone :-). I'm having a bit of trouble with Trestle (and hence FormsVBT) under Linux 0.99pl15. Trestle and FormsVBT compile without errors, and so do programs which use them (I've tried 'Cards', 'Hello Trestle', 'Calculator' and 'Cube'). When I try to run these programs, however, they run successfully for anything from a few to 20 or more seconds, and then crash with a 'Virtual time alarm' error. This (or so gdb and the kernel source tell me) is due to their being sent signal 26 (Virtual time alarm). If I insert a signal handler for SIGVTALRM, Cards and Hello Trestle work fine - I haven't tried with Calculator and Cube because they take ages to build on my platform. I assume that what's happening is that Trestle is setting a timeout, expecting to recieve SIGALRM or something, and is instead recieving what it expects, is getting SIGVTALRM. This is fixable by inserting a null SIGVTALRM handler in whatever package under Trestle (ui, X11R4 or tcp) sets the alarm, but since the alarm is probably supposed to be doing something, that sounds like a silly thing to do. I'd be grateful if someone could tell me what incredibly obvious and stupid thing I'm doing wrong, or provide some sort of bug fix ? Thanks in advance, Richard. ======================================================================= 57 === Date: Mon, 28 Feb 1994 18:30:32 GMT From: mms@dcs.glasgow.ac.uk (Miguel Mira da Silva) Subject: FAQ ? Is there a FAQ for this newsgroup? Thanks, Miguel. -- Miguel Mira da Silva mms@dcs.glasgow.ac.uk ======================================================================= 58 === Date: Mon, 28 Feb 1994 18:22:53 GMT From: 890930g@dragon.acadiau.ca (D. Aaron Gallagher) Subject: a couple of formsVBT/Trestle questions First I'd like to thank everyone who mailed me about the last post. I ended up using a RigidVBT with the FromHV command. (I'd never have found it if I'd been looking by my self) I now have two rather major problems which are stumping me :-( The first seems to be a font problem or something similar. I'm using a JoinVBT to display on several displays and the fonts, menubars and FormsVBT buttons won't show up on the other displays. The buttons are there, because they work when clicked on, but they appear as just a block of the background. Anyone have any ideas ? The other problem has to do with TextEdit windows from FormsVBT. I want to have one come up on just one screen while the JoinVBT window is displayed on several. It installs fine if The JoinVBT window is displayed on only the originating display, but when I try to open more than one display for the JoinVBT, I get the following runtime error message: *** *** runtime error: *** ASSERT failed *** file "Thread.m3", line 575 *** . Again, I'm stumped. I'm specifying the trsl and everything, and it works for and FormsVBT type I've tried except the TextEdit, and TypeIn (and probably the Typescript too). Any help is greatly appreciated! -- ------------------------------------------------------------------------------- Aaron Gallagher, aka 890930g@dragon.acadiau.ca Go ahead and flame. Just remember, I'm on a Dragon. +++++++++++++++++++++++++E-mail at 890930g@acadiau.ca++++++++++++++++++++++++++ ======================================================================= 59 === Date: Mon, 28 Feb 1994 14:14:02 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Trestle problems under Linux 0.99pl15 I have built Trestle on Linux but have not run it yet so i cannot say if it works (my regular machine is at the repair shop and a 4MB 386 does not run well under X11). The SIGVTALARM signal is used for thread scheduling so disabling it will cause you problem eventually. It is not enabled for programs without threads but Trestle uses multiple threads internally (at least that was true for 2.11). -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 60 === Date: 28 Feb 94 18:28:15 -0500 From: Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer) Subject: Where to start Ok, I got the DOS port of Modula-3, I got the Book, I got a computer, where to start? What is a good begining for learning M3? Any suggestions? Tips? Pitfalls? Thanks, Joe