======================================================================= 1 === Date: 01 Jun 1995 00:28:19 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: more m3build wishes Farshad's question about using m3build to generate documentation reminded me of something else I'd like to do with m3build. Basically, I'd like it to be possible to integrate RCS into m3build, so that whenever a package properly compiles it checks all the source files in using a new minor revision. Similarly, when a package is shipped, a new major revision could be checked in. If nobody else has done this, I may try it sometime. Any ideas or comments? -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 2 === Date: Thu, 01 Jun 95 13:58:37 -0700 From: kalsow@pa.dec.com Subject: Re: more m3build wishes Spencer: From the little that I've explored, it seems that m3build is just short of being a language in and among itself. It is. Quake is a generic language with procedures, loops, conditionals variables, arrays, lists, and strings. Farshad: I think that within SRC, there is a system called Vesta that is used for systems management for the sort of things you describe. Yes and No. Vesta I is gone, Vesta II is being built. So far we haven't used Vesta for Modula-3. Farshad: As far as I understand, m3build was supposed to be the sort of minimum stuff you need to compile Modula-3 programs. It is supposed to be easy on the novice. Quake seems to be somewhat arbitrary basis for m3build; I think an equivalent system can be built on top of other scripting languages such as Python or Tcl. Certainly. We just needed something that supported reasonable abstraction (i.e. procedures) and lists. Farshad: I think the addition of the hooks to trigger at various events (somewhat like a metaobject protocol) seems to be consistent with m3build's original design goal as it doesn't make it harder for novices to use m3build. The goal of m3build was to produce short and portable makefiles that hid the operational aspects of building. The current system builds a bunch of lists (e.g. MODULE_SOURCES, IMPORT_LIBS, ...) and invokes m3. Unlike C systems, m3 decides which sources to recompile. The hooks already exist to invoke user code before m3 is invoked. These hooks could easily look around for RCS directories and missing sources or do most anything you'd like. Simply removing the "readonly" in front of the definitions of "interface", "module", and friends in COMMON would allow users to override the definitions of these functions. For example, old_interface_proc = interface proc interface (x) is old_interface_proc (x) ... end With a little creativity, who knows what might be accomplished? - Bill Kalsow ======================================================================= 3 === Date: Thu, 1 Jun 95 11:51:58 GMT From: buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409) Subject: Re: Can someone explain this behaviour? Blair MacIntyre (bm@shadow.cs.columbia.edu) wrote: : What I'm wonder is, why can't I create a subrange that has : FIRST(INTEGER) in it. : TYPE T = BITS 32 FOR [FIRST(INTEGER)..LAST(INTEGER)]; : TYPE R = BITS 32 FOR [-2147483647..2147483647]; [...] : All this makes sence. However, I cannot change "R" to match INTEGER : and T, like this: : TYPE R = BITS 32 FOR [-2147483648..2147483647]; : or I get the following error: : "../src/Main.m3", line 5: illegal integer literal, zero used Same Problem as in C, C++, Pascal, Algol68, ... Try TYPE R = BITS 32 FOR [-2147483647 -1..2147483647]; ``-2147483648'' is not a literal, but the constant expression ``(- (2147483648))''. And ``2147483648'' is not a valid integer literal, but out of range. The real problem is, the integer range is asymetric. ``- FIRST(INTEGER)'' is not in the integer range on twos-complement cpus. There are no negative integer type constants in Modula3. There are also no negative floatingpoint constants in Modula3, but it dosn't result in this sort of errors, cause the floatingpoint range is symetric. Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@lts.sel.alcatel.de ======================================================================= 4 === Date: 01 Jun 1995 15:46:12 GMT From: nayeri@gte.com (Farshad Nayeri) Subject: Re: more m3build wishes In article bm@shadow.cs.columbia.edu (Blair MacIntyre) writes: Basically, I'd like it to be possible to integrate RCS into m3build, so that whenever a package properly compiles it checks all the source files in using a new minor revision. Similarly, when a package is shipped, a new major revision could be checked in. If nobody else has done this, I may try it sometime. Any ideas or comments? Good idea! You can also do automatic check out like what GNU make does if the file doesn't appear to exist in the src directory, and there is an RCS directory. I don't know anyone who's done it, but it doesn't sound too hard. But what if I want to use CVS or Siphon? It seems to me that all these sorts of requests are symptoms of a more global need for some "hooks" in m3build where the user can register handlers for doing useful things when certain interesting events (for example, successful or unsuccessful compilation of module or interface or package, or shipping) take place. -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 5 === Date: Thu, 1 Jun 1995 16:05:22 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Re: more m3build wishes Hmm, if too much stuff gets integrated "into" m3build, it'll be a gigantic mess. I'm far from a m3build expert, in fact I consider myself a blatant novice :) I just feel that it might be a better idea to create "hooks" from m3build to the package that you want to do the RCS, etc. type stuff. Maybe this is already possible, but it'd be nice if the build system were extensible so that you could call external procedures and/or programs while doing things. From the little that I've explored, it seems that m3build is just short of being a language in and among itself. Hmm, here's a thought. Maybe the build environment should also be a semi-high level language tailored to deal with the compilation rules of other languages? I'm assuming that m3build isn't quite that powerful, but I may be wrong. Anybody that's ever had to suffer with Makefiles should rejoice over m3build, but that doesn't mean that improvements should stop. I think integrating other "build" tools with m3build is a great idea, but I hope that every new improvement doesn't involve changing how things work in general. I guess I should examine the m3build stuff more closely in my spare time. ---------------------------------------------------------------------- Spencer Allain E-mail: spencer@era.com Engineering Research Associates Phone : (703) 734-8800 x1414 1595 Spring Hill Road Fax : (703) 827-9411 Vienna, VA 22182-2235 ---------------------------------------------------------------------- ======================================================================= 6 === Date: 01 Jun 1995 02:29:20 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: WinNT porting of standard M3 packages I'd like to talk to anyone else using modula-3 on NT. I've finally gotten NT and spent a little while today and yesterday installing it and Modula3. The biggest problem is that some of the standard packages don't work. Obviously, X11R4 and anything it depends on won't work (unless, I suppose, you had X installed on NT). I'm not too worried about that right now. But, I do need netobj and obliq to work. The netobjd distributed with 3.5.2 crashes in a variety of interesting ways, so I was wondering if anyone else has it working. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 7 === Date: 01 Jun 1995 02:46:17 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Re: WinNT porting of standard M3 packages More interesting details about netobjd on NT. In another post (subject: "Can someone explain this behaviour?"), I ask about subrange types. In particular, WireRep.m3 bombs out on NT with an Illegal value error since FIRST(INTEGER) is not in the Int32 subrange, yet that is what is being returned by "ROUND(Time.Now())" in the following statement (I changed the type definition of Int32 and printed out the value of myTs). VAR myTs: Int32 := ROUND(Time.Now()); So, that no longer bombs, although I suspect having ROUND(Time.Now()) return -2147483648 is symptomatic of other problems. However, after that, netobjd dies in the startup initialization of TCP.m3 (the first line of this routine fails: PROCEDURE Init() = VAR data: WinSock.WSAData; BEGIN IF WinSock.WSAStartup(WinSockVersion, ADR(data)) # 0 THEN Die(); END; Process.RegisterExitor(Exitor); END Init; ) I'm using stock Windows NT 3.5 from the CD (something like build 808). Does TCP work yet? I'd heard a while ago that people were working on it but it wasn't 100% yet ... is this a side effect of this? -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 8 === Date: 01 Jun 1995 02:38:42 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Can someone explain this behaviour? What I'm wonder is, why can't I create a subrange that has FIRST(INTEGER) in it. In WireRep.m3, we have the following type defined: Int32 = BITS 32 FOR [-2147483647..2147483647]; If I run the following program: MODULE Main; IMPORT Fmt, IO; TYPE T = BITS 32 FOR [FIRST(INTEGER)..LAST(INTEGER)]; TYPE R = BITS 32 FOR [-2147483647..2147483647]; BEGIN IO.Put("Bits in INTEGER: " & Fmt.Int(BITSIZE(INTEGER)) & "\n"); IO.Put(" from: " & Fmt.Int(FIRST(INTEGER)) & "\n"); IO.Put(" to: " & Fmt.Int(LAST(INTEGER)) & "\n"); IO.Put("Bits in T: " & Fmt.Int(BITSIZE(T)) & "\n"); IO.Put(" from: " & Fmt.Int(FIRST(T)) & "\n"); IO.Put(" to: " & Fmt.Int(LAST(T)) & "\n"); IO.Put("Bits in R: " & Fmt.Int(BITSIZE(R)) & "\n"); IO.Put(" from: " & Fmt.Int(FIRST(R)) & "\n"); IO.Put(" to: " & Fmt.Int(LAST(R)) & "\n"); END Main. I get this output (on SPARC and NT): Bits in INTEGER: 32 from: -2147483648 to: 2147483647 Bits in T: 32 from: -2147483648 to: 2147483647 Bits in R: 32 from: -2147483647 to: 2147483647 All this makes sence. However, I cannot change "R" to match INTEGER and T, like this: TYPE R = BITS 32 FOR [-2147483648..2147483647]; or I get the following error: "../src/Main.m3", line 5: illegal integer literal, zero used The reason this came up is that the following line in WireRep.m3 was bombing out netobjd on NT (with an Illegal value error): VAR myTs: Int32 := ROUND(Time.Now()); Changing Int32 to be the same as "T" above fixed that problem, since "myTs" was being assigned -2147483648 (yes, I think that this is a sign of other problems, but I'm not attempting to address them here). -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 9 === Date: 01 Jun 1995 17:22:56 GMT From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Modula-3 and mixed language kernel coding In article dagenais@notung.vlsi .polymtl.ca (Michel Dagenais) writes: Building new releases of m3 is a problem even for those of us in an institutional environment. I have found that to reliably install it I had better have in the region of 200M or over. Things may have improved since packages are built and cleaned one after another instead of building everything and then cleaning. In any case 200MB costs about 100$, slightly more expensive than a book. That's true if you "own" the machine you are using to program in Modula-3. Now, suppose you don't have the root password on your system, and the system admin doesn't agree with your economic analysis... For some time now I've wondered whether it wouldn't be possible to distribute m3 as binaries. ... To deal with the problem of those with limited space, a distribution of binaries only, with none of the sources would result presumably in a requirement of <20M disk. As mentioned in the FAQ, I have been offering for some time binaries for LINUX, LINUXELF, SPARC, HPPA, FreeBSD, NeXT on ftp.vlsi.polymtl.ca in pub/m3. Perhaps what we need is a *minimal* m3 distribution. Even in source form, a minimal SRC M3 distribution (even when you include libm3) should not be very large these days. Note that the problem with the sizes still holds for the binary release. That is, if all of the packages are included, the binary release of SRC Modula-3 is quite large (and the way things are organized, it is not easy to separate the essential parts of the release from the bonus stuff if you don't have a lot of disk space.) Given proper organization, the large size of the library should be an advantage, and not a problem! (Michel you may want to keep the following in mind in the re-organization of your ftp site. I don't know if your ftp server allows this but it may be worth a try:) Here as idea for a minimal release of SRC Modula-3: - Make a directory on the ftp.vlsi... server and call it "minimal". - In "minimal", make links to all the required files and directories for a minimal distribution from (expanded version of) the standard distribution. - Now, combining the link-directory with automatic tar'ing, you can allow users to download a minimal distribution easily. I imagine this "virtual directory" containing the minimal release should be relatively easy to maintain in the long run. -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 10 === Date: Thu, 1 Jun 1995 17:37:59 -0400 From: wds@research.nj.nec.com (Warren Smith) Subject: (none) To m3@src.dec.com QUESTIONS ABOUT MODULA 3 1. I'm presently thinking about writing a chess program, and if I do, it is going to be in either modula-3 or C++. Anybody have any feedback on which is the better choice? 2. Has anybody got a set of benchmarks comparing C and modula-3 speed? In particular something heavy in allocation and garbage collection? 3. The SRC modula-3 compiler does not work with the latest GNU assembler on SGI machines when "-g" is turned on (as it must be if you want to use the profiler or the debugger). This may be due to the switch between ELF and COFF binaries? When will this be fixed? 4. I generally like modula-3 syntax, but the gratuitous refusal to allow you to be concise annoys me. Why DO and THEN and BEGIN and END; rather than (as in C) { and }? Less to remember, less to type, editors with paren matching do the right thing, C syntax wins on all counts here. 5. I find it understandable that modula-3 does not have macros... but they nevertheless can be useful. For instance, in my chess program I want to represent the board with an array of 64 squares ordered A1,B1,...H1,A2,...H2,...A8,...H8. In C I can initialize arrays using a 64-argument macro boardfull(x1,...,x64) which allows me to use a picture of the board in array initializations RankForWhite[] = boardfull( 7,7,7,7,7,7,7,7, 6,6,6,6,6,6,6,6, 5,5,5,5,5,5,5,5, 4,4,4,4,4,4,4,4, 3,3,3,3,3,3,3,3, 2,2,2,2,2,2,2,2, 1,1,1,1,1,1,1,1, 0,0,0,0,0,0,0,0); and it would be the wrong thing (chess-wise) if it had to be RankForWhite[] = {0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,...7,7,7,7,7,7,7,7}; So C macros increase my expressive power and make my program readable in this instance. Modula-3? Noooo! 6. Another thing I can use macros for in C (I admit, it is disgusting looking and I hate to do it) is to make custom iterators. E.g. in chess: loop over all pieces attacking square X { stuff; } There appears to be no way to make custom iterators in modula-3? 7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor DEC alpha machine? Or will the compiler just put all threads on a single one of those 4 processors...? ------------------------------------ From: Warren D. Smith (Research Staff; Library Committee Chair) NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA Phone: (609) 951-2717 Web: http://www.neci.nj.nec.com/homepages/smith.html Email: wds@research.NJ.NEC.COM Fax: (609) 951-2496 ("for W.D.Smith 1D04") ======================================================================= 11 === Date: Thu, 1 Jun 1995 19:10:09 GMT From: bwbecker@dragon.uwaterloo.ca (Byron Weber Becker) Subject: Re: Help with WWW documentation of M3 sources In article , hudson@cs.umass.edu wrote : > I looked into a similar problem a few weeks ago and their seems to be a bug i n > some versions of Netscape tickled when you have a trailing / on your URL. Thanks, but I don't see any trailing /s on my URLs. Byron -- Byron Weber Becker Voice: (519)888-4567 x4661 Lecturer/Advisor Fax: (519)885-1208 Department of Computer Science e-mail:bwbecker@dragon.uwaterloo.ca University of Waterloo Waterloo, ONT N2L 3G1 CANADA ======================================================================= 12 === Date: Thu, 1 Jun 1995 20:22:28 -0400 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: more m3build wishes Bill said: >Simply removing the "readonly" in front of the definitions of "interface", >"module", and friends in COMMON would allow users to override the >definitions of these functions. For example, > > old_interface_proc = interface > proc interface (x) is > old_interface_proc (x) > ... > end > >With a little creativity, who knows what might be accomplished? This is interesting. I had thought about uses of readonly, but never thought that of this one. One nice syntactic sugar will then be to include: extension interface (x) is ... end to be syntactic sugar for Bill's fragment. This way I could have in the m3makefile for pacakge "documentation": extension interface(x) is make_doc(x & ".i3") end extension module(x) is ... end and then just do import (documentation) in order to make documentation happen. Then again, simpler semantics is nice too. Great trick, Bill! -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 13 === Date: Fri, 2 Jun 1995 05:03:45 GMT From: iec@netcom5.netcom.com (Interstate Electronics Corp) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) > Brian, someone has worked on a gcc implementation of Modula-3, I do not > know what state it is in, but it was in reasonable working shape on a > VAX a while back! The only other implementation attempts I'm aware of are an early attempt by Olivetti (subsequently dropped) and that of Eliot Moss' group at UMass Amherst. The latter was planned to be the GNU Modula-3 compiler, but budget problems and the excellent quality of the DEC SRC compiler (which now uses gcc, anyway) put that project into deep background. -- -- ======================================================================== Mike Elliott mre@emerald.ccss.com mre@lpf.org ======================================================================== ======================================================================= 14 === Date: Fri, 2 Jun 1995 09:52:50 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Concurrency I would be interested to know what (if any) views the m3 developers have on the problems of supporting true concurrency. Lately, I have been carrying out some performance tests of a database system I am developing in m3. I've been running it on a dual processor server so I only have half the processor power available to me. A more subtle problem however, is the effect on I/O scheduling of running a 'concurrent' system in a single thread. In particular, in my case, having the I/O processors running concurrently with the rest of the system would undoubtedly improve peformance dramatically. What plans, if any, are there for providing such support? As I see it there are various levels: 1. Full concurrency for all threads. Would mean making all global variables shared. 2. Optional concurrency and sharing. A new type of fork which generates a new process and some language constructs to indicate variables are shared between concurrent processes 3. Subroutine support (which probably exists already). ======================================================================= 15 === Date: Fri, 2 Jun 1995 18:43:01 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: Concurrency > >Global variables ! Banish them from your code or protect them mutex >locks. > I think you miss the point. I use the term global variables a little loosely perhaps. I have a specific appliaction in mind but I'm sure the requirements are fairly general. To deal with the particular in case some light will come out of it: I have a page formatted I/O system which includes a multi-megabyte page cache. Pages are written from and read into the cache by I/O processors. I/O processors take requests of a queue, satisfy the requests and then signal their completion. Within a single address space this all works in a fairly simple but inefficient manner. I/O does not proceed in a truly concurrent manner. Now I know I can implement some sort of independent I/O processor by the use of shared memory, semaphores and the rest. I have many years of experience in implementing such systems. However, the model that m3 provides is nearly sufficient. What it lacks is the ability to 1. Fork() a separate process (in the OS sense) 2. Provide some mechanism whereby logically related, but independently executing processes can access memory in each others address space. For example, in my case I want to either be able to declare cache buffers and perhaps I/O queue objects as being shared in some sense or have some efficient way of making them appear in each others address space. Efficiency is important. People worry about 5 extra instruction inserted here and there for stack checking while all the time megabytes of information are being copied over and over from process to process. That is why I want my storage truly shared where that is appropriate. If modula 3 is really going to become a fully usable systems language I believe it is going to have to face up to the problems of true concurrency. By the way, I don't expect modula3 or it's runtime to provide concurrency where the underlying system doesn't. What I do hope for is that it will give us access to what are fairly generally available OS features. ======================================================================= 16 === Date: Sat, 3 Jun 95 12:18:14 BST From: sknee@client44.comlab (Simon Knee) Subject: Calling M3 from C How do I call Modula-3 procedures from inside some C code in release 3.5.2? In Modula-3 2.11 I would put Name__procedure in my C code to call the Modula-3 procedure Name.procedure. You might ask why?? Well I am using lex and yacc to build a parse tree of Modula-3 objects. On another point - It is really annoying that all of the libraries have changed from 2.11 -> 3.5.2. Now I have got to recode a lot of my Modula-3 programs to use the new interfaces. I thought that a strong point of the language was code reuse - that goes out the window a bit if the libraries that come with the distribution change. Thanks, Simon Knee, Programming Research Group, Oxford University UK. ======================================================================= 17 === Date: 3 Jun 1995 09:39:07 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: more m3build wishes In article , Spencer Allain wrote: > >Hmm, if too much stuff gets integrated "into" m3build, it'll be >a gigantic mess. Seconded. [snip]> >Maybe this is already possible, but it'd be nice if the build system >were extensible so that you could call external procedures and/or >programs while doing things. From the little that I've explored, it >seems that m3build is just short of being a language in and among >itself. > >Hmm, here's a thought. Maybe the build environment should also be >a semi-high level language tailored to deal with the compilation >rules of other languages? I'm assuming that m3build isn't quite >that powerful, but I may be wrong. > Indeed, it occurs that perhaps a solution might be to write a simple Modula-3 interpreter using the AST toolkit (this has been done as a part II project here; well, almost), and use that to direct builds. The supported subset needn't be that large, since libraries can be linked and called directly (though we would need dynamic linking), and if the interpreter is linked into the driver, we can potentially eliminate m3build and quake altogether (though whether this is desirable or not is another issue). There is also the advantage that generic modules and others need not have separate .tmpl files (though source code or dynamic linking will have to be available for the interpreter). In fact, if we are prepared to put up with having to write intermediate stages, there doesn't seem any need for an interpreter at all. As long as we have a bootstrap (import(libm3)/import(paths)/implementation(Boot)/ program(makesimple) for example), we can build our build programs iteratively. However, I think this is likely to be inadequate from speed, debugging, portability, and usability points of view. For a simple m3makefile, something along the lines of : MODULE Build EXPORTS Main; <*BUILD IMPORT LIBRARY MyBuildLibrary*> IMPORT BuildUtils, MyBuild; VAR info : BuildUtils.T := NEW(BuildUtils.T).init(); table : BuildUtils.Template := BuildUtils.Import("libm3","Table"); BEGIN info.ImportLib("libm3"); info.ImportLib("netobj"); info.ImportLib("mylib","/home/rrw1000/m3/mylib"); table.Build(info,"TEXT","Text"); info.Module("Test"); info.Build("Main"); MyBuild.Log(info); END Build. ... which would have the fixed `m3makefile' : import(Build) % For convenience implementation([whatever]) program([whatever]) I think it might be interesting to build a system like this, but I doubt it would be terribly usable :-(. [snip] Richard. -- `The past tempts us; the present confuses us; the future frightens us - and our lives slip away moment by moment - lost in that vast, terrible inbetween' (Babylon 5) The University of Cambridge can't have these opinions even if it wants them. ======================================================================= 18 === Date: 3 Jun 1995 01:29:20 GMT From: bluemist@seanet.com (Jim Brumbaugh) Subject: M3 FAQ? I've tried accessing the Modula-3 FAQ through WWW and both FAQ's I located seem to be unaccessable. Could someone point me to a resource to locate a FAQ? Furthermore I am interested in an OS/2 version of M3. I noticed that there seems to be a NT version and that there may be a GNU version which can be recompiled currently stalled in the works. Is this information accurate and is there a M3 compiler available (or in the works) for OS/2? Many thanks. |For consumer, technical, and marketing information about Geos call: |1-800-824-4558 | Geos- The best little GUI on the face of the third planet! |For demonstration ftp to- ftp://130.219.44.141/pub/geos/publish |Jim Brumbaugh- Internet: bluemist@seanet.com Fido: 1:343/179 ======================================================================= 19 === Date: 3 Jun 95 22:39:11 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: M3 FAQ? In article <3qodtg$20d@kaleka.seanet.com> bluemist@seanet.com (Jim Brumbaugh) w rites: I've tried accessing the Modula-3 FAQ through WWW and both FAQ's I located seem to be unaccessable. Could someone point me to a resource to locate a FAQ? Try ftp.vlsi.polymtl.ca:/pub/m3/faq.html. I just tried it and it worked. If you can't access it, feel free to write me and I will e-mail you a copy. Furthermore I am interested in an OS/2 version of M3. I noticed that there seems to be a NT version and that there may be a GNU version which can be recompiled currently stalled in the works. SRC Modula-3 works under NT and Win'95. People have posted interest and some committment to an OS/2 port, but I haven't heard of too much progress yet. Such a port is probably not too hard (as compared to, say, a Mac port!) Until then, you may want to try one of the DOS ports of SRC Modula-3 and run them from DOS emulation (?) -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 20 === Date: Sun, 4 Jun 1995 03:45:23 GMT From: hgeorge@eskimo.com (Harry George) Subject: M3 version of MFC on WinNT? Thanks to Kalsow and Nayeri, I'm rolling with M3 on WinNT. First obvious task is to put an OOP wrapper on Win32. The obvious approach is to use the same inheritance tree and naming scheme as Microsoft's Foundation Classes (MFC). That way the mental skills are more or less transportable from M3 to C++. It makes life easier for C++ folk to take a look at M3, and it makes M3'ers more or less capable of doing MFC-based C++ (BYOBB bring your own barf bag) So, I'm in the process of generating a m3MFC library with MfcBase and MfcGDI modules. It occurred to me that someone may a) already have done it b) is part way there c) would like to participate d) would like to kibbitz, bitch, offer sage advice, etc. Let me know. way there, or would like to -- -------------------- Harry George email: hgeorge@eskimo.com smail: 22608 90th Ave W / Edmonds WA 98026 quote: ======================================================================= 21 === Date: Mon, 5 Jun 1995 12:38:06 GMT From: hgeorge@eskimo.com (Harry George) Subject: Re: Calling M3 from C In article <1995Jun3.121814.27673@inca.comlab.ox.ac.uk>, sknee@client44.comlab says... > >How do I call Modula-3 procedures from inside some >C code in release 3.5.2? > I'd like an answer too. Even if it requires turning off gc. >On another point - It is really annoying that all of the >libraries have changed from 2.11 -> 3.5.2. Now I have got >to recode a lot of my Modula-3 programs to use the new >interfaces. I thought that a strong point of the language >was code reuse - that goes out the window a bit if the libraries >that come with the distribution change. > I'm moving from 2.11 to 3.5.2 myself, and I realize it is frustrating. But it is also important to allow and support such reorganizations of the libraries at this stage in the language's development. A cleanup now makes it all the more viable as it moves into broader use. So the pioneers have to a) stress the language by writing "real" programs, and b) encourage changes which lead to conceptual simplification, even when that means revising existing code. >Thanks, > >Simon Knee, >Programming Research Group, >Oxford University >UK. -- -------------------- Harry George email: hgeorge@eskimo.com smail: 22608 90th Ave W / Edmonds WA 98026 quote: ======================================================================= 22 === Date: Mon, 5 Jun 1995 09:46:31 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: Concurrency Mike Douglass writes: > However, the model that m3 provides is nearly sufficient. What it lacks is > the ability to > > 1. Fork() a separate process (in the OS sense) > I'm not sure what you mean by this. This could mean (1) Fork() an entirely new address space; (2) create a new stack and PC that shares the address space of the caller of Fork; (3) mean create a new OS level process that shares a caller-defined set of r esources with the invoker of 'Fork'. > 2. Provide some mechanism whereby logically related, but independently > executing processes can access memory in each others address space. > > For example, in my case I want to either be able to declare cache buffers > and perhaps I/O queue objects as being shared in some sense or have some > efficient way of making them appear in each others address space. > > Efficiency is important. People worry about 5 extra instruction inserted > here and there for stack checking while all the time megabytes of > information are being copied over and over from process to process. That is > why I want my storage truly shared where that is appropriate. > > If modula 3 is really going to become a fully usable systems language I > believe it is going to have to face up to the problems of true concurrency. > By the way, I don't expect modula3 or it's runtime to provide concurrency > where the underlying system doesn't. What I do hope for is that it will > give us access to what are fairly generally available OS features. > > The thread specification assumes an evironment where threads may be executing concurrently on different processors. It is not the case that all implementatio ns of the thread specification support that assumption; however if you program to the thread specification and you move from an environment where this assumption doesn't hold to one where it does hold, your system should have the same behavi or as it did before. While the threads interface is silent on the matter of address spaces, it in fact gives you (2) above. That is, there seems to be the implicit assumption t hat state visible in one thread can be made visible to another thread without any special action on the part of either thread. A newly created thread runs in the same address space as the invoker of 'Fork'. Whether or not this thread is capa ble of being run on a separate processor is implementation dependent. A permissible implementation of 'Thread.Fork' would be one in which the child ran as a separa te OS level process, but where its address-space was mapped one-to-one with the pa rent, and where changes in address space mappings were synchronized between the paren t and child in both directions. The current runtime does use OS-level threads on Windows-NT and Win95 and I have a buggy version that uses Solaris threads/LWPS on Solaris-2 systems. The libraries that are designed to make use of multithreading (Trestle, FormsVB T, VBTKit, etc) are all designed assuming that the runtime supports threads that are capable of being run on independent processors, although the default Unix implementation doesn't not provide that capability. What the thread interface does not give you is the ability to linguistically control visibility of information between two threads. That is, it does not admit the notion (at the language level) of thread private state except through the standard M3 mechanisms of objects/closures. It sounds like you want somethi ng closer to (3) above, where two independent address spaces can share some state without any special action on the part of processes executing in either address space. If this is a correct characterization of what you want, then I would characteri ze this ability as being OS dependent, and could see providing an OS dependent interfac e for creating this kind of process. As far as I know, only SGI and Plan9 currently a llow for this kind of process creation. --geoff ======================================================================= 23 === Date: 5 Jun 1995 19:20:34 GMT From: John Riley Subject: Installing the Linux bineries I have unpacked the stripped binaries on my system but there doesn't seem to be any directions on what to do next. Can anyone give me any information on environment variables, links, etc. I will be grateful for any help. Thanks, JPR ======================================================================= 24 === Date: 5 Jun 1995 19:35:27 -0400 From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) "Does anyone know if the FSF will separate their backend more from their front ends? The current hack of adding a m3.c file to the gcc compiler is fine, but even SRC has problems using the gcc backend optimizations properly." I doubt it, what possible FSF goal can be met by such a separation, it would seem to promote exactly that which FSF tries hard to prevent, the creation of proprietary technologies which make use of free software. ======================================================================= 25 === Date: Mon, 5 Jun 1995 20:35:56 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Re: Calling M3 from C In article hgeorge@eskimo.com (Harry George) writes: In article <1995Jun3.121814.27673@inca.comlab.ox.ac.uk>, sknee@client44.comlab says... > >How do I call Modula-3 procedures from inside some >C code in release 3.5.2? > I'd like an answer too. Even if it requires turning off gc. >Thanks, > >Simon Knee, >Programming Research Group, >Oxford University >UK. -- -------------------- Harry George email: hgeorge@eskimo.com smail: 22608 90th Ave W / Edmonds WA 98026 quote: Hmm, this seems to be a very popular question lately. It is a very good question to ask in fact, since a "good" answer solves several problems that chain off one another. 1) It allows us to easily call m3 from C programs. (This is the obvious answer) 2) If we have [1] we have a semi-portable way of calling m3 from other languages that can export C functions. (This is still not as powerful as ILU, but allows non-class stuff to be passed around easily) 3) If we have [2] we have a "better" way to switch from another language to m3. (This is part of the c->c++ theory, although it doesn't always work, it sure sells on managers) 4) We can possibly convince managers (or customers) that m3 is a better solution for the type of problem being worked on, and the change can be slightly incremental. (This should be done *only* for projects where the benefits of m3 outweigh the language presently being used) Ok, so it's not a perfect chain, but it does show how a seemingly inconsequential thing can greatly impact the future. I believe that if there were a way to "easily" call m3 from C code, it would pave the way for conversion. ---------------------------------------------------------------------- Spencer Allain E-mail: spencer@era.com Engineering Research Associates Phone : (703) 734-8800 x1414 1595 Spring Hill Road Fax : (703) 827-9411 Vienna, VA 22182-2235 ---------------------------------------------------------------------- ======================================================================= 26 === Date: 5 Jun 95 21:31:34 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article dewar@cs.nyu.edu (Robert Dewar) writes: "Does anyone know if the FSF will separate their backend more from their front ends? The current hack of adding a m3.c file to the gcc compiler is fine, but even SRC has problems using the gcc backend optimizations properly." I doubt it, what possible FSF goal can be met by such a separation, it would seem to promote exactly that which FSF tries hard to prevent, the creation of proprietary technologies which make use of free software. I suspect that soon enough, the gcc-based backend for SRC Modula-3 is going to be replaced by a "direct" code-generation for important platforms. The Windows release of SRC Modula-3 supports COFF directly, and efforts are underway for a direct ELF generation for LINUX although I hear Linux ELF support itself is not completely robust yet. Granted, this will not be as optimized as gcc, but for many uses this doesn't matter, especially for CS1 and CS2 courses. I actually find the gcc-backend to be a pain throughout the development as it slows things down considerably. By bypassing gcc-backend, M3 has a very good chance of having a super-fast (incremental) development environment. (I must admit, I don't know the complete context of this discussion. I better start reading comp.lang.ada.) -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 27 === Date: 5 Jun 1995 19:49:09 GMT From: "Marc E. Fiuczynski" Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) iec@netcom5.netcom.com (Interstate Electronics Corp) wrote: > > Brian, someone has worked on a gcc implementation of Modula-3, I do not > > know what state it is in, but it was in reasonable working shape on a > > VAX a while back! > >The only other implementation attempts I'm aware of are an early >attempt by Olivetti (subsequently dropped) and that of Eliot Moss' >group at UMass Amherst. > >The latter was planned to be the GNU Modula-3 compiler, but budget >problems and the excellent quality of the DEC SRC compiler (which now uses >gcc, anyway) put that project into deep background. >-- >-- >======================================================================== >Mike Elliott mre@emerald.ccss.com mre@lpf.org >======================================================================== Does anyone know if the FSF will separate their backend more from their front ends? The current hack of adding a m3.c file to the gcc compiler is fine, but even SRC has problems using the gcc backend optimizations properly. Marc ======================================================================= 28 === Date: 5 Jun 1995 19:54:14 GMT From: sims@linux.acsys.com (dave sims) Subject: when NEW fails, revisited What should I do when NEW fails to allocate memory? I recall the discussion in comp.lang.modula3 sometime back about possible solutions and workarounds. However, I don't recall if anyone agreed on anything. As far as I know, the DEC SRC distribution always terminates the program with an error message. I've written a couple servers using the DEC SRC Modula-3 distribution. They are intended to be used in a commercial environment. Needless to say, having such a program crash when it runs out of memory isn't acceptable. Any suggestions? What about the suggestion that the program raise an 'OutOfMemory' exception? thanks for any help, dave sims -- Dave Sims sims@usa.acsys.com KC5JKN ======================================================================= 29 === Date: Tue, 6 Jun 1995 09:18:34 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: when NEW fails, revisited >What should I do when NEW fails to allocate memory? > >I recall the discussion in comp.lang.modula3 sometime back about >possible solutions and workarounds. However, I don't recall if anyone >agreed on anything. As far as I know, the DEC SRC distribution always >terminates the program with an error message. > >I've written a couple servers using the DEC SRC Modula-3 distribution. >They are intended to be used in a commercial environment. Needless to >say, having such a program crash when it runs out of memory isn't >acceptable. > >Any suggestions? What about the suggestion that the program raise an >'OutOfMemory' exception? > I too would like to see an implementation that allows the possibility of recovery when the application runs out of memory. I'd also like that generalised to cope with other kinds of runtime failure. The exception mechanism seems to be the most appropriate choice. Perhaps as an intermediate step, would it be possible to provide us with a new NEW which raises an exception for out of memory. I presume at least one major problem is that the recovery may fail because of lack of memory. We might at least get a chance to keep going though. ======================================================================= 30 === Date: 6 Jun 95 08:53:35 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Installing the Linux bineries I have unpacked the stripped binaries on my system but there doesn't seem to be any directions on what to do next. Can anyone give me any information on environment variables, links, etc. Basically setup your PATH and LD_LIBRARY PATH variables. From the README (for LINUXELF): ftp> cd bin-strip ftp> get modula3-3.5.1.tar.Z ftp> quit me> mkdir -p /usr/local/soft me> gunzip setenv PATH $PATH:/usr/local/soft/modula3-3.5.1/bin me> setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/usr/local/soft/modula3-3.5.1/lib/m 3/LINUXELF -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 31 === Date: Tue, 6 Jun 1995 11:52:07 PDT From: jacobi.PARC@xerox.com Subject: Re: when NEW fails, revisited When you really run out of memory all hell breaks loose. It is too late to handle the case. If you want to handle running out of memory you'd have to watch the free memory space and reduce allocating more memory long before you will run out. Anyway, if you have an operating system, virtual memory will pitch in when you run out of real memory. Most often the application might start trashing long before it really runs out of virtual memory. The exception mechanism just isn't the right way to handle out of memory. You need prevention, not recovery. >Perhaps as an intermediate step, would it be possible to provide us with a >new NEW which raises an exception for out of memory. This wouldn't help. Just think when one thread allocates too much memory and it will raise that exception, no other thread will be able to allocate memo ry either. Chris ======================================================================= 32 === Date: 6 Jun 1995 12:55:04 GMT From: vleuge00@marvin.informatik.uni-dortmund.de (Dirk Vleugels) Subject: Re: Installing the Linux bineries John Riley (johnr@juliet.ll.mit.edu) wrote: : I have unpacked the stripped binaries on my system but there doesn't : seem to be any directions on what to do next. Can anyone give me : any information on environment variables, links, etc. Same for me! Another question: I use the modula-3.3.4 (??) version and would like to use it with ILU-1.8. Is this possible? Any documentation available? : I will be grateful for any help. : Thanks, : JPR Dirk ======================================================================= 33 === Date: Tue, 6 Jun 1995 15:10:53 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: when NEW fails, revisited >When you really run out of memory all hell breaks loose. It is too late to >handle the case. If you want to handle running out of memory you'd have >to watch the free memory space and reduce allocating more memory long >before you will run out. > >Anyway, if you have an operating system, virtual memory will pitch >in when you run out of real memory. Most often the application might >start trashing long before it really runs out of virtual memory. > >The exception mechanism just isn't the right way to handle out of memory. >You need prevention, not recovery. > I'm aware of that but there are many examples of programs which currently handle running out of memory (by which I meant VM in any case) in a graceful manner. For example, in a gui application an appropriate approach might be to shut a window down. This is what the mail client does on my machine. I get an alert box telling me which window it is shutting, I click and it's done. No problem. The alternative is for the whole application to just exit sideways (as some others do). That often is a problem. Many systems set limits on the amount of memory (virtual) that a process can own. It is these limits we might hit. In fact it's one of those limits my mail client hits. Having VM limits is good. It prevents one process killing everything. But we have to be able to cope with them. How do we keep a check on memory? 1. The runtime system allows us to see how close we are to running out. 2. We define a threshold. 3. We do all our allocation through routines that check the above and then probably raise an exception when we run out. It would be much easier if we could devise some way of setting off an alarm when we hit some limit. ======================================================================= 34 === Date: 6 Jun 1995 18:00:38 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Re: when NEW fails, revisited In article <3qvnd6$g6l@mtv.acsys.com>, dave sims wrote: >What should I do when NEW fails to allocate memory? > >I recall the discussion in comp.lang.modula3 sometime back about >possible solutions and workarounds. However, I don't recall if anyone >agreed on anything. My guess is you'll have to pick one of these and implement it. I think deciding on the policy is the hard part. Myself, I would lean toward being able to register procedures (closures) that are called when memory runs out, and changing the allocator to call those procedures when memory runs out. This gives you a chance to try to reclaim memory or to try to terminate the address space gracefully. What do C/C++ programmers do about memory exhaustion? Norman ======================================================================= 35 === Date: Tue, 6 Jun 1995 17:53:32 GMT From: kominek@links.uwaterloo.ca () Subject: Re: Calling M3 from C : >How do I call Modula-3 procedures from inside some : >C code in release 3.5.2? : : It is a very good question to ask in fact, since a "good" answer : solves several problems that chain off one another. : : [ 4-level chain answer ] : : Spencer Allain E-mail: spencer@era.com You forgot to mention a salient point. One of the major forms of commercial software development is the creation and sale of libraries. The creation of good libraries is made easier by Modula-3, but if you want to stay in business they _must_ be callable from C. As it stands, application vendors can get down to work, but library vendors are not in a viable position. John Kominek --------------------------------- Department of Applied Mathematics University of Waterloo Waterloo, Ontario, Canada N2L 3G1 --------------------------------- ======================================================================= 36 === Date: Wed, 7 Jun 1995 08:58:15 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: when NEW fails, revisited <3r2546$qbt@lowell.bellcore.com>Cc: m3@src.dec.com In-Reply-To: <3r2546$qbt@lowell.bellcore.com> Distribution: world X-Received: from suneast.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3) X-Received: by src-mail.pa.dec.com; id AA08490; Wed, 7 Jun 95 06:10:42 -0700 X-Newsgroups: comp.lang.modula3 X-Received: from cloyd.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117 ) X-Received: from Sun.COM by inet-gw-2.pa.dec.com (5.65/24Feb95) X-Received: by cloyd.East.Sun.COM (5.x/SMI-SVR4) X-Received: from East.Sun.COM (eastmail1.East.Sun.COM) by Sun.COM (sun-barr.Sun .COM) X-Received: by src-news.pa.dec.com; id AA26152; Wed, 7 Jun 95 06:10:43 -0700 Norman Ramsey writes: > In article <3qvnd6$g6l@mtv.acsys.com>, dave sims wrot e: > >What should I do when NEW fails to allocate memory? > > > >I recall the discussion in comp.lang.modula3 sometime back about > >possible solutions and workarounds. However, I don't recall if anyone > >agreed on anything. > > My guess is you'll have to pick one of these and implement it. I > think deciding on the policy is the hard part. Myself, I would lean > toward being able to register procedures (closures) that are called > when memory runs out, and changing the allocator to call those > procedures when memory runs out. This gives you a chance to try to > reclaim memory or to try to terminate the address space gracefully. > I think the tough issues revolve around the issues of multithreading, especially on systems that allow threads to run concurrently on different processors. Maybe it's time for someone to go back and summarize the issues. > What do C/C++ programmers do about memory exhaustion? > Fail horribly...The only large system I've seen that actually dealt with memory allocation failure was CodeCenter/ObjectCenter. When the environment (as opposed to the application running in the environment) was unable to allocate more memory, it issued a dialog that allowed you to add more swap space. I imagine that all the resources necessary to create this dialog were statically allocated or allocated early during the initialization of the environment. --geoff ======================================================================= 37 === Date: 7 Jun 1995 18:23:25 GMT From: "Marc E. Fiuczynski" Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) It seems that it would be beneficial to the FSF to separate their backend from their frontend. Many of the backend optimizations are applicable to Fortran, Ada, M3, C and friends, and possibly other languages. The FSF already provides a set of nice compiler tools, and separating the backend would not only assist them in developing different frontends quickly, but allow projects, like SRC M3, to take advantage of their software. What would be required to separate the backend? I guess someone has to define an acceptable intermediate representation that the frontends compile to and then have the backend read that back in. This is what M3 does right now, however, I doubt that its the format that every other frontend will want to agree to. Marc cracauer@wavehh.hanse.de (Martin Cracauer) wrote: >dewar@cs.nyu.edu (Robert Dewar) writes: > >>"Does anyone know if the FSF will separate their backend more from their >>front ends? The current hack of adding a m3.c file to the gcc compiler >>is fine, but even SRC has problems using the gcc backend optimizations >>properly." > >>I doubt it, what possible FSF goal can be met by such a separation, it >>would seem to promote exactly that which FSF tries hard to prevent, the >>creation of proprietary technologies which make use of free software. > >I don't think so. IMHO, the only reason why the separation isn't done >is that noone spent the time on it. > >The GNU-Objective-C folks, for example, would be very happy to have >their frontend mixed with the C++ frontent to allow Objctive-C++ >programs. That would be much easier with a cleaner compiler >structure and better documentation would pull it out of deep magic so >that some mortal could do this. > >From what I heared, the FSF would be happy to make the gcc backend an >easier-to-use tool for language implementors. The backend has to be >modified anyway to allow better optimization for the deeper pipelines >of modern CPUs. > >If the current way to implement m3 causes major overhead, maybe the >time required for every m3-inside-gcc-backend release would be better >invested in turning gcc into something that causes less overhead. > >Martin ======================================================================= 38 === Date: Wed, 7 Jun 95 10:15:38 GMT From: cracauer@wavehh.hanse.de (Martin Cracauer) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) dewar@cs.nyu.edu (Robert Dewar) writes: >"Does anyone know if the FSF will separate their backend more from their >front ends? The current hack of adding a m3.c file to the gcc compiler >is fine, but even SRC has problems using the gcc backend optimizations >properly." >I doubt it, what possible FSF goal can be met by such a separation, it >would seem to promote exactly that which FSF tries hard to prevent, the >creation of proprietary technologies which make use of free software. I don't think so. IMHO, the only reason why the separation isn't done is that noone spent the time on it. The GNU-Objective-C folks, for example, would be very happy to have their frontend mixed with the C++ frontent to allow Objctive-C++ programs. That would be much easier with a cleaner compiler structure and better documentation would pull it out of deep magic so that some mortal could do this. >From what I heared, the FSF would be happy to make the gcc backend an easier-to-use tool for language implementors. The backend has to be modified anyway to allow better optimization for the deeper pipelines of modern CPUs. If the current way to implement m3 causes major overhead, maybe the time required for every m3-inside-gcc-backend release would be better invested in turning gcc into something that causes less overhead. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer . No NeXTMail, please. Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a private address. At (netless) work programming in data analysis. ======================================================================= 39 === Date: Wed, 7 Jun 1995 14:26:35 GMT From: freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman) Subject: Re: [C++ or M3] In article <199506012137.RAA12434@iris51> wds@research.nj.nec.com (Warren Smith ) writes: > QUESTIONS ABOUT MODULA 3 > > 1. I'm presently thinking about writing a chess program, > and if I do, it is going to be in either modula-3 or C++. > Anybody have any feedback on which is the better choice? how much time do you have? ;-) I'm an M3 exile, having been forced back to C++, and to me there is no question--I find myself spending, say, 40% of my time worrying about memory management (even with all the usual tricks) which, curiously, is about how much longer it takes me to write C++ programs. I also deeply miss having exceptions as part of signatures, partial revelations, lots of robust libraries (with no clashes over basic types such as strings), integrated threads, etc, etc. Furthermore, there are two very serious maintenance issues: 1) C++ provides no help getting your modules initialised in the right order. With threads spinning as well, this can be a major pain. 2) what can you expect from a language (ie. C++) in which you can read the statement 'a = b + c' and have _no_idea_ what it does. > 2. Has anybody got a set of benchmarks comparing C and modula-3 speed? > In particular something heavy in allocation and garbage collection? I don't as such, but I spent a summer at SRC implementing a desktop video widget that had also been implemented in C(++?)/Motif. The performance was comparable (ours was slightly slower but with slightly less latency). If allocation and GC is a real cost, you do like you do in C and manage free lists--except you don't worry about it at all until it proves a problem. > 4. I generally like modula-3 syntax, but the gratuitous refusal to > allow you to be concise annoys me. Why DO and THEN and BEGIN and END; > rather than (as in C) { and }? Less to remember, less to type, > editors with paren matching do the right thing, C syntax wins on all > counts here. If this is really a problem, then preprocess it :). Most of us seem to have got used to it, it can be clearer than parentheses--depending on your editing/pretty-printing environment, and the emacs mode does most of the work for you. This could be argued over but is surely not a reason for rejecting the whole language. > 5. I find it understandable that modula-3 does not have macros... > but they nevertheless can be useful. For instance, in my chess program > I want to represent the board with an array of 64 squares > ordered A1,B1,...H1,A2,...H2,...A8,...H8. > In C I can initialize arrays using a 64-argument macro > boardfull(x1,...,x64) > which allows me to use a picture of the board in array initializations > > RankForWhite[] = boardfull( > 7,7,7,7,7,7,7,7, > 6,6,6,6,6,6,6,6, > 5,5,5,5,5,5,5,5, > 4,4,4,4,4,4,4,4, > 3,3,3,3,3,3,3,3, > 2,2,2,2,2,2,2,2, > 1,1,1,1,1,1,1,1, > 0,0,0,0,0,0,0,0); > > and it would be the wrong thing (chess-wise) if it had to be > RankForWhite[] = {0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,...7,7,7,7,7,7,7,7}; > > So C macros increase my expressive power and make my program readable > in this instance. Modula-3? Noooo! How does a 64-argument macro differ from a 64-argument procedure to do the same thing? Furthermore, in this particular case, I think you can use structure assignments, so it looks the same anyway. (someone back me up on this?). > 6. Another thing I can use macros for in C (I admit, it is disgusting > looking and I hate to do it) is to make custom iterators. E.g. in chess: > loop over all pieces attacking square X { stuff; } > There appears to be no way to make custom iterators in modula-3? this is an issue of program structure, and depends on how you write your looping code. You could write an iterator object (maybe there's one already in a library) with 'test' and 'apply' methods so the loop would like: FOR i := 0 TO LAST(array) DO IF iterator.test(array[i]) THEN iterator.apply(array[i]) END; END; much clearer than hiding it all in a macro. Check out the Patterns book (Gamma et al) for lots of descriptions of this sort of stuff. > 7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor > DEC alpha machine? Or will the compiler just put all threads on a single > one of those 4 processors...? pass. finally, you might note that there is only one Modula-3 definition, which is clear and implementable. A significant issue with C++ is which implementation of which dialect you intend to choose. good luck, steve -- - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Steve Freeman, Research Scientist, Rank Xerox France. Surface: Rank Xerox Research Centre, 6, chemin de Maupertuis, 38240 Meylan, France. Internet: steve.freeman@xerox.fr Phone: +33 76 61 50 21 Fax: +33 76 61 50 99 but wotthehel wotthehel toujours gai -- mehitabel the cat ======================================================================= 40 === Date: 7 Jun 1995 08:35:43 GMT From: pucci@cli.di.unipi.it (Igor Pucci) Subject: modula3 from C ======================================================================= 41 === Date: 8 Jun 1995 15:30:05 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) > >I doubt it, what possible FSF goal can be met by such a separation, it > >would seem to promote exactly that which FSF tries hard to prevent, the > >creation of proprietary technologies which make use of free software. > > I don't think so. IMHO, the only reason why the separation isn't done > is that noone spent the time on it. No. I recently talked to Richard Stallman on the phone. He is quite concerned that the current technique used by the Modula-3 compiler will subvert the FSF goals. The FSF CopyLeft virus does not infect programs across process boundaries. You must link with FSF code to become infected. So, the SRC Modula-3 front-end is not infected. We could charge a bundle for anyone using it :-). In principle, compiling to C and using gcc out-of-the-box as a backend produces the same result. But, C isn't a very good intermediate language and it makes it quite difficult to get reasonable debugging information into the symbol tables. - Bill Kalsow ======================================================================= 42 === Date: 07 Jun 1995 19:04:09 GMT From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) Subject: Re: when NEW fails, revisited In article <3r2546$qbt@lowell.bellcore.com> norman@flaubert.bellcore.com (Norman Ramsey) writes: [...] |> What do C/C++ programmers do about memory exhaustion? Core dump. -- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France Conseils en informatique industrielle -- -- Beratung in industrieller Datenverarbeitung ======================================================================= 43 === Date: 7 Jun 95 08:32:22 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: when NEW fails, revisited I too would like to see an implementation that allows the possibility of recovery when the application runs out of memory. I'd also like that generalised to cope with other kinds of runtime failure. The exception mechanism seems to be the most appropriate choice. Perhaps as an intermediate step, would it be possible to provide us with a new NEW which raises an exception for out of memory. I presume at least one major problem is that the recovery may fail because of lack of memory. We might at least get a chance to keep going though. A very long and detailed explanation about why this was extremely difficult was posted by the DEC SRC people about 6 months ago. You should be able to find it in the archives in: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3 -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 44 === Date: 8 Jun 95 12:20:43 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: [C++ or M3] In article <3r69u4$8hb@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) wri tes: In article , nayeri@gte.com (Farshad Naye ri) writes: |> |>[interesting things about threads cut] [someone thinks that M3 syntax is heavy and I agree] | |> I agree with Steve's sentiments about the syntax. You can either |> accept it or just pre-process "your own" syntax into M3. One such |> syntax was created by Andrew Myers at MIT. Now the question, I'd like to see this "modified" syntax, is this available on the net ? Thanks. (Note that Andrew's syntax still keeps the "end", I think, but takes away other things that annoys some people like upper-case keywords, and semicolons.) (From a posting in Feb 1994:) 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). [Can we put this in the FAQ answers, if it isn't already, and I am stating to feel a distinct need for a gopher service that allows interactive searches over the M3 postings. I never can figure out how to make kwic work. Perhaps this is another FAQ.] -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 45 === Date: 08 Jun 1995 21:51:24 GMT From: jackg@downhaul.crc.ricoh.com (Jack Greenbaum) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <3r4qqt$rkj@nntp5.u.washington.edu> "Marc E. Fiuczynski" writes: It seems that it would be beneficial to the FSF to separate their backend from their frontend. Many of the backend optimizations are applicable to Fortran, Ada, M3, C and friends, and possibly other languages. [...] What would be required to separate the backend? I guess someone has to define an acceptable intermediate representation that the frontends compile to and then have the backend read that back in. What am I missing here? The gcc intermediate representation, RTL, is quite seperate from the front end parse tree representation, the "tree" data structures. RTL is the most well documented part of GCC, while building a new front end is certainly black magic. So what parts of RTL back end are people complaining about being tied to the front end? Is it that you bascially have to use the GCC front end to make RTL that is the complaint? -- Jack Greenbaum -- Research Engineer, Ricoh California Research Center --------------------------------------------------------------------- Digital: jackg@crc.ricoh.com | http://www.crc.ricoh.com/~jackg --------------------------------------------------------------------- Analog: (415) 496-5711 voice | 2882 Sand Hill Rd. Suite 115 (415) 854-8740 fax | Menlo Park, CA 94025-7002 --------------------------------------------------------------------- -- Jack Greenbaum -- Research Engineer, Ricoh California Research Center --------------------------------------------------------------------- Digital: jackg@crc.ricoh.com | http://www.crc.ricoh.com/~jackg --------------------------------------------------------------------- ======================================================================= 46 === Date: 7 Jun 95 18:59:12 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: [C++ or M3] In article freeman@c oolidge.coolidge.grenoble.xerox.fr (Steve Freeman) writes: Warren Smith says: > 7. Do "threads" in modula-3 really run in parallel on, e.g. a 4-processor > DEC alpha machine? Or will the compiler just put all threads on a single > one of those 4 processors...? pass. I will pick up where Steve left off. The language definition allows both cases. The exact behavior depends on the implementation of M3 threads on a particular platform (but the Thread INTERFACE general semantics are preserved even in the multi-processor case.) If the M3 thread implementation uses native threads (like the Windows port of SRC Modula-3), and if native threads are allocated to various processors by the operating system, then you will have multiple threads "really" run in parallel. Geoff Wyant is working on a port to Solaris 2 native threads. There also possibilities for exploiting parallelism via Network Objects. I seem to recall someone at Caltech doing this, but it may be an overkill for your uses. With comparable amount of work done, I think you'd do better with Modula-3. (I am speculating that) your chess program may involve a lot of search, which means heavy use of memory management to keep things sane, and coordinating multiple threads for the search. The integrated threads and garbage collection make it easy to "alert" a thread to abort and not worry too much about the memory that was allocated to it. If you are interested in doing a GUI for your system, it probably is easier to do GUIs for concurrent programs using Trestle. It is also easy to learn and well-documented; this way you can forget the X event loop for the most part. I agree with Steve's sentiments about the syntax. You can either accept it or just pre-process "your own" syntax into M3. One such syntax was created by Andrew Meyers at MIT. -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 47 === Date: 08 Jun 1995 15:43:25 GMT From: hudson@cs.umass.edu (Rick Hudson) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) When one discusses seperating the front end from the backend we need to remember that as languages advance the need to pass semantic information to the backend only increases. For example, accurate garbage collection requires the gcc backend to understand object data structures so it can distinguish between pointers to TRACED objects and pointers to UNTRACED objects. This information must be combined with backend tasks such as stack frame layout. Add requirements like debugging optimized code and we start to see an increased amount of 'front end' knowledge needed by the backend. - Rick -- Richard L. Hudson - Hudson@cs.umass.edu; (413) 545-1220; Advanced Languages Project - University Computing Services Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 ======================================================================= 48 === Date: 8 Jun 1995 18:14:25 GMT From: tlh20@thor.cam.ac.uk (Tim Harris) Subject: Re: Help with WWW documentation of M3 sources >> 2. If I view that copy using Netscape 1.1 from a Mac, all >> the HTML markup codes are displayed. Looks ugly; not >> usable. Netscape is thinking the file is a text file. This is likely to be because the server told it that it was a text file :-). I had this problem on my machine using the NCSA httpd. The work-around is to modify the mime-types file in the configuration directory (by default I think that's /usr/local/etc/httpd/conf) and find the line starting text/html. This line lists file extensions for which the daemon should tell the client that the file is HTML, so adding i3 and m3 on the end should make them be recognised correctly. Admittedly the word starting with k and ending with ludge springs to mind (what if another user has a normal modula-3 program which they want to be available as text?) - but I think that's about as well as it can be done without large-scale changing of the links in the M3 files. Hope it works! tim -- ---------- Tim Harris | --'What shall we do tonight Brain?' "The same thing 46k Churchill College | ---we do every night, Pinky, we're going to take over ----Cambridge CB3 0DS | ---the world" - Pinky and Brain, who are cartoon mice ------tlh20@cam.ac.uk | - http://www.chu.cam.ac.uk/home/tlh20/home.html ------ ======================================================================= 49 === Date: 9 Jun 1995 00:14:38 GMT From: pbh@cs.sunysb.edu (Peter B. Henderson) Subject: Comments on Chess Playing Program I am posting this for Warren Smith. Maybe of interest to some of you. -- Peter B. Henderson pbh@sbcs.sunysb.edu Department of Computer Science, SUNY at Stony Brook Stony Brook, N.Y. 11794-4400 -------- Warren's comments start here -------- Tests of runtime speed modula-3 vs C, also comments on language choice for implementing a chess playing program. ---------------------------------------------------------------------- By Warren D. Smith, wds@research.NJ.NEC.COM (Now also T, Chez Scheme, and Standard ML of New Jersey, thanks to Kevin Lang and Andrew Wright for writing those. This arose from my desire to write a chess program and decide between C and m3.) test1: a 1000000 iter loop with a bunch of bit-ops and array accesses. Incidentally this test reveals that neither C nor modula-3 compilers have tables of special cases of common operations, such as, e.g. x MOD 64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x, etc. Pretty damn stupid of certain compiler writers. (Later note.... actually C does have some such optimizations, but only for unsigned ints...) test2: make a 1000 node binary tree and do a 1000000 random insertions and deletions from it. (Tests data structures and malloc/free/garbage collect.) fib: find fibonacci(33)=5702887 by the slow (exp time) recursion. Tests recursion. josephus: go round a 200000 element circular list deleting every 47th guy until 1 left. (Tests linked lists and malloc/free/garbage collect.) test3: 10000000 iter loop with heavy flow control via if/else and a bunch of bit and array ops. Mildly similar in some ways to hottest code (sweep moves) in chess prog "flea". chesstest: an entire small chess program, material only eval, search to depth 4 + quiescence on all 299 reinfeld WAC test positions. (also tried gelfer testset.) A sad thing happened on this test program: it crashed the m3 compiler!!! However, Garrett was able to find the compiler bug and modify my program to avoid exciting it. Results (runtime in user sec on iris51): gcc gcc -O5 cc -O4 m3 m3 -O t chezO3 sml test1 97.3 43.6 45.5 142.5 51.7 test2 12.2 9.8 9.8 24.9 26.7 (!) fib 14.5 9.5 5.9 10.1 10.1 8.2 21.0 11.3 josephus 12.3 7.3 6.5 35.8 31.0 16.4 17.5 9.5 test3 23.8 6.2 8.1 16.8 8.7 27 58 31 the following were run on zeitgeist instead of iris51, and cc -O2 not O4. chesstest WAC 42.5 69.0 chesstest gelfer 49.4 79.2 I am still tempted to go with modula-3 over C++, despite paying a factor of 3-5 on linked list malloc'd and garbage collected stuff (and I am also informed that nested subroutine declarations and calls to procedures passed as parameters, will be slower in m3 than C), because I know the main time consumer in a chess prog will be bit-op and array and recursion stuff, and on this, the time hit is only a factor of 1.1-1.7. In our chess test the runtime ratio was 1 : 1.62. I suspect that upon tweaking the hot parts of the code in both C and m3 for more speed, that more will be gained in the m3 tweaking than in the C tweaking since we can put the hot m3 code portions in small "unsafe modules" in which runtime checking is turned off. So in chess I suspect the final runtime ratio will be a factor of 1.3, not 1.6. This is acceptable. On the other hand, the factor 4-9 runtime hits in chezO3, sml, and T on test3, make them unnacceptable. But the garbage collection / malloc / pointer following performance of sml (josephus) is very impressive; one wishes m3 could duplicate it... The reasons (ignoring speed) why m3 is the right language for a chessprog are: it is designed to support large multimodule programs, C was not (only as an afterthought) and the safety of m3 (no memory leaks! no out of bounds array accesses!) will lead to tremendous reduction in debugging time. Also m3 is easier to learn than C++ and there is a nice online HTML tutorial for it. The main reasons to prefer C over m3 are, in my view, ones of language support. Kalsow at DEC SRC tells me that DEC has 1.5 people working full time to support m3, and m3 is only a "research project" not an officially supported "product". For C, it is 1000s of programmers. Under those circs, that m3 compiler crash scared the shit out of me. The m3gdb debugger does not work on our SGI machines but does work on our LINUX machines. The m3pp pretty printer is rather poor performing and buggy (the cb C beautifier isnt so great either, though). Feedback I get from net people: > Which is better for a chess prog, C or m3? kalsow@pa.dec.com (Bill Kalsow, mr. Modula-3) That depends on whether you're going to use any of the features of Modula-3 that aren't in C++ (e.g. threads, garbage collection, a rich standard library) or vice versa (e.g. multiple inheritance, operator overloading). It is for large multifile programs that m3 really shines. [WDS: all this favors m3 for me.] > Can I trust SRC to support me and fix such bugs fast? Richard Watts (rrw1000@cam.ac.uk): By and large, yes. I've never known them not to fix a bug they have been provided with the fix for [WDS: Oh, great. This is what the software community calls "good"], and they're by and large very good at fixing errors in new releases. That said, obscure bugs for which you haven't got a fix or good tracing information, or machine-specific bugs for platforms SRC haven't got tend not to be fixed by SRC - people like me get to them first :-). > m3gdb debugger? m3gdb is temperamental at the best of times. I've just about given up on it myself as being more trouble than it's worth :-(. Luckily, M3 is sufficiently clear that code walk-throughs and diagnostics seem to work almost as well. > I am sure modula-3 is the better choice, EXCEPT > that it looks to me like DEC has pretty much thrown it > to the wolves and don't officially support it, etc. Tim Mann : "DEC has thrown it to the wolves" is not an accurate picture. Modula-3 has *always* been a research project, completely unsupported except for the time that a few folks here at the Systems Research Center (and elsewhere) are able to put into it. You cannot expect support. After all, you are not paying for support, nor is anybody else. It is much like GNU software---user supported. Nevertheless, the people working on it here are very good, and the user community is growing. The decision is similar to deciding whether to base part of your project on some GNU software. Peter Moylan : Here's a useful hint to people, like me, who have to do some projects in C but are unhappy about the exorbitant time C demands for program design and maintenance. A year or two ago I tried the experiment of developing a C program by first writing it (and testing it, of course) in Modula-2, and then hand-translating it into C. This really works! Not only did I get a program that was more readable and maintainable than usual, but the initial development time went down quite substantially. Since then I've done all my C programming that way. Sure, at first sight it sounds as if you're doing double the work. But, believe me, you really do win in terms of time invested. The hand-translating is somewhat tedious, but not as bad as you might at first think. The reason it's a win is mostly due to the fact that you spent practically no time on debugging. ------------------ I think the Moylan experiment says it all. In the worst case, where the m3 compiler completely blows up on us and we have to translate our enitre m3 program into C (probability = 0.1) we lose a month, but according to Moylan, we would have gained more than a month anyway! I think the probability is more like 0.3 that, if we try to write it in C++, I will end up going nuts with bug explosions. And by use of RCS to keep track of versions, we can easily go back to the latest version which did not excite an m3 compiler bug, so it will not be that hard to avoid them (I hope...). ------------------------------------ From: Warren D. Smith (Research Staff; Library Committee Chair) NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA Phone: (609) 951-2717 Web: http://www.neci.nj.nec.com/homepages/smith.html Email: wds@research.NJ.NEC.COM Fax: (609) 951-2496 ("for W.D.Smith 1D04" ======================================================================= 50 === Date: 08 Jun 1995 23:09:24 GMT From: eric@telebit.com (Eric Smith) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article dewar@cs.nyu.edu (Robert Dewar) writes: > I doubt it, what possible FSF goal can be met by such a separation, it > would seem to promote exactly that which FSF tries hard to prevent, the > creation of proprietary technologies which make use of free software. While I doubt they'll do it, I don't think it is in any way inconsistent with their goals. If they get people to write front ends (proprietary or not) for their back end, that will get more people to use their copylefted back end, and will eventually get people to write more copylefted front ends. ======================================================================= 51 === Date: 8 Jun 95 18:58:24 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: src-m3 for Linux In article <3r69vi$ioq@martha.utk.edu> elemings@unix1.utm.edu (Eric Lemings) wr ites: What directory can I find the SRC distribution on gatekeeper.dec.com? gateekeeper.dec.com:/pub/DEC/Modula-3. The subdirectory "release-3.5.2" is the most current release. 3.5.3 is in testing phase right now. -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 52 === Date: 9 Jun 1995 01:58:07 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article eric@telebit.com (Eric Smith) writes: >While I doubt they'll do it, I don't think it is in any way inconsistent >with their goals. If they get people to write front ends (proprietary or >not) for their back end, that will get more people to use their copylefted >back end, and will eventually get people to write more copylefted front ends. No, you misunderstand the priorities of the FSF. The most important goal, by far, is preventing free software from being subverted and used in a proprietary fashion. Everything else, including trying to increase use of FSF software, is a distant second. ======================================================================= 53 === Date: 8 Jun 1995 07:47:16 GMT From: hebert@prism.uvsq.fr (Renaud HEBERT) Subject: Re: [C++ or M3] In article , nayeri@gte.com (Farshad Nayeri) writes: |> |>[interesting things about threads cut] [someone thinks that M3 syntax is heavy and I agree] |> I agree with Steve's sentiments about the syntax. You can either |> accept it or just pre-process "your own" syntax into M3. One such |> syntax was created by Andrew Meyers at MIT. No the question, I'd like to see this "modified" syntax, is this available on the net ? Thanks. |> |> -- Farshad |> |> -- |> Farshad Nayeri |> nayeri@gte.com |> |> ``Obviously, in each of these cases design decisions have been made, |> but unfortunately they were wrong.'' --Victor Papanek, |> Design for the Real World -- Renaud HEBERT E-mail: Renaud.Hebert@prism.uvsq.fr Serveur Mosaic: http://www.prism.uvsq.fr ======================================================================= 54 === Date: 7 Jun 1995 22:00:04 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <3qvn3l$bue@nntp5.u.washington.edu> "Marc E. Fiuczynski" writes: >Does anyone know if the FSF will separate their backend more from their >front ends? The current hack of adding a m3.c file to the gcc compiler >is fine, but even SRC has problems using the gcc backend optimizations >properly. They have been separated since GCC 2.6.0. Each language front-end resides in its own subdirectory from GCC. The configure script looks for which languages you have (by searching all subdirectories for Make-lang.in) and stitches things together. ======================================================================= 55 === Date: 09 Jun 1995 15:58:20 GMT From: nayeri@gte.com (Farshad Nayeri) Subject: When NEW fails (summary) The following is my summary (in form of question and answers) on the topic of dealing with allocation failure in SRC Modula-3. The questions and answers are based on my interpretations and do not represent opinions of the participants in the conversation. I'd be happy to hear from you about corrections or include your contributed Q&A's on this topic. The detailed account of some of the postings (as well as this summary) is filed as: ftp.gte.com:/pub/m3/notes/When-NEW-fails.txt. -- Farshad When New Fails or Dealing With Allocation Failures in Modula-3 Q: What does SRC Modula-3 do when NEW is called and virtual memory is exhausted? A: It crashes with a checked run-time error. Q: The fact that NEW crashes if there is not enough memory is inconvenient. Why can't we have it raise an exception or return NIL? A: Chaning NEW semantics at this point is difficult since so many programs are not prepared to deal with an exception or a NIL result. In fact, to have NEW raise an exception means that you need to be aware of this exception practically at all times. This will affect most Modula-3 programs which don't care about such conditions. Q: So, changing NEW is not the right thing to do. What about having an internal routine such as RTAllocator.New* to return either a NIL or raise an exception. In the future such an interface can become part of the 'standard'. A: This makes more sense, but we still need to find out what the semantics of such an interface would be and how to go about implementing it. As for it becoming a part of the 'standard', it may restrict implementations too much to put this into the standard. Q: As for the semantics of RTAllocator.New*, why not call some programmer-defined handler when memory is low, like what C++ implements "new"? This way the programmer can allocate a 'safety net' block of memory and register a callback that will free the safety net, sets a flag, and returns. The handler is called upon an out-of-memory condition and the callers of NEW can check for the flag and when it is set, they will treat the call to NEW as invalid. A: This solution includes a race condition since another thread could run and do an allocation between the time the faulting NEW returns and when the handler's actions take place. (Perhaps this can be mimimized by adding some slop to the safety net.) In general, it is hard to come up with a mechanism that will work well in a multi-threaded environment. First, the procedures notified can't acquire locks or call most procedures in other modules. Second, it requires a new collection to run synchronously after the procedures to see if enough space has been freed and whether some of the procedures must be called again; this causes an interruption of service. [I need to be convinced of this.] Q: What about having a thread to sit in the background and monitoring the allocator's limits, or have the programmer check before allocating something if there is enough room for it? A: Unfortunately, since the collector can't move some of the objects, it is hard to predict if for example, 1M free heap would allow a 1M object could be allocated. A fragmented 1M heap wouldn't allow allocation of 1M objects, because some objects may be "pinned down" in the heap by the collector. Q: Why can't we ask the collector what is the largest contiguous space available at the moment? Surely if I ask for something smaller than the largest contiguous space currently available I should be able to get at it. This may be too optimistic in many cases but it may work for programs that want to be "extra careful". A: [Presumably this is going to be too small for most cases? Or that garbage collectors don't have the information available easily.] Q: Maybe we could operate in a failsafe mode at all times, where the allocator always allocates enough to make sure it will make it to the next collection. A: Yes, a complicated scheme like this is possible, but it is messy and will involve a lot of work. Besides, it is not clear if it will be that useful. Q: What do most C programs do in low memory conditions? A: Most of them fail with an unchecked run-time error. There are few carefully programmed applications that avoid this problem. Some examples are multi-window GUI applications that close some windows in low-memory conditions. Some (such as GNU Emacs) don't allow the user to allocate the memory until some more memory is gathered. But most C programs are single-threaded which will make this problem easier to deal with. Q: What do multiple threads have to do with this? A: If RTAllocator.New* raises an exception when the memory is too low (and therefore stop you from allocating), how are you going to stop other threads from allocating more memory? Q: What if you set a flag, alert all the threads to terminate, and then raise an exception? A: This is quite messy! Q: I want to deal with low-memory situations now. Which interface do I use to look up how much heap there is, etc.? A: [Don't know.] Q: So, what is this all good for? A: Someone's master's project! Any volunteers? -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 56 === Date: 9 Jun 95 08:11:46 GMT From: Iovely1@aol.com Subject: ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles --------------------- Forwarded message: Subj: ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles Date: 95-06-08 23:58:25 EDT From: Iovely1 To: comp.society.futures@paris.ics.uci.edu To: universe.net.events@paris.ics.uci.edu To: bit.listserv.sportpsy@paris.ics.uci.edu To: rabbit.customers@paris.ics.uci.edu To: resif.info.amiga@paris.ics.uci.edu To: alt.sports.basketball.nba.hou-rockets@paris.ics.uci.edu To: bionet.molbio.evolution@paris.ics.uci.edu To: uiuc.ncsa.hci@paris.ics.uci.edu --------------------- Forwarded message: Subj: ==>FREE 1yr MagazineSub sent worldwide-314 Popular USA Titles Date: 95-06-08 23:37:57 EDT From: Iovely1 To: bionet.metabolic-reg@paris.ics.uci.edu To: sfnet.harrastus.visailu@paris.ics.uci.edu To: uk.lisp@paris.ics.uci.edu To: uk.media@paris.ics.uci.edu To: uk.misc@paris.ics.uci.edu To: uk.net@paris.ics.uci.edu To: pdx.music@paris.ics.uci.edu To: pdx.online@paris.ics.uci.edu CHEAPEST USA MAG SUB AGENCY - SHIPS WORLDWIDE + FREE 1yrSUB Hi, my name is Susan Loring and I recently started using a magazine subscription club in the USA that has a FREE 1 yr. magazine subscription deal with your first paid order- and I have been very pleased with them. They have over 1,500 different USA titles that they can ship to any country on a subscription basis. They saved me a lot of money on my Economist subscription: over $40 off the best subscription price on I had seen anywhere else and they got me a great deal on USA Today newspaper, which arrives the same day as the cover date. (I still don't know how they manage to do that!) They will send you some FREE info. via E-mail (the short version (around 40K) of their catalogue, or if you request it the DELUXE LONG VERSION (around 400K-big and juicey) !)...if you fill out the form below. Please do not email me as I am just a happy customer and a *busy* student. I don't have time to even complete my thesis in time, let alone run my part-time software business! Email them directly at: julie12@freenet.fsu.edu *------------cut here-----------------------------------------------* REQUEST FOR MORE INFO: please copy this section *only* and email to: julie12@freenet.fsu.edu (sorry, but they cannot acknowledge incomplete forms sent back) Name: Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Name of USA mags you currently get: Name of USA mags you would like price quotes on when we call you: Do you want the short (~40K) or long version (~400K) of our catalogue emailed to you?: How did you hear about us (name of person who referred you or the area of the internet that you saw us mentioned in): Susan Loring 060995 par *------------cut here-----------------------------------------------* They guarantee to beat all their competitors' prices. Sometimes they are less than half of the next best deal I have been able to find and other times, just a little cheaper - but I have never found a lower rate yet. They assured me that if I ever do, they will beat it. They have been very helpful and helped me change my address from the USA to Finland and then back again when I moved last month. They are very knowledgeable about addressing mags worldwide. They have a deal where you can get a free 1 yr. sub to a new magazine from a special list of over 300 popular titles published in the USA. They will give you this free 1 yr. sub when you place your first paid order with them to a renewal or new subscription to any of the over 1,500 different popular USA titles they sell. They can arrange delivery to virtually any country and I think they have clients in around 35 or 36 countries now. Outside the USA there is a charge for foreign postage and handling (on both paid and freebie subs) that varies from magazine to magazine. I have found their staff to be very friendly and courteous. They even helped me with an address change when I moved from one country to another. The owner thinks of his service as a "club" and his clients as "members" (even though there is no extra fee to become a member - your first purchase automatically makes you a member) and he is real picky about who he accepts as a new member. When he sets you up as a new member, he himself calls you personally on the phone to explain how he works his deal, or sometimes he has one of his assistants call. He is kind of quirky sometimes - he insists on setting up new members by phone so he can say hi to everyone (I sure wouldn't want to have his phone bills!), but you can place future orders (after your first order) via E-mail. He has some really friendly young ladies working for him, who seem to know just as much as he does about this magazine stuff. If you live overseas, he will even call you there, as long as you are interested, but I think he still makes all his overseas calls on the weekends, I guess cause the long distance rates are cheaper then. He only likes to take new members from referrals from satisfied existing members and he does virtually no advertising- so you can email me and I will forward your message on to him as a referral. When I got set-up, they had a 2-3 week waiting list for new members to be called back so that they could join up. (Once you are an existing member, they help you immediately when you call. ) I think they are able to get back to prospective new members the same day or within a few days now, as they have increased their staff. I am not sure about this.........but if you email the above form to them, that is the way to get started! They will send you some FREE info. via E-mail (the short version (around 40K) of their catalogue, or if you request it the DELUXE LONG VERSION (around 400K-big and juicey) !)...if you fill out the form near the top of this message. They then send you email that outlines how his club works and the list of free choices that you can choose from, as well as the entire list of what he sells; and then they will give you a quick (3-5 minute) friendly, no-pressure no-obligation call to explain everything to you personally and answer all your questions. Here is a list of some of the 1500+ titles that they sell (for your free selection with your first paid order, approximately one-fifth of these appear on their special freebies list). ACCENT ACCENT ON LIVING ACCESSORIES ACTION COMICS ACTION PURSUIT GAMES ADIRONDACK LIFE ADVENTURE WEST ADVENTURES OF SUPERMAN (COMIC) ADVERTISING AGE ADVOCATE AFRICAN PROFILES INTERNATIONAL AIR CLASSICS AIR COMBAT AIR FORCE TIMES AIR & SPACE ALASKA ALASKA MEN ALASKA OUTDOORS ALBUQUERQUE MONTHLY ALFRED HITCHCOCK MYSTERY ALLURE ALOHA AMATEUR RADIO TECHNICAL JOURNAL AMAZING SPIDERMAN (COMIC) AMERCAN HEALTH AMERICA'S CIVIL WAR AMERICAN ARTIST AMERICAN ASTROLOGY AMERICAN BABY AMERICAN BABY AMERICAN CAGE BIRD AMERICAN COLLECTOR'S JOURNAL AMERICAN COTTON GROWER AMERICAN COWBOY AMERICAN COWBOY AMERICAN DEMOGRAPHICS AMERICAN FORESTS AMERICAN FRUIT GROWER AMERICAN HANDGUNNER AMERICAN HEALTH AMERICAN HERITAGE (HARD COVER) AMERICAN HERITAGE INVENTION & TECHNOLOGY AMERICAN HERITAGE (SOFT COVER) AMERICAN HISTORY ILLUSTRATED AMERICAN JOURNAL OF MATERNAL / CHILD NURSING AMERICAN JOURNAL OF NURSING AMERICAN LIQUIDATION MONTHLY AMERICAN PHOTO AMERICAN SALON AMERICAN SPECTATOR AMERICAN SQUARE DANCE AMERICAN VEGETABLE GROWER AMERICAN VISIONS AMERICAN WOODWORKER AMERICANA AMERICAS (ENGLISH) AMERICAS (SPANISH) AMIGA WORLD ANALOG SCIENCE FICTION / FACT ANTIQUE TRADER WEEKLY ANTIQUES ANTIQUING AMERICA AQUARIUM FISH ARCHAEOLOGY ARCHITECTURAL DIGEST ARCHITECTURE ARIEL ARMY TIMES ART & ANTIQUES ART & ANTIQUES INVESTMENT REPORT ART IN AMERICA ARTIST'S MAGAZINE ARTNEWS ARTS & ACTIVITIES ASIAN SOURCES (COMPUTER PRODUCTS) ASIAN SOURCES (ELECTRONIC COMPONENTS) ASIAN SOURCES (ELECTRONICS) ASIAN SOURCES (GIFTS & HOME) ASIAN SOURCES (HARDWARE) ASIMOV'S SCIENCE FICTION ASTROLOGY ATLANTA ATLANTA HOMES & LIFESTYLES ATLANTIC MONTHLY AUDIO AUDIO / VIDEO INTERIORS AUDUBON AUTO RACING DIGEST AUTOMOBILE AUTOMOTIVE NEWS AUTOMUNDO AUTOTRONICS AUTOWEEK AVENGERS (COMIC) AVENGERS WEST COAST (COMIC) AVIATION HERITAGE BACK STAGE BACKPACKER BACKSTRETCH BALTIMORE BANK NOTE REPORTER BARBIE (COMIC) BARBIE FASHION BOOK (COMIC) BARBIE MAGAZINE BARELY LEGAL BARTER NEWS BASEBALL CARD PRICE GUIDE BASEBALL CARDS MAGAZINE BASEBALL DIGEST BASEBALL WEEKLY (USA TODAY) BASKETBALL DIGEST BASKETBALL WEEKLY BASS PLAYER BASS & WALLEYE BOATS BASSIN' BATMAN (COMIC) BEAVIS & BUTTHEAD BERKSHIRE BEST RECIPES BETTER HOMES & GARDENS BEVERAGE WORLD BEVERAGE WORLD BIBLE REVIEW BIBLICAL ARCHAEOLOGY REVIEW BICYCLE GUIDE BICYCLING BIG BEAUTIFUL WOMAN (BBW) BIRD TALK BIRDER'S WORLD BLACK AXE (COMIC) BLACK BELT BLACK COLLEGIAN BLACK ELEGANCE BLACK ENTERPRISE BLOOD HORSE BLUE & GOLD ILLUSTRATED BOARDROOM REPORTS BOATING BOATING WORLD BODY - MIND - SPIRIT BON APPETIT BOSTON MAGAZINE BOTTOM LINE / PERSONAL BOW & ARROW BOW & ARROW HUNTING BOW HUNTING WORLD BOWHUNTER BOWHUNTING BOWHUNTING WORLD BOWLING DIGEST BOWMASTERS BOXING ILLUSTRATED BOY'S LIFE BRIDAL GUIDE BRIDES BRITISH CAR BRITISH HERITAGE BROADCASTING BUCKHUNTERS DIGEST BUENHOGAR BUSINESS PUBLISHING BUSINESS START-UPS BUSINESS WEEK BUZZ (TALK OF LOS ANGELES) BYTE CABLE (COMIC) CALIFORNIA JOURNAL CAMCORDER CAMERA & DARKROOM CAMPUS LIFE CANDY INDUSTRY CANOE CAPPER'S CAPTAIN AMERICA (COMIC) CAR AUDIO & ELECTRONICS CAR COLLECTOR & CAR CLASSICS CAR CRAFT CAR & DRIVER CAR STEREO REVIEW CARAS DE PUERTO RICO CARD COLLECTOR'S PRICE GUIDE CARIBBEAN TRAVEL & LIFE CARS & PARTS CASH SAVER CAT FANCY CATALOG SHOPPING CATHOLIC DIGEST CATHOLIC FAMILY BIBLE CATTLEMAN CATWOMAN (COMIC) CD REVIEW CD-ROM TODAY CD-ROM WORLD CENTRAL FLORIDA CAREER GUIDE (W/UPDATES) CHAMPION CROSSWORD PUZZLES CHAMPION VARIETY PUZZLES CHAMPION VARIETY REVIEW CHANGES CHARISMA & CHRISTIAN LIFE CHATELAINE (IN ENGLISH) CHATELAINE (IN FRENCH) CHESAPEAKE BAY CHEVY HIGH PERFORMANCE CHIC CHICAGO CHILD CHILD LIFE CHILDREN'S ALBUM CHILDREN'S CLASSICS CHILDREN'S DIGEST CHILDREN'S PLAYMATE CHOCOLATIER CHRISTIAN HISTORY CHRISTIAN PARENTING TODAY CHRISTIAN READER CHRISTIAN SCIENCE MONITOR CHRISTIANITY TODAY CIRCLE TRACK CIRCUS CIVIL WAR CHRONICLES CIVIL WAR TIMES CLASSIC AUTO RESTORER CLEVELAND MAGAZINE COACH COIFFURE DE PARIS COIN PRICES COIN WORLD COINAGE COINS MAGAZINE COLLECTOR EDITIONS COLLECTORS MART COLLECTORS NEWS COLLECTORS NEWS COLLEGE SPORTS COLONIAL HOMES COLORADO BUSINESS COLORADO HOMES & LIFESTYLES COLUMBIA JOURNALISM REVIEW COMIC BOOK COLLECTOR COMIC BOOK COLLECTOR'S PRICE GUIDE COMIC SCENE COMICS BUYERS GUIDE COMICS SCENE COMMON CAUSE COMMONWEAL COMPUTER GAME REVIEW & CD-ROM ENTERTAINMENT COMPUTER GAMING WORLD COMPUTER LIFE COMPUTER SHOPPER COMPUTERWORLD CONAN CLASSICS (COMIC) CONAN SAGA (COMIC) CONAN THE ADVENTURER (COMIC) CONDE NASTE TRAVELER CONSUMER REPORTS CONSUMER REPORTS ON HEALTH CONSUMER REPORTS TRAVEL LETTER CONSUMER RESEARCH CONSUMERS DIGEST CONSUMERS RESEARCH CONTEMPORARY CHRISTIAN MUSIC COOK'S ILLUSTRATED COOKBOOK DIGEST COOKING LIGHT CORVETTE FEVER COSMOPOLITAN COSMOPOLITAN EN ESPANOL COUNTRY COUNTRY ACCENTS COUNTRY AMERICA COUNTRY FEVER COUNTRY GUIDE COUNTRY HANDCRAFTS COUNTRY HOME COUNTRY HOME FOLK CRAFTS COUNTRY JOURNAL COUNTRY JOURNAL COUNTRY LIVING COUNTRY MUSIC COUNTRY MUSIC CITY NEWS COUNTRY SAMPLER COUNTRY WOMAN CQ RADIO AMATEURS JOURNAL CRAFTING TODAY CRAFTS CRAFTS 'N THINGS CRAFTWORKS FOR THE HOME CRAIN'S NEW YORK BUSINESS CRAYOLA KIDS CREATIVE CLASSROOM CREATIVE KIDS CREATIVE QUILTING CREATIVE REAL ESTATE CREATIVE WOODWORKING & CRAFTS CRICKET CROCHET DIGEST CROCHET FANTASY CROCHET HOME CROCHET WORLD CROCHET WORLD SPECIALS CROSS COUNTRY SKIER CROSS STITCH CROSS STITCH PLUS CROSS STITCHER CROSSSTITCH & COUNTRY CRAFTS CRUISE TRAVEL CRUISE TRAVEL CRUISES & TOURS CRUISING WORLD CUSTOM & CLASSIC TRUCKS CUSTOMER ASSURANCE REPORT CUSTOMER SERVICE NEWSLETTER CYCLE WORLD DAILY NEWS RECORD DANCE DAREDEVIL (COMIC) DARKHAWK (COMIC) DAS LEBEN DATA BASED ADVISOR DAYTIME TV DBMS (DATABASE MANAGEMENT SYSTEMS) DEATH'S HEAD II (COMIC) DEBATE ISSUES DECORATING DIGEST DECORATIVE ARTIST'S WORKBOOK DECORATIVE ARTS PAINTING DECORATVE WOODCRAFTS DEER & DEER HUNTING DEFENSE NEWS DELAWARE TODAY DELL CROSSWORD PUZZLES DELL CROSSWORD SPECIAL DELL CROSSWORDS & VARIETY PUZZLES DELL HOROSCOPE DELL LOGIC PUZZLES DELL OFFICIAL CROSSWORD PUZZLES DELL OFFICIAL PENCIL PUZZLE & WORD GAMES DELL OFFICIAL WORD SEARCH PUZZLES DELL PENCIL PUZZLES & WORD GAMES DELL POCKET CROSSWORD PUZZLES DELL POCKET CROSSWORD PUZZLES DELL WORD SEARCH PUZZLES DES DESKTOP VIDEO WORLD DESSERTS DETAILS DETECTIVE COMICS DETROIT MONTHLY DIRT BIKE DISCIPLESHIP JOURNAL DISCOUNT STORE NEWS DISCOVER DISCOVER DIVING DISNEY ADVENTURES DISNEY'S HOW IT WORKS DISTRIBUTION CENTER MANAGEMENT DOG FANCY DOG WORLD DOLL CASTLE NEWS DOLL DESIGNS DOLL LIFE DOLL WORLD DOLLMAKING DOLLS DOOM 2099 (COMIC) DOWN EAST DOWN MEMORY LANE DOWNBEAT DR. DOBB'S JOURNAL DR. STRANGE (COMIC) DRUG & COSMETIC INDUSTRY EARLY AMERICAN LIFE EARLY CHILDHOOD NEWS EARLY CHILDHOOD TODAY EARTH EARTH JOURNAL EASY FAST "N FUN CROSSWORDS EATING WELL EBONY EBONY MAN (EM) ECONOMIST ECOTRAVELER ELECTRONIC GAMES ELECTRONIC GAMING MONTHLY ELECTRONIC LEARNING ELECTRONICS NOW ELITE MAGAZINE ELLE (AMERICAN) ELLE DECOR ELLERY QUEEN'S MYSTERY ELLERY QUEEN'S MYSTERY EM (EBONY MAN) EMERGE ENGINEERING NEWS RECORD (ENR) ENTERTAINMENT WEEKLY (EW) ENTREE ENTREPRENEUR ENVIRONMENT EQUITIES EQUUS ESQUIRE ESSENCE EUROPEAN CAR EXCALIBUR (COMIC) EXCEPTIONAL PARENT EXECUTIVE FEMALE FAITH & STUFF FAMILY CIRCLE FAMILY HANDYMAN FAMILY LIFE FANCY FOOD & CANDY FANGORIA FANTASTIC FOUR (COMIC) FANTASY & SCIENCE FICTION FAR OUT FARM BUILDING NEWS FARM & RANCH LIVING FARMERS DIGEST FASHION GUIDE FASHION KNITTING FATE FEDERAL TIMES FEMALE BODYBUILDING FIELD & STREAM FIGHTING KNIVES FIGHTING STARS NINJA MAGAZINE FILM THREAT FINANCIAL TIMES OF LONDON (MON - SAT) FINANCIAL WORLD FINE GARDENING FINE HOMEBUILDING FINE WOODWORKING FIREHOUSE FISHING FACTS FISHING & HUNTING NEWS FISHING WORLD FIVE LITER MUSTANG FLARE FLASH (COMIC) FLEX FLOORING FLORIDA LIVING FLORIDA SPORTSMAN FLORIDA TREND FLORIDA VACATION RENTALS FLOWER & GARDEN FLY FISHERMAN FLY FISHING FLYING FLYING MODELS FOOD & WINE FOOTBALL DIGEST FOOTBALL NEWS FORBES FORCE WORKS (COMIC) FOREIGN AFFAIRS FOREIGN POLICY FORTUNE FORUM (PENTHOUSE) FOUR WHEEL / OFF ROAD FOUR WHEELER FRONT PAGE DETECTIVE FUN-ZONE FUR - FISH - GAME FUTURIFIC FUTURIFIC G.I. JOE (COMIC) GAME PLAYERS NINTENDO GUIDE GAME PLAYERS NINTENDO - SEGA GAME PLAYERS PC ENTERTAINMENT GAMEPRO GAMES GARBAGE GEMS & GEMNOLOGY GEMS & GEMNOLOGY GENTLEMEN'S QUARTERLY (GQ) GEOMUNDO GET RICH NEWS GHOST RIDER 2099 (COMIC) GHOST RIDER / BLAZE (COMIC) GHOST RIDER (COMIC) GIFTS & DECORATIVE ACCESSORIES GIFTWARE NEWS GLAMOUR GLASS DIGEST GLEANINGS IN BEE CULTURE GOD'S WORD TODAY GOLDMINE GOLF DIGEST GOLF FOR WOMEN GOLF MAGAZINE GOLF TIPS GOLF WEEK GOLF WORLD GOLFING GOOD DAY SUNSHINE GOOD HOUSEKEEPING GOOD OLD DAYS GOOD OLD DAYS SPECIALS GOURMET GREEN LANTERN (COMIC) GRIT GROO (COMIC) GROWING UP WITH SCIENCE GUARDIANS OF THE GALAXY (COMIC) GUIDEPOSTS GUIDEPOSTS (LARGE PRINT EDITION) GUN DOG GUN LIST GUN WORLD GUNS GUNS & AMMO GUNS & AMMO HAIR ADDITIONS HAIR & BEAUTY NEWS HANDCRAFT ILLUSTRATED HANDGUNNING HANDGUNS HARPER'S BAZAAR HARPER'S BAZAAR EN ESPANOL HARPER'S MAGAZINE HARROWERS (COMIC) HARVARD BUSINESS REVIEW HAWAII HEALTH HELLSTORM (COMIC) HERALD TRIBUNE CROSSWORD PUZZLES ONLY HERALD TRIBUNE & OTHER CROSSWORD GAMES HERO ILLUSRATED HIGHLANDER HIGHLIGHTS HIGHLIGHTS HISPANIC HISTORIC PRESERVATION HOCKEY DIGEST HOCKEY NEWS HOLLYWOOD STUDIO HOLLYWOOD STUDIO MAG THEN & NOW HOMBRE DE MUNDO HOME COOKING HOME GYM & FITNESS HOME MAGAZINE HOME MAGAZINE HOME MECHANIX HOME OFFICE COMPUTING HONOLULU HOOKED IN CROCHET HORIZON HOROSCOPE HOROSCOPE/ A PERSONAL DAILY GUIDE FOR EVERYONE HOROSCOPE / DELL HORSE & HORSEMAN HORSE & HORSEMAN HORSE ILLUSTRATED HORSE & RIDER HORSEPLAY HORTICULTURE HOT BOAT HOT ROD HOT ROD HARLEYS HOUSE BEAUTIFUL HOUSTON METROPOLITAN HOUSTON PEOPLE HOUSTON PROFILES HOW HUDSON VALLEY HUMPTY DUMPTY HUNTING HUSTLER HUSTLER'S BUSTY BEAUTIES HUSTLER'S EROTIC VIDEO GUIDE HUSTLER'S FANTASIES HUSTLER'S HUMOR I LOVE CATS IDEAS IDEAS PARA SU HOGAR ILLUSTRATED BIBLE FOR CHILDREN IMPORT AUTO PARTS & ACCESSORIES IN BUSINESS IN-FISHERMAN INC. INCOME OPPORTUNITIES INCOME PLUS INCREDIBLE HULK (COMIC) INDIVIDUAL INVESTOR IINDUSTRIAL MARKET PLACE INSIDE EDGE INSIDE IRELAND INSIDE KARATE INSIDE KUNG FU INSIDE SPORTS INSIGHT INSTITUTIONAL INVESTOR INSTRUCTOR INTERIOR DECORATOR'S HANDBOOK INTERIOR DESIGN INTERIORS INTERNATIONAL LIVING INTERNATIONAL NURSING INDEX INTERNET WORLD INTERVIEW INTIMATE FASHION NEWS INVESTOR'S DAILY IRON MAN (COMIC) ISLANDS ISRAEL SCENE JACK & JILL JERSEY WOMAN JERUSALEM POST INTERNATIONAL WEEKLY EDITION JERUSALEM REPORT JET JEWISH EXPONENT JEWISH HOMEMAKER JEWISH POST & OPINION JEWISH PRESS JUSTICE LEAGUE AMERICA (COMIC) JUSTICE LEAGUE EUROPE ( COMIC) KARATE / KUNG FU ILLUSTATED KEYBOARD KID CITY KIDSPORTS KIPLINGER'S PERSONAL FINANCE KIT CAR KITPLANES KNIFE WORLD KNITTING DIGEST KNITTING WORLD L'ACTUALITE LA LUZ LA VIE LADIES HOME JOURNAL LADY'S CIRCLE LADYBUG LAKELAND BOATING LAN MAGAZINE (LOCAL AREA NETWORK) LAPIDARY JOURNAL LEADERSHIP LEARNING '94 LEFTHANDER LEGAL GUIDE FOR THE FAMILY LEGION OF SUPER-HEROES (COMIC) LET'S LIVE LIBRARY OF NATURAL WONDERS LIFE LIGHTING DIMENSIONS LINK-UP LINN'S STAMP NEWS LITTLE MERMAID LLUMO VOGUE LONGEVITY LOONEY TUNES (COMIC) LOOSE CHANGE LOS ANGELES LOTTERY PLAYERS MAGAZINE MAC HOME JOURNAL MACLEANS MACUSER MACWORLD MADEMOISELLE MARKETERS FORUM MARRIAGE PARTNERSHIP MARVEL AGE (COMIC) MARVEL COMICS PRESENTS MARVEL TALES SPIDERMAN (COMIC) MCCALL'S MCCALL'S NEEDLEWORK & CRAFTS MECANICA POPULAR MECHANICA POPULAR MEDIA & METHODS MEDICAL & HEALTH ENCYCLOPEDIA MEDICAL HOTLINE MEDICAL UPDATE MEGA PLAY MEMPHIS MAGAZINE MEN'S CONFIDENTIAL MEN'S FITNESS MEN'S HEALTH MEN'S JOURNAL METROPOLIS METROPOLITAN HOME MICKEY MOUSE MICRO COMPUTER JOURNAL MICROSOFT SYSTEMS JOURNAL MID-ATLANTIC COUNTRY MIDSTREAM MIDWEST LIVING MILITARY HISTORY MILWAUKEE MINISTRIES TODAY MINNESOTA MONTHLY MIRABELLA MOBILE OFFICE MODEL AIRPLANE NEWS MODEL NEWS MODEL SHOPPER MODELS & TALENT/CASTING NEWS MODERN BRIDE MODERN GUN MODERN HORSE BREEDING MODERN SALON MOMENT MONEY MONEYPAPER MOODY MAGAZINE MOODY MONTHLY MOPAR MUSCLE MORIBUS (COMIC) MOTHER EARTH NEWS MOTHER JONES MOTHERING MOTOR BOATING & SAILING MOTOR TREND MOTORCROSS ACTION MOTORCYCLE CONSUMER NEWS MOTORCYCLIST MOTORHOME MOUNTAIN BIKE MOVIE MARKETPLACE MOVIELINE MUNDO 21 MUSCLE & FITNESS MUSCLECAR REVIEW MUSICIAN MUSTANG MONTHLY MUSTANGS & FORDS MUSTANGS MONTHLY NAILS NAMOR (COMIC) NATION NATION'S BUSINESS NATION'S RESTAURANT NEWS NATIONAL AUCTION REPORT NATIONAL ENQUIRER NATIONAL FISHERMAN NATIONAL LAW JOURNAL NATIONAL OTC STOCK JOURNAL NATIONAL PARK MAGAZINE NATIONAL REVIEW NATIONAL TRIAL LAWYER NATURAL HEALTH NATURAL HISTORY NAVY TIMES NBA INSIDE STUFF *THE NET* (about the Internet) NEEDLE & CRAFT NEVADA MAGAZINE NEW AGE JOURNAL NEW BUSINESS OPPORTUNITIES NEW CHOICES NEW ENGLAND JOURNAL OF MEDICINE NEW FARM NEW JERSEY MONTHLY NEW JERSEY OUTDOORS NEW MEXICO NEW REPUBLIC NEW TITANS (COMIC) NEW WARRIORS (COMIC) NEW WOMAN NEW YORK MAGAZINE NEW YORK REVIEW OF BOOKS NEW YORKER NEWSWEEK NICE & EASY FAMILY COOKBOOK NIGHT TRASHER (COMIC) NIGHT WATCH (COMIC) NO-TILL FARMER NORTH FLORIDA LIVING NORTH SHORE (CHICAGO) NOVA (COMIC) NUMISMATIC NEWS NURSING NUTRITION & DIETARY CONSULTANT NUTRITION HEALTH REVIEW OCCASIONAL BULLETIN OFF ROAD OFFICIAL CROSSWORD PUZZLES OFFICIAL DETECTIVE OFFICIAL MAJOR LEAGUE BASEBALL ROOKIE LEAGUE MAGAZINE FOR KIDS OFFICIAL PENCIL PUZZLES / WORD GAMES OFFICIAL US CUSTOM HOUSE GUIDE OFFICIAL WORD SEARCH PUZZLES OLD CARS NEWS & MARKETPLACE OLD CARS PRICE GUIDE OLD HOUSE JOURNAL OLD TIME CROCHET OMNI ONLINE ACCESS ONSAT OPEN WHEEL OPERA NEWS OPPORTUNITY MAGAZINE ORGANIC GARDENING OUTDOOR LIFE OUTDOOR PHOTOGRAPHER OUTDOOR PRESS OUTSIDE OVERDRIVE PACIFIC NORTHWEST PACK -O-FUN PADDLE SPORTS PADDLER PAINTWORKS PALM BEACH LIFE PALM SPRINGS LIFE PARENTING PARENTS PARENTS OF TEENAGERS PASSION PASSION FOR MEN PC COMPUTING PC GAMER PC GAMES PC KIDS PC LAPTOP PC MAGAZINE PC NOVICE PC TODAY PC WORLD PC WORLD LOTUS EDITION PC WORLD MULTI MEDIA EDITION PCM PENNSYLVANIA SPORTSMAN PENTHOUSE PENTHOUSE LETTERS PEOPLE PET DEALER PHILADELPHIA PHOENIX HOME & GARDEN PHOTOGRAPH COLLECTOR PHOTOGRAPHIC PINHEAD (COMIC) PLANE & PILOT PLASTIC CANVAS PLASTIC CANVAS & MORE PLASTIC CANVAS WORLD PLAYBOY PLAYGIRL PLAYTHINGS POCKET CROSSWORD PUZZLES POLO POPULAR COMMUNICATIONS POPULAR ELECTRONICS POPULAR HOT RODDING POPULAR MECHANICS POPULAR PHOTOGRAPHY POPULAR SCIENCE POPULAR WOODWORKING PORTABLE COMPUTING POST SCRIPT POST SCRIPTS: ESSAYS IN FILM & THE HUMANITIES POWDER POWER & MOTOR YACHT PRACTICAL HORSEMAN PREMIERE PRESENT TENSE PREVENTION PRIVATE PILOT PRO FOOTBALL WEEKLY PROGRESSIVE PROGRESSIVE FARMER PROTESTANT DELUXE BIBLE PROTESTANT FAMILY BIBLE PSYCHOLOGY TODAY PUBLISH PULSE PUNISHER 2099 (COMIC) PUNISHER (COMIC) PUNISHER WAR JOURNAL (COMIC) PUNISHER WAR ZONE (COMIC) QUASAR (COMIC) QUICK & EASY CRAFTS QUICK & EASY CROCHET QUICK & EASY NEEDLECRAFT QUICK & EASY PLASTIC CANVAS QUICK & EASY QUILTING QUILT WORLD QUILTER'S NEWSLETTER QUILTER'S TREASURY QUILTER'S TREASURY QUILTING INTERNATIONAL QUILTMAKER RAILROAD MODEL CRAFTSMAN RAPPAGES RAPPORT RAVAGE 2099 (COMIC) REAL PEOPLE REALTY MAGAZINE REDBOOK REMINISCE REN & STIMPY (COMIC) RETIREMENT INCOME NEWSLETTER RIDER RIGHT ON RIP ROAD RIDER ROAD & TRACK ROBB REPORT ROCK & GEM ROD & CUSTOM ROLLING STONE RUNNER'S WORLD RUNNING TIMES RURAL BUILDER S.W.A.T. SABERTOOTH CLASSICS (COMIC) SADDLE & BRIDE SAIL SAILING SAILING WORLD SALTWATER SPORTSMAN SAN DIEGO HOME & GARDEN SAN DIEGO MAGAZINE SAN FRANCISCO SASSY SATELLITE TV PRE-VUE SATELLITE TV WEEK SATURDAY EVENING POST SAVAGE SWORD OF CONAN (COMIC) SCHOLASTIC COACH SCHOOL & COLLEGE SCIENCE LIBRARY SCIENCE NEWS SCIENCE OF MIND SCIENCES SCIENTIFIC AMERICAN SCUBA DIVING SCUBA TIMES SEA MAGAZINE SECRET DEFENDERS (COMIC) SELF SESAME STREET SEVENTEEN SEVENTY-THREE AMATEUR RADIO SEW NEWS SEYBOLD REPORT ON DESKTOP PUBLISHING SHAPE SHOOTING TIMES SHOP TALK SHORT STORY INTERNATIONAL SHOW BIZ / CASTING NEWS SHOW BIZ NEWS/MODEL NEWS SHOWBOATS INTERNATIONAL SIDEKICKS SIDEKICKS SOCCER SILVER SABLE (COMIC) SILVER SURFER (COMIC) SIMPLY CROSS STITCH SKATEBOARDING SKI SKIING SKIN DIVER SKIN & INK SMITHSONIAN SNOW COUNTRY SNOW GOER SNOW WEEK SNOWBOARDING SNOWMOBILE SOAP OPERA DIGEST SOAP OPERA MAGAZINE SOAP OPERA STARS SOCCER AMERICA SOCCER DIGEST SOCCER INTERNATIONAL SOUNDINGS SOUTH FLORIDA SOUTHERN ACCENTS SOUTHERN BOATING SOUTHERN HOMES SOUTHERN LIVING SOUTHERN OUTDOORS SPACE NEWS SPECIAL EVENTS SPECIAL SITUATIONS REPORT SPECIALTY CAR SPECTACULAR SPIDERMAN (COMIC) SPIDERMAN 2099 (COMIC) SPIDERMAN CLASSIC (COMIC) SPIDERMAN (COMIC) SPIN SPORT SPORT DIVER SPORT FISHING SPORT RIDER SPORT TRUCK SPORTING CLASSICS SPORTING NEWS SPORTS AFIELD SPORTS CARD TRADER SPORTS COLLECTORS DIGEST SPORTS ILLUSTRATED SPORTS ILLUSTRATED FOR KIDS SPORTSWEAR INTERNATIONAL SPOTLIGHT STAR STAR TREK (COMIC) STAR TREK : THE NEXT GENERATION (COMIC) STARLOG STEREO REVIEW STITCH 'N SEW QUILTS STOCK CAR RACING STONE SOUP STORY STUDIO USA STYLE TRENDS SUCCESS SUCCESSFUL RETIREMENT SUNBONNET CRAFTS SUNSET SUPER CHEVY SUPER COMPUTING REVIEW SUPER CYCLE SUPER FORD SUPER NES BUYERS GUIDE SUPER STOCK & DRAG ILLUSTRATED SUPERCYCLE SUPERMAN - MAN OF STEEL (COMIC) SURFER SURFING SURPRISES SWAP USA SWAT T-SHIRT RETAILER TAMPA BAY CAREER GUIDE (WITH UPDATES) TASTE OF HOME TAX HOTLINE TCI TEACHING PRE K-8 TECHNOLOGY & LEARNING TEDDY BEAR REVIEW TEEN TEEN BEAT TEENAGE MUTANT NINJA TURTLES (COMIC) TEK WORLD (COMIC) TENNIS TEXAS FISH & GAME TEXAS GARDENER THE SCIENCES THEATRE CRAFTS THEOLOGY TODAY THOR (COMIC) THREADS THREE-TWO-ONE CONTACT THUNDERSTRIKE (COMIC) TIME TODAY'S CATHOLIC TEACHER TODAY'S CHRISTIAN WOMAN TOLE WORLD TOTAL HEALTH TOURING AMERICA TOWN & COUNTRY TOY SHOP TRACK & FIELD NEWS TRADING CARDS TRADITIONAL HOME TRADITIONAL QUILTER TRAILER BOATS TRAILER LIFE TRANSFORMERS GENERATION 2 (COMIC) TRANSWORLD SKATEBOARDING TRAPPER & PREDATOR CALLER TRAVEL 50 & BEYOND TRAVEL AMERICA TRAVEL HOLIDAY TRAVEL & LEISURE TRAVELAMERICA TREASURE TRIATHLETE TRUE DETECTIVE TRUE STORY TU TURKEY & TURKEY HUNTING TURTLE TV CROSSWORDS TV HOST TV Y NOVELAS (PUERTO RICO) TV Y NOVELAS (USA) TWINS UNCANNY X-MEN (COMIC) UNDERWATER USA UNIQUE HAIR & BEAUTY UNIQUE HOMES US AVIATOR US CATHOLIC US MAGAZINE US NEWS & WORLD REPORT USA TODAY UTNE READER VACATIONS VANIDADES VANITY FAIR VARIATIONS (PENTHOUSE) VARIETY (WEEKLY) VEGETARIAN TIMES VEGGIE LIFE and many, many more!!! Once you get in, you'll love them. I do. For more info, just fill out the form near the top of this message and email it to their email address shown there. Thanks, Susan Loring ======================================================================= 57 === Date: 9 Jun 1995 17:04:32 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article , jackg@downhaul.crc.rico h.com (Jack Greenbaum) writes: > > What am I missing here? The gcc intermediate representation, RTL, is > quite seperate from the front end parse tree representation, the "tree" > data structures. RTL is the most well documented part of GCC, while > building a new front end is certainly black magic. Yes, but the RTL is machine-specific. If you want to use gcc to as a high-leverage, already-ported backend, you must generate "trees". Generating well-formed trees is difficult. I know of no written spec for what's a well-formed tree. - Bill Kalsow ======================================================================= 58 === Date: Fri, 09 Jun 95 10:20:20 -0700 From: mcjones@pa.dec.com Subject: Re: when NEW fails, revisited Michel notes: A very long and detailed explanation about why this was extremely difficult was posted by the DEC SRC people about 6 months ago. You should be able to find it in the archives in: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3 In particular, the message is archived in the file 94-08.Z in the directory Michel specified. Here is the header: Date: Wed, 24 Aug 94 09:05:33 -0700 From: mcjones@src.dec.com Subject: Re: Robustness, <*FATAL*>, NEW() Paul McJones mcjones@pa.dec.com Digital Equipment Corporation Systems Research Center ======================================================================= 59 === Date: 9 Jun 1995 17:07:04 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Help with WWW documentation of M3 sources In article <3r7em1$jks@lyra.csx.cam.ac.uk>, tlh20@thor.cam.ac.uk (Tim Harris) w rites: > The work-around is to modify the mime-types file in the configuration > directory (by default I think that's /usr/local/etc/httpd/conf) and find > the line starting text/html. This line lists file extensions for which > the daemon should tell the client that the file is HTML, so adding > i3 and m3 on the end should make them be recognised correctly. > > Admittedly the word starting with k and ending with ludge springs to > mind (what if another user has a normal modula-3 program which they > want to be available as text?) - but I think that's about as well as > it can be done without large-scale changing of the links in the M3 > files. Yes. I changed the program that generates the static HTML from Modula-3 sources to add ".html" to every file. The new web will be availible in the next release. - Bill Kalsow ======================================================================= 60 === Date: 9 Jun 1995 08:21:32 GMT From: hebert@prism.uvsq.fr (Renaud HEBERT) Subject: Re: Comments on Chess Playing Program In article <3r83pf$29p@newsserv.cs.sunysb.edu>, pbh@cs.sunysb.edu (Peter B. Hen derson) writes: |> I am posting this for Warren Smith. Maybe of interest to some of you. |> -- |> Peter B. Henderson |> pbh@sbcs.sunysb.edu |> Department of Computer Science, SUNY at Stony Brook |> Stony Brook, N.Y. 11794-4400 |> |> -------- Warren's comments start here -------- |> |> Tests of runtime speed modula-3 vs C, also comments on language choice |> for implementing a chess playing program. |> ---------------------------------------------------------------------- |> By Warren D. Smith, wds@research.NJ.NEC.COM |> (Now also T, Chez Scheme, and Standard ML of New Jersey, thanks to |> Kevin Lang and Andrew Wright for writing those. This arose from my |> desire to write a chess program and decide between C and m3.) |> |> test1: a 1000000 iter loop with a bunch of bit-ops and array accesses. |> Incidentally this test reveals that neither C nor modula-3 compilers |> have tables of special cases of common operations, such as, e.g. x MOD |> 64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x, |> etc. Pretty damn stupid of certain compiler writers. |> (Later note.... actually C does have some such optimizations, but |> only for unsigned ints...) Yes because in fact if x is negative x/2 isn't the same thing as x >> 1 in C, because of the rounding. -- Renaud HEBERT E-mail: Renaud.Hebert@prism.uvsq.fr Serveur Mosaic: http://www.prism.uvsq.fr ======================================================================= 61 === Date: 9 Jun 1995 17:16:38 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Comments on Chess Playing Program In article <3r83pf$29p@newsserv.cs.sunysb.edu>, pbh@cs.sunysb.edu (Peter B. Hen derson) writes: > I am posting this for Warren Smith. Maybe of interest to some of you. > -- > -------- Warren's comments start here -------- > test1: a 1000000 iter loop with a bunch of bit-ops and array accesses. > Incidentally this test reveals that neither C nor modula-3 compilers > have tables of special cases of common operations, such as, e.g. x MOD > 64 is Word.And(x,63), x/2 is Word.RightShift(x,1), for integer x, > etc. Pretty damn stupid of certain compiler writers. > (Later note.... actually C does have some such optimizations, but > only for unsigned ints...) Modula-3 defines: x DIV y == FLOOR (x / y) x MOD y == x - y * (x DIV y) Before you get your "pretty damn smart" compiler writer merit badge, try x=-1 in your examples... - Bill Kalsow ======================================================================= 62 === Date: Fri, 9 Jun 1995 17:59:24 GMT From: smcneil@netcom.com (Sean McNeil) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <3r9uv0$5ea@src-news.pa.dec.com>, Bill Kalsow wrote: > >In article , jackg@downhaul.crc.ric oh.com (Jack Greenbaum) writes: >> >> What am I missing here? The gcc intermediate representation, RTL, is >> quite seperate from the front end parse tree representation, the "tree" >> data structures. RTL is the most well documented part of GCC, while >> building a new front end is certainly black magic. > >Yes, but the RTL is machine-specific. If you want to use gcc to >as a high-leverage, already-ported backend, you must generate "trees". >Generating well-formed trees is difficult. I know of no written >spec for what's a well-formed tree. > I am also confused. From my understanding the RTL is not machine-specific. As far as I know, there are currently several front-ends for gcc (C, C++, Ada, and Fortran are the ones I know of). None of these front-ends are different from platform to platform. So, I should think that the RTL is robust enough for any front-end you might want to write. Like Modula-3. -- -- Sean McNeil smcneil@netcom.com -- Please append a :-) to any and all comments as I am never serious. ======================================================================= 63 === Date: 9 Jun 1995 23:09:14 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article , smcneil@netcom.com (Sean McNeil) wri tes: > I am also confused. From my understanding the RTL is not machine-specific. > As far as I know, there are currently several front-ends for gcc (C, C++, > Ada, and Fortran are the ones I know of). None of these front-ends are > different from platform to platform. So, I should think that the RTL is > robust enough for any front-end you might want to write. Like Modula-3. Yes, you are confused. RTL is machine-specific. Its *syntax* (ie. parentheses) is not. Each of the existing frontends generates a "tree". Then, somewhat magically, the trees are transformed into machine-dependent RTL. RTL encodes all sorts of machine dependencies like register numbers and calling conventions. Go read the sources. - Bill Kalsow ======================================================================= 64 === Date: 8 Jun 1995 07:48:02 GMT From: elemings@unix1.utm.edu (Eric Lemings) Subject: Re: src-m3 for Linux Torsten R. Kirschner (torki@file01.mpfpi-muenchen.mpg.de) wrote: : as far as the SRC source destribution is concerned, the closest FTP mirror : of gatekeeper.dec.com to Ulm in Germany might be ftp.informatik.tu- : muenchen.de or ftp.leo.org/pub/comp/programming/languages/Modula-3. What directory can I find the SRC distribution on gatekeeper.dec.com? Eric Lemings ======================================================================= 65 === Date: 09 Jun 1995 22:41:02 GMT From: bm@roadkill.cs.columbia.edu (Blair MacIntyre) Subject: Re: When NEW fails (summary) >>>>> On 09 Jun 1995 15:58:20 GMT, nayeri@gte.com (Farshad Nayeri) >>>>> said: Farshad> The following is my summary (in form of question and answers) on the Farshad> topic of dealing with allocation failure in SRC Modula-3. I bought most of what you said, but I need convincing on the following point: Farshad> Q: The fact that NEW crashes if there is not enough memory is Farshad> inconvenient. Why can't we have it raise an exception or return Farshad> NIL? Farshad> A: Chaning NEW semantics at this point is difficult since so many Farshad> programs are not prepared to deal with an exception or a NIL Farshad> result. In fact, to have NEW raise an exception means that you need Farshad> to be aware of this exception practically at all times. This will Farshad> affect most Modula-3 programs which don't care about such Farshad> conditions. At first glance, it would appear that the only effect on the libraries of raising new would be a plethora of "unhandled exception" warnings during the next compile. These could be fixed very fast by adding <*FATAL OutOfMemory*> to the files in question. More importantly, current libraries that bomb right now with out of memory conditions would continue to bomb. While not exactly what we want, this would give no change in behaviour. So, programs that don't care about memory problems would behave as they now do. I realize that it would take a fair amount of cleaning up to actually make many of the libraries percolate the exception up to the user, but it would seem to me to be worth it. So much so that I would volunteer to help tidy things up. Since it's mostly a busy-work exercise, if we got a dozen people to add to the "RAISES" clauses of the various library routines, things would move along quickly. Be that as it may, I prefer the solution of registering routines to be called when memory runs out. That way, a programmer could free up memory used for things like caches when it gets low, without having to worry about handling exceptions. As for the multithreaded issues, it would seem to me that if the allocator calls these routines inside a mutex, then tries again to allocate the required when they have all been called and the garbage collector given a chance to collect, there would be no multithreading conflicts. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 66 === Date: 9 Jun 1995 18:43:47 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article smcneil@netcom.com (Sean McNeil) writ es: >I am also confused. From my understanding the RTL is not machine-specific. >As far as I know, there are currently several front-ends for gcc (C, C++, >Ada, and Fortran are the ones I know of). None of these front-ends are >different from platform to platform. So, I should think that the RTL is >robust enough for any front-end you might want to write. Like Modula-3. The RTL *format* is machine-independent, so that the optimizer can work on it. The actual RTL *values* for a particular function are machine- specific since they are a representation of the machine language. However, front ends do not generate RTL. They build expression trees (which are completely machine-independent) and call function in the backend that generate RTL from them. Front ends are not *entirely* machine-independent, though, since they sometimes need to know such things as sizes, alignments, and enddianness. This is why it is easier to write front ends linked with the backend instead of splitting them into two programs. ======================================================================= 67 === Date: 09 Jun 1995 23:37:01 GMT From: sean@mcneil.ni.net (Sean McNeil) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <3ra4p3$a88@cmcl2.NYU.EDU> kenner@lab.ultra.nyu.edu (Richard Kenner) writes: The RTL *format* is machine-independent, so that the optimizer can work on it. The actual RTL *values* for a particular function are machine- specific since they are a representation of the machine language. However, front ends do not generate RTL. They build expression trees (which are completely machine-independent) and call function in the backend that generate RTL from them. Front ends are not *entirely* machine-independent, though, since they sometimes need to know such things as sizes, alignments, and enddianness. This is why it is easier to write front ends linked with the backend instead of splitting them into two programs. OK, but then I see nothing preventing a Modula-3 front-end that creates expression trees from being implemented. The RTL level is, I assume, the level where people porting to new platforms must contend with. Front- ends would just generate mostly machine-independant expression trees with a few hints from the back-end on the architecture of the machine (like endian-ness and required alignment and so forth). I seem to recall this thread being about technical problems in using gcc as a back-end to a Modula-3 compiler. I still don't see any problem if the front-end generates the expression trees correctly. Is the problem that this is not properly documented? Perhaps the GNAT team and the people/person doing g77 could assist in documenting this better. Sean McNeil ======================================================================= 68 === Date: Fri, 9 Jun 1995 15:45:17 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Re: Comments on Chess Playing Program In article <3r83pf$29p@newsserv.cs.sunysb.edu> pbh@cs.sunysb.edu (Peter B. Hend erson) writes: I am posting this for Warren Smith. Maybe of interest to some of you. -- Peter B. Henderson pbh@sbcs.sunysb.edu Department of Computer Science, SUNY at Stony Brook Stony Brook, N.Y. 11794-4400 -------- Warren's comments start here -------- Tests of runtime speed modula-3 vs C, also comments on language choice for implementing a chess playing program. [snip interesting stats on C vs m3] ---------------------------------------------------------------------- I am still tempted to go with modula-3 over C++, despite paying a factor of 3-5 on linked list malloc'd and garbage collected stuff (and I am also informed that nested subroutine declarations and calls to procedures passed as parameters, will be slower in m3 than C), because I know the main time consumer in a chess prog will be bit-op and array and recursion stuff, and on this, the time hit is only a factor of 1.1-1.7. Unless I'm mistaken, those test were only C vs Modula-3 and not C++ vs Modula-3. Even though C++ is a better C, once you attempt to use the O-O techniques the actual performance times get closer to the Modula-3 times. I don't even want to talk about compilation times, due to inconsequential changes in a class's private representation. In our chess test the runtime ratio was 1 : 1.62. [snip optimization comments] The reasons (ignoring speed) why m3 is the right language for a chessprog are: it is designed to support large multimodule programs, C was not (only as an afterthought) and the safety of m3 (no memory leaks! no out of bounds array accesses!) will lead to tremendous reduction i n debugging time. Also m3 is easier to learn than C++ and there is a nice online HTML tutorial for it. C++ doesn't have much cleaner support for large multimodule programs, unless you encapsulate everything in the class or wait several years before some of the compiler writers are able to get namespaces working. (actually namespaces should be easy to implement, but they have more than enough other problems to keep themselves busy) [snip reasons for preferring C] Feedback I get from net people: > Which is better for a chess prog, C or m3? kalsow@pa.dec.com (Bill Kalsow, mr. Modula-3) That depends on whether you're going to use any of the features of Modula-3 that aren't in C++ (e.g. threads, garbage collection, a rich standard library) or vice versa (e.g. multiple inheritance, operator overloading). It is for large multifile programs that m3 really shines. [WDS: all this favors m3 for me.] Multiple inheritance does have it's uses, I think I've actually used it once, but I've written thousands of lines of code that wouldn't have benefited from it. In fact, C++'s multiple inheritance has inconsistencies, and if you really want to play with MI, I suggest you look at Eiffel or Sather. Operator overloading is useful, but can get you into trouble, in fact we 'have' to use it in addition to templates to simulate a simple type of RTTI at compile time. Garbage collection is a big win. More time is spent in the debugger when writing C++ programs due to a deletion of some memory when it shouldn't have been, and the program continues along its merry way until sometime in the future some other access to the memory causes everything to fail miserably. This can account for a LOT of time. Threads are very nice, but I doubt that many people use them on their first cut at a program until they've grown more accustomed to the multi-threading concept. The standard library is by far a significant reason to choose Modula-3. Some day real soon I've been assured that the STL (Standard Template Library) for C++ will be blessed. This will include a String Class (most people have library collisions with this because every library writer chose to implement their own String class) Part of the delay is that they want everything in STL to fit together. I'm still not sure if they are going to include exception handling in the first release. The Modula-3 standard library alreay is filled with exception handling, and is multi-thread safe. Don't even ask about multi-threading and C++ (it's considered the operating system's problem). > Can I trust SRC to support me and fix such bugs fast? Richard Watts (rrw1000@cam.ac.uk): By and large, yes. I've never known them not to fix a bug they have been provided with the fix for [WDS: Oh, great. This is what the software community calls "good"], and they're by and large very good at fixing errors in new releases. That said, obscure bugs for which you haven't got a fix or good tracing information, or machine-specific bugs for platforms SRC haven't got tend not to be fixed by SRC - people like me get to them first :-). I don't know how many bugs the SRC compiler has, but I've been using g++ for over a year (and while it's one of the best C++ compilers) we send in a bug report almost once a week. Causing the compiler to fail occasionally is considered normal. So far, I haven't done anything nasty enough to cause the Modula-3 compiler to fail, but then, it actually implements the whole language, whereas there isn't a C++ compiler that comes close to implementing the C++ language (that is still a moving target that won't be fully defined until 1997). > m3gdb debugger? m3gdb is temperamental at the best of times. I've just about given up on it myself as being more trouble than it's worth :-(. Luckily, M3 is sufficiently clear that code walk-throughs and diagnostics seem to work almost as well. Hmm, I haven't had to resort to using m3gdb, but I'm well acquainted with the regular gdb debugger. I wish that I weren't, but I've managed to demangle just about every piece of infomation it gives you. Unfortunately, many problems can't be traced because you slam into a virtual pointer. > I am sure modula-3 is the better choice, EXCEPT > that it looks to me like DEC has pretty much thrown it > to the wolves and don't officially support it, etc. [snip comments about things being thrown to wolves] I've personally received very good help from the people in the modula-3 newsgroup, and don't worry about being thrown to the wolves for support. Ask a simple question in the C++ newsgroup and you'll either find a helpful person or two (there are some in and among the fray) or you'll probably get some comment about referening to some page in the ARM. The ARM is the Annotated Reference Manual, and although it is out of date on some issues, it's still considered the C++ programmer's bible. (BTW, it's not an inexpensive book) I've noticed that since the Modula-3 language carries around little baggage, I don't need to ask as many questions. When learing C++, I had to first get past the syntax, then understand the "proper" way to do things by interpreting what the ARM said, and then just using trial-and-error to figure out what parts of the language definition that my particular compiler could handle. Porting code from one compiler to another is a horrendous task since each compiler has it's own special deficiencies. This is only one of the many reasons that we are hoping to use some different languages on contracts that don't specifically require C++. If I were to have to choose between C++ and Modula-3, even given my extra expertise in C++ already, I would clearly choose Modula-3. I am sick and tired of constantly fighting C++ in order to get my tasks done. I prefer to work "with" a language, not spend all day trying to "by-pass" its weaknesses. ------------------------------------ From: Warren D. Smith (Research Staff; Library Committee Chair) NEC Research Institute (Room 1D04) 4 Independence Way Princeton NJ 08540 USA Phone: (609) 951-2717 Web: http://www.neci.nj.nec.com/homepages/smith.html Email: wds@research.NJ.NEC.COM Fax: (609) 951-2496 ("for W.D.Smith 1D0 4" ---------------------------------------------------------------------- Spencer Allain E-mail: spencer@era.com Engineering Research Associates Phone : (703) 734-8800 x1414 1595 Spring Hill Road Fax : (703) 827-9411 Vienna, VA 22182-2235 ---------------------------------------------------------------------- ======================================================================= 69 === Date: 10 Jun 1995 15:11:17 GMT From: hudson@cs.umass.edu (Rick Hudson) Subject: Re: Comments on Chess Playing Program >>>>> "Peter" == Peter B Henderson writes: > I am posting this for Warren Smith. Maybe of interest to some of you. -- > -------- Warren's comments start here -------- > josephus: go round a 200000 element circular list deleting every 47th guy > until 1 left. (Tests linked lists and malloc/free/garbage collect.) > But the garbage collection / malloc / > pointer following performance of sml (josephus) is very impressive; one > wishes m3 could duplicate it... Interesting, recalling the Lisp Gabriel benchmark wars of the mid 80s, benchmarks for the sake of numbers is silly without understanding why the numbers were different. This in mind, most GCs are called when there is a need for more memory. Josephus seems to allocate and then delete, the GC is probable never run. - Rick -- Richard L. Hudson - Hudson@cs.umass.edu; (413) 545-1220; Advanced Languages Project - University Computing Services Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 ======================================================================= 70 === Date: 10 Jun 1995 11:55:36 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article sean@mcneil.ni.net (Sean McNeil) w rites: >I still don't see any problem if the front-end generates the expression >trees correctly. Is the problem that this is not properly documented? Yes, that's the major problem. Luckily, there just isn't that much to document, though, since the interface is fairly straightforward, but it can be hard to find out where to start. Unlike config files, there are relatively few back ends to look at. But the best way to do it is to copy pieces from other front ends. >Perhaps the GNAT team and the people/person doing g77 could assist in >documenting this better. The only person on the GNAT team who looks at GCC trees much is me. g77 is a one person project and I doubt he's interested in creating documentation. I gave a tutorial on GCC for POPL and prepared about 135 slides, 1/3 of which are on the front end interface. I also wrote a front end for a "toy" language that was about 1,000 lines of code. If anybody wants these, let me know. ======================================================================= 71 === Date: 10 Jun 95 22:41:35 GMT From: stj@cornell.edu ("stj@cornell.edu") Subject: ===>> FREE 1 yr. Magazine Sub sent worldwide- 300+ Popular USA Titles (fwd) ---------- Forwarded message ---------- Date: Sat, 10 Jun 1995 17:43:18 -0400 (edt) From: stj@cornell.edu To: sbionet.metabolic-reg@paris.ics.uci.edu, sfnet.harrastus.visailu@paris.ics.uci.edu, uk.lisp@paris.ics.uci.edu, uk.media@paris.ics.uci.edu, uk.misc@paris.ics.uci.edu, uk.net@paris.ics.uci.edu, pdx.music@paris.ics.uci.edu, pdx.online@paris.ics.uci.edu Subject: ===>> FREE 1 yr. Magazine Sub sent worldwide- 300+ Popular USA Titles CHEAPEST USA MAG SUB AGENCY - SHIPS WORLDWIDE + FREE 1yrSUB Hi, my name is Susan Johnson and I recently started using a magazine subscription club in the USA that has a FREE 1 yr. magazine subscription deal with your first paid order- and I have been very pleased with them. They have over 1,500 different USA titles that they can ship to any country on a subscription basis. They saved me a lot of money on my Economist subscription: over $40 off the best subscription price on I had seen anywhere else and they got me a great deal on USA Today newspaper, which arrives the same day as the cover date. (I still don't know how they manage to do that!) They will send you some FREE info. via E-mail (the short version (around 40K) of their catalogue, or if you request it the DELUXE LONG VERSION (around 400K-big and juicey) !)...if you fill out the form below. Please do not email me as I am just a happy customer and a *busy* student. I don't have time to even complete my thesis in time, let alone run my part-time software business! Email them directly at: suschow@freenet.fsu.edu *------------cut here-----------------------------------------------* REQUEST FOR MORE INFO: please copy this section *only* and email to: suschow@freenet.fsu.edu (sorry, but they cannot acknowledge incomplete forms sent back) Name: Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Name of USA mags you currently get: Name of USA mags you would like price quotes on when we call you: Do you want the short (~40K) or long version (~400K) of our catalogue emailed to you?: How did you hear about us (name of person who referred you or the area of the internet that you saw us mentioned in): Susan Johnson 061095 p *------------cut here-----------------------------------------------* They guarantee to beat all their competitors' prices. Sometimes they are less than half of the next best deal I have been able to find and other times, just a little cheaper - but I have never found a lower rate yet. They assured me that if I ever do, they will beat it. They have been very helpful and helped me change my address from the USA to Finland and then back again when I moved last month. They are very knowledgeable about addressing mags worldwide. They have a deal where you can get a free 1 yr. sub to a new magazine from a special list of over 300 popular titles published in the USA. They will give you this free 1 yr. sub when you place your first paid order with them to a renewal or new subscription to any of the over 1,500 different popular USA titles they sell. They can arrange delivery to virtually any country and I think they have clients in around 35 or 36 countries now. Outside the USA there is a charge for foreign postage and handling (on both paid and freebie subs) that varies from magazine to magazine. I have found their staff to be very friendly and courteous. They even helped me with an address change when I moved from one country to another. The owner thinks of his service as a "club" and his clients as "members" (even though there is no extra fee to become a member - your first purchase automatically makes you a member) and he is real picky about who he accepts as a new member. When he sets you up as a new member, he himself calls you personally on the phone to explain how he works his deal, or sometimes he has one of his assistants call. He is kind of quirky sometimes - he insists on setting up new members by phone so he can say hi to everyone (I sure wouldn't want to have his phone bills!), but you can place future orders (after your first order) via E-mail. He has some really friendly young ladies working for him, who seem to know just as much as he does about this magazine stuff. If you live overseas, he will even call you there, as long as you are interested, but I think he still makes all his overseas calls on the weekends, I guess cause the long distance rates are cheaper then. He only likes to take new members from referrals from satisfied existing members and he does virtually no advertising- so you can email me and I will forward your message on to him as a referral. When I got set-up, they had a 2-3 week waiting list for new members to be called back so that they could join up. (Once you are an existing member, they help you immediately when you call. ) I think they are able to get back to prospective new members the same day or within a few days now, as they have increased their staff. I am not sure about this.........but if you email the above form to them, that is the way to get started! They will send you some FREE info. via E-mail (the short version (around 40K) of their catalogue, or if you request it the DELUXE LONG VERSION (around 400K-big and juicey) !)...if you fill out the form near the top of this message. They then send you email that outlines how his club works and the list of free choices that you can choose from, as well as the entire list of what he sells; and then they will give you a quick (3-5 minute) friendly, no-pressure no-obligation call to explain everything to you personally and answer all your questions. Here is a list of some of the 1500+ titles that they sell (for your free selection with your first paid order, approximately one-fifth of these appear on their special freebies list). ACCENT ACCENT ON LIVING ACCESSORIES ACTION COMICS ACTION PURSUIT GAMES ADIRONDACK LIFE ADVENTURE WEST ADVENTURES OF SUPERMAN (COMIC) ADVERTISING AGE ADVOCATE AFRICAN PROFILES INTERNATIONAL AIR CLASSICS AIR COMBAT AIR FORCE TIMES AIR & SPACE ALASKA ALASKA MEN ALASKA OUTDOORS ALBUQUERQUE MONTHLY ALFRED HITCHCOCK MYSTERY ALLURE ALOHA AMATEUR RADIO TECHNICAL JOURNAL AMAZING SPIDERMAN (COMIC) AMERCAN HEALTH AMERICA'S CIVIL WAR AMERICAN ARTIST AMERICAN ASTROLOGY AMERICAN BABY AMERICAN BABY AMERICAN CAGE BIRD AMERICAN COLLECTOR'S JOURNAL AMERICAN COTTON GROWER AMERICAN COWBOY AMERICAN COWBOY AMERICAN DEMOGRAPHICS AMERICAN FORESTS AMERICAN FRUIT GROWER AMERICAN HANDGUNNER AMERICAN HEALTH AMERICAN HERITAGE (HARD COVER) AMERICAN HERITAGE INVENTION & TECHNOLOGY AMERICAN HERITAGE (SOFT COVER) AMERICAN HISTORY ILLUSTRATED AMERICAN JOURNAL OF MATERNAL / CHILD NURSING AMERICAN JOURNAL OF NURSING AMERICAN LIQUIDATION MONTHLY AMERICAN PHOTO AMERICAN SALON AMERICAN SPECTATOR AMERICAN SQUARE DANCE AMERICAN VEGETABLE GROWER AMERICAN VISIONS AMERICAN WOODWORKER AMERICANA AMERICAS (ENGLISH) AMERICAS (SPANISH) AMIGA WORLD ANALOG SCIENCE FICTION / FACT ANTIQUE TRADER WEEKLY ANTIQUES ANTIQUING AMERICA AQUARIUM FISH ARCHAEOLOGY ARCHITECTURAL DIGEST ARCHITECTURE ARIEL ARMY TIMES ART & ANTIQUES ART & ANTIQUES INVESTMENT REPORT ART IN AMERICA ARTIST'S MAGAZINE ARTNEWS ARTS & ACTIVITIES ASIAN SOURCES (COMPUTER PRODUCTS) ASIAN SOURCES (ELECTRONIC COMPONENTS) ASIAN SOURCES (ELECTRONICS) ASIAN SOURCES (GIFTS & HOME) ASIAN SOURCES (HARDWARE) ASIMOV'S SCIENCE FICTION ASTROLOGY ATLANTA ATLANTA HOMES & LIFESTYLES ATLANTIC MONTHLY AUDIO AUDIO / VIDEO INTERIORS AUDUBON AUTO RACING DIGEST AUTOMOBILE AUTOMOTIVE NEWS AUTOMUNDO AUTOTRONICS AUTOWEEK AVENGERS (COMIC) AVENGERS WEST COAST (COMIC) AVIATION HERITAGE BACK STAGE BACKPACKER BACKSTRETCH BALTIMORE BANK NOTE REPORTER BARBIE (COMIC) BARBIE FASHION BOOK (COMIC) BARBIE MAGAZINE BARELY LEGAL BARTER NEWS BASEBALL CARD PRICE GUIDE BASEBALL CARDS MAGAZINE BASEBALL DIGEST BASEBALL WEEKLY (USA TODAY) BASKETBALL DIGEST BASKETBALL WEEKLY BASS PLAYER BASS & WALLEYE BOATS BASSIN' BATMAN (COMIC) BEAVIS & BUTTHEAD BERKSHIRE BEST RECIPES BETTER HOMES & GARDENS BEVERAGE WORLD BEVERAGE WORLD BIBLE REVIEW BIBLICAL ARCHAEOLOGY REVIEW BICYCLE GUIDE BICYCLING BIG BEAUTIFUL WOMAN (BBW) BIRD TALK BIRDER'S WORLD BLACK AXE (COMIC) BLACK BELT BLACK COLLEGIAN BLACK ELEGANCE BLACK ENTERPRISE BLOOD HORSE BLUE & GOLD ILLUSTRATED BOARDROOM REPORTS BOATING BOATING WORLD BODY - MIND - SPIRIT BON APPETIT BOSTON MAGAZINE BOTTOM LINE / PERSONAL BOW & ARROW BOW & ARROW HUNTING BOW HUNTING WORLD BOWHUNTER BOWHUNTING BOWHUNTING WORLD BOWLING DIGEST BOWMASTERS BOXING ILLUSTRATED BOY'S LIFE BRIDAL GUIDE BRIDES BRITISH CAR BRITISH HERITAGE BROADCASTING BUCKHUNTERS DIGEST BUENHOGAR BUSINESS PUBLISHING BUSINESS START-UPS BUSINESS WEEK BUZZ (TALK OF LOS ANGELES) BYTE CABLE (COMIC) CALIFORNIA JOURNAL CAMCORDER CAMERA & DARKROOM CAMPUS LIFE CANDY INDUSTRY CANOE CAPPER'S CAPTAIN AMERICA (COMIC) CAR AUDIO & ELECTRONICS CAR COLLECTOR & CAR CLASSICS CAR CRAFT CAR & DRIVER CAR STEREO REVIEW CARAS DE PUERTO RICO CARD COLLECTOR'S PRICE GUIDE CARIBBEAN TRAVEL & LIFE CARS & PARTS CASH SAVER CAT FANCY CATALOG SHOPPING CATHOLIC DIGEST CATHOLIC FAMILY BIBLE CATTLEMAN CATWOMAN (COMIC) CD REVIEW CD-ROM TODAY CD-ROM WORLD CENTRAL FLORIDA CAREER GUIDE (W/UPDATES) CHAMPION CROSSWORD PUZZLES CHAMPION VARIETY PUZZLES CHAMPION VARIETY REVIEW CHANGES CHARISMA & CHRISTIAN LIFE CHATELAINE (IN ENGLISH) CHATELAINE (IN FRENCH) CHESAPEAKE BAY CHEVY HIGH PERFORMANCE CHIC CHICAGO CHILD CHILD LIFE CHILDREN'S ALBUM CHILDREN'S CLASSICS CHILDREN'S DIGEST CHILDREN'S PLAYMATE CHOCOLATIER CHRISTIAN HISTORY CHRISTIAN PARENTING TODAY CHRISTIAN READER CHRISTIAN SCIENCE MONITOR CHRISTIANITY TODAY CIRCLE TRACK CIRCUS CIVIL WAR CHRONICLES CIVIL WAR TIMES CLASSIC AUTO RESTORER CLEVELAND MAGAZINE COACH COIFFURE DE PARIS COIN PRICES COIN WORLD COINAGE COINS MAGAZINE COLLECTOR EDITIONS COLLECTORS MART COLLECTORS NEWS COLLECTORS NEWS COLLEGE SPORTS COLONIAL HOMES COLORADO BUSINESS COLORADO HOMES & LIFESTYLES COLUMBIA JOURNALISM REVIEW COMIC BOOK COLLECTOR COMIC BOOK COLLECTOR'S PRICE GUIDE COMIC SCENE COMICS BUYERS GUIDE COMICS SCENE COMMON CAUSE COMMONWEAL COMPUTER GAME REVIEW & CD-ROM ENTERTAINMENT COMPUTER GAMING WORLD COMPUTER LIFE COMPUTER SHOPPER COMPUTERWORLD CONAN CLASSICS (COMIC) CONAN SAGA (COMIC) CONAN THE ADVENTURER (COMIC) CONDE NASTE TRAVELER CONSUMER REPORTS CONSUMER REPORTS ON HEALTH CONSUMER REPORTS TRAVEL LETTER CONSUMER RESEARCH CONSUMERS DIGEST CONSUMERS RESEARCH CONTEMPORARY CHRISTIAN MUSIC COOK'S ILLUSTRATED COOKBOOK DIGEST COOKING LIGHT CORVETTE FEVER COSMOPOLITAN COSMOPOLITAN EN ESPANOL COUNTRY COUNTRY ACCENTS COUNTRY AMERICA COUNTRY FEVER COUNTRY GUIDE COUNTRY HANDCRAFTS COUNTRY HOME COUNTRY HOME FOLK CRAFTS COUNTRY JOURNAL COUNTRY JOURNAL COUNTRY LIVING COUNTRY MUSIC COUNTRY MUSIC CITY NEWS COUNTRY SAMPLER COUNTRY WOMAN CQ RADIO AMATEURS JOURNAL CRAFTING TODAY CRAFTS CRAFTS 'N THINGS CRAFTWORKS FOR THE HOME CRAIN'S NEW YORK BUSINESS CRAYOLA KIDS CREATIVE CLASSROOM CREATIVE KIDS CREATIVE QUILTING CREATIVE REAL ESTATE CREATIVE WOODWORKING & CRAFTS CRICKET CROCHET DIGEST CROCHET FANTASY CROCHET HOME CROCHET WORLD CROCHET WORLD SPECIALS CROSS COUNTRY SKIER CROSS STITCH CROSS STITCH PLUS CROSS STITCHER CROSSSTITCH & COUNTRY CRAFTS CRUISE TRAVEL CRUISE TRAVEL CRUISES & TOURS CRUISING WORLD CUSTOM & CLASSIC TRUCKS CUSTOMER ASSURANCE REPORT CUSTOMER SERVICE NEWSLETTER CYCLE WORLD DAILY NEWS RECORD DANCE DAREDEVIL (COMIC) DARKHAWK (COMIC) DAS LEBEN DATA BASED ADVISOR DAYTIME TV DBMS (DATABASE MANAGEMENT SYSTEMS) DEATH'S HEAD II (COMIC) DEBATE ISSUES DECORATING DIGEST DECORATIVE ARTIST'S WORKBOOK DECORATIVE ARTS PAINTING DECORATVE WOODCRAFTS DEER & DEER HUNTING DEFENSE NEWS DELAWARE TODAY DELL CROSSWORD PUZZLES DELL CROSSWORD SPECIAL DELL CROSSWORDS & VARIETY PUZZLES DELL HOROSCOPE DELL LOGIC PUZZLES DELL OFFICIAL CROSSWORD PUZZLES DELL OFFICIAL PENCIL PUZZLE & WORD GAMES DELL OFFICIAL WORD SEARCH PUZZLES DELL PENCIL PUZZLES & WORD GAMES DELL POCKET CROSSWORD PUZZLES DELL POCKET CROSSWORD PUZZLES DELL WORD SEARCH PUZZLES DES DESKTOP VIDEO WORLD DESSERTS DETAILS DETECTIVE COMICS DETROIT MONTHLY DIRT BIKE DISCIPLESHIP JOURNAL DISCOUNT STORE NEWS DISCOVER DISCOVER DIVING DISNEY ADVENTURES DISNEY'S HOW IT WORKS DISTRIBUTION CENTER MANAGEMENT DOG FANCY DOG WORLD DOLL CASTLE NEWS DOLL DESIGNS DOLL LIFE DOLL WORLD DOLLMAKING DOLLS DOOM 2099 (COMIC) DOWN EAST DOWN MEMORY LANE DOWNBEAT DR. DOBB'S JOURNAL DR. STRANGE (COMIC) DRUG & COSMETIC INDUSTRY EARLY AMERICAN LIFE EARLY CHILDHOOD NEWS EARLY CHILDHOOD TODAY EARTH EARTH JOURNAL EASY FAST "N FUN CROSSWORDS EATING WELL EBONY EBONY MAN (EM) ECONOMIST ECOTRAVELER ELECTRONIC GAMES ELECTRONIC GAMING MONTHLY ELECTRONIC LEARNING ELECTRONICS NOW ELITE MAGAZINE ELLE (AMERICAN) ELLE DECOR ELLERY QUEEN'S MYSTERY ELLERY QUEEN'S MYSTERY EM (EBONY MAN) EMERGE ENGINEERING NEWS RECORD (ENR) ENTERTAINMENT WEEKLY (EW) ENTREE ENTREPRENEUR ENVIRONMENT EQUITIES EQUUS ESQUIRE ESSENCE EUROPEAN CAR EXCALIBUR (COMIC) EXCEPTIONAL PARENT EXECUTIVE FEMALE FAITH & STUFF FAMILY CIRCLE FAMILY HANDYMAN FAMILY LIFE FANCY FOOD & CANDY FANGORIA FANTASTIC FOUR (COMIC) FANTASY & SCIENCE FICTION FAR OUT FARM BUILDING NEWS FARM & RANCH LIVING FARMERS DIGEST FASHION GUIDE FASHION KNITTING FATE FEDERAL TIMES FEMALE BODYBUILDING FIELD & STREAM FIGHTING KNIVES FIGHTING STARS NINJA MAGAZINE FILM THREAT FINANCIAL TIMES OF LONDON (MON - SAT) FINANCIAL WORLD FINE GARDENING FINE HOMEBUILDING FINE WOODWORKING FIREHOUSE FISHING FACTS FISHING & HUNTING NEWS FISHING WORLD FIVE LITER MUSTANG FLARE FLASH (COMIC) FLEX FLOORING FLORIDA LIVING FLORIDA SPORTSMAN FLORIDA TREND FLORIDA VACATION RENTALS FLOWER & GARDEN FLY FISHERMAN FLY FISHING FLYING FLYING MODELS FOOD & WINE FOOTBALL DIGEST FOOTBALL NEWS FORBES FORCE WORKS (COMIC) FOREIGN AFFAIRS FOREIGN POLICY FORTUNE FORUM (PENTHOUSE) FOUR WHEEL / OFF ROAD FOUR WHEELER FRONT PAGE DETECTIVE FUN-ZONE FUR - FISH - GAME FUTURIFIC FUTURIFIC G.I. JOE (COMIC) GAME PLAYERS NINTENDO GUIDE GAME PLAYERS NINTENDO - SEGA GAME PLAYERS PC ENTERTAINMENT GAMEPRO GAMES GARBAGE GEMS & GEMNOLOGY GEMS & GEMNOLOGY GENTLEMEN'S QUARTERLY (GQ) GEOMUNDO GET RICH NEWS GHOST RIDER 2099 (COMIC) GHOST RIDER / BLAZE (COMIC) GHOST RIDER (COMIC) GIFTS & DECORATIVE ACCESSORIES GIFTWARE NEWS GLAMOUR GLASS DIGEST GLEANINGS IN BEE CULTURE GOD'S WORD TODAY GOLDMINE GOLF DIGEST GOLF FOR WOMEN GOLF MAGAZINE GOLF TIPS GOLF WEEK GOLF WORLD GOLFING GOOD DAY SUNSHINE GOOD HOUSEKEEPING GOOD OLD DAYS GOOD OLD DAYS SPECIALS GOURMET GREEN LANTERN (COMIC) GRIT GROO (COMIC) GROWING UP WITH SCIENCE GUARDIANS OF THE GALAXY (COMIC) GUIDEPOSTS GUIDEPOSTS (LARGE PRINT EDITION) GUN DOG GUN LIST GUN WORLD GUNS GUNS & AMMO GUNS & AMMO HAIR ADDITIONS HAIR & BEAUTY NEWS HANDCRAFT ILLUSTRATED HANDGUNNING HANDGUNS HARPER'S BAZAAR HARPER'S BAZAAR EN ESPANOL HARPER'S MAGAZINE HARROWERS (COMIC) HARVARD BUSINESS REVIEW HAWAII HEALTH HELLSTORM (COMIC) HERALD TRIBUNE CROSSWORD PUZZLES ONLY HERALD TRIBUNE & OTHER CROSSWORD GAMES HERO ILLUSRATED HIGHLANDER HIGHLIGHTS HIGHLIGHTS HISPANIC HISTORIC PRESERVATION HOCKEY DIGEST HOCKEY NEWS HOLLYWOOD STUDIO HOLLYWOOD STUDIO MAG THEN & NOW HOMBRE DE MUNDO HOME COOKING HOME GYM & FITNESS HOME MAGAZINE HOME MAGAZINE HOME MECHANIX HOME OFFICE COMPUTING HONOLULU HOOKED IN CROCHET HORIZON HOROSCOPE HOROSCOPE/ A PERSONAL DAILY GUIDE FOR EVERYONE HOROSCOPE / DELL HORSE & HORSEMAN HORSE & HORSEMAN HORSE ILLUSTRATED HORSE & RIDER HORSEPLAY HORTICULTURE HOT BOAT HOT ROD HOT ROD HARLEYS HOUSE BEAUTIFUL HOUSTON METROPOLITAN HOUSTON PEOPLE HOUSTON PROFILES HOW HUDSON VALLEY HUMPTY DUMPTY HUNTING HUSTLER HUSTLER'S BUSTY BEAUTIES HUSTLER'S EROTIC VIDEO GUIDE HUSTLER'S FANTASIES HUSTLER'S HUMOR I LOVE CATS IDEAS IDEAS PARA SU HOGAR ILLUSTRATED BIBLE FOR CHILDREN IMPORT AUTO PARTS & ACCESSORIES IN BUSINESS IN-FISHERMAN INC. INCOME OPPORTUNITIES INCOME PLUS INCREDIBLE HULK (COMIC) INDIVIDUAL INVESTOR IINDUSTRIAL MARKET PLACE INSIDE EDGE INSIDE IRELAND INSIDE KARATE INSIDE KUNG FU INSIDE SPORTS INSIGHT INSTITUTIONAL INVESTOR INSTRUCTOR INTERIOR DECORATOR'S HANDBOOK INTERIOR DESIGN INTERIORS INTERNATIONAL LIVING INTERNATIONAL NURSING INDEX INTERNET WORLD INTERVIEW INTIMATE FASHION NEWS INVESTOR'S DAILY IRON MAN (COMIC) ISLANDS ISRAEL SCENE JACK & JILL JERSEY WOMAN JERUSALEM POST INTERNATIONAL WEEKLY EDITION JERUSALEM REPORT JET JEWISH EXPONENT JEWISH HOMEMAKER JEWISH POST & OPINION JEWISH PRESS JUSTICE LEAGUE AMERICA (COMIC) JUSTICE LEAGUE EUROPE ( COMIC) KARATE / KUNG FU ILLUSTATED KEYBOARD KID CITY KIDSPORTS KIPLINGER'S PERSONAL FINANCE KIT CAR KITPLANES KNIFE WORLD KNITTING DIGEST KNITTING WORLD L'ACTUALITE LA LUZ LA VIE LADIES HOME JOURNAL LADY'S CIRCLE LADYBUG LAKELAND BOATING LAN MAGAZINE (LOCAL AREA NETWORK) LAPIDARY JOURNAL LEADERSHIP LEARNING '94 LEFTHANDER LEGAL GUIDE FOR THE FAMILY LEGION OF SUPER-HEROES (COMIC) LET'S LIVE LIBRARY OF NATURAL WONDERS LIFE LIGHTING DIMENSIONS LINK-UP LINN'S STAMP NEWS LITTLE MERMAID LLUMO VOGUE LONGEVITY LOONEY TUNES (COMIC) LOOSE CHANGE LOS ANGELES LOTTERY PLAYERS MAGAZINE MAC HOME JOURNAL MACLEANS MACUSER MACWORLD MADEMOISELLE MARKETERS FORUM MARRIAGE PARTNERSHIP MARVEL AGE (COMIC) MARVEL COMICS PRESENTS MARVEL TALES SPIDERMAN (COMIC) MCCALL'S MCCALL'S NEEDLEWORK & CRAFTS MECANICA POPULAR MECHANICA POPULAR MEDIA & METHODS MEDICAL & HEALTH ENCYCLOPEDIA MEDICAL HOTLINE MEDICAL UPDATE MEGA PLAY MEMPHIS MAGAZINE MEN'S CONFIDENTIAL MEN'S FITNESS MEN'S HEALTH MEN'S JOURNAL METROPOLIS METROPOLITAN HOME MICKEY MOUSE MICRO COMPUTER JOURNAL MICROSOFT SYSTEMS JOURNAL MID-ATLANTIC COUNTRY MIDSTREAM MIDWEST LIVING MILITARY HISTORY MILWAUKEE MINISTRIES TODAY MINNESOTA MONTHLY MIRABELLA MOBILE OFFICE MODEL AIRPLANE NEWS MODEL NEWS MODEL SHOPPER MODELS & TALENT/CASTING NEWS MODERN BRIDE MODERN GUN MODERN HORSE BREEDING MODERN SALON MOMENT MONEY MONEYPAPER MOODY MAGAZINE MOODY MONTHLY MOPAR MUSCLE MORIBUS (COMIC) MOTHER EARTH NEWS MOTHER JONES MOTHERING MOTOR BOATING & SAILING MOTOR TREND MOTORCROSS ACTION MOTORCYCLE CONSUMER NEWS MOTORCYCLIST MOTORHOME MOUNTAIN BIKE MOVIE MARKETPLACE MOVIELINE MUNDO 21 MUSCLE & FITNESS MUSCLECAR REVIEW MUSICIAN MUSTANG MONTHLY MUSTANGS & FORDS MUSTANGS MONTHLY NAILS NAMOR (COMIC) NATION NATION'S BUSINESS NATION'S RESTAURANT NEWS NATIONAL AUCTION REPORT NATIONAL ENQUIRER NATIONAL FISHERMAN NATIONAL LAW JOURNAL NATIONAL OTC STOCK JOURNAL NATIONAL PARK MAGAZINE NATIONAL REVIEW NATIONAL TRIAL LAWYER NATURAL HEALTH NATURAL HISTORY NAVY TIMES NBA INSIDE STUFF *THE NET* (about the Internet) NEEDLE & CRAFT NEVADA MAGAZINE NEW AGE JOURNAL NEW BUSINESS OPPORTUNITIES NEW CHOICES NEW ENGLAND JOURNAL OF MEDICINE NEW FARM NEW JERSEY MONTHLY NEW JERSEY OUTDOORS NEW MEXICO NEW REPUBLIC NEW TITANS (COMIC) NEW WARRIORS (COMIC) NEW WOMAN NEW YORK MAGAZINE NEW YORK REVIEW OF BOOKS NEW YORKER NEWSWEEK NICE & EASY FAMILY COOKBOOK NIGHT TRASHER (COMIC) NIGHT WATCH (COMIC) NO-TILL FARMER NORTH FLORIDA LIVING NORTH SHORE (CHICAGO) NOVA (COMIC) NUMISMATIC NEWS NURSING NUTRITION & DIETARY CONSULTANT NUTRITION HEALTH REVIEW OCCASIONAL BULLETIN OFF ROAD OFFICIAL CROSSWORD PUZZLES OFFICIAL DETECTIVE OFFICIAL MAJOR LEAGUE BASEBALL ROOKIE LEAGUE MAGAZINE FOR KIDS OFFICIAL PENCIL PUZZLES / WORD GAMES OFFICIAL US CUSTOM HOUSE GUIDE OFFICIAL WORD SEARCH PUZZLES OLD CARS NEWS & MARKETPLACE OLD CARS PRICE GUIDE OLD HOUSE JOURNAL OLD TIME CROCHET OMNI ONLINE ACCESS ONSAT OPEN WHEEL OPERA NEWS OPPORTUNITY MAGAZINE ORGANIC GARDENING OUTDOOR LIFE OUTDOOR PHOTOGRAPHER OUTDOOR PRESS OUTSIDE OVERDRIVE PACIFIC NORTHWEST PACK -O-FUN PADDLE SPORTS PADDLER PAINTWORKS PALM BEACH LIFE PALM SPRINGS LIFE PARENTING PARENTS PARENTS OF TEENAGERS PASSION PASSION FOR MEN PC COMPUTING PC GAMER PC GAMES PC KIDS PC LAPTOP PC MAGAZINE PC NOVICE PC TODAY PC WORLD PC WORLD LOTUS EDITION PC WORLD MULTI MEDIA EDITION PCM PENNSYLVANIA SPORTSMAN PENTHOUSE PENTHOUSE LETTERS PEOPLE PET DEALER PHILADELPHIA PHOENIX HOME & GARDEN PHOTOGRAPH COLLECTOR PHOTOGRAPHIC PINHEAD (COMIC) PLANE & PILOT PLASTIC CANVAS PLASTIC CANVAS & MORE PLASTIC CANVAS WORLD PLAYBOY PLAYGIRL PLAYTHINGS POCKET CROSSWORD PUZZLES POLO POPULAR COMMUNICATIONS POPULAR ELECTRONICS POPULAR HOT RODDING POPULAR MECHANICS POPULAR PHOTOGRAPHY POPULAR SCIENCE POPULAR WOODWORKING PORTABLE COMPUTING POST SCRIPT POST SCRIPTS: ESSAYS IN FILM & THE HUMANITIES POWDER POWER & MOTOR YACHT PRACTICAL HORSEMAN PREMIERE PRESENT TENSE PREVENTION PRIVATE PILOT PRO FOOTBALL WEEKLY PROGRESSIVE PROGRESSIVE FARMER PROTESTANT DELUXE BIBLE PROTESTANT FAMILY BIBLE PSYCHOLOGY TODAY PUBLISH PULSE PUNISHER 2099 (COMIC) PUNISHER (COMIC) PUNISHER WAR JOURNAL (COMIC) PUNISHER WAR ZONE (COMIC) QUASAR (COMIC) QUICK & EASY CRAFTS QUICK & EASY CROCHET QUICK & EASY NEEDLECRAFT ?QUICK & EASY PLASTIC CANVAS QUICK & EASY QUILTING QUILT WORLD QUILTER'S NEWSLETTER QUILTER'S TREASURY QUILTER'S TREASURY QUILTING INTERNATIONAL QUILTMAKER RAILROAD MODEL CRAFTSMAN RAPPAGES RAPPORT RAVAGE 2099 (COMIC) REAL PEOPLE REALTY MAGAZINE REDBOOK REMINISCE REN & STIMPY (COMIC) RETIREMENT INCOME NEWSLETTER RIDER RIGHT ON RIP ROAD RIDER ROAD & TRACK ROBB REPORT ROCK & GEM ROD & CUSTOM ROLLING STONE RUNNER'S WORLD RUNNING TIMES RURAL BUILDER S.W.A.T. SABERTOOTH CLASSICS (COMIC) SADDLE & BRIDE SAIL SAILING SAILING WORLD SALTWATER SPORTSMAN SAN DIEGO HOME & GARDEN SAN DIEGO MAGAZINE SAN FRANCISCO SASSY SATELLITE TV PRE-VUE SATELLITE TV WEEK SATURDAY EVENING POST SAVAGE SWORD OF CONAN (COMIC) SCHOLASTIC COACH SCHOOL & COLLEGE SCIENCE LIBRARY SCIENCE NEWS SCIENCE OF MIND SCIENCES SCIENTIFIC AMERICAN SCUBA DIVING SCUBA TIMES SEA MAGAZINE SECRET DEFENDERS (COMIC) SELF SESAME STREET SEVENTEEN SEVENTY-THREE AMATEUR RADIO SEW NEWS SEYBOLD REPORT ON DESKTOP PUBLISHING SHAPE SHOOTING TIMES SHOP TALK SHORT STORY INTERNATIONAL SHOW BIZ / CASTING NEWS SHOW BIZ NEWS/MODEL NEWS SHOWBOATS INTERNATIONAL SIDEKICKS SIDEKICKS SOCCER SILVER SABLE (COMIC) SILVER SURFER (COMIC) SIMPLY CROSS STITCH SKATEBOARDING SKI SKIING SKIN DIVER SKIN & INK SMITHSONIAN SNOW COUNTRY SNOW GOER SNOW WEEK SNOWBOARDING SNOWMOBILE SOAP OPERA DIGEST SOAP OPERA MAGAZINE SOAP OPERA STARS SOCCER AMERICA SOCCER DIGEST SOCCER INTERNATIONAL SOUNDINGS SOUTH FLORIDA SOUTHERN ACCENTS SOUTHERN BOATING SOUTHERN HOMES SOUTHERN LIVING SOUTHERN OUTDOORS SPACE NEWS SPECIAL EVENTS SPECIAL SITUATIONS REPORT SPECIALTY CAR SPECTACULAR SPIDERMAN (COMIC) SPIDERMAN 2099 (COMIC) SPIDERMAN CLASSIC (COMIC) SPIDERMAN (COMIC) SPIN SPORT SPORT DIVER SPORT FISHING SPORT RIDER SPORT TRUCK SPORTING CLASSICS SPORTING NEWS SPORTS AFIELD SPORTS CARD TRADER SPORTS COLLECTORS DIGEST SPORTS ILLUSTRATED SPORTS ILLUSTRATED FOR KIDS SPORTSWEAR INTERNATIONAL SPOTLIGHT STAR STAR TREK (COMIC) STAR TREK : THE NEXT GENERATION (COMIC) STARLOG STEREO REVIEW STITCH 'N SEW QUILTS STOCK CAR RACING STONE SOUP STORY STUDIO USA STYLE TRENDS SUCCESS SUCCESSFUL RETIREMENT SUNBONNET CRAFTS SUNSET SUPER CHEVY SUPER COMPUTING REVIEW SUPER CYCLE SUPER FORD SUPER NES BUYERS GUIDE SUPER STOCK & DRAG ILLUSTRATED SUPERCYCLE SUPERMAN - MAN OF STEEL (COMIC) SURFER SURFING SURPRISES SWAP USA SWAT T-SHIRT RETAILER TAMPA BAY CAREER GUIDE (WITH UPDATES) TASTE OF HOME TAX HOTLINE TCI TEACHING PRE K-8 TECHNOLOGY & LEARNING TEDDY BEAR REVIEW TEEN TEEN BEAT TEENAGE MUTANT NINJA TURTLES (COMIC) TEK WORLD (COMIC) TENNIS TEXAS FISH & GAME TEXAS GARDENER THE SCIENCES THEATRE CRAFTS THEOLOGY TODAY THOR (COMIC) THREADS THREE-TWO-ONE CONTACT THUNDERSTRIKE (COMIC) TIME TODAY'S CATHOLIC TEACHER TODAY'S CHRISTIAN WOMAN TOLE WORLD TOTAL HEALTH TOURING AMERICA TOWN & COUNTRY TOY SHOP TRACK & FIELD NEWS TRADING CARDS TRADITIONAL HOME TRADITIONAL QUILTER TRAILER BOATS TRAILER LIFE TRANSFORMERS GENERATION 2 (COMIC) TRANSWORLD SKATEBOARDING TRAPPER & PREDATOR CALLER TRAVEL 50 & BEYOND TRAVEL AMERICA TRAVEL HOLIDAY TRAVEL & LEISURE TRAVELAMERICA TREASURE TRIATHLETE TRUE DETECTIVE TRUE STORY TU TURKEY & TURKEY HUNTING TURTLE TV CROSSWORDS TV HOST TV Y NOVELAS (PUERTO RICO) TV Y NOVELAS (USA) TWINS UNCANNY X-MEN (COMIC) UNDERWATER USA UNIQUE HAIR & BEAUTY UNIQUE HOMES US AVIATOR US CATHOLIC US MAGAZINE US NEWS & WORLD REPORT USA TODAY UTNE READER VACATIONS VANIDADES VANITY FAIR VARIATIONS (PENTHOUSE) VARIETY (WEEKLY) VEGETARIAN TIMES VEGGIE LIFE and many, many more!!! Once you get in, you'll love them. I do. For more info, just fill out the form near the top of this message and email it to their email address shown there. Thanks, Susan Johnson ======================================================================= 72 === Date: 8 Jun 1995 02:37:46 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <3r4qqt$rkj@nntp5.u.washington.edu> "Marc E. Fiuczynski" writes: >It seems that it would be beneficial to the FSF to separate their backend >from their frontend. Many of the backend optimizations are applicable to >Fortran, Ada, M3, C and friends, and possibly other languages. The FSF >already provides a set of nice compiler tools, and separating the backend >would not only assist them in developing different frontends quickly, but >allow projects, like SRC M3, to take advantage of their software. I don't follow the logic here. The existing front ends already have the use of these optimizations and backend technology by virtue of being linked in with it. How does this improve if they are not linked together as one image? Initially, the GNAT project, for bootstrapping reasons, had its front end write out its annotated Ada syntax tree (NOT the representation used by GCC) and have it read back in by a small (6,000 line) GCC front end. We have now merged these three pieces into a single image; the 6,000 line program is called Gigi (GNAT-to-GCC). However, currently, Gigi makes extensive calls into front end routines. The front end also calls the backend to do things besides compiling (such as finding out various sizes and machine parameters). It is also possible for the backend (via callbacks) to call parts of the front end. If these were split into separate programs, all these tasks would be much harder. We merged them into one program precisely to make our task simpler. >What would be required to separate the backend? I guess someone has to >define an acceptable intermediate representation that the frontends compile >to and then have the backend read that back in. But the interface between the front ends and the backend is procedural, and does not involve forming a data structure by the front end and reading it in the backend. Doing such a split would: (1) Inflict serious damage to the concept of free software. (2) Make it harder for people to write efficient front ends. (3) Take considerable resources in designing, writing, and testing such an interface. I don't understand why anybody would want to do this. ======================================================================= 73 === Date: 8 Jun 95 08:55:18 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: when NEW fails, revisited In article <9506071258.AA11543@cloyd.East.Sun.COM> gwyant@cloyd.East.Sun.COM (G eoffrey Wyant - Sun Microsystems Labs BOS) writes: Maybe it's time for someone to go back and summarize the issues. I agree with Geoff on the need for a summary. I will see if I can find the old article posted by Paul McJones and add the new points to it in a little bit. For now, I want to respond to something Geoff said. > What do C/C++ programmers do about memory exhaustion? > Fail horribly... [... CodeCenter's behavior was omitted.] While this may be true for UNIX-based C/C++ programs, C programs running on not-so-programmer-friendly operating systems such as the Macintosh deal with lack of memory much more gracefully. Take Adobe Photoshop, for example. It uses a scratch disk for "emulating" virtual memory; it warns you if you don't have enough scratch disk; it warns you when it thinks your operation will take too much memory to complete, and in the worst case, it will cancel your operation. (Though Photoshop, having a very simple application flow, and "internal" virtual memory is probably not a great comparison.) Macintosh Finder will close windows when it realizes you are close to being out of memory. I bet if you put it in weird situations it will not address them, but its policy works for the most part. When there is not enough memory, Macintosh PrintMonitor asks you whether you want to "bring it to the front" (and therefore give it more memory) or if it should print later. Eudora for the Macintosh will do the same in a less gracefull fashion. It will warn you before hand and then if you run out, it will "save the files" and then exit, I think. I bet there are some Macintosh programming guidelines for dealing with low-memory conditions gracefully. In the worst case, what about trying something like the NeXT Session Manager? I recall hearing that NeXT's Session Manager (or whatever it is called) will warn you before going down (due to a severe errors) and gives you a few seconds to save your files and quit important applications. (This procedure can be applied in a multi-threaded environment, I think, couldn't it?) I agree that in Modula-3 things are more complicated, but I think most mainstream Mac apps (with the exception of Microsoft ones probably ;-) handle low-memory conditions pretty well. There is also the question of portability and operating system dependence. It'd be interesting to see what the UNIX and Windows versions of Photoshop, or Eudora do in low memory. -- Farshad -- Farshad Nayeri nayeri@gte.com ``Obviously, in each of these cases design decisions have been made, but unfortunately they were wrong.'' --Victor Papanek, Design for the Real World ======================================================================= 74 === Date: 8 Jun 1995 02:26:27 GMT From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) In article <1995Jun7.101538.26580@wavehh.hanse.de> cracauer@wavehh.hanse.de (Ma rtin Cracauer) writes: >>I doubt it, what possible FSF goal can be met by such a separation, it >>would seem to promote exactly that which FSF tries hard to prevent, the >>creation of proprietary technologies which make use of free software. > >I don't think so. IMHO, the only reason why the separation isn't done >is that noone spent the time on it. Robert is quite correct. Richard Stallman has been adamantly opposed to any attempt to split front ends into separate programs for precisely the reason Robert gives. >The GNU-Objective-C folks, for example, would be very happy to have >their frontend mixed with the C++ frontent to allow Objctive-C++ >programs. True, but what does this have to do with the separation issue? It seems instead that such mixture would be even *less* separated. >From what I heared, the FSF would be happy to make the gcc backend an >easier-to-use tool for language implementors. Certainly true, but again this has nothing to do with separation of the kind Robert was talking about. >The backend has to be modified anyway to allow better optimization for the >deeper pipelines of modern CPUs. There are lots of optimizations that could be added to the backend to produce better code; GCC does reasonably well now with pipeline delays, so the above doesn't appear to be one of the more important. However, again, what does this have to do with the separation issue? >If the current way to implement m3 causes major overhead, maybe the >time required for every m3-inside-gcc-backend release would be better >invested in turning gcc into something that causes less overhead. The experiences of the GNAT project show how valuable GCC has been to language implementation since they were able to concentrate solely on language issues and leave code generation, optimization, and portability issues to GCC. However, everything can be improved. I welcome your suggestions for making it easier to write front ends to GCC. ======================================================================= 75 === Date: 11 Jun 95 21:19:02 GMT From: amichail@cs.toronto.edu (Amir Michail) Subject: modula 3 compiler for PC Hi. I was wondering how quickly the modula-3 compiler (by DEC) works on a fast PC with 8 megs. How long does it take to compile and link a "hello world" program? Thanks, Amir ======================================================================= 76 === Date: Mon, 12 Jun 95 06:46:24 GMT From: cracauer@wavehh.hanse.de (Martin Cracauer) Subject: Re: Modula-3 (Was: Comparison of languages for CS1 and CS2) Folks, I admit that my previous posting to comp.lang.modula3 regarding the seperation of the gcc front- and backend was uninformed in a number of techincal and non-techincal ways. Please ignore it. -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer . No NeXTMail, please. Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a private address. At (netless) work programming in data analysis. ======================================================================= 77 === Date: 12 Jun 95 17:48:55 HKT From: clewis@ferret.ocunix.on.ca (Sylvia Wong) Subject: Lonely Lily - Still Alive! Rumors of Lily's demise are greatly exagerated. As I said before, my friend Lily lives in Hong Kong, like me. She loves to receive phone calls from foreign men. She does not have computer, so I am sending this message for her. If you want to call her and you are in the United States the number is 011 852 1747 3094. Callers from other countries need to put the international code then 852 1747 3094. No e-mail please. Sylvia Wong PS. Lily sends her love to all the boys at new@pobox.com ======================================================================= 78 === Date: Mon, 12 Jun 1995 17:49:02 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: When NEW fails (summary) >Blair MacIntyre wrote (summarised) > >At first glance, it would appear that the only effect on the libraries >of raising new would be a plethora of "unhandled exception" warnings .... While not exactly what we >want, this would give no change in behaviour. > >I realize that it would take a fair amount of cleaning up ..., but >it would seem to me to be worth it. So much so that I would volunteer >to help tidy things up. >Be that as it may, I prefer the solution of registering routines to be >called when memory runs out. ... > >As for the multithreaded issues, it would seem to me that if the >allocator calls these routines inside a mutex, then tries again... > I guess we might be surprised at how many exceptions we'll see but I'm all for doing it. Having an exception at least highlights the fact that an operation might bring our world down, for example a := b & c; I wonder how many operations there are that implicitly allocate memory? I would like to see both approaches implemented. If we want to put up with the possibility of running out of memory that should be our choice, not forced upon us as currently is the case. Even within a single system the use of both might be appropriate, perhaps in concert. Consider for example a database server with many clients. When we run out of memory the first thing that might happen is that our registered routine get's called. It will adjust some global information which will tend to reduce the memory usage. It can then return indicating either that the exception be raised or the allocation retried, whichever is appropriate. The problem I have with having no exception mechanism is, how do you inform a thread that its attempted allocation just failed? The only way implemented so far is the exception mechanism. ======================================================================= 79 === Date: Thu, 15 Jun 1995 06:55:04 -0400 From: Wayne Ward Subject: Calling process Hi All, I'am a COBOL programmer thinking of going to modula3. I would like to know how the calling process works. If i have two programs, progA and progB, both being main. Can progA call progB, have progB do somthing then return to progA where the instruction to call progB was excuted? I just finished taken a 'C' class and was suprise that this can not be done in 'C', so my professor said. Thanks Wayne, ======================================================================= 80 === Date: Thu, 07 Jun 95 19:34:39 GMT From: ts4@iis.joanneum.ac.at Subject: telematic sculptur 4 (T.S.4) this mobile sculpture (length 21,8 meters, weight 1800 kg) by r. kriesche is physically positioned in the austrian pavilion during the biennale of venice. T.S.4 is driven by the data flow in internet according to the relation of the world wide computer newsgroups versus world wide art newsgroups. according to this relation T.S.4 will transcross the austrian pavilion during the time of the biennale and might even break through the wall of the pavilion. you are invited to become part of T.S.4 by: o visiting its www homepage http://iis.joanneum.ac.at/kriesche/biennale95.html o discussion about T.S.4 on usenet news o sending e-mail to T.S.4 (mailto:ts4@iis.joanneum.ac.at) your participation will slow down the movement of T.S.4 and prevent it crashing.