======================================================================= 1 === Date: Tue, 1 Dec 92 16:37:20 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Need expert help w/ re: to generics Your problem is in Queue.mg where you wrote: > REVEAL T = Public_T BRANDED OBJECT > ... > METHODS > enqueue(x : Elem.T) := Enqueue; > dequeue(): Elem.T RAISES {QueueEmpty} := Dequeue; > head(): Elem.T RAISES {QueueEmpty} := Head; > tail(): Elem.T RAISES {QueueEmpty} := Tail; > find(x : Elem.T): QueueElem RAISES {NotInQueue, QueueEmpty} := F ind; > length(): CARDINAL := Length; > isempty(): BOOLEAN := IsEmpty; > END; What you meant was: > REVEAL T = Public_T BRANDED OBJECT > ... > OVERRIDES > enqueue := Enqueue; > dequeue := Dequeue; > head := Head; > tail := Tail; > find := Find; > length := Length; > isempty := IsEmpty; > END; You created a second set of methods inside the implementation, but your main program was calling the methods defined in the interface. The original methods defined in the interface were never given implementations. - Bill Kalsow ======================================================================= 2 === Date: 1 Dec 92 21:03:08 GMT From: Roland.Radtke@arbi.informatik.uni-oldenburg.de (Roland Radtke) Subject: Where do I get it (FAQ) Well, I suppose the summary says it all. Sorry to bother all of you, but since there ain't no FAQ, I don't see any alternative. rrrrrrrradtke, the utterly, utterly combusted. Ah,... make that fused. CONfused. ======================================================================= 3 === Date: 1 Dec 92 21:12:52 GMT From: moss@cs.cmu.edu (Eliot Moss) Subject: GNU Modula-3 help request A number of people have indicated willingness to help with the development of GNU Modula-3 (gm3). Given the difficulties of educating and coordinating with a distributed collection of people hacking the guts of a production compiler, we have generally indicated that there is not much others can do to help. However, now that the system is nearing Alpha release there are several things that others can help us accomplish: 1) Alpha testers: We need one or more Alpha testers. The Alpha release will be for VAX/Ultrix (the reasons are historical; we realize this is not now the most interesting target), and will not support thread forking (but will have minimal support for MUTEX and LOCK so that one can use single threaded thread-safe code, as appears in the IO libraries). The debugging support is fairly primitive: gdb allows breakpoints (by procedure and line) and source code display, but there is no access to variables by name, and no support for Modula-3 expression evaluation (see related request below). We anticipate the Alpha release will be ready for testing at the end of January 1993. 2) Ports: We expect to work on a MIPS port in short order, and possibly an Digital Alpha port. Especially welcome would be SPARC and MSDOS (386/486) hackers, though many other machines would be interesting too. The gm3 compiler is essentially gcc adjusted to compile Modula-3 rather than C; it produces optimized assmebly code. Porting should require only incremental effort if a gcc port already exists, but gcc porting/building experience will undoubtedly be helpful. 3) Debugging support: There are several extensions needed for gdb to support gm3 really well. One is for gm3 to produce the appropriate debugger symbol table information, which itself needs to be extended to handle Modula-3's additional types. Another is for gdb to accept and evaluate Modula-3 expressions. A third is support for debugging multiple threads, presumably by being able to list the various threads, and to change the "current thread" being debugged (which gives one a stack context, etc.). Any interested parties should send email to me (Eliot Moss, moss@cs.umass.edu) and/or to Rick Hudson (hudson@cs.umass.edu). I am the professor overseeing the project (from afar; I'm on sabbatical at Carnegie Mellon this year), and Rick is the staff programmer doing a lot of the real work. Thanks to all for their continued encouragement and support! -- J. Eliot B. Moss, Associate Professor Visiting Associate Professor Department of Computer Science School of Computer Science Lederle Graduate Research Center Carnegie Mellon University University of Massachusetts 5000 Forbes Avenue Amherst, MA 01003 Pittsburgh, PA 15213-3891 (413) 545-4206, 545-1249 (fax) (412) 268-6767, 681-5739 (fax) Moss@cs.umass.edu Moss@cs.cmu.edu ======================================================================= 4 === Date: Tue, 1 Dec 1992 13:31:28 PST From: David Goldberg Subject: Re: Need expert help w/ re: to generics The essence of your example is this: Given declarations (possibly not all in the same file) Public = OBJECT METHODS proc():= X1; END; T <: OBJECT REVEAL T = Public BRANDED OBJECT METHODS proc() := X2; END; what is NEW(T).proc? If the revelation is visible to NEW(), then the answer is X2, otherwise X1. In your program, the revelation is not visible, X1 was NIL, hence the error. Although this is the only interpretation of NEW(T) for opaque objects T that makes sense, I didn't see it explicitly stated in the Modula-3 report. Did I miss something? -david ======================================================================= 5 === Date: Tue, 01 Dec 92 18:01:03 PST From: bhayes@CS.Stanford.EDU Subject: Meta-key events and Trestle I use the vtwm window manager and navigate using [shades of Lisp machines!] meta-control-arrow to jump around on my desktop. However, when the focus is in an m3 application using Trestle, the events are eaten by the application and not passed up to the window manager. This seems to be what Trestle does, and it is annoying. Any chance for a change, or at least a good reason it has to be that way? -b ======================================================================= 6 === Date: Wed, 2 Dec 92 18:59:18 GMT From: stilley@csr.UVic.CA (Scott Tilley) Subject: Help installing Modula-3 on RS/6000 Can some kind soul please provide me with the required hints and tips to get the Modula-3 compiler from gatekeeper.dec.com installed and running on RS/6000 running AIX 3.2. Here are some of the problems I have encountered: - modify imake.c to include AIX as "stripping whitespaces" kludge so that the generated m3makefiles will work - edit M3Machine.h in ./compiler and ./driver to remove the "volatile" keyword from _IMPORT, _EXPORT, etc; xlc complains After this, m3 gets built, but won't run. It complains "looking for libc.a and libbsd.a". If I link those libraries into the same directory as m3 (via "ln -s /usr/lib/libc.a", etc) it either runs and crashes in runtime, or gripes about "option -z3 unknown". Aarg! This install is getting aggravating. The install for sun4 went (reasonably) smooth. Help! ..Scott ======================================================================= 7 === Date: 2 Dec 92 19:51:59 GMT From: dmb@srl02.cacs.usl.edu (David M. Brumley) Subject: I can't compile my Color interface! I recently installed the latest version of libm3 (libm3-2.07.tar.Z in the gatekeeper.dec.com release directory), and now I can't compile one of my programs. I get the following error when I run m3make: cd /u11/dmb/src/MERLIN/Src/ m3make /usr/local/modula3/bin/m3 -make -why -w2 -g -o merlin -F.PGM_SOURCES stale imports -> compile ./Color.i3 duplicate Color.i3: in ./Color.i3 and /usr/local/modula3/lib/libm3.a Fatal Error: bad version stamps Fatal Error: bad version stamps *** Error code 255 Stop. It seems that the new version of libm3 defines a Color interface, as does my program, and the compiler|linker is getting confused. How do I get the driver to ignore the libm3 Color interface and compile my own? Setting the -nostd option in M3FLAGS allows the interface to compile, but of course, prevents the program from linking with the standard library. Also, various incantations of the "-Ddefpath" ("-D.", "-D -D.", "-D.:/usr/local/modula3/include" etc..) option have no effect. FYI: DS5000/200, Ultrix 4.2a, boot.DS3100-2.07.tar.Z Apologies if this is a stupid question. ======================================================================= 8 === Date: Wed, 2 Dec 1992 18:42:19 -0500 From: rhoover@watson.ibm.com (Roger Hoover) Subject: Re: Help installing Modula-3 on RS/6000 >Can some kind soul please provide me with the required hints and >tips to get the Modula-3 compiler from gatekeeper.dec.com installed >and running on RS/6000 running AIX 3.2. Here are some of the problems I >have encountered: Which version are you trying to bring up? I've ported m3 to aix 3.2 and I believe that these changes have been added to version 2.10 in the test directory on gatekeeper. Bring it up and let me know if anything fails. It should work out of the box. roger hoover rhoover@watson.ibm.com (I'd like to try this myself, but gatekeeper refuses to talk to me when I anonymous ftp: 220 gatekeeper.dec.com FTP server (Version 5.83 Sat Sep 19 18:47:23 PDT 1992) r e ady. ftp> u anonymous 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> dir 200 PORT command successful. ftp: bind Can't assign requested address ftp> Anyone else have this problem?) ======================================================================= 9 === Date: Fri, 4 Dec 92 01:49:28 GMT From: Eric Muller Subject: Re: Can't use trestle In article <44262@imag.imag.fr>, chevalet@imag.fr (Chevallet Jean-Pierre) write s: |> I've install the 2.07 version of SRC Modula3 : it`s seems to work |> fine except for the trestle library. |> The use of the given make file produce : |> |> boole [76] ~/Modula-3/trestle/apps> m3make -f m3makefile.old |> /users1/enseigt/chevalet/Modula-3/bin/m3 -w1 -make -why -g |> -D/users1/enseigt/chevalet/Modula-3/include/m3 -commands -o Hello Hello.m3 |> ../mips/libm3ui.a -lm3X11R4 -lX11 |> inhale ../mips/libm3ui.a |> inhale /users1/enseigt/chevalet/Modula-3/lib/m3/libm3X11R4.a |> inhale -lX11 |> inhale /users1/enseigt/chevalet/Modula-3/lib/m3/libm3.a |> inhale -lm |> missing interface "Trestle" imported by: |> Hello.m3 |> missing interface "TextVBT" imported by: |> Hello.m3 The apps subdir in trestle contains only test programs for the developpers. And they work on 'mips' machines (i.e. DECstations), so they have built that in the m3makefile. You can fix it by replacing all occurrences of 'mips' by '$(CPU_TYPE)', and it should work better. I suppose that will also help to locate correctly the X11 libraries (assuming your config file is ok). By the way, you realize that you need X11 (R4 or R5) to run trestle ? -- Eric. ======================================================================= 10 === Date: Fri, 4 Dec 1992 13:51:25 GMT From: werner@cs.sun.ac.za (Werner Fouche) Subject: Modula-3 on 386/SVR4 Unix? Has anyone done a port of SRC-Modula-3 to 80386-based computers running SVR4 Unix? If an M3 port does not exist, I would like to compile the AIX distribution of SRC-Modula-3 for SVR4 Unix, will that work? If no implementation of Modula-3 for SVR4 Unix exists I may have to port the DEC-SRC-Modula-3 compiler. How portable is the compiler? How long do you think it will take to port the compiler? I have read the release notes of the compiler and it sounds to me that one should be able to port the compiler with hopefully little effort! Where can I find either commercial or public domain Modula-3 interfaces for Motif? Thank you very much. Werner Fouche' University of Stellenbosch Stellenbosch, 7600 Republic of South Africa ======================================================================= 11 === Date: Fri, 4 Dec 92 11:14:13 EST From: Benoit Desrosiers Subject: smallest possible system I have the m3 compiler installed on my system and I want to know which files ar e really needed to have a working compiler. I need this information because my hard disk is full... Also, I compiled the small example given in the documentation (hello world) and I got a 1Mb file, is it normal or do I have to tell the compiler to optimize s omething. thank's Benoit Desrosiers Universite du Quebec a Hull Hull, Quebec, Canada ======================================================================= 12 === Date: Fri, 4 Dec 1992 17:34:40 GMT From: neurogen@reks.uia.ac.be (Neurogenetica) Subject: m3 on PC(286 or up) Hello m3 world, I'm new to this news system so don't kill me, kill the pianist instead, if I ask questions that are supposed to be common knowledge. 1. Where can I get a m3-compiler for the PC running under DOS 2. If not under DOS, can I run UNIX on a 286-PC to use the UNIX-based m3 compilers? Thats all folks, SGR aka Geert Raes neurogen@reks.uia.ac.be ======================================================================= 13 === Date: Fri, 4 Dec 92 18:16:52 GMT From: Eric Muller Subject: Re: smallest possible system In article <9212041617.AA09425@Amnesix.UQSS.UQuebec.CA>, Benoit Desrosiers writes: |> I have the m3 compiler installed on my system and I want to know |> which files are really needed to have a working compiler. |> I need this information because my hard disk is full... Say you have unpacked the archives in /usr/local/src/m3, and you have configured to install the files in /usr/local/{bin,man,lib}: you can delete all of /usr/local/src/m3, you need to keep only the installed files. Of course, if you do not plan to use an archive, you don't need to build/install it. |> Also, I compiled the small example given in the documentation |> (hello world) and I got a 1Mb file, is it normal or do I have to tell |> the compiler to optimize something. I looked at the size of Hello World a while ago: there is about 600KB of symbols and 250KB of text for the runtime. Note that we haven't made any attempt to have the runtime as small as possible for each program (i.e. by not including some of thread, gc, exception, type system if they are not needed); most of the interesting programs need those things anyway. You can look for a message where I described the situation in the archives of this newsgroup. By default, I think that everything is compiled with debug. Compiling without debug or even with optimization should help a lot. However, if you compile with optimization and that causes some problems and the machine is not a DECstation, you will have to figure out the problem, since we won't be able to reproduce it. Stripping the executables is also a safe way to go. Shared libraries help a lot. Hopefully, they should be usable with 2.10 (which is now under test) if your system has them. -- Eric. ======================================================================= 14 === Date: Fri, 4 Dec 1992 18:49:31 GMT From: jredford@shearson.com (John Redford) Subject: Why Use Modula-3 I have been using M3 for a short while now and am trying to convince others to use it. It would be appreciated if someone could help me find information about the current usage of Modula-3 at various sites. Most desired would be any documents showing how Modula-3 improves productivity and reusability. Any general material on the Modula-3 langauge would also be good. Thanks -- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@shearson.com | 5 cans of Scotchguard. ======================================================================= 15 === Date: Fri, 4 Dec 1992 23:22:15 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: Re: smallest possible system Eric Muller writes: I looked at the size of Hello World a while ago: there is about 600KB of symbols and 250KB of text for the runtime. ... most of the interesting programs need those things anyway. Nonetheless, an 800K runtime system is rather shocking, even for an interesting program. Shared libraries dull the shock, until you notice the size of your working set. ======================================================================= 16 === Date: 4 Dec 92 20:36:06 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: Why Use Modula-3 > I have been using M3 for a short while now and am trying to convince others > to use it. It would be appreciated if someone could help me find > information about the current usage of Modula-3 at various sites. Most > desired would be any documents showing how Modula-3 improves productivity > and reusability. Any general material on the Modula-3 langauge would also > be good. There's an article in the December issue of the Usenix ";login:" newsletter that attempts to answer this. Of course, the best way to answer it is to write some medium-scale application in it and make up your own mind. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Don't be a rebel, or a conformist; decwrl!vixie they're the same thing, anyway. Find vixie!paul your own path, and stay on it." -me ======================================================================= 17 === Date: 5 Dec 92 06:57:58 GMT From: tmg@panix.com (Thomas Genereaux) Subject: Re: Modula-3 on 386/SVR4 Unix? In <1992Dec4.135125.25358@hippo.ru.ac.za> werner@cs.sun.ac.za (Werner Fouche) w rites: >Has anyone done a port of SRC-Modula-3 to 80386-based computers >running SVR4 Unix? If an M3 port does not exist, I would like to compile >the AIX distribution of SRC-Modula-3 for SVR4 Unix, will that work? >If no implementation of Modula-3 for SVR4 Unix exists I may have to >port the DEC-SRC-Modula-3 compiler. How portable is the compiler? >How long do you think it will take to port the compiler? I have >read the release notes of the compiler and it sounds to me that >one should be able to port the compiler with hopefully little effort! >Where can I find either commercial or public domain >Modula-3 interfaces for Motif? >Thank you very much. >Werner Fouche' >University of Stellenbosch >Stellenbosch, 7600 >Republic of South Africa The AIX distribution *will not* compile under SVR4, and it is going to take more time hacking it up than I have (grumble). The AIX port is at least a reasonable starting point though. Tom G. ======================================================================= 18 === Date: 5 Dec 92 15:22:31 GMT From: moss@cs.cmu.edu (Eliot Moss) Subject: m3 on x86 architecture So far as I know there are no 80x86 Modula-3 compilers. On the other hand, I have heard that various people have tried or are in the process of porting SRC M3 to DOS and or UNIX x86 systems. Another possible route (a little ways off) is to port our GNU M3 compiler to the x86, along the lines of djgpp, a port of gcc/g++ to the 386/486. While a compiler for 8086/80286 is conceptually feasible, the current paths seem to be ports of large machine compilers, so tend to need the larger address space (or virtual address space) support of the 386/486. If M3 becomes popular enough, maybe Borland will do a great, fast, x86 system, but I wouldn't hold my breath. -- J. Eliot B. Moss, Associate Professor Visiting Associate Professor Department of Computer Science School of Computer Science Lederle Graduate Research Center Carnegie Mellon University University of Massachusetts 5000 Forbes Avenue Amherst, MA 01003 Pittsburgh, PA 15213-3891 (413) 545-4206, 545-1249 (fax) (412) 268-6767, 681-5739 (fax) Moss@cs.umass.edu Moss@cs.cmu.edu ======================================================================= 19 === Date: Mon, 7 Dec 1992 16:00:59 GMT From: jredford@shearson.com (John Redford) Subject: Re: Why Use Modula-3 In article vixie@pa.dec.com (Paul A Vixie) writes: > I have been using M3 for a short while now and am trying to convince other s > to use it. It would be appreciated if someone could help me find > information about the current usage of Modula-3 at various sites. Most > desired would be any documents showing how Modula-3 improves productivity > and reusability. Any general material on the Modula-3 langauge would also > be good. There's an article in the December issue of the Usenix ";login:" newsletter that attempts to answer this. Of course, the best way to answer it is to write some medium-scale application in it and make up your own mind. I dont think I am going to be able to find this newsletter without some reference as to where it can be found. I have made up my own mind about my personal preference, but I can't ask people to all write applications to test-drive the language. I am hoping that someone can provide some semi-internal document regarding the point of using Modula-3. I would assume that DEC had one of these floating around at some point, and other places might as well. I presently have enough material to write a brief description of the aleged benefits of M3, but I have no examples of actual usage to support this. -- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@shearson.com | 5 cans of Scotchguard. ======================================================================= 20 === Date: Mon, 7 Dec 1992 23:10:12 GMT From: aghg1@cl.cam.ac.uk (A.G.H. Gibson) Subject: ANSA Can anyone send me some example source code that shows how to use ANSA with Modula3 ? Thanks, Aidan ======================================================================= 21 === Date: Tue, 8 Dec 92 19:17:46 GMT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: I can't compile my Color interface! The current M3 system is quite ruthless about name clashes. There is no way that I know of to shadow a library unit with a local copy. You simply have to rename your unit so that it doesnt clash. Mick Jordan ======================================================================= 22 === Date: 11 Dec 92 07:39:33 GMT From: gwh@elric.cs.mcgill.ca (Gene W. Homicki) Subject: Modula3 on a NeXT Has anyone compiled Modula-3 on a NeXT? I'm having a problem compiling the libm3 library. Whenever I atte,pt to compile I get the following error: ============================= Building in NEXT /usr/local/bin/m3 -w1 -make -why -nostd -times -g -a libm3.a -F.PGM_SOURCES *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x350000 = Uin.htons + 0x2b61ac *** *** Quit Any help on this would be very much appreciated. Other things of note: I'm using the McGill MouseX distribution running under NeXTSTEP 2.1. Thanks in advance. --Gene gwh@cs.mcgill.ca ======================================================================= 23 === Date: 11 Dec 92 23:57:14 GMT From: kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner) Subject: Q: libm3-2.10 lacks Uin.[im]3? Hello... I succesfully installed m3-2.10 and libm3-2.10 (and trestle,...) on our HPPA machines. Now I tried to install m3rpc-1.3, too. It works until Uin.m3 is needed. I checked for it, but it's actually not in our installation. Does anybody know where the Internet-stuff from Uin.m3 went? I'd appriacate any hint. I'd really like to work with m3rpc. Thanks in advance, Torsten -- kirschnt@informatik.{uni|tu}-muenchen.de ======================================================================= 24 === Date: Tue, 15 Dec 1992 12:43:20 GMT From: marc@ecrc.de (Marc Bourgois) Subject: modula-90 anyone heard of it? any description around? any references? --- Marc Bourgois European Computer-Industry Research Centre Tel. + (49) 89-92699-179 Arabellastr 17, 8000 Muenchen 81. Germany. Internet: marc@ecrc.de UUCP: ..unido!ecrc!marc ======================================================================= 25 === Date: Tue, 15 Dec 1992 22:26:11 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Re: modula-90 I *think* it`s this one: @ARTICLE{Odersky90, AUTHOR = "Martin Odersky", TITLE = "Extending {Modula-2} for Object-Oriented Programming", JOURNAL = "Microprocessors and Microsystems", VOLUME = 14, NUMBER = 3, PAGES = {153--159}, MONTH = apr, YEAR = 1990, KEYWORDS = "PROGLANG, MODULA-2, OOP, TYPE GUARD, MODULE TYPE" } -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ======================================================================= 26 === Date: Tue, 15 Dec 92 23:33:31 GMT From: dmiller@dragon.tricity.wsu.edu (David L. Miller) Subject: Modula-3 for Amiga? Has anyone worked on a Modula-3 port for the Amiga? -- ***************************************************************************** David L. Miller Internet: dmiller@beta.tricity.wsu.edu Systems Programmer/Network Analyst BITNET: MILLERD@WSUVM1 Washington State University Tri-Cities UUCP: ...!yoda!dmiller 100 Sprout Road Richland, WA 99352 Phone: (509)375-9245 ***************************************************************************** ======================================================================= 27 === Date: Wed, 16 Dec 1992 20:48:54 GMT From: kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner) Subject: Re: pretty printing marc@ecrc.de (Marc Bourgois) writes: > Library modules exist for pretty printing symbolic expressions > (Sx__,FWr,... modules), > but where is the pretty printer for (in our case: generated) > modula3 code hidden? the Modula-3 pretty printer "m3pp" is part of the tools-VERSION.tar.Z. (Replace Version with Your current version of m3, i.e. "2.10".) Apart from gatekeeper.dec.com, You can ftp that from ftp.germany.eu.net and ftp.informatik.{tu | uni}-muenchen.de. Torsten ======================================================================= 28 === Date: Wed, 16 Dec 1992 14:52:06 GMT From: marc@ecrc.de (Marc Bourgois) Subject: pretty printing Library modules exist for pretty printing symbolic expressions (Sx__,FWr,... mo dules), but where is the pretty printer for (in our case: generated) modula3 code hidde n? --- Marc Bourgois European Computer-Industry Research Centre Tel. + (49) 89-92699-179 Arabellastr 17, 8000 Muenchen 81. Germany. Internet: marc@ecrc.de UUCP: ..unido!ecrc!marc ======================================================================= 29 === Date: Thu, 17 Dec 92 09:01:15 EST From: Roger Hoover Subject: IBMR2 fixes for 2.10 Bug fixes to get 2.10 to compile on RS6000 with shared libs. > From: Eric Muller > Another problem we have fixed recently, in m3make/src/M3makefile: the > lines for the rule install should look like: > > ---------------------------------------- > install:: > @../src/recmkdir $(BIN_INSTALL) > @../src/recmkdir $(LIB_INSTALL) > @../src/recmkdir $(PUB_INSTALL) > > #if defined (MAN_SECTION) > install:: > @../src/recmkdir $(MAN_INSTALL)/man##MAN_SECTION > #else > install: > @../src/recmkdir $(MAN_INSTALL)/man1 > @../src/recmkdir $(MAN_INSTALL)/man2 > @../src/recmkdir $(MAN_INSTALL)/man3 > @../src/recmkdir $(MAN_INSTALL)/man4 > @../src/recmkdir $(MAN_INSTALL)/man5 > @../src/recmkdir $(MAN_INSTALL)/man6 > @../src/recmkdir $(MAN_INSTALL)/man7 > @../src/recmkdir $(MAN_INSTALL)/man8 > #endif > ---------------------------------------- > > otherwise you have a extra blank line at line 121 in .makefile. > Changes in model_configs/IBMR2: o A warning about which aix c compiler you need. o The library produced by library() is of the form lib##name.a, not lib##name.so.1.1 as it is for SPARK, thus all:: and clean:: should be lib##name.a o the sed command must contain real tabs, not \t's o there is a / missing before the p at the end of the sed expression. o colons in bsdcc command must be escaped with \ or imake will think they are make productions and screw up the tab before the line. o -nostart should be _nostart o libname.a should be lib##name.a (two occurrences) o _DREDUCED_TO_ASCII_SPACE should be -DREDUCED_TO_ASCII_SPACE o it turns out there is a second incompatable sysV install on AIX, so we need to specify /usr/ucb/install o Shared libraries on RS6K require all name resolution to be done at link time. All libraries need -lm, but other libraries will need -lm3 and perhaps more. (for example, libm3ui.a requires -lm3X11R4 -lX11 -lm3 in addition to -lm) I've added a second argument to library and Library to specify these. This means adding a second argument to all of the library lines in m3makefiles. Also, if you want to run on other architectures, you have to fix up the library macros everywhere with an ignored second arg. roger trek[m3]% diff -c m3make/model-configs/IBMR2 m3make/IBMR2/config *** m3make/model-configs/IBMR2 Tue Oct 27 14:25:43 1992 - --- m3make/IBMR2/config Thu Dec 17 08:01:16 1992 *************** *** 43,48 **** - --- 43,53 ---- discusses the remaining incompatibilities. The troff source for a version of the porting document is in file /usr/lpp/bos/bsdport.tr. + + ALSO NOTE: There is a bug in earlier versions of the 3.2 xlc compiler + that will give you compilation errors. The earliest version known to + compile m3 2.10(and above) is 1.2.0.7. 1.2.0.0 does not work. To see + which version you have, type "/usr/ucb/what /usr/lpp/xlc/bin/xlcentry". */ /*********************************************************************/ *************** *** 152,175 **** /* These macros are used instead of the ones in the template, so that we can have shared libraries */ ! #define library(name) @ @\ ! all:: lib##name.so.1.1 @ @\ ! clean:: ; rm -f lib##name.so.1.1 lib##name.ax @ @\ lib##name.a: FRC @ @\ $(DO_M3) -a lib##name.a $(PGM_SOURCES) $(IMPORT_LIBS) @@\ /bin/dump -g lib##name.a | sed -n -e \ @@\ ! 's/^[ \t]*[0-9][0-9]*[ \t]*\([^ \t.][^ \t]*\)$$/\1p' > _expnames @@\ ! /bin/bsdcc -bE:_expnames -bM:SRE -o _shar.o lib##name.a \ @@\ ! -L$(LIB_USE) $(IMPORT_LIBS) $(LINKFILES) -e -nostart @@\ ! rm -f libname.a @@\ ! /bin/ar cru libname.a _shar.o @@\ rm -f _expnames _shar.o ! #define Library(name) @ @\ install:: @ @\ INSTALL (lib##name.a, $(LIB_INSTALL), 644) @@\ INSTALL (lib##name.ax, $(LIB_INSTALL), 644) @@\ ! library(name) /* Give the value 0 if you want the m3 driver to pass -L/-l arguments to LD for libraries; otherwise (value = 1), the m3 driver will pass - --- 157,181 ---- /* These macros are used instead of the ones in the template, so that we can have shared libraries */ ! #define library(name,deplibs) @ @\ ! all:: lib##name.a @ @\ ! clean:: ; rm -f lib##name.a lib##name.ax @ @\ lib##name.a: FRC @ @\ $(DO_M3) -a lib##name.a $(PGM_SOURCES) $(IMPORT_LIBS) @@\ /bin/dump -g lib##name.a | sed -n -e \ @@\ ! 's/^[ ]*[0-9][0-9]*[ ]*\([^ .][^ ]*\)$$/\1/p' \ @@\ ! > _expnames @@\ ! /bin/bsdcc -bE\:_expnames -bM\:SRE -o _shar.o lib##name.a \ @@\ ! -L$(LIB_USE) deplibs -lm -e _nostart @@\ ! rm -f lib##name.a @@\ ! /bin/ar cru lib##name.a _shar.o @@\ rm -f _expnames _shar.o ! #define Library(name,deplibs) @ @\ install:: @ @\ INSTALL (lib##name.a, $(LIB_INSTALL), 644) @@\ INSTALL (lib##name.ax, $(LIB_INSTALL), 644) @@\ ! library(name,deplibs) /* Give the value 0 if you want the m3 driver to pass -L/-l arguments to LD for libraries; otherwise (value = 1), the m3 driver will pass *************** *** 188,194 **** /* Imake may need to be configured Note: the value of this symbol must not use the values of other symbols. * / ! IMAKEFLAGS = _DREDUCED_TO_ASCII_SPACE /* Some versions of make(1) let us specify the shell to use. In any case, we want sh */ - --- 194,200 ---- /* Imake may need to be configured Note: the value of this symbol must not use the values of other symbols. * / ! IMAKEFLAGS = -DREDUCED_TO_ASCII_SPACE /* Some versions of make(1) let us specify the shell to use. In any case, we want sh */ *************** *** 205,211 **** MAKE = /usr/bin/make /* And install */ ! #define INSTALL(f,d,p) install -c -m p f d /* Here are the pieces that the Modula-3 driver needs. PASS0: the Modula-3 to C compiler - --- 211,217 ---- MAKE = /usr/bin/make /* And install */ ! #define INSTALL(f,d,p) /usr/ucb/install -c -m p f d /* Here are the pieces that the Modula-3 driver needs. PASS0: the Modula-3 to C compiler trek[m3]% diff -c libm3/src/m3makefile~ libm3/src/m3makefile *** libm3/src/m3makefile~ Mon Nov 16 13:07:47 1992 - --- libm3/src/m3makefile Thu Dec 17 07:50:26 1992 *************** *** 201,204 **** M3FLAGS = -w1 -make -why -nostd -times ! Library (m3) - --- 201,204 ---- M3FLAGS = -w1 -make -why -nostd -times ! Library (m3,) trek[m3]% ======================================================================= 30 === Date: Fri, 18 Dec 92 08:27:55 EST From: Geoff.Wyant@East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: re: Forking a threaded Modula 3 process > From: dagenais@vlsi.polymtl.ca (Michel Dagenais) > Newsgroups: comp.lang.modula3 > Subject: Forking a threaded Modula 3 process > Date: 17 Dec 92 14:05:49 GMT > Organization: Ecole Polytechnique de Montreal, Canada > > > I want to communicate between a Modula 3 program and another already > written C program. Ideally, the C program should interact through its > stdin/stdout/stderr file descriptors. I know how to do that by creating > pipes, forking the Modula 3 program and exec on the C program. I am worried > about the multiple threads in the forked process however (they should not > attemps X windows output and so on). I suppose that adding an interface to > the "popen" unix call would be cleaner and safer. Advices? > -- > --------------------------------------------------------------------- > > Prof. Michel Dagenais dagenais@vlsi.polymtl.ca > Dept of Electrical and Computer Eng. > Ecole Polytechnique de Montreal tel: (514) 340-4029 > > --------------------------------------------------------------------- > The time between the fork and the exec should be short enough that threads shouldn't be a problem. After the exec, they will disappear. On a fast multi-processor, there would be a race condition, but there isn't much you can do without the requisite kernel support. Popen would suffer the same race condition as it ultimately does a fork and an exec as well. If you wanted to be squeaky-clean, you could have a C-based "exec server" that you sent a message to and it forked off the program of interest. That would eliminate any M3 threads from the picture. Hope this helps ! --geoff ======================================================================= 31 === Date: 17 Dec 92 14:05:49 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Forking a threaded Modula 3 process I want to communicate between a Modula 3 program and another already written C program. Ideally, the C program should interact through its stdin/stdout/stderr file descriptors. I know how to do that by creating pipes, forking the Modula 3 program and exec on the C program. I am worried about the multiple threads in the forked process however (they should not attemps X windows output and so on). I suppose that adding an interface to the "popen" unix call would be cleaner and safer. Advices? -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 32 === Date: 20 Dec 92 16:29:42 GMT From: fn00@gte.com (Farshad Nayeri) Subject: What happenned to Wr.Error and Rd.Error... Documentation for the "Wr" interface, on page 133 of SPwM3 says: Illegal operations (for example, writing to a closed writer) raise the exception "Error". At some point of time, exception "Error" was changed to a checked run-time error. The current "Wr" interface says: Illegal operations (for example, writing to a closed writer) cause checked runtime errors by raising an internal exception. I was just wondering about the reason for this change... Thanks, --farshad -- Farshad Nayeri Intelligent Database Systems fn00@gte.com Computer and Intelligent Systems Laboratory (617)466-2473 GTE Laboratories, Waltham, MA "Our research shows that even double-clicking can be hard concept for some new users to grasp." -- John Cook, Apple consumer product manager ======================================================================= 33 === Date: Mon, 21 Dec 92 09:48:53 -0800 From: kalsow@src.dec.com Subject: Re: What happenned to Wr.Error and Rd.Error... The original M2+ authors used Wr.Error and Rd.Error to document the behavior of the streams in presence of programming bugs. It was never intended that programmers catch Wr.Error or Rd.Error. They were supposed to cause a crash. We decided that in Modula-3 "checked runtime error" was more appropriate. - Bill Kalsow