Date: 1 Mar 91 13:52:27 From: sdl@lyra.mitre.org (Steven D. Litvinchouk) Subject: Re: Oberon or Modula-3 Amiga versions ? In article <91059.104102JFS10@psuvm.psu.edu> JFS10@psuvm.psu.edu (Jonathan Swab y) writes: > Are modula-3 or Oberon available for the Amiga? If so where can one > ftp them from? A demo version of a (supported) Oberon compiler for the Amiga, is available on disk number 380 of the "Fred Fish Freely Redistributable Software Library". This may be ftp'ed from ux1.cso.uiuc.edu (128.174.5.59), as the file amiga/fish/ff380/Oberon.zoo (or something like that). That file also explains how to order the supported version of the compiler. -- Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mbunix.mitre.org UUCP: ...{att,decvax,genrad,necntc,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" ------------------------------------------------------------------------------ Date: Tue, 19 Feb 91 13:02:53 -0500 From: Norman Ramsey Subject: Re: Closures in m3 > An even simpler approach would be to use procedures without the REFANY > argument, relying on the ability to make local procedures as the mechanism fo r > binding to other data. The only problem I have with this proposal is that Modula-3 is a functional language, so these local procedures can't escape (be assigned or returned). If I were to use local procedures for enumerations, and if I wanted to perform the same enumeration in two different places, I would have to duplicate the implementation of the local procedure (or write two different local procedures that call a third, fetching the arguments from the closure). Returning an enumeration procedure would be impossible. The advantage of using local procedures is that the closure is allocated on the stack, not the heap, and the language mechanisms do it automatically. Using my proposal, the programmer has to declare the type of the closure and allocate it himself from the heap. > ...[but the > local procedure scheme needs an additional change: the ability to assign loca l > procedures to procedure variables; this is currently forbidden, but no more > unsafe than dereferencing UNTRACED references --- so I don't see why it > shouldn't be equally possible.] Because the local procedures are allocate on the stack, so their closures are allocated on the stack. Assignment to global variables is like returning procedure values: the function ``escapes,'' which means that the closure (free variables) must be allocated on the heap, because a stack-allocated closure would refer to stack locations that have been reused for something else. Imagine > TYPE > WalkProc = PROCEDURE (element: REFANY) RAISES {}; > (* The type of procedures for walking over lists. *) > > PROCEDURE Walk( l: T; p: WalkProc ); PROCEDURE NewSum(start:REFANY; add:PROCEDURE(x,y:REFANY):REFANY): WalkProc = VAR sum := start; PROCEDURE Walk(element:REFANY) RAISES {} = BEGIN sum := add(sum,element); END Walk; BEGIN RETURN Walk; (* or ``walker := walk; RETURN; '' *) END NewSum; Now `Walk' has free variables `sum' and add, but these were allocated to a stack frame that is reclaimed when NewSum returns. > PROCEDURE SumIt( it: List.T ) : INTEGER = > VAR sum: INTEGER; > BEGIN > sum := 0; > List.Walk(it, LAMBDA (element: REFANY) = BEGIN (* add element *) END); > RETURN sum; > END SumIt; This example is OK because the local procedure is passed down the stack. ------------------------------------------------------------------------------ Date: Sunday, 3 Mar 1991 20:28:09 CST From: Shaun Wetzstein Subject: wanted Modula-3 for (MSDOS)? Is it too early or does any one know of a M3 compiler for the PC running MS/PC-DOS? Shaun ------------------------------------------------------------------------------ Date: Mon, 04 Mar 91 08:08:52 PST From: harbison@bert.pinecreek.com Subject: Re: Modula-3 for MSDOS, etc. From: Shaun Wetzstein Subject: wanted Modula-3 for (MSDOS)? Is it too early or does any one know of a M3 compiler for the PC running MS/PC-DOS? Shaun I've been concerned about the lack of a Modula-3 implementation for MSDOS for some time, and I've investigated some approaches to getting one. I'll use the opportunity of Shaun Wetzstein's question to report what I know. The short answer is: No, there aren't any yet. I do know of one or two people who have expressed an intent to port SRC Modula-3 to the PC. I don't know if they have started or how much progress they have made. I don't know if they want their identities released, so I won't name them. A port of SRC Modula-3 to the PC is not straightforward, due to the dependencies on long file names, BSD-style symbolic links, and the generally large size of the implementation. I think the approach would be to first create a UNIX-to-PC cross compiler out of SRC Modula-3, use it to generate a C version of the system, and then try to build it on the PC with a C compiler that can handle large applications. I'm sure there are some eager hackers out there who would like to give it a try. Good for you! If you get it done, I'll certainly publicize it for you. Unfortunately, this will not get you a Modula-3 implementation that is competitive with the very good Pascal, C++, and Modula-2 environments for the PC. That's what I really want to have. I have approached some of the companies that have existing PC environments for other languages, and have discussed licensing and marketing proposals that would turn an existing integrated environment for language X (say, Modula-2 or Pascal with objects) into an integrated Modula-3 environment. (The work could be done either by the company or by a third party.) Preliminary responses were generally positive, with licensing/development fees in the $100K-500K range. This may be a real opportunity for an entrepreneur, but so far I don't believe anyone is pursuing it. [Contact me if you're interested...] I have heard rumors that a company is proceding on this path for a Macintosh implementation of Modula-3. I don't have any more information. An easier and still valuable project would be a port of SRC Modula-3 to one of the PC UNIX environments--SCO, Interactive, Xenix. If you're equipped to do that, go for it! [Send me a note and I'll publicize it...] Sam Harbison; harbison@bert.pinecreek.com Pine Creek Software, Pgh, PA. +1 412 681 9811 ------------------------------------------------------------------------------ Date: Tue, 05 Mar 91 10:54:42 GMT From: Marc Wachowitz Subject: Modula-3 for MS-DOS Recently there was some discussion about porting Modula-3 to MS-DOS. I think it would be nearly impossible to get (derivations of) SRC-M3 working under DOS, or at least it would be nearly useless. It uses very much memory, both at compile and at run time, which is reasonable with virtual memory, but will prevent large programs to be written given the 640 KB barrier of MS-DOS (I don't consider EMS etc. a useful alternative, since its usage as ordinary storage space would be too slow) It should be possible and not even very difficult (but, of course, a good bunch of work :-) to create a new implementation with less overhead, and doing more work at compile/link time than the SRC version. Much of the runtime overhead, especially at startup time, might be done by a specialized linker, which may use temporary files. I guess the most serious problem would be garbage collection. In principle there are three methods, all of which have serious drawbacks: Reference counting cannot cope with cyclic data structures, which makes it pretty useless from my view. Mark&scan methods cause probably unacceptable delays, since they are an all-or-nothing approach. Finally incremental methods, based on copying the whole heap between two or more storage area, usually need a large amount of additional memory, somtimes even twice as much as the raw data. The only way out seem to be generational collectors, which are somewhat difficult to implement. Of course, all these problems should disappear on true 386 operating systems with virtual memory. ------------------------------------------------------------------------------ Date: 6 Mar 91 05:52:08 GMT From: v087mxgb@ubvmsa.cc.buffalo.edu (Shawn E Thompson) Subject: need Modula2 compiler for PC......I know this is Modula3 folder..:-( Hello, I have posted in the Modula2 folder, but it is not as heavily trafficked. Please direct me to a Modula2 package for IBM PC's, preferably like Metrowerks' Mac package... TIA, st ------------------------------------------------------------------------------ Date: 8 Mar 91 16:39:49 GMT From: cheever@sumax.seattleu.edu (Richard L. Cheever) Subject: MOD2 prog compiled by MOD3 ??? Is Modula-3 backwards compatible to Modula-2? In short, can I compile a MOD2 program with a MOD3 compiler, or have things changed that much? Thanks, Richard Cheever cheever@seattleu.edu ------------------------------------------------------------------------------ Date: Fri, 8 Mar 91 11:04:56 PST From: muller@src.dec.com (Eric Muller) Subject: Re: MOD2 prog compiled by MOD3 ??? In article <2415@sumax.seattleu.edu>, Richard L. Cheever asks: > Is Modula-3 backwards compatible to Modula-2? > In short, can I compile a MOD2 program with a MOD3 compiler, or > have things changed that much? That won't work. However, the changes should be small. -- Eric. ------------------------------------------------------------------------------ Date: Fri, 8 Mar 91 19:10:57 PST From: muller@src.dec.com (Eric Muller) Subject: archive of comp.lang.modula3 for February 91 available The articles posted to comp.lang.modula3 during the month of February 91 are availabe via anonymous ftp on gatekeeper.dec.com, in 'pub/DEC/Modula-3/comp.lang.modula3/feb91.Z'. Previous months are also available there. Eric. ------------------------------------------------------------------------------ Date: 8 Mar 91 23:20:08 GMT From: erv@k2.everest.TANDEM.COM (E. R. Videki) Subject: Oberon for MSDOS Available I am making available an Oberon compiler and associated tools for the MSDOS (Intel 80x86) environment. For a short time, this will be provided free to anyone who asks for it via network mail. Oberon, if you don't already know, is the 2nd generation programming language past Pascal (and is the next step past Modula-2). It cleans up most of the difficulties of Modula, while giving a clean, simple way to do just about anything in a type-safe way. The definition comes from Niklaus Wirth, at ETH in Zurich (who of course defined its predecessors). My MSDOS compiler has been in use for 18 months, and has seen no bugs for over a year. It contains the language revisions made by Professor Wirth. Note that this compiler (and its associated library modules) are exclusively for MSDOS; standard object files are generated and theoretically may be linked with other non-Oberon files. Programs written using this package are source compatible with the so-called Oberon System used at ETH Zurich. If you would like the package of compiler, library routines, and some utilities, plus documentation files, contact me: E. R. Videki erv @ k2.everest.tandem.com internet: 130.252.59.153 Distribution is in the form of a single binary file which un-Zips itself into the package when executed under MSDOS (PKZIP format). Our system's rules do not permit someone from outside reaching in to grab the file, so you must provide for me FTP information for me to give it to you (userid, password, directory, and PLEASE make the directory writeable by the userid!) . The file must be moved to a MSDOS machine in BINARY (!!!) and executed in the subdirectory where you want the unzipped files. -- ERV 6 Mar 91 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: 11 Mar 91 10:28:45 GMT From: lupus@fb14vax.sbsvax.uucp (Markus Wolf) Subject: Modula3 on Sun3/60 Hi, is there a Modula3 Compiler for a Sun 3/60 available via ftp. If this question has already occurred in this newsgroup please mail directly. Lupus ------------------------------------------------------------------------------ Date: 11 Mar 91 14:26:49 GMT From: uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges) Subject: X11R4 interface ? Hello ! I wonder wether anyone has written some wrappers for Xlib/Xt. I would be glad if I did not have to reinvent the wheel. Thank You. Rick@vee.lrz-muenchen.de ------------------------------------------------------------------------------ Date: Mon, 11 Mar 91 11:56:12 PST From: muller@src.dec.com (Eric Muller) Subject: Re: X11R4 interface ? In article , Henrik Klagges asks: > I wonder wether anyone has written some wrappers for Xlib/Xt. SRC Modula-3 provides the libm3X{11,t,aw}.a libraries that contain binding interfaces to X11R4. Using a standard installation, just import the appropriate interfaces in your program (see $(PREFIX)/lib/m3/X*); no need to mention the search path for the interfaces, they are built in the driver. To link you program, add the appropriate subset of "-lm3Xaw -lm3Xt -lm3X11"; the driver knows where to find these libraries. -- Eric. ------------------------------------------------------------------------------ Date: Mon, 11 Mar 91 12:57:04 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Modula3 on Sun3/60 In article , Markus Wolf asks: > is there a Modula3 Compiler for a Sun 3/60 available via ftp. You can try SRC Modula-3 1.6beta5 available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/1.6beta. This is a beta release and you have to expect some problems. However, I believe that it is in better shape than 1.5. As far as I know, this is the only available implementation. -- Eric. ------------------------------------------------------------------------------ Date: 11 Mar 91 22:33:48 GMT From: ken@dali.cc.gatech.edu (Ken Seefried iii) Subject: SCO Unix version of DECWRL Modula-3? ----- Now that DEC has some SCO Unix-based product lines, might we see an SCO version of the DECWRL Modula-3 compiler? -- ken seefried iii ken@dali.cc.gatech.edu "If 'ya can't be with the one you love, honey, love the one you're with..." ------------------------------------------------------------------------------ Date: Mon, 11 Mar 91 19:10:33 PST From: muller@src.dec.com (Eric Muller) Subject: Re: SCO Unix version of DECWRL Modula-3? In article <24074@hydra.gatech.EDU>, Ken Seefried iii asks > Now that DEC has some SCO Unix-based product lines, might we see an > SCO version of the DECWRL Modula-3 compiler? Modula-3 has been developped by SRC, not WRL. WRL has a Modula-2 implementation; may be this is what you are refering to ? In any case, SRC Modula-3 hasn't yet been ported to SCO Unix. Anyone who wants to try that is more than welcome. -- Eric. ------------------------------------------------------------------------------ Date: 12 Mar 91 13:37:31 GMT From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Subject: Install Trouble: 1.6b5 on SPARC I am having some trouble installing 1.6beta5 on a SPARC. (1) The sh commands in the Makefile under the target 'config' fail the first time through with the message: 'test: too many arguments'. I believe that this is because the config.0 file has the contents MACHINE = not configured and so the argument $$n in the Makefile expands to two words, as in if test SPARC != not configured which gets test upset. I fixed this by running this statement on my SGI machine instead! (2) There is an error in system/compiler/misc/String.?? which is demonstrated in the following log: chester 288% make system --- driver starting on Tue Mar 12 08:17:16 EST 1991 --- driver done on Tue Mar 12 08:17:18 EST 1991 --- compiler starting on Tue Mar 12 08:17:18 EST 1991 ------ builtinOps starting on Tue Mar 12 08:17:20 EST 1991 ------ builtinOps done on Tue Mar 12 08:17:25 EST 1991 ------ builtinTypes starting on Tue Mar 12 08:17:25 EST 1991 ------ builtinTypes done on Tue Mar 12 08:17:30 EST 1991 ------ builtinWord starting on Tue Mar 12 08:17:31 EST 1991 ------ builtinWord done on Tue Mar 12 08:17:34 EST 1991 ------ exprs starting on Tue Mar 12 08:17:35 EST 1991 ------ exprs done on Tue Mar 12 08:17:43 EST 1991 ------ misc starting on Tue Mar 12 08:17:43 EST 1991 .ROOT/system/driver/m3.bootstrap -D../Interfaces -w1 -g -c String.mc "String.m3", line 189: illegal character: '#' "String.m3", line 189: line undefined "String.m3", line 189: syntax error at or near constant 187 *** Error code 1 make: Fatal error: Command failed for target `String.mo' Current working directory /sgi/usr/src/Lang/Modula-3/dist-1.6beta5/system/compi l er/misc .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `fromC' Current working directory /sgi/usr/src/Lang/Modula-3/dist-1.6beta5/system/compi l er .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `fromC' Current working directory /sgi/usr/src/Lang/Modula-3/dist-1.6beta5/system .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `system' I looked in the appropriate files, and I must admit that I have no idea what is going on! The only thing I can guess is that some parentheses or quoting might be unbalanced, so that it tries to interpret the next #line command in String.mc as part of the text. Any ideas from someone who knows what is going on? P.S. By building a dummy String.mo, I was able to get the rest of the 'system' target to compile -- until the load step, when it needs the String.mo file.... -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET ------------------------------------------------------------------------------ Date: Tue, 12 Mar 91 12:10:30 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Install Trouble: 1.6b5 on SPARC Thanks for your report. > (1) The sh commands in the Makefile under the target 'config' fail the > first time through ... What I have done for 1.6beta6 is to change the target util/config.0 in makefile to echo "not_configured" instead of "not configured". > (2) There is an error in system/compiler/misc/String.?? which is > demonstrated in the following log: > .... The problem is that the String.mc looks like: ... RANGEFAULT ( #line 187 a, b, c) .... and RANGEFAULT is a preprocessor macro. Some cpp do not like the presence of the "#line" in the middle of the macro. I have fixed the compiler. As a fix, you can move "RANGEFAULT (" after the "#line". Eric. ------------------------------------------------------------------------------ Date: 12 Mar 91 21:38:35 GMT From: erv@everest.TANDEM.COM (E. Videki) Subject: Oberon MSDOS (2nd msg) About Oberon for the MSDOS environment (see my message in any of the newsgroups mentioned in the header): I have been deluged with requests for the compiler and libraries. There have been so many requests that I have been only able to reply to a small fraction of them so far. This has forced me to abandon the hope that I can keep direct contact with the few (hah!) Oberon users of my compiler. So, I am setting up a public FTP machine as well as mail-message uuencode format entries to distribute this to all that want it. Please be patient just another day or two, and I'll put out a message on these newsgroups on how to fetch the package yourself. Regards to all and thanks for the interest, Ed Videki -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: Fri, 15 Mar 91 17:56:32 PST From: muller@src.dec.com (Eric Muller) Subject: the fifth change A few months ago, Greg Nelson posted an article describing twelve changes that will be made to the language defined by the revised report (he did not say what the name of the new report will be). The fifth of these changes is: 1.5 The semantics of method overrides supplied at NEW time will be defined by the following rewriting: NEW( T, m := P ) is sugar for NEW( T OBJECT OVERRIDES m := P END ). I think that the sugaring should be removed. My observation is that I am not allowed to write: TYPE U = T, m := P; but I have to write: TYPE U = T OBJECT OVERRIDES m := P END; This means that the sugaring is allowed not on its own value but for historical reasons. I believe that the Modula-3 history is still short enough that the cost of changing existing code will be compensated by the cleaner language. Furthermore, NEW (T OBJECT OVERRIDES m := M END, p := P) where p is a method of T is really confusing. -- Eric. ------------------------------------------------------------------------------ Date: Fri, 15 Mar 91 22:37:13 PST From: muller@src.dec.com (Eric Muller) Subject: Modula-3 binding for Tcl [ For tcl-oriented readers: Modula-3 is a programming language developed by Digital Equipment SRC and Olivetti. Send me a message if you want more info, or join the comp.lang.modula3 newsgroup. ] [ For Modula-3-oriented readers: tcl is a simple command language; you can embed tcl interpreters in programs. There is also an associated X toolkit. Send me a message if you want more info, or join the tcl mailing list (tcl-request@sprite.berkeley.edu). ] I played with tcl and being a Modula-3 fanatic I made a binding interface. The shar file below contains TclC.i3 and Test.m3, a simple test program. Test.m3 defines the "fact" command (implemented in Modula-3) and repeatedly reads stdin to feed an interpreter and sends its output to stdout. This interface is a "raw" interface. It maps directly the C world. I will probably work on a "nice" interface, using Text.T rather than C.char_star and so on. Another thing would be a TclWriter.T, created on top of another Wr.T; when tcl commands are fed into this TclWriter, it writes the result of the evaluation on its underlying Wr.T. Suggestions are welcome. While doing this exercise, I discovered the following details about the tcl man pages: - Tcl_AddErrorInfo: returns void (instead of char*) - Tcl_AppendResult: interp is an in argument (instead of out) - Tcl_Eval: flags is an int (instead of char) - Tcl_RecordAndEval: idem - Tcl_GetInt: TCL_OK and TCL_ERRROR are in roman (instead of bold) Thanks to John for this great little tool, Eric. ---- Cut Here and unpack ---- #!/bin/sh # This is a shell archive (shar 3.32) # made 03/16/1991 06:28 UTC by muller@procope.pa.dec.com # Source directory /flimflam/dlusers2/muller/src/Tk/m3 # # existing files WILL be overwritten # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 5976 -rw-r--r-- TclC.i3 # 1880 -rw-r--r-- Test.m3 # if touch 2>&1 | fgrep 'amc' > /dev/null then TOUCH=touch else TOUCH=true fi # ============= TclC.i3 ============== echo "x - extracting TclC.i3 (Text)" sed 's/^X//' << 'SHAR_EOF' > TclC.i3 && X(* Copyright (C) 1991, Digital Equipment Corporation *) X(* All rights reserved. *) X X(* Last modified on Sat Mar 16 07:37:04 1991 by muller *) X X X(* This file has been derived from tcl.h, covered by the following copyright: X X * Copyright 1987, 1990 Regents of the University of California X * Permission to use, copy, modify, and distribute this X * software and its documentation for any purpose and without X * fee is hereby granted, provided that the above copyright X * notice appear in all copies. The University of California X * makes no representations about the suitability of this X * software for any purpose. It is provided "as is" without X * express or implied warranty. X *) X XUNSAFE INTERFACE TclC; X XFROM Ctypes IMPORT char_star, int_star, int, char, double; XIMPORT Word; X XCONST X TCL_OK = 0; X TCL_ERROR = 1; X TCL_RETURN = 2; X TCL_BREAK = 3; X TCL_CONTINUE = 4; X X BRACKET_TERM = 1; X NO_EVAL = -1; X X STATIC = 0; X DYNAMIC = 1; X VOLATILE = 2; X X TRACE_READS = 1; X TRACE_WRITES = 2; X TRACE_DELETES = 4; X X VARIABLE_UNDEFINED = 8; X X XTYPE X Argv = UNTRACED REF ARRAY [0..255] OF char_star; X Interp = UNTRACED REF RECORD X result: char_star; (* Points to result string returned by X command. *) X dynamic: int; (* Non-zero means result is dynamically- X allocated and must be freed by Eval X before executing the next command. *) X errorLine: int; (* When TCL_ERROR is returned, this gives X the line number within the command where X the error occurred (1 means first line). *) X END; X X ClientData = Word.T; X X X X<*EXTERNAL Tcl_AddErrorInfo *> XPROCEDURE AddError (interp: Interp; message: char_star); X X<*EXTERNAL Tcl_AppendResult *> XPROCEDURE AppendResult (interp: Interp; s1, s2, s3, s4, s5: char_star := NIL); X XTYPE X CmdBuf = int_star; X X<*EXTERNAL Tcl_CreateCmdBuf *> XPROCEDURE CreateCmdBuf (): CmdBuf; X X<*EXTERNAL Tcl_DeleteCmdBuf *> XPROCEDURE DeleteCmdBuf (buffer: CmdBuf); X X<*EXTERNAL Tcl_AssembleCmd *> XPROCEDURE AssembleCmd (buffer: CmdBuf; string: char_star): char_star; X X<*EXTERNAL Tcl_Backslash *> XPROCEDURE Backslash (src: char_star; VAR count: int): char; X X<*EXTERNAL Tcl_Concat *> XPROCEDURE Concat (argc: int; argv: Argv): char_star; X XTYPE X CommandProc = PROCEDURE (clientData: ClientData; X interp: Interp; X argc: int; X argv: Argv): int; X X DeleteProc = PROCEDURE (clientData: ClientData); X X<*EXTERNAL Tcl_CreateCommand *> XPROCEDURE CreateCommand (interp: Interp; X cmdName: char_star; X proc: CommandProc; X clientData: ClientData; X deleteProc: DeleteProc); X X<*EXTERNAL Tcl_CreateInterp *> XPROCEDURE CreateInterp (): Interp; X XTYPE X TraceProc = PROCEDURE (clientData: ClientData; X interp: Interp; X level: int; X command: char_star; X cmdProc: CommandProc; X cmdClientData: ClientData; X argc: int; X argv: Argv); X Trace = int_star; X X<*EXTERNAL Tcl_CreateTrace *> XPROCEDURE CreateTrace (interp: Interp; X level: int; X proc: TraceProc; X clientData: ClientData): Trace; X X<*EXTERNAL Tcl_DeleteCommand *> XPROCEDURE DeleteCommand (interp: Interp; cmdName: char_star); X X<*EXTERNAL Tcl_DeleteInterp *> XPROCEDURE DeleteInterp (interp: Interp); X X<*EXTERNAL Tcl_DeleteTrace *> XPROCEDURE DeleteTrace (interp: Interp; trace: Trace); X X<*EXTERNAL Tcl_Eval *> XPROCEDURE Eval (interp: Interp; X cmd: char_star; X flags: int; X termPtr: Argv): int; X X<*EXTERNAL Tcl_Expr *> XPROCEDURE Expr (interp: Interp; string: char_star; VAR value: int): int; X X<*EXTERNAL Tcl_GetInt *> XPROCEDURE GetInt (interp: Interp; string: char_star; VAR val: int): int; X X<*EXTERNAL Tcl_GetDouble *> XPROCEDURE GetDouble (interp: Interp; string: char_star; VAR val: double): int; X X<*EXTERNAL Tcl_GetBoolean *> XPROCEDURE GetBoolean (interp: Interp; string: char_star; VAR value: int): int; X X<*EXTERNAL Tcl_GetVar *> XPROCEDURE GetVar (interp: Interp; varName: char_star; global: int): char_star; X X<*EXTERNAL Tcl_Merge *> XPROCEDURE Merge (argc: int; argv: Argv): char_star; X X<*EXTERNAL Tcl_ParseVar *> XPROCEDURE ParseVar (interp: Interp; X string: char_star; X term: Argv): char_star; X X<*EXTERNAL Tcl_RecordAndEval *> XPROCEDURE RecordAndEval (interp: Interp; cmd: char_star; flags: int): int; X X<*EXTERNAL Tcl_Return *> XPROCEDURE Return (interp: Interp; string: char_star; status: int); X X<*EXTERNAL Tcl_SetVar *> XPROCEDURE SetVar (interp: Interp; varName, newValue: char_star; global: int); X X<*EXTERNAL Tcl_SplitList *> XPROCEDURE SplitList (interp: Interp; X list: char_star; X VAR argc: int; X VAR argv: Argv): int; X X<*EXTERNAL Tcl_StringMatch *> XPROCEDURE StringMatch (string, pattern: char_star): int; X X<*EXTERNAL Tcl_TildeSubst *> XPROCEDURE TildeSubst (interp: Interp; name: char_star): char_star; X XTYPE X VarTraceProc = PROCEDURE (clientData: ClientData; X interp: Interp; X varName: char_star; X global, flags: int; X oldValue, newValue: char_star): char_star; X X<*EXTERNAL Tcl_TraceVar *> XPROCEDURE TraceVar (interp: Interp; X varName: char_star; X global, flags: int; X proc: VarTraceProc; X clientData: ClientData): int; X X<*EXTERNAL Tcl_UnTraceVar *> XPROCEDURE UnTraceVar (interp: Interp; varName: char_star; global: int); X X<*EXTERNAL Tcl_VarTraceInfo *> XPROCEDURE VarTraceInfo (interp: Interp; X varName: char_star; X global: int; X VAR proc: VarTraceProc; X VAR clientData: ClientData): int; X XEND TclC. SHAR_EOF $TOUCH -am 0315222891 TclC.i3 && chmod 0644 TclC.i3 || echo "restore of TclC.i3 failed" set `wc -c TclC.i3`;Wc_c=$1 if test "$Wc_c" != "5976"; then echo original size 5976, current size $Wc_c fi # ============= Test.m3 ============== echo "x - extracting Test.m3 (Text)" sed 's/^X//' << 'SHAR_EOF' > Test.m3 && X(* Copyright (C) 1991, Digital Equipment Corporation *) X(* All rights reserved. *) X X XUNSAFE MODULE Test EXPORTS Main; X XIMPORT TclC; XIMPORT Rd, Wr, Stdio, Fmt; XFROM M3toC IMPORT TtoS, CopyTtoS, CopyStoT; XFROM Ctypes IMPORT int, char_star; X XPROCEDURE FactCmd (<*UNUSED*> clientData: TclC.ClientData; X interp: TclC.Interp; X argc: int; X argv: TclC.Argv): int = X BEGIN X IF argc # 2 THEN X interp.result := TtoS ("fact has exactly one argument"); X RETURN TclC.TCL_ERROR; X ELSE X VAR i: INTEGER; BEGIN X IF TclC.GetInt (interp, argv[1], i) = TclC.TCL_ERROR THEN X RETURN TclC.TCL_ERROR; END; X interp.result := CopyTtoS (Fmt.Int (Fact (i))); X RETURN TclC.TCL_OK; END; END; X END FactCmd; X XPROCEDURE Fact (i: INTEGER): INTEGER = X BEGIN X IF i = 1 THEN X RETURN 1; X ELSE X RETURN i * Fact (i - 1); END; X END Fact; X X XVAR X i: TclC.Interp; X buf: TclC.CmdBuf; X s: char_star; X status: int; X XBEGIN X i := TclC.CreateInterp (); X TclC.CreateCommand (i, TtoS ("fact"), FactCmd, 0, NIL); X buf := TclC.CreateCmdBuf (); X X TRY X LOOP X s := TclC.AssembleCmd (buf, TtoS (Rd.GetLine (Stdio.stdin) & "\n")); X IF s # NIL THEN X status := TclC.Eval (i, s, 0, NIL); X CASE status OF X | TclC.TCL_OK => X Wr.PutText (Stdio.stderr, "-> " & CopyStoT (i.result) & "\n"); X | TclC.TCL_ERROR => X Wr.PutText (Stdio.stderr, "error: " & CopyStoT (i.result) & "\n"); X ELSE X Wr.PutText (Stdio.stderr, "TclC.Eval returned with code = " X & Fmt.Int (status) & "\n"); X END; END; END; X EXCEPT X | Rd.EndOfFile => END; X X TclC.DeleteCmdBuf (buf); X TclC.DeleteInterp (i); XEND Test. SHAR_EOF $TOUCH -am 0315222691 Test.m3 && chmod 0644 Test.m3 || echo "restore of Test.m3 failed" set `wc -c Test.m3`;Wc_c=$1 if test "$Wc_c" != "1880"; then echo original size 1880, current size $Wc_c fi exit 0 ------------------------------------------------------------------------------ Date: 18 Mar 91 21:01:17 GMT From: jbtubman@arc.ab.ca (Jim Tubman) Subject: Looking for Modula-3 Report Source I've obtained the Modula-3 report in PostScript form (Report.ps) but it won't print out on our QMS or Apple PostScript laser printers. Is the report available in TeX or troff source form from some FTP site? --Jim Tubman -- ------------------------------------------------------------------------------- James B. Tubman Alberta Research Council Expert Systems Researcher Advanced Computing & Engineering Dept. jbtubman@noah.arc.ab.ca 3rd Floor ------------------------------------------------------------------------------ Date: Tue, 19 Mar 91 15:04:05 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Looking for Modula-3 Report Source In article <1991Mar18.210117.13060@arc.ab.ca>, jbtubman@arc.ab.ca (Jim Tubman) writes: > I've obtained the Modula-3 report in PostScript form (Report.ps) but > it won't print out on our QMS or Apple PostScript laser printers. Is > the report available in TeX or troff source form from some FTP site? No, but you can send a message to src-report@src.dec.com to get a paper version. -- Eric. ------------------------------------------------------------------------------ Date: Tue, 19 Mar 91 15:06:20 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 1.6beta7 available A new beta release (beta7) of SRC Modula-3 1.6 is available via anonymous ftp on gatekeeper.dec.com, in pub/DEC/Modula-3/m3-1.6beta. The 1.6 release should occur sometime next week, and I don't expect that it will be different from this beta (except for corrections to the bugs in this beta release that are reported this week). This release is an improvement over 1.5 and should be used rather than 1.5. In addition to a bunch of fixes, this release introduces two new architectures: UMAX Encore Multimax UMAX 4.3 (R4.1.1) ARM Acorn R260 RISC iX 1.21 Thanks to R.J. Stroud and Dick Snow for these ports. This is the first integration of these ports to the SRC Modula-3 1.6. I suppose that I introduced a small number of problems while doing this integration, so please bear with me. -- Eric. ------------------------------------------------------------------------------ Date: Wed, 20 Mar 91 16:46:16 GMT From: erv@everest.TANDEM.COM (E. Videki) Subject: Oberon for MSDOS Many people have been asking how to get my Oberon package for the MSDOS environment. Last week I sent a ZIP form to SIMTEL20, and it is available under FTP from pd1: . Additionally, I prepared last week a long messages with Questions and Answers that I'd been receiving. This was send to comp.compilers, comp.lang.modula2, comp.lang.modula3, and comp.archives. Maybe the backbones are running slow, but the messages aren't in the newsgroups yet. I've contacted some people to try and find out why. Also last week, the Oberon package was prepared in uuencode format (5 messages, all under 50K to meet most mail requirements) for the comp.compilers and comp.binaries.ibm.pc newsgroups. Again, they are not yet there, and I'm trying to find where they are. Finally, UCSD is placing a copy on their public machine in the next day or so. They (and I) will announce when it is available. This will be for anonymous FTP. To all the people interested in getting this package, the number of requests for it has been so large that only by public FTP or uuencode-download at the requestor's convenience will I be able to satisfy most requests. So, please keep watching these newsgroups. Both FTP and uuencode formats should be widely distributed here soon, or you can go to those alternate sources I mentioned. --Regards, E. Videki [Comp.compilers is not the place for large chunks of code, I expect it'll appear in comp.binaries.ibm.pc in due course. -John] -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: 26 Mar 91 18:08:34 GMT From: dme@ely.cl.cam.ac.uk (David Evers) Subject: Motif Widget Set Interfaces for Modula-3 I'm considering constructing a Modula-3 interface to the Motif widget set, in the style of libs/Xaw/X11R4/Xaw.i3 in the Modula-3 distribution from DEC SRC. Before I re-invent the wheel, has anyone out there already done this? If so, could I have a copy? If not, does anyone (eg. the SRC Modula-3 implementers) have the awk script/sed script/bit of code/whatever that was used to generate Xaw.i3 from /usr/include/Xaw/*.h ? I can't believe it was done entirely by hand... :-). If Xm.i3 ever gets built, I'll try and make it available to the net somehow (perhaps in a future SRC M3 distribution?). Thanks, ---- Dave. [David Evers Janet: dme@uk.ac.cam.cl Computer Laboratory (T76) Inet: dme%cl.cam.ac.uk@nsfnet-relay.ac.uk University of Cambridge UUnet: ...!uunet!mcvax!ukc!cam-cl!dme Corn Exchange Street Cambridge CB2 3QG U.K. Phone: +44 223 334639 ] ------------------------------------------------------------------------------ Date: Wed, 27 Mar 91 16:38:04 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Motif Widget Set Interfaces for Modula-3 In article <1991Mar26.180834.29742@cl.cam.ac.uk>, dme@ely.cl.cam.ac.uk (David E vers) writes: > I'm considering constructing a Modula-3 interface to the Motif > widget set, in the style of libs/Xaw/X11R4/Xaw.i3 in the Modula-3 > distribution from DEC SRC. Before I re-invent the wheel, has > anyone out there already done this? We started some work in that area, but we haven't had the time to finish. > If so, could I have a copy? > If Xm.i3 ever gets built, I'll try and make it available to the > net somehow (perhaps in a future SRC M3 distribution?). There is a little problem of copyright. Theses interfaces are basically translation in Modula-3 of Motif software; our current understanding is that the original copyright applies to these translations as well. (For the X interfaces, this was not a problem are the copyright comes with a licence that allows redistribution). We'll try to figure out the details there and follow-up to this newsgroup with whatever we learn. > If not, does anyone (eg. the SRC Modula-3 implementers) have the > awk script/sed script/bit of code/whatever that was used to generate > Xaw.i3 from /usr/include/Xaw/*.h ? I can't believe it was done > entirely by hand... :-). Unfortunately, the X includes files are not clean enough to support a near-complete automatic translation. If you look carefully, you will discover that the Modula-3 bindings are more precise than the X include files (that's one of the benefits of type checking). -- Eric. ------------------------------------------------------------------------------ Date: 27 Mar 91 22:56:44 GMT From: nr@elan.Princeton.EDU (Norman Ramsey) Subject: access to command line arguments Now that M3toC has become UNSAFE, it would be pleasant to include in RTMisc a VAR argv : REF ARRAY OF TEXT; for those of us who want safe access to command-line arguments (and who don't want to fool with ParseParams). -- Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: 27 Mar 91 16:43:18 GMT From: nr@atomic.Princeton.EDU (Norman Ramsey) Subject: making pickles smaller I have a program that is generating pickles that are too large. I can imagine two strategies for making them smaller: a) increasing sharing b) where sharing is unimportant, using WriteBytesProc and ReadBytesProc As an example of the first stragety, since TEXTs are supposed to be immutable, I would like to store a single REF for both s and t whenever TYPECODE(s)=TYPECODE(TEXT) AND TYPECODE(s)=TYPECODE(TEXT) AND Text.Equal(s,t) I suspect that this change would realize a substantial savings in my particular pickles, but I can't think of any way of using ConvertProcs to implement this strategy using the current Pkl interface. By the time I know I have a TEXT, it's too late to change it. Trying to find all the TEXT-containing REF types might be very painful. I might apply the second strategy to the type REF CHAR, resulting in a savings of four bytes per value pickled. Question 1: are there any general techniques that can be used to increase sharing, so that distinct references that point to isomorphic structures are merged into a single reference? Question 2: how can I dissect a pickle to determine which types are responsible for the most space usage? Are there any tools? -- Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: Thu, 28 Mar 91 13:38:47 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 1.6 available SRC Modula-3 ------------ A new release, version 1.6, of the SRC Modula-3 compiler and runtime are available now. This is the fourth public release of SRC Modula-3. The system was developed at the DEC Systems Research Center. It is being distributed in source form (mostly Modula-3) and is available for public ftp. You must have a C compiler to build and install the system. NEW IN THIS RELEASE ------------------- The primary changes since version 1.5 are: - many bugs are fixed (in particular, installation bugs) - additional library modules (more U**X bindings, pickles) - it is easier to build shared libraries (by default on IBMR2) - the system was ported to: SUN3 running SunOS Encore Multimax running UMAX 4.3 (R4.1.1) Acorn R260 running RISC iX 1.21 in addition to the previous ports: Apollo DN4500 running Domain/OS, IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, HP 9000/300 running HP-UX 8.0 VAX running Ultrix 3.1 DECstation 3100 and 5100 running Ultrix 3.1 SPARCstation running SunOS 4.0.3 DISTRIBUTION ------------ The system is available: - via anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2], - via uucp from decwrl - via Easynet from DECWRL Due to limited resources, we cannot distribute SRC Modula-3 in any other form. The SRC Modula-3 files are in '/pub/DEC/Modula-3'. Those files include: % ls -R README m3-1.6 report comp.lang.modula3 comp.lang.modula3: README aug90.Z dec90.Z feb91.Z jan91.Z jun90.Z may90.Z oct90.Z apr90.Z dec89.Z feb90.Z jan90.Z jul90.Z mar90.Z nov90.Z sep90.Z m3-1.6: README dist-1.6.tar.Z-02 dist-1.6.tar.Z-05 dist-1.6.tar.Z-08 dist-1.6.tar.Z dist-1.6.tar.Z-03 dist-1.6.tar.Z-06 dist-1.6.tar.Z-09 dist-1.6.tar.Z-01 dist-1.6.tar.Z-04 dist-1.6.tar.Z-07 report: README Report.ps.Z Report1.ps.Z Report2.ps.Z Report3.ps.Z The compressed tar file dist-1.6.tar.Z is about 4.6Mbytes. The entire system requires about 35Mbytes of disk space to build and install. CONDITIONS ---------- SRC Modula-3 is not a Digital Equipment Corporation product. It is a research work which is provided ``as is''. We do not promise to fix bugs, but we will try. SRC Modula-3 is available without signing any license agreements. If you chose to sign the commercial license, you will be able to use SRC Modula-3 commercially. See the documents that are included in the release for more information. WHAT IS SRC MODULA-3 ? ---------------------- SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. KEEPING IN TOUCH ---------------- If you want to communicate with other Modula-3 users, you can post articles to the comp.lang.modula3 Usenet newsgroup. If you do not have access to this newsgroup, you can send a message to m3-request@src.dec.com to be added to the relay mailing list. Messages sent to m3@src.dec.com are forwarded to the newsgroup and to the members of the relay mailing list. If you want to communicate with us, please send your message to m3-request@src.dec.com We may also be reached at: Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 Enjoy, Bill Kalsow and Eric Muller REFERENCES ---------- [1] The Modula-3 Report (Revised), L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89. VAX, DECstation and ULTRIX are registered trademarks of Digital Equipment Corporation. Unix is a registered trademark of AT&T Corporation. SPARC and SunOS are trademarks of Sun MicroSystems. Apollo and Domain/OS are trademarks of Apollo. IBM and AIX are registered trademarks of International Business Machines Corporation. RT and PS/2 are trademarks of International Business Machines Corporation. HP, HP9000 and HP9000/300 are trademarks of Hewlett-Packard Company. HP-UX is Hewlett-Packard's implementation of the Unix operating system. PostScript is a registered trademark of Adobe Systems Incorporated. ------------------------------------------------------------------------------