======================================================================= 1 === Date: 01 Apr 1995 05:33:44 GMT From: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Subject: Re: need font-lock support for modula3 mode in lemacs umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes: | Does anyone have a nice "modula3-font-lock-keywords" to color modula-3 | programs in lucid emacs? Big colored capital letters sounds really unappealing. Better to put them in a small font, which will simulate the easy to read style of lower case keywords. (Simulated ergonomics. Cool!) ======================================================================= 2 === Date: 1 Apr 95 17:42:07 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: need font-lock support for modula3 mode in lemacs In article schwartz@galapagos.cse .psu.edu (Scott Schwartz) writes: umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes: | Does anyone have a nice "modula3-font-lock-keywords" to color modula-3 | programs in lucid emacs? Big colored capital letters sounds really unappealing. Better to put them in a small font, which will simulate the easy to read style of lower case keywords. (Simulated ergonomics. Cool!) It depends, if they are not appealing to you, you can use a lighter shade of gray for keywords. I agree though: an editor that quickly changed the keywords to lowercase (perhaps bold lowercase) upon loading would be cool. Kind of like good old THINK Pascal. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 3 === Date: 1 Apr 1995 12:34:08 -0500 From: fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.) Subject: m3rpc package I'm looking to build the RPC package for RPC which Xerox contributed. I'm using a new installation of M3 3.5.2 on an Alpha machine running OSF/1. The installation ran fine so long as we had disk space left. The difficulty we've come across is that the m3 compiler doesn't seem to know what machine type we're running on, even though it worked while building the various libraries we've installed. Is there an option to specify the target machine, or some way to use m3build with the Xerox RPC package (currently, it uses make). Any help would be appreciated; please e-mail or post. Thanks! -Fred -- http://csgrad.cs.vt.edu/~fdrake/ ======================================================================= 4 === Date: Sat, 01 Apr 95 16:20:19 -0800 From: mhb@pa.dec.com ("Marc H. Brown") Subject: Re: Quake/m3build question -- installing resources If you don't want m3build linked into your file, don't use m3bundle and don't use Rsrc; just use FileRd and Pathname. However, Rsrc is probably what you want: you can set a resource path containing environment variables and bundles. To read from the file system rather than the linked bundle, do two things: 1) be sure that the env var is before the bundle when you call Rsrc.BuildPath. 2) set the env var to the directory containing the file Just unset the env var when you want the file to come from the bundle rather than from the file system. Bundle and m3bundle are documented in SRC #113 (Some Useful M3 Interface). Unfortuntaely, Rsrc isn't documented there, however. ======================================================================= 5 === Date: 1 Apr 1995 19:14:35 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Re: help wanted converting code from m3 v2.11 to v3.x In article , Michel Dagenais wrote: > Does anybody know how to copy a heap object in m3 v3.x? > >Well, you can Pickle in and out of a TEXT or Pipe. That copies not only the object but everything linked to it, which is not quite what I'm after. Bill's procedure for a ``shallow'' copy does the job. Norman ======================================================================= 6 === Date: 2 Apr 1995 00:52:37 GMT From: linus@step.polymtl.ca (linus) Subject: Re: need font-lock support for modula3 mode in lemacs Farshad Nayeri (nayeri@gte.com) wrote: : In article schwartz@galapagos.c se.psu.edu (Scott Schwartz) writes: : umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes: : | Does anyone have a nice "modula3-font-lock-keywords" to color modula-3 : | programs in lucid emacs? : Big colored capital letters sounds really unappealing. Better to : put them in a small font, which will simulate the easy to read : style of lower case keywords. First of all, CAP-LETERS-KEYWORDS really SUCKS !!!!!!!!!!!!!!!!!!! It's the worst thing in M3 ..... ;;;------------------------------------------------------------------- (defvar modula-3-font-lock-keywords '(("^[ \t]*PROCEDURE[ \t]+\\([A-Za-z1-9_]+\\)" 1 font-lock-function-name-face ) ("^[ \t]*\\([A-Za-z1-9_]+\\)[ \t]+=[A-Za-z0-9_\. \t]*\\(OBJECT\\|RECORD\\)" 1 font-lock-function-name-face) ("^[ \t]*\\([A-Za-z1-9_]+\\)[ \t]+\<\:" 1 font-lock-function-name-face) ("^\\(VAR\\|TYPE\\|REVEAL\\|CONST\\)" 1 font-lock-keyword-face) ("IMPORT\\|EXPORTS\\|GENERIC\\|INTERFACE\\|MODULE" . font-lock-keyword-face ) ("\\(RAISES\\|RAISE\\)\\|EXIT\\|RETURN" . font-lock-keyword-face)) "m3 font-lock-kw") ---------------------------- LD : (Simulated ergonomics. Cool!) : It depends, if they are not appealing to you, you can use a lighter : shade of gray for keywords. : I agree though: an editor that quickly changed the keywords to : lowercase (perhaps bold lowercase) upon loading would be cool. Kind of : like good old THINK Pascal. : -- Farshad : -- : Farshad Nayeri : nayeri@gte.com ======================================================================= 7 === Date: 2 Apr 1995 04:34:19 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Q: What is the inverse of m3ship? Is there an operation that reverse the effect of m3ship? That is, something that removes all teh files originally created by m3ship? I want to `start over with a clean slate' to test an installation procedure... While I'm at it, does m3ship offer any protection against name collisions (e.g., two people decide that `foo' would be a dandy name for a {package, binary, other})? If not, does it have more discriminating friends? Norman -- Norman Ramsey norman@bellcore.com ======================================================================= 8 === Date: Sun, 2 Apr 1995 01:57:06 GMT From: kendall@spark.mv.com (Sam Kendall) Subject: Re: Opinions on M3->C interface "consistency" bm@shadow.cs.columbia.edu (Blair MacIntyre) writes: > In making an interface to a C library (OpenGL, in particular), there > is a tradeoff between "consistency" with the original C > constant/variable names and consistency with the way typical .i3 files > are written, as illustrated here: > > GL.h: > > #define GL_ACCUM 0x0100 > > GL.i3: > > CONST GL_ACCUM: INTEGER = 16_0100; > > But, then to reference the constants, we write GL.GL_ACCUM, which is > long (writing GL.ACCUM would be nicer, I'd think). Yes, the problem with redundant prefixes is particularly bad when mapping C enumerators -- you can get things like `regex.reg_errcode_t.REG_ERPAREN'. Going with the consistent style but making use of FROM IMPORT in client code can be a good compromise. Ideally, I'd keep the mapping from the M3 interface to the corresponding C simple, even if cumbersome to use, but try to build a safe M3 interface on top of that "raw", unsafe M3 interface. --- Sam Kendall ======================================================================= 9 === Date: 2 Apr 1995 04:22:01 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: ANSWER: Quake/m3build question -- installing resources (Following up my own post.) In article , Norman Ramsey wrote: >I'd like to make ``resources'' (arbitrary binary files) available in a >standard place for an application that needs them. (A location >analogous to /proj/pkg/foo-rsrc/src would be just fine.) >Unfortunately, I don't see any way to do this with m3build and quake >(I have version 3.3). Note well that I do *not* want to use m3bundle >to turn the resources into a module; I expect the resources to change >more rapidly than the program that uses them, so I want to get them >out of the file system dynamically. OK, here's some quake code to do the installation. I wrote some even more frightening code to create an interface that points to the appropriate subdirectory of PKG_USE (modelled on build_generic_intf). BTW I discovered if a packages calls neither program() nor library(), it's not much use unless it calls something like this: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % this is what's needed to export things properly when we % don't build a program or a library proc Source_Package() is gen_m3exports("bogus bogus") install_derived (M3EXPORTS) install_sources() end So far the only such packages I've written are the ones exporting quake code or `resources' :-) Norman here is resource.tmpl %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % installed resources -- provide for files that should be installed % with the package, even if they aren't part of a program % % % dynamic_resource(X) installs X in pkg/NAME/src/X % derived_dynamic_resource(X) installs X in pkg/NAME/BUILD/X % % The derived stuff hasn't been tested. % implementation means using the quake `hooks' provided. DYNAMIC_RESOURCES = {} % units just like the standard ones % add hooks for installation by m3ship readonly resource_install_units_hooks = install_units_hooks proc install_units_hooks(install_impls) is local x = resource_install_units_hooks(install_impls) return [x, DYNAMIC_RESOURCES] end % add hooks for lookup by m3where readonly resource_where_units_hooks = where_units_hooks proc where_units_hooks() is local x = resource_where_units_hooks() return [x, DYNAMIC_RESOURCES] end % add hooks for writing into M3EXPORTS readonly resource_map_hooks = gen_map_hooks proc gen_map_hooks() is gen_unit_map(DYNAMIC_RESOURCES, "dynamic_resource") end proc _map_add_dynamic_resource(unit, pkg, subdir, visibility) is DYNAMIC_RESOURCES{unit} = [Location(pkg, subdir), visibility, IMPORTED] end %%%% naming the source is simplicity itself proc dynamic_resource(x) is DYNAMIC_RESOURCES{x} = _new_unit(VISIBLE) end %%%% dealing with deriveds requires none of this goo... proc derived_dynamic_resource(x) is install_derived(x) deriveds(x, no_extension) end ======================================================================= 10 === Date: 01 Apr 1995 23:24:49 GMT From: umesh@note.lcs.mit.edu (Umesh Maheshwari) Subject: enigmatic smuggling I ran into a rather unexpected semantics of IMPORT/EXPORT (it does not seem to be documented.) I wasted a lot of time to figure out what must be happening. I would appreciate your views on the problem. Here is the essence of the condition when the problem arises: 1) interface X declares an opaque type T 2) module Y reveals X.T 3) interface X and module Y are used to form a library, say, z 4) Some other module, Main, imports X (the package containg Main imports the library z). In building main, the compiler complains that X.T is not revealed. I have pasted the simplified source files and m3makefiles below: ====================================== file z/src/m3makefile import(libm3) Interface(X) Module(Y) Library(z) file z/src/X.i3 INTERFACE X; TYPE T <: ROOT; END X. file z/src/Y.i3 INTERFACE Y; END Y. file z/src/Y.m3 MODULE Y; IMPORT X; REVEAL X.T = ROOT BRANDED OBJECT i: INTEGER; END; BEGIN END Y. ====================================== file main/src/m3makefile import(libm3) override(z, "../..") import(z) implementation(Main) program(main) file main/src/Main.m3 MODULE Main; IMPORT X; BEGIN END Main. ====================================== The library "z" builds successfully. But m3builds gives an error in building main: new "Main.mo" -> linking main opaque type never revealed: X.T (_tb81ca1e6) defined in X.i3 The error can be rid of by either of the following: 1) Importing Y (besides X) in Main.m3. This is unexpected because the interface Y does not contain anything. 2) Exporting X in Y.m3 This is unexpected because, according to the reference manual by Nelson, the only effect of "EXPORTS X" would be to provide bodies of procedures declared in X. The above two points indicate that the revelation of types is exported by a module just as it would export procedures. This is not documented. 3) Main.m3 is put together with the sources of library z import(libm3) Interface(X) Module(Y) implementation(Main) program(main) It is unexpected that separating the sources into libraries with all interfaces visible should effect the linkability of the program. ======================================================================= 11 === Date: 2 Apr 95 10:00:53 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Opinions on M3->C interface "consistency" In article kendall@spark.mv.com (Sam Kendal l) writes: bm@shadow.cs.columbia.edu (Blair MacIntyre) writes: > In making an interface to a C library (OpenGL, in particular), there > is a tradeoff between "consistency" with the original C > constant/variable names and consistency with the way typical .i3 files > are written, as illustrated here: > > GL.h: > > #define GL_ACCUM 0x0100 > > GL.i3: > > CONST GL_ACCUM: INTEGER = 16_0100; > > But, then to reference the constants, we write GL.GL_ACCUM, which is > long (writing GL.ACCUM would be nicer, I'd think). Yes, the problem with redundant prefixes is particularly bad when mapping C enumerators -- you can get things like `regex.reg_errcode_t.REG_ERPAREN'. Going with the consistent style but making use of FROM IMPORT in client code can be a good compromise. Ideally, I'd keep the mapping from the M3 interface to the corresponding C simple, even if cumbersome to use, but try to build a safe M3 interface on top of that "raw", unsafe M3 interface. I tend to agree with Sam. If you are not satisfied with that answer, however, here are some other ideas: - Generate the safe M3 interface and corresponding module that Sam mentioned in your tool to take the grunt work out of doing the safe wrapper. This interface can include all of the safe portions of the original interface, and perhaps some generated utilities for dealing with safe handles to unsafe data. - As for stripping, you can change the rule to: only strip the prefix when the resulting identifier is valid in the current context. This will make for an easy rule for "blind" naming of identifiers. - More messy is changing the documentation: nroff, TeX, and PostScript and comments in C header files files should not be that hard to scan. You can actually change the documentation! I don't think it is a great way to go, but it is certainly an alternative. - Trivial points: Don't forget about casing and underscores (gl, GL, GL_) Also you may want to name the unsafe interface UGL or CGL so that there can be a safe interface built on top of it called GL. Overall, if you want to follow "the Modula-3 philosophy" of making unsafe practices harder, you may want to leave the identifiers the same as in a C program. Unfortunately this aspect of M3 philosophy does not sit well with "wanting to make integration easier". -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 12 === Date: 3 Apr 1995 12:23:09 GMT From: Quentin Stafford-Fraser Subject: Re: m3rpc package fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.) wrote: > Is there ... some way to use m3build with >the Xerox RPC package (currently, it uses make). I have a version which works, though I haven't tested it very much, or indeed used it much since 3.3. It does a little hack in quake to produce m3rpcgen, which is a C-only program. You can get the package from http://www.cl.cam.ac.uk/users/qs101/m3rpc.tar.gz. -- --------------------------------------------------------------------- Quentin Stafford-Fraser http://pelican.cl.cam.ac.uk/people/qs101/me.html --------------------------------------------------------------------- ======================================================================= 13 === Date: 3 Apr 1995 14:10:36 -0400 From: fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.) Subject: Re: m3rpc package In article <3lopbd$391@news.parc.xerox.com>, Quentin Stafford-Fraser wrote: >I have a version which works, though I haven't tested it very much, or >indeed used it much since 3.3. It does a little hack in quake to produce >m3rpcgen, which is a C-only program. > >You can get the package from >http://www.cl.cam.ac.uk/users/qs101/m3rpc.tar.gz. Quentin, Thanks for the pointer, and the effort! I'll take a look at what you have there. Since my post I brought m3rpcgen to life on the Alpha (that much was working fine on a Linux box); I think the problem was in the 32/64 bit translation. A serious lack of prototypes can be a problem when the platforms are changing so rapidly! Again, thanks, and I'll let you & others know here if/when it's all working under 3.5.2. -Fred -- http://csgrad.cs.vt.edu/~fdrake/ ======================================================================= 14 === Date: 3 Apr 95 09:51:15 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Modula-3 expected developments With the increasing activity on comp.lang.modula3, it would be interesting to discuss where the Modula-3 environment may go in the short and medium term. It helps put things in perspective and coordinate the efforts. Obviously most of the efforts come from DEC SRC, and are well coordinated there, but the outside SRC community is rapidly expanding and maturing. A Modula-3 users meeting will probably be held at the Usenix COOTS (conference on OO technologies) in Monterey (June 26-29). The m3build/quake/m3/m3cg suite of programs is being melted into an extremely fast compile server which caches pre compiled interfaces and library information. The very fast integrated code generator will need to be adapted to each platform architecture. M3gdb is quickly maturing (on other that DS3100 platforms) and is now quite usable although there are still a number of minor problems to fix. I had students this term build prototypes of an integrated development environment (file chooser, editor and links to compiler, debugger and performance analysis tools). Something will eventually come out of this. The user interface development environment is excellent. The newly released shared board graphics editor could form the basis of a structured graphics library (a la Unidraw). With a couple of additions like a table VBT, rotated texts and even an HTML viewer, this would be real nice. Stable persistent objects were recently released. Hopefully this will evolve towards an OO database toolbox; this with FormsVBT, network objects and Obliq would be the right tool for a lot of interesting applications. I am exploring ways of automating the submission of contributed Modula-3 items (packages, binaries, FAQ items) with immediate linking into the documentation Web. In parallel, work is underway to generate linear printable versions of documentation Web subgraphs on the fly. This scheme will fit well with M3browser. In summary, all the pieces are getting in place at an increasing pace, in large part because the SRC researchers have experimented with all these ideas before. -- 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 ======================================================================= 15 === Date: 3 Apr 95 08:48:18 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: what is modula 3 i often writing programs in an Modula 2 Environment (DOs) can you help me what is modula 3 ? Modula-3 resembles Modula-2 but has objects, threads, garbage collection, generics and exceptions. A good starting point is reading the Modula-3 FAQ available from ftp.vlsi.polymtl.ca:pub/m3/m3-faq.txt. -- 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 ======================================================================= 16 === Date: 3 Apr 1995 18:31:33 GMT From: ken.seefried@6856.404259.bst.bst.bellsouth.sprint.com (K.J. Seefried I II) Subject: Modula-3 on NT I'm about to start looking at the Modula-3 compiler for NT. Since DEC is big on NT, I'm curious as to how much support the NT port is going to recieve. Will it be equal to the fine support the Unix variants seem to be recieving? -- K.J. Seefried III ken.seefried@bridge.bst.bls.com Compaid Consulting Services @ BellSouth Telecommunications ======================================================================= 17 === Date: Mon, 03 Apr 95 17:28:38 -0700 From: heydon@pa.dec.com Subject: Re: enigmatic smuggling Umesh, The behaviors you observed are consistent with the language definition, which says (section 2.5): A "program" is a collection of modules and interfaces that contains every interface imported or exported by any of its modules or interfaces, and in which no procedure, module, or interface is multiply defined. Hence, a program is a collection of "units" (my generic term for an interface or a module) that is closed under IMPORTs and EXPORTS. However, the language does not say how the SRC compiler constructs this closed set from the units listed in m3makefiles. These rules do not seem to be documented anywhere, so here they are for posterity, as explained to me by Bill Kalsow: * First, the compiler only includes in the build those units that are deemed reachable from a certain set of "roots" in a directed graph defined on the units. An edge exists in this graph from unit A to unit B if either: 1) A IMPORTs B, or 2) B EXPORTS A. * Second, the set of search "roots" (or starting points of the traversal) is the set of units declared in the "main" m3makefile. Together, these two rules explain all the behaviors you witnessed. First, consider the case that failed: > Here is the essence of the condition when the problem arises: > 1) interface X declares an opaque type T > 2) module Y reveals X.T > 3) interface X and module Y are used to form a library, say, z > > 4) Some other module, Main, imports X > (the package containing Main imports the library z). > > In building main, the compiler complains that X.T is not revealed. Since "Main.m3" only imports "X", and since neither "X" imports "Y" nor "Y" exports "X", here is the graph formed by the first rule: Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3 ~~~~~~~ I I E (I've labeled the edges with "I" and "E" based on whether they are included due to an "IMPORT" or "EXPORTS" relation, and I've underlined the root.) In this graph, the only root node is "Main.m3", and only "X.i3" is reachable from it, so the compiler includes neither "Y.i3" nor "Y.m3" in the build, and hence complains that "X.T" is not revealed. Now, consider the three cases you proposed to fix the problem: > 1) Importing Y (besides X) in Main.m3. Adding this IMPORT changes the graph, and makes "Y.m3" reachable though "Y.i3": I /------------------------------\ | | | V Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3 ~~~~~~~ I I E Hence, "Y.m3" gets included in the build, and the compiler finds a concrete revelation for "X.T". > 2) Exporting X in Y.m3 This adds an "EXPORTS" edge from "X.i3" to "Y.m3": E Main.m3 ---> X.i3 <===> Y.m3 <--- Y.i3 ~~~~~~~ I I E Now, "Y.m3" has again become reachable from the root "Main.m3" through "X.i3". > 3) Main.m3 is put together with the sources of library z > > import(libm3) > Interface(X) > Module(Y) > implementation(Main) > program(main) This does not change the original graph, but it does change the set of roots: Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3 ~~~~~~~ I ~~~~ I ~~~~ E ~~~~ In this case, all of the units are roots, so they are all included in the build. Hence, the concrete revelation for "X.T" contained in "Y.m3" is seen by the compiler. I hope I've cleared things up, but let me know if you still have any questions. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 18 === Date: 4 Apr 1995 08:01:02 GMT From: heinze@i41s5.ira.uka.de (Ernst A. Heinz) Subject: Re: Modula-3 expected developments Adding to all the efforts mentioned by Michel, I like to inform the Modula-3 community that the integration of our general-purpose parallel programming model GPPM into Modula-3 has made good progress, too. Due to limited time and personnel we cannot proceed as fast as we wish, but we have already caught up with SRC-M3 release 3.5.2 and hope to release a first Modula-3* version during this year. For the interested, I include more information on GPPM and Modula-3* below. ------------------------------------------------------------------------------ GPPM is remarkably compact yet very powerful, including only high-level, machine-independent abstractions. It demands the explicit formulation of parallel computations in order to exploit parallelism and offers unified control+data parallelism by means of general FORALLs, structured pipeline parallelism by means of typed pipelines, and general task parallelism by means of FORK/JOIN/LOCK primitives. These different kinds of parallelism may freely be nested with each other and the remaining control constructs, e.g. branches, loops, or subroutines. Modula-3* does not only orthogonally embed GPPM's different kinds of parallelism with each other but also with the full Modula-3 language, including such sophisticated concepts like exception handling, garbage collection, generics, inheritance, and objects. Hence, it supports all Modula-3 abstraction mechanisms for parallel programming as well. GPPM's full integration into Modula-3 requires only three new language constructs, namely FORALL, NOSYNC, and PIPE statements. The additional syntax rules for Modula-3* with respect to the original Modula-3 grammar are listed listed below. ForallSt ::= FORALL Id ":" "[" Range "]" (DO | NOSYNC) S END. NoSyncSt ::= NOSYNC S END. PipeSt ::= PIPE [CallSt] {"|" CallSt} END | PIPE [IN | OUT] Expr | PIPE EXIT. Stmt ::= ForallSt | NoSyncSt | PipeSt. Range ::= Expr ".." Expr [BY Expr]. Please note that earlier Modula-3* publications contain other definitions of FORALL range syntax and do not support pipeline parallelism, thus not completely providing GPPM. ------------------------------------------------------------------------------ =Ernst= -- +--------------------------------------------------------+-------------------+ | Ernst A. Heinz (email: heinze@ira.uka.de) | | | Institut fuer Programmstrukturen und Datenorganisation | Make it as simple | | Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but | | Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. | | (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092) | | +--------------------------------------------------------+-------------------+ "It has recently been found out that research causes cancer in rats!" ======================================================================= 19 === Date: 04 Apr 1995 01:35:45 GMT From: bm@age.cs.columbia.edu (Blair MacIntyre) Subject: Re: Modula-3 expected developments >>>>> On 3 Apr 95 09:51:15, dagenais@notung.vlsi.polymtl.ca (Michel >>>>> Dagenais) said: Michel> With the increasing activity on comp.lang.modula3, it would be Michel> interesting to discuss where the Modula-3 environment may go Michel> in the short and medium term. It helps put things in Michel> perspective and coordinate the efforts. Obviously most of the Michel> efforts come from DEC SRC, and are well coordinated there, but Michel> the outside SRC community is rapidly expanding and maturing. Well, I'm currently working on a simple form of "replicated objects" (for lack of a better term). My basic need is to have the ability to have an object replicated across many machines, have changes propogate (as quickly as possible in some cases), have them be somewhat transparent to the user (as network objects are), and have them integrated with Obliq. There are some other nitpicky requirements, but that's the gist of it right now. If anyone else has worked, or is working on, or is just interested in talking about this, let me know. This seems like a database problem (of which I'm not an expert), but I need it for the augmented reality system I'm building. -- 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 ======================================================================= 20 === Date: 4 Apr 1995 09:45:17 -0500 From: hosking@cs.purdue.edu (Tony Hosking) Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS >>>>> "Blair" == Blair MacIntyre writes: >>>>> On 30 Mar 1995 16:11:46 -0500, hosking@cs.purdue.edu (Tony >>>>> Hosking) said: Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to Guido> gcc. Well, I installed gcc 2.6.3 hoping this will solve the Guido> problem, but it doesn't. I installed it using Sun's as and ld. Tony> Just delete the line: Tony> boot_import ("-lDYNAMIC_LINKING_AFTER_THIS") Tony> from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be Tony> away and laughing. Blair> Well, laughing might not be the right word. You cannot statically Blair> link an m3 binary on solaris without this option and without using Blair> the m3-gcc script (or something like it). Blair> If you remove it, remove all "build_standalone()" commands from Blair> your m3makefiles. -- Blair MacIntyre (bm@cs.columbia.edu), Blair> Graduate Student (Graphics and UI Lab) If you had read my message more closely, this is only in the make.boot file, not the SOLgnu configuration file. There is no real need for make.boot to link the compiler statically. The build_standalone stuff will still work just fine for the other packages in the distribution. Now I am laughing! -- Tony Hosking | Voice: (317) 494-6001 Department of Computer Sciences | Fax: (317) 494-0739 Purdue University | Email: hosking@cs.purdue.edu West Lafayette, IN 47907URL: | http://www.cs.purdue.edu/people/hosking ======================================================================= 21 === Date: 4 Apr 1995 06:20:43 GMT From: dhwang@ic.sunysb.edu (David Hwang) Subject: FileStream.i3 I've been having trouble invoking FileStream.i3 under M3PC. The compiler just tell me that it can't find such interface. FileStream.i3 is the first long filename(more than 8 letter in prefix) I use for M3PC, is it because of the long filename? I've checked names.map and everthing mapped fine. Help! -- (-_-;) SF - DH ======================================================================= 22 === Date: 4 Apr 1995 18:55:13 GMT From: davidf@cais2.cais.com (David R Fruehwald) Subject: Modula-3 on OS/2 Should one want to dabble a bit with Modula-3 is there a compiler for OS/2? ======================================================================= 23 === Date: Wed, 05 Apr 1995 9:59:34 METDST From: rudy@cs.rug.nl Subject: Language Definition (equal types) At this moment I find Modula-3 one of the best programming languages. Working with Modula-3 I still find minor points where the language (definition) could be improved. Therefore I will propose some minor changes to the language definition. I hope to initiate a fruitful discussion about the language definition. I will collect the reactions and write a final report. I have already posted (newsgroup: comp.lang.modula3) the final report on readonly variables. Due to an insufficient number of reactions, I can not (yet) write final reports on the subjects: "addresses" and "overrides" Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup comp.lang.modula3. Reactions can also be sent to me personally: rudy@cs.rug.nl Example ======= When are two types equal? See the Language report section 1.3: Modula-3 uses structural equivalence, instead of the name equivalence of Modula-2. Two types are the same if their definitions become the same when expanded; that is, when all constant expressions are replaced by their values and all type names are replaced by their definitions. Application of this rule stricktly leads to the following erroneous program: MODULE Main; VAR x:RECORD p:=0.3 END; y:RECORD p:=0.4 END; z:RECORD p:REAL END; BEGIN x:=y; (* error: types are not assignable *) END Main. (Bill Kalsow:) Under the strictest intrepretation, the default values of fields are part of the type's definition. The Modula-3 designers generally agree that this is a bug. It probably would have been better to ignore the default values. Trying to decide whether two types with floating-point expressions for their defaults are equal makes this bug painfully obvious. >From my point of view; structural equivalence and initialization are different properties. So "x" and "y" are structural equivalent, but posses different initializations. So this program should correct. Even a subtype relations does not make sense. We could consider the types of "x" and "y" to be subtypes of "z". A subtype relation suggests restricted assignability which is not the case here. The variables "x", "y" and "z" should be fully assignable amongst eachother. So the language definition must be changed in the sense that the types of "x", "y" and "z" are equal types with different initializations. As a consequence, the initialisation should not be considered as a part of the type definition. In case of objects this new definition leads to problems. The question is now more subtile. TYPE O1 = OBJECT METHODS p():=P1 END; O2 = OBJECT METHODS p():=P2 END; These objects differ in their method suite. The essential question to determine wether these two types are different is: is the pointer to the method suite a constant or a hidden (for the user) initializez readonly variable? In the first case, the pointer is a constant and the types are structural different. You have a similar situation in case of array declaration, the index range is also described by two constants which are (if expanded) part of the type definition. The constant pointer can at compile time be replaced by the actual value. This keads sometimes to slightly more efficient implementations. In the second case, if the number of declared methods and their declarations are equal (which is the case in this example) the method suites of both object types are structurally equal, so they are of the same type. If also the number of fields and their declarations are equal, both object types are equal. E.g. these types only differ in their initialization. Now we consider the method suite as a hidden initialized readonly variable, to be initialized by the default method initializations and the overrides. I have a slight preference for the second interpretation, but at this moment I can not fully oversee all consequences. I believe that this choise should be made by the compiler builders and not by the users. Notice that the second interpretation reduces the number of different types tremendously! With the present interpretation or the first proposed interpretation NEW(O1, p:=P1) produces a new anonymous type with a different typecode. With the second interpretation the type of the result is as expected O1. This means that with the second interpretation the concept of anonymous types disappears from the language definitions. Personally I believe I is not correct that NEW can construct new types! This should only be a task to be performed by type constructors. Proposal 7: structural equivalence ================================== Modula-3 uses structural equivalence, instead of the name equivalence of Modula-2. Two types are the same if their definitions become the same when expanded; that is, when all constant expressions refering to packing or the lower- and upperbound of subrange types are replaced by their values and all type names are replaced by their definitions. Constant expressions for field initialization of records and default result or parameters for procedures or are not considered. Syntax ====== No changes ======================================================================= 24 === Date: Tue, 4 Apr 1995 17:26:10 GMT From: shang@corp.mot.com (David L. Shang) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <3lcilu$4sa@hermes.dna.mci.com> 7231780@mcimail.com writes: > In <3536sa$5se@cantaloupe.srv.cs.cmu.edu>, rwh@cs.cmu.edu (Robert Harper) writes: > >For example, one cannot tell > >by the bit pattern whether the value in a variable represents a "set" > >or a "time of day" or a "favorite color of the author of the program". > >Nor can one check at run-time properties of, say, functions that can be > >enforced by a static type discipline. > > In a dynamically typed system such as Smalltalk (or, untyped), I don't have to examine the bit pattern to determine the value. The class lookup mechanism knows the value representation and invokes the class that will process the variable. (polymorphism). This increases programmer productivity factorially over statically typed compilers. > > Therefore, the argument is flawed by the response "I, the programmer, do not care." Also, dynamically typed languages also have "isKindOf" queries to determine type if they have to. > > Your argument is flawed. What is static typing, what is dynamic typing after all? Runtime type check or runtime type identification is not the watershed between dynamic typing and static typing. When type is a first-class object, one can always pass it as value and check it at runtime. As long as full type information is loaded into the runtime executable, one can always ask an object the "IsKindOf" question, no mater the language is static or dynamic. Dynamic typing: type is not a constant object (a dynamic object), i.e. the state of a type can be changed at runtime. One can add/delete/change attributes associated to a type at runtime; Static typing: type is a constant object (a static object), i.e. the state of a type can not be changed at runtime. One can change the attributes associated to a type once it is defined in the program; Dynamic typing: subtypes can be created/deleted at runtime. The class hierachical graph is dynamic. Dynamic typing: subtypes cannot be created/deleted at runtime. The class hierachical graph is static. Is there any way that one can smooth the gap between static typing and dynamic typing? One of the major goals of the Cluster-2 programming language is to address this question. Classes can be "frozen" or "melt" among the dynamic environment and the static environment freely. David Shang ======================================================================= 25 === Date: Wed, 5 Apr 1995 12:33:36 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: Modula-3 expected developments So you know why I'm here: I'm currently working on the development of a database system with leanings towards bibliographic databases, hopefully for use in our library (at RPI). The system consists of a database server, a Z39.50 server and some grungy special purpose clients. The system makes use of the following components: secondary storage manager: manages page formatted (disk) storage. Provides page caching, atomic updates, disk mirroring etc. Interpreted scripting language: An extensible language which can be executed stand alone, in the server or in the client(s). For example, Z39.50 functionality is provided by calling routines defined in this language to carry out the required searching and display functions. The server itself consists of: the secondary storage manager, an object manager: provides retrieval/storage of objects using the Ss manager, caching of objects, sharing of read only versions between processes etc. transaction manager: index objects database objects A network interface, communicating with clients using network objects. The Z39.50 server is implemented as a general purpose server, that is it can provide Z39.50 access to any system that has enough functionality. The server is provided with an object the methods of which are called to carry out the desired functions. Essentially the Z39.50 code is a subroutine to a main program which interfaces to the database system. The server has functioned with the above system and with the current online catalog system running on the mainframe. Along with all this is code to handle MARC formatted data and much else besides . The system as a whole has made it's first faltering steps. A small database has been built and records displayed using a Z39.50 client. At the moment I'm working on some extensions to allow me to build a duplicate of a known subset of our online catalog. The results can then be compared to provide some degree of confidence in what we have. ======================================================================= 26 === Date: 5 Apr 1995 16:54:10 +0200 From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Modula-3 expected developments I once had a group of two students work on a translation of the scanner- and parser generators from the Modular Pascal toolbox. The total ModPas set includes a compiler, code generator generator, etc. The project did result in running generators, but the generated code had problems, and at that time the HPPA port was far from stable. We ran out of time, and I built a parser/scanner set by hand for my own project. The ModPas people however did agree to allowing the software to spread. If anyone is interested in taking over the project, the set includes a LALR and a LL parser generator, with of course a scanner generator. Modular Pascal is an extension of Pascal that includes exceptions and modules, be it without separate interfaces. Porting from ModPas to Modula-3 is not too hard, a Pascal-to-m3 converter might speed up things a lot. (IF/WHILE syntax etc.) Any takers are invited to react by email. Bert Laverman -- ------------------------------------------------------------------ Bert Laverman, Dept. of Computing Science, Groningen University Email: laverman@cs.rug.nl Phone: +31-50-633948 Home: bert@rakis.iaf.nl Fax: +31-50-633800 ======================================================================= 27 === Date: Wed, 05 Apr 95 15:29:23 -0700 From: heydon@pa.dec.com Subject: Re: Finalization Spencer Allain writes: > Modula-3 has garbage collection, just like Eiffel, but I'm unsure > how to release something like a network connection, a file, or a > socket automatically when the object that contained that resource gets > collected. > > I'm sure there must be some mechanism, but I don't recall seeing > anything specifically about this. The "WeakRef" interface is designed exactly for this purpose. The first paragraph of the interface says: Most Modula-3 programs simply let the garbage collector deallocate storage automatically, but some programs need more control. For example, if a variable allocated in the traced heap contains a handle on a resource in the operating system or in some other address space, then when the variable is garbage-collected it may be important to deallocate the resource. The "WeakRef" interface provides this additional control. "WeakRef" is part of the libm3core library; its source files are in the package named "weakref". - Allan ======================================================================= 28 === Date: Wed, 05 Apr 1995 09:01:42 -0700 From: bruce@newton.apple.com (Bruce Thompson) Subject: Re: enigmatic smuggling In article , umesh@note.lcs.mit.edu (Umesh Maheshwari) wrote: > I ran into a rather unexpected semantics of IMPORT/EXPORT (it does not seem > to be documented.) I wasted a lot of time to figure out what must be > happening. I would appreciate your views on the problem. > > Here is the essence of the condition when the problem arises: > 1) interface X declares an opaque type T > 2) module Y reveals X.T > 3) interface X and module Y are used to form a library, say, z > > 4) Some other module, Main, imports X > (the package containg Main imports the library z). > > In building main, the compiler complains that X.T is not revealed. > I have pasted the simplified source files and m3makefiles below: > > ====================================== > > file z/src/m3makefile > > import(libm3) > Interface(X) > Module(Y) > Library(z) > > file z/src/X.i3 > > INTERFACE X; > > TYPE > T <: ROOT; > END X. > > file z/src/Y.i3 > > INTERFACE Y; > END Y. > > file z/src/Y.m3 > > MODULE Y; ^ EXPORTS X; > > IMPORT X; > > REVEAL X.T = ROOT BRANDED OBJECT > i: INTEGER; > END; > > BEGIN > END Y. > The syntax may be a bit off, but that's the idea. The problem is that in the code that you've provided, no module in the library _implements_ the interface X. The revelation on X.T is not connected with interface X because Y has not been declared to implement interface X. Simply changing Y to declare that it implements interface X will solve the problem. Cheers, Bruce. -- -------------------------------------------------------------------- Bruce Thompson | "Never put off till tomorrow what PIE Developer Information Group | you can comfortably put off till Apple Computer Inc. | next week." | -- Unknown Usual Disclaimers Apply | ======================================================================= 29 === Date: Wed, 5 Apr 1995 14:38:09 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Finalization I have been following an interesting discussion in another newsgroup (comp.lang.eiffel) concerning whether eiffel is able to release an objects resources. I have included a piece of it below: >>One thing I haven't found is a way of finalizing objects: ie cleaning them >>up when they are no longer needed (what C++ would call destructors). > >>I know Eiffel garbage collects objects, thereby freeing memory, but what >>happens if the object should release other resources, like a network >>connection, a display context, or whatever? > >You can redefine feature 'delete' which normally does nothing. Have >a look at the descendants of IO_MEDIUM (ISE base libraries), they redefine >delete to close files, sockets, etc when the objects are garbage collected. > >Delete is called by the garbage collector when an object is collected. Modula-3 has garbage collection, just like Eiffel, but I'm unsure how to release something like a network connection, a file, or a socket automatically when the object that contained that resource gets collected. I'm sure there must be some mechanism, but I don't recall seeing anything specifically about this. Thanks in advance for any insight. -Spencer Allain Engineering Research Associates Vienna, VA 22182 ======================================================================= 30 === Date: 6 Apr 1995 06:38:59 GMT From: ssthind@flash.LakeheadU.Ca (Sonny Thind) Subject: What is modula 3 used for? I used modula 2 about 5-6 years ago but then kind of left it behind and have been using C now. I am wondering what kind of applications and uses modula 3 is being used for, maybe I should go back to it. Any information will be greatly appreciated. ______________________________________________________________________________ Sonny Thind SSThind@flash.LakeheadU.ca ======================================================================= 31 === Date: Thu, 6 Apr 1995 09:47:55 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: re: Modula-3 expected developments Our group here at Sun Labs East is using Modula-3 to support it's research in distributed systems in a variety of ways. We have developed a distributed transaction manager and an object activation service for Network Objects. I expect these will be made publically available in the not too distant future. We have also implemented a distributed event registration and notification service on top of Network Objects. I am in the process of building a lightweight UDP-based transport for network objects with the eventual goal of running directly on top of a raw ATM network driver. If there is interest, we may make the event service and our UDP-based network object's transport available in the future. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 32 === Date: 6 Apr 1995 16:42:44 GMT From: ml@lptl.jussieu.fr (Mathieu LAFARGE p 72551) Subject: Modula3 and Oberon2. Keywords: Well. I had never heard about Modula-3 before. How can it be compared to Oberon-2? Both are sons of Modula-2,aren't they? ======================================================================= 33 === Date: 6 Apr 1995 20:46:54 GMT From: jim.anderson@cyberstore.ca (Jim Anderson) Subject: comdex on cd-rom CD-ROM of ALL COMDEX (This is the worlds largest computer trade show-ie all the newest and coolest in software and computer hardware)(Las Vegas, Nov.1994) bro chures for $49.95 US (Money Order) Scanned in at 200 DPI, line art with corresponding database.(Windows,DOS) Mail money order and where you want your CD-ROM mailed to: First National Data Bank Box 24008, Kelowna, V1Y 9P9, BC, Canada Please allow 2 weeks for delivery. ======================================================================= 34 === Date: Thu, 6 Apr 1995 19:06:56 GMT From: spencer@ERA.COM (Spencer Allain) Subject: translation listing exist? I was wondering if someplace there exists a repository of Examples that show how to implement a concept particular to another language in Modula-3. I just thought of asking this question because of another question I just recently asked concerning finalization. I was envisioning some type of document that would cite common questions for someone who wants to start using Modula-3, and has knowledge of some other O-O capable language. I can see questions like: Where are the constructors and destructors????? What do I use for a string???? I cross-include header files in C++ source files, so I can have two objects point at each other - can, and how do I do that with Modula-3? In C++ I grab command line arguments from main(argc, argv**), what's the best way to do this in Modula-3? I know what a template looks like, now what would a corresponding GENERIC module look like? Good persistent storage in C++ is practically non-existant, is there some easy way to do this in Modula-3. (Is there some way to do this so that the file is human readable and platform independent?) How are cycles of objects pointing to each other deleted from memory? (This is a problem regardless of whether you have garbage collection or do the collection manually) (Yes, I'm very familiar with C++ :) (Not by choice though) Documents like these would make it easier for people to transition to Modula-3, because it would give them a way to translate their thought patterns. Many people are hesitant to change languages because they already know how to do something "neat" with their current language and are afraid that it won't be possible in another one, or that it would take too long to figure out how to emulate their "cool" functionality. I feel like I'm asking a lot of questions, but not contributing many answers to this newsgroup :) Hopefully, I'll have time to keep learning more about Modula-3, and then I'll be one of the friendly people who _answers_ questions. Thanks for everyone's time and patience. -Spencer Allain Engineering Research Associates Vienna, VA 22182 ======================================================================= 35 === Date: Fri, 7 Apr 95 09:17:23 GMT From: ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) Subject: re: Modula-3 expected developments In article <9504061347.AA08641@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.COM ( Geoffrey Wyant - Sun Microsystems Labs BOS) writes: |> Our group here at Sun Labs East is using Modula-3 to |> support it's research in distributed systems in a |> variety of ways. We have developed a distributed transaction |> manager and an object activation service for Network Objects. |> I expect these will be made publically available in the |> not too distant future. We have also implemented a distributed |> event registration and notification service on top of Network |> Objects. I am in the process of building a lightweight UDP-based |> transport for network objects with the eventual goal of running |> directly on top of a raw ATM network driver. If there is interest, |> we may make the event service and our UDP-based network object's |> transport available in the future. |> |> --geoff |> |> Geoff Wyant |> Geoff.Wyant@east.sun.com |> Sun Microsystems Laboratories |> |> 2 Elizabeth Drive |> Chelmsford, Ma. |> 01824 Yes, a *lightweight* UDP on top of an ATM network would be great. The group I am working in is using message passing on an ATM swith as part of a parallell, highly fault tolerant soft real time RDBMS, and the depressing fact is that most of the time used in message passing is consumed by Unix, not by the A TM switch. The net effect is that using an ATM network is just slightly faster than using ethernet in terms of message round trip times. The throughput is much better, of course. It seems that Unix refuse s to let the our process regain control instantly when a message arrives, but instead waits for some time (several hundred microseconds), possibly in the hop e of catching more incoming messages. (We use C++, but the problem would be the same in any language) If you have any suggestions to how we can avoid what seems to be unnecessary delay in the message passing, we would be very interested. Btw, this phenomenon occurs both on SUN (SunOs 4.1.3) and HP platforms. Ole-Hj. Kristensen ======================================================================= 36 === Date: 07 Apr 1995 17:51:03 GMT From: nayeri@gte.com (Farshad Nayeri) Subject: Re: translation listing exist? Spencer Allain said: > I was wondering if someplace there exists a repository of Examples > that show how to implement a concept particular to another language > in Modula-3. I just thought of asking this question because of > another question I just recently asked concerning finalization. > > [...] > > Documents like these would make it easier for people to transition > to Modula-3, because it would give them a way to translate their > thought patterns. Many people are hesitant to change languages > because they already know how to do something "neat" with their > current language and are afraid that it won't be possible in another > one, or that it would take too long to figure out how to emulate > their "cool" functionality. Spencer, A long time ago, I saw a promotional article on the net by Sam Harbison which had answers to some of your questions. (I specifically recall that the it addressed constructors and destructors to an extent.) Looking at my old mail, I found a reference to the document I was talking about, but I am affraid I don't have a copy of it. The Pine Creek catalog also included other information that is probably useful to programmers today. > pub/doc/m3forcpp.ps.Z 1-page (legal-size) brochure on M3 for C++ users > pub/doc/m3forcpp.txt (text version) Perhaps Sam is willing to distribute some of the old Pine Creek articles. (They may be outdated given the many improvements in the SRC system since 1991.) I will be happy to help out in updating them or making them available on the net. (By the way, I think it's great that you are asking all these questions. Unfornately, this week I don't have time to try to post something coherent to answer some of your questions. Keep the questions coming though!) -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 37 === Date: 7 Apr 1995 15:40:34 GMT From: sims@linux.acsys.com (dave sims) Subject: Static linking on Solaris SOLsun? I managed to compile and run my M3 application under Solaris using the SOLsun distribution. Woohoo! Everything worked except when I tried to fork a second threads. Then I got an assertion in ThreadPosix.m3, line 1473. But that's not my main problem. How can I statically link my application under SOLsun? I'm trying to take my application to a different Solaris box that doesn't have all the M3 dynamic libraries on it. Any suggestions for static linking on SOLsun? thanks, dave sims -- Dave Sims I'm an anarchist, and I vote. sims@usa.acsys.com Don't tread on me. http://www.acsys.com/~sims/ Finger or WWW for PGP key. KC5JKN ======================================================================= 38 === Date: Fri, 7 Apr 1995 17:32:51 GMT From: dduggan@nuada.uwaterloo.ca (Dominic Duggan) Subject: tips on installing 3.5.2 on solaris with gcc [Posted to fill gaps I found in the notes with the distribution, and with the hope it may help some who want to get m3 up fast without farting around figuring this out for themselves] 1. Replace these lines in boot-SOLgnu/m3build/templates/SOLgnu CC = _ifdef ("CC", CC, [ "gcc", "-compat-bsd", "-fpic" ]) BOOT_CC = [ "gcc", "-compat-bsd" ] with CC = [ "m3-gcc", "-compat-bsd", "-fpic" ] BOOT_CC = [ "m3-gcc", "-compat-bsd" ] respectively. You may want to temporarily copy boot-SOLgnu/m3-gcc to a directory in your search path (just while booting compiler). 2. Edit quake/src/makefile, replace "CC = cc" with "CC = gcc" 3. Having installed the compiler, but before installing the libraries, type setenv LD_LIBRARY_PATH /usr/local/lib/m3/SOLgnu or wherever you are putting the libraries. (This is a bit of a surprise to me, your mileage may vary...) -- Spoken: Dominic Duggan Internet: dduggan@uwaterloo.ca Canada: Dept of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 WWW: http://nuada.uwaterloo.ca/dduggan.html ======================================================================= 39 === Date: 8 Apr 1995 00:11:38 GMT From: mojemj@unidhp.uni-c.dk (Mogens Jensen) Subject: Re: Should I learn Modula-3? How? Fraser Campbell (fraser@wingham.com) wrote: : I want to learn how to program. I have dabbled in C and understand the : basics but have never done anything very significant. What I am wondering : is whether Modula-3 is worth learning ... that article in Linux Journal made : it sound very good! : Any advice on how to learn modula-3 would be appreciated - books, text : files, newsgroups, etc. Also, I need some help with basic (language : independant) program development. I have a couple of apps in mind and just : need some advice to get me of the ground ... then I plan to learn as I go : along (probably not the best way ;). I realize that eventually C is a : language I must become comfortable with especially using UNIX ... but : Modula-3 sounds intriguing! : So if you know of any good books (or whatever) outlining basic programming : concepts and perhaps on Modula-3 please share your knowledge. Thanks ... Sorry, this follow-up may not be appropriate in this newsgroup - but how can others see if (and how) articles are responded to if you post private e-mail ? Now to your question: Maybe you _should_ learn Modula-3, but have you checked other languages ? I am currently looking for a language that better suits my needs; I currently use C++ (which really is great for some purposes, but is troubled by it's C heritage). If you are just starting to program you may want to get into the object-oriented paradigm at once (_The_Standard_ seems to be SmallTalk, I think I prefer Sather), or use some mixture (I would say Ada95, or Delphi? (Win only)) - with mixture I mean languages in wich you are tempted to write "good-old" algorithm-oriented programs. It *REALLY* depends on your needs: - How easy must your programs be to maintain (to others) ? (Ada may win) - How easy must your programs be to extend ? (Some Object-Oriented Language) - How important is it that your program works (!) ? (Ada folks say Ada wins) - How fast should it be to program ? (SmallTalk wins if you are experienced) - How fast should your programs run ? (*NOT* SmallTalk to my knowledge) - What platform(s) do you want, and at what price ? (GNU = Good News2 U) - Are you going to use multitasking (concurrency) ? (Ada wins here IMO) - Do you want a GUI-development environment ? (Varies with platform) - Etc. Of course there is a whole bunch of programming languages out there which I don't know (either) - in particular Modula-3 (which I can't use under DOS/WIN/OS/2 I think). This is where I currently is: (you probably can't use this at all) I really like Ada95; - it is now an ISO-standard, which means that the language you learn doesn't change every year - C++ will soon be an ISO-standard, Sather are more experimental. SmallTalk is SmallTalk. - check-out: packages (with childs), tasks, protected units, The Rationale (this language seems big, but one doesn't have to use all the facilities), etc. Sather has some very interesting facilities: - The single greatest thing since sliced bread is Sather Iters ! IMO - check-out: iters, inheritance (code seperate from interface), etc. As of Fraser Campbell (fraser@wingham.com) wrote: : Also, I need some help with basic (language independant) program : development. I have a couple of apps in mind and just need some advice : to get me of the ground ... then I plan to learn as I go along just mail me (my father, that is, see sig.) if I can help; I don't know Linux though, if that's your platform... Greetings from Jens Jakob Jensen, Denmark - (Using my fathers account) ======================================================================= 40 === Date: 7 Apr 95 14:58:23 From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: translation listing exist? In article spencer@ERA.COM (Spencer Allai n) writes: I was wondering if someplace there exists a repository of Examples that show how to implement a concept particular to another language in Modula-3. I ju st thought of asking this question because of another question I just recently asked concerning finalization. I was envisioning some type of document that would cite common questions for someone who wants to start using Modula-3, and has knowledge of some other O -O capable language. I can see questions like: Where are the constructors and destructors????? What do I use for a string???? Such answers could be in the FAQ. I am currently in the process of restructuring the FAQ to make it easier to submit items to include in the FAQ or to store on my FTP/WWW server. Different categories of items will be included in the FAQ, mentioned in the FAQ or simply stored on the server. The submission process will be handled automatically with a human simply "checking" entries. As for the specific questions you asked, some are answered in course notes that i have been writing lately, which are available at http://www.vlsi.polymtl.ca/dagenais/if515/main/main.html. The table of content is as follows: {chapter}{ {1}Introduction}{11} {chapter}{ {2}Object Oriented Programming}{13} {section}{ {2.1}The Evolution of Programming Languages}{13} {subsection}{ {2.1.1}Ada 9X}{14} {subsection}{ {2.1.2}CLOS}{15} {subsection}{ {2.1.3}Eiffel}{15} {subsection}{ {2.1.4}ML}{15} {subsection}{ {2.1.5}Modula-3}{16} {subsection}{ {2.1.6}Object Pascal}{16} {subsection}{ {2.1.7}Oberon}{16} {subsection}{ {2.1.8}Smalltalk}{16} {section}{ {2.2}Object Oriented Concepts}{16} {subsection}{ {2.2.1}Inheritance}{17} {subsection}{ {2.2.2}Class variables}{18} {subsection}{ {2.2.3}Encapsulation}{19} {subsection}{ {2.2.4}Procedure name overloading}{19} {subsection}{ {2.2.5}Operator overloading}{20} {subsection}{ {2.2.6}Methods}{21} {subsection}{ {2.2.7}Before and after methods}{26} {subsection}{ {2.2.8}Method selection based on all arguments}{28} {subsection}{ {2.2.9}Non virtual methods}{30} {subsection}{ {2.2.10}Constructors and destructors}{31} {subsection}{ {2.2.11}Metaclasses}{33} {subsection}{ {2.2.12}Exception Handling}{33} {subsection}{ {2.2.13}Generic Modules}{34} {subsection}{ {2.2.14}Substitutes for multiple inheritance}{36} {subsection}{ {2.2.15}Discussion}{38} {section}{ {2.3}Object Oriented Design}{39} {subsection}{ {2.3.1}The Object Model}{39} {subsection}{ {2.3.2}The Dynamic Model}{40} {subsection}{ {2.3.3}The Functional Model}{40} {subsection}{ {2.3.4}Analysis}{40} {subsection}{ {2.3.5}System Design}{41} {subsection}{ {2.3.6}Object Design}{41} {chapter}{ {3}Sample Object Oriented Languages}{43} {section}{ {3.1}A Simple Object Oriented Language: Obliq}{43} {subsection}{ {3.1.1}Single and Multiple Inheritance}{44} {subsection}{ {3.1.2}Class and Instance Variables and Methods}{45} {section}{ {3.2}C++}{46} {subsection}{ {3.2.1}Classes}{46} {subsection}{ {3.2.2}References}{48} {subsection}{ {3.2.3}Automatic Type Conversion}{49} {subsection}{ {3.2.4}Constructors and Destructors}{49} {subsection}{ {3.2.5}Function Name Overload}{51} {subsection}{ {3.2.6}Operator Overload}{52} {subsection}{ {3.2.7}Templates}{53} {subsection}{ {3.2.8}Exceptions}{53} {subsection}{ {3.2.9}Linkage with C}{54} {subsection}{ {3.2.10}Conclusion}{55} {section}{ {3.3}Modula-3}{55} {chapter}{ {4}Modular Programming}{57} {section}{ {4.1}Interfaces}{57} {section}{ {4.2}Litterate Programming}{62} {section}{ {4.3}Dependency Analysis}{62} {section}{ {4.4}Modules in Modula-3}{64} {chapter}{ {5}Run time Libraries and Tools}{77} {section}{ {5.1}Safe Language Features}{77} {section}{ {5.2}Debugging}{78} {section}{ {5.3}Coverage Analysis}{79} {section}{ {5.4}Performance Analysis}{80} {section}{ {5.5}Dynamic Memory Allocation}{81} {subsection}{ {5.5.1}Memory allocation errors}{81} {subsection}{ {5.5.2}Memory allocation algorithms}{82} {subsection}{ {5.5.3}Garbage collection}{83} {subsection}{ {5.5.4}Run time type identification}{84} {section}{ {5.6}Multi-threading}{84} {section}{ {5.7}Embedded Languages}{85} {section}{ {5.8}Run Time Analysis of Modula-3 Programs}{86} {subsection}{ {5.8.1}Run time checks}{86} {subsection}{ {5.8.2}Coverage Analysis}{86} {subsection}{ {5.8.3}Profiling}{89} {subsection}{ {5.8.4}Debugging}{92} {subsection}{ {5.8.5}Graphical tools}{97} {subsection}{ {5.8.6}Embedded language}{97} {chapter}{ {6}Object Oriented Libraries}{105} {section}{ {6.1}Standard Libraries}{106} {section}{ {6.2}The Modula-3 Standard Library}{106} {section}{ {6.3}User Interface Libraries}{107} {subsection}{ {6.3.1}Device independence}{107} {subsection}{ {6.3.2}Low level graphics}{108} {subsection}{ {6.3.3}Building blocks for toolkits}{108} {subsection}{ {6.3.4}Toolkits}{109} {subsection}{ {6.3.5}Graphical interface builders}{109} {subsection}{ {6.3.6}User interface and Object Orientation}{109} {section}{ {6.4}Trestle}{110} {section}{ {6.5}VBTKit}{111} {section}{ {6.6}FormsVBT}{112} {section}{ {6.7}A Complete Graphical Application Example}{112} {subsection}{ {6.7.1}Graphical items}{113} {subsection}{ {6.7.2}View: displaying items}{117} {subsection}{ {6.7.3}Win: user interaction}{126} {subsection}{ {6.7.4}The user interface}{141} {subsection}{ {6.7.5}The diagram editor}{148} {chapter}{ {7}Distributed and Persistent Objects}{163} {section}{ {7.1}Network Objects}{163} {subsection}{ {7.1.1}Remote procedure calls}{163} {subsection}{ {7.1.2}Network objects}{165} {section}{ {7.2}Persistent Objects}{166} {subsection}{ {7.2.1}Translation between memory and disk representations}{167} {subsection}{ {7.2.2}Lazy loading and unloading}{167} {subsection}{ {7.2.3}Persistence through reachability}{169} {subsection}{ {7.2.4}Updating the persistent storage}{169} {section}{ {7.3}Object Oriented Databases}{170} {subsection}{ {7.3.1}Fized size limitations}{170} {subsection}{ {7.3.2}Unique object identifiers}{171} {subsection}{ {7.3.3}The programming language versus database gap}{171} {subsection}{ {7.3.4}Storing procedures in the database}{171} {section}{ {7.4}Distributed Persistent Objects in Modula-3}{172} {subsection}{ {7.4.1}Network objects}{172} {subsection}{ {7.4.2}Persistent objects}{190} {subsection}{ {7.4.3}Stable persistent objects}{191} {subsection}{ {7.4.4}Indexing}{193} {subsection}{ {7.4.5}Query Processing}{196} {subsection}{ {7.4.6}Transactions}{197} {subsection}{ {7.4.7}Optimized loading and unloading}{197} {chapter}{ {8}Conclusion}{199} {chapter}{ {A}Digital License Agreement}{201} -- 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 ======================================================================= 41 === Date: 7 Apr 95 14:42:14 From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula-3 expected developments In article <9504061347.AA08641@cloyd.East.Sun.COM> gwyant@cloyd.East.Sun.COM (G eoffrey Wyant - Sun Microsystems Labs BOS) writes: variety of ways. We have developed a distributed transaction manager and an object activation service for Network Objects. I expect these will be made publically available in the not too distant future. Great! I am starting to have a few network objects applications and having an activation service (a la inetd.conf) will be very helpful! Distributed transactions are neat but the underlying storage services are still slim (Stable and SmallDB). -- 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 ======================================================================= 42 === Date: 9 Apr 95 09:35:52 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Should I learn Modula-3? How? In this long reply I will first try to answer Fraser Campbell's questions about Modula-3. Then I will try to address some of Jens Jacob Jensen's comments. In article <3m4kbq$mkk@news.uni-c.dk> mojemj@unidhp.uni-c.dk (Mogens Jensen) wr ites: Fraser Campbell (fraser@wingham.com) wrote: I want to learn how to : program. I have dabbled in C and understand the basics but have : never done anything very significant. What I am wondering is : whether Modula-3 is worth learning ... that article in Linux : Journal made it sound very good! : Any advice on how to learn modula-3 would be appreciated - books, : text files, newsgroups, etc. Also, I need some help with basic : (language independant) program development. I have a couple of : apps in mind and just need some advice to get me of the ground : ... then I plan to learn as I go along (probably not the best : way ;). I realize that eventually C is a language I must become : comfortable with especially using UNIX ... but Modula-3 sounds : intriguing! : So if you know of any good books (or whatever) outlining basic : programming concepts and perhaps on Modula-3 please share your : knowledge. Thanks ... I won't comment about introductory programming texts and ideas as my post is very long already. Modula-3 is a good language for learning programming where you can be introduced to simple to advanced features one feature at a time. And the language is complete enough that you can do a variety of tasks when you get to them. Modula-3 will ensure the "safety" of your programs under many situations that C and many other languages don't. This will be allow you to learn programming without too much worry about safety initially. As you learn more, you can program in "unsafe" modules which is closer to the model of programming in C/C++. You may want to consider Sam Harbison's book "Modula-3", as it uses something like the approach of uncovering features one thing at a time. It covers all of the language, and it is a cross between a tutorial and a reference to the language. I believe it is meant for people who have some or little exposure to programming. Unfortunately, Harbison's "Modula-3" is a bit outdated in its description of libraries as they have changed since the print date. I also recommend browsing around the Modula-3 home page and the Modula-3 FAQ via World Wide Web for basic information on Modula-3. I am not sure why you are learning to program -- do you want to write your own programs? Do you have a mandate as to what tools to use by your employer? Are you going to try to get a job doing programming? Depending on the answer to these questions, you may or may not have to "be comfrotable with C". It is quite feasible under Linux to write programs in Modula-3 without learning C. Would this look as good on your resume as C++ experience? Probably not. But it'd certainly get the programming job done (probably a lot faster and cleaner too.) Sadly, Modula-3 is missing an easy-to-use programming environment for the novice. Perhaps Oberon-2, Eiffel, and Smalltalk are better in this respect, but the current implementations of Modula-3 are closer to the process you go through to build C programs (if that is your ultimate goal). Modula-3 also allows you to do "systems programming" sorts of tasks: you can twiddle bits and talk about machine-level pointer strucutres which will come handy if you ever move to the C world (though the M3 assumptions are totally opposite of C assumption). Also, I think learning by programming is a good idea as long as you take the time to think about the process and not always "just getting the application done". Sometime I find that people who learn by hands-on programming just try to get the code finished, without too much regard about the process. One problem of learning by programming is that you get hit by syntax too soon, and that may or may not work. Anyway, it is hard to make generalizations on this subject, so I will stop here. Finally, I think the choice of your platform does make a difference in your choice of a system. On Mac, if Macintosh Pascal is still around, it's a quite nice environment for a beginner. Under Windows, as Jens Jacob Jensen mentions Delphi may not be bad for a beginner. Turbo Pascal is pretty good under DOS. Under Linux -- well probably Modula-3 is a good choice under Linux, especially if you want to get it "for free". * * * Regarding Jens Jacob Jensen's remarks. I will divide them up into several categories. ==== "I am not so sure if I agree, but why should a beginning programmer care" category ==== - How easy must your programs be to maintain (to others) ? (Ada may win) Why is this a concern for a beginner programmer? I certainly hope that the first couple of apps that a beginner programmer writes are not necessarily going to be maintained by others. - How easy must your programs be to extend ? (Some Object-Oriented Language) Again, I am not sure why this should be a concern for a beginner programmer. Extensibility is overrated anyway given today's programming language technology using any programming language. ==== "Huh?" category ==== - How important is it that your program works (!) ? (Ada folks say Ada wins) What do you mean "your program works"? ==== "Can apply to many other systems including Modula-3" category ==== - What platform(s) do you want, and at what price ? (GNU = Good News2 U) Modula-3 is also available on a variety of platforms for free. Perhaps the only popular platforms where M3 is not accessible is the MacOS. (Under OS/2 and Windows you can run m3pc I believe in DOS emulation mode.) - Are you going to use multitasking (concurrency) ? (Ada wins here IMO) I would say that Modula-3 has a simpler concurrency model than Ada. All important Modula-3 libraries are thread-safe, and some even take advantage of threads (thread-friendly). - Do you want a GUI-development environment ? (Varies with platform) You can get one of these for free under the Modula-3 archive, called FormsVBT. It is probably not as complete as commercial systems, but you don't have to pay and it's good enough for many tasks. You may also want to experiment with Visual Obliq which is a part of Modula-3 distribution. Perhaps that will allow you to build applications fast and play with their user interfaces, etc, like you would in Smalltalk environment. * * * Mr. Jensen goes on to say: Of course there is a whole bunch of programming languages out there which I don't know (either) - in particular Modula-3 (which I can't use under DOS/WIN/OS/2 I think). There are two ports of Modula-3 which are available under DOS, which I think you can run under emulation from OS/2, and Windows. Modula-3 will also run under Windows'95 whenever it becomes available; it currently runs fine on Windows/NT. I really like Ada95; - it is now an ISO-standard, which means that the language you learn doesn't change every year - C++ will soon be an ISO-standard, Sather are more experimental. SmallTalk is SmallTalk. - check-out: packages (with childs), tasks, protected units, The Rationale (this language seems big, but one doesn't have to use all the facilities), etc. If you are worried about standards as a programmer who just started, I recommend you go with IEEE-standard programming language Scheme! It is a nice language to learn progrmming in and there are many good books and implementations available. Note that complying with standards usually involves adding of a lot of crud to a language (due to varying interests of the standard participants) which will probably make it harder to learn the language for a beginner programmer. Modula-3 hasn't changed much since 1989, by the way. -- Farshad (speaking for myself) -- Farshad Nayeri nayeri@gte.com ======================================================================= 43 === Date: 10 Apr 1995 15:02:07 GMT From: sims@linux.acsys.com (dave sims) Subject: Re: Static linking on Solaris SOLsun? I wrote> I managed to compile and run my M3 application under Solaris I wrote> using the SOLsun distribution. Woohoo! Everything worked I wrote> except when I tried to fork a second threads. Then I got an I wrote> assertion in ThreadPosix.m3, line 1473. Just as a side note, I upgraded from Solaris 2.3 to Solaris 2.4, and the thread problem mentioned above went away. -- Dave Sims I'm an anarchist, and I vote. sims@usa.acsys.com Don't tread on me. http://www.acsys.com/~sims/ Finger or WWW for PGP key. KC5JKN ======================================================================= 44 === Date: Mon, 10 Apr 1995 21:53:19 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Re: Why you should use C++ This was just posted in comp.lang.ada, and now I believe that it should find it's way over to Modula-3 :) Hmm, I seem to recall someone asking about why they might want to start programming in Modula-3. Wouldn't it be great to just hand them a "Why Modula-3" paper, in addition to the FAQ? In article <3m8ttn$d52@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (Davi d Weller) writes: I'm reposting this from the comp.lang.c++ newsgroup. I kinda like Robert Martin, he's a pretty level-headed person. The reason I"m reposting it is that the arguments below represent the kind of things we need to consider as we make a business case to the commercial world. Ponder his words (but don't flame him). It'd be nice to see a "Why Ada" paper from a similar perspective. Why C++ Robert C. Martin Object Mentor Associates rmartin@oma.com 708.918.1004 4 Apr 1995 Abstract C++ is a language that seems to stimulate a tremendous amount of debate and religious furor. This paper attempts to cut through this "nonsense" and make a case for why C++ is a reasonable language for developing object oriented applications. Introduction. Why is there so much controversy about C++? Probably because it has enjoyed so much success. It is easy to believe that if C++ had remained a backwater language, the voices of its detractors would not be so loud. However, C++ *has* succeeded in a huge segment of the industry, and the proponents of other languages are quite vocal in bemoaning this fact. But what are they really complaining about? Ian Joyner, one of the most vocal and prolific C++ detractors, has published and widely distributed his notorious "C++?? A Critique of C++, Second Edition" (write to ian@ssyacus.acus.os.au for a copy). This is a generally well written (although in my opinion misguided) paper, and I recommend it to anyone considering C++ as a language. In this paper Ian says: "...the C base is C++'s greatest weakness." And this is a common thread through many of the arguments against C++. They say that C++ is a bad language because C was a bad language. I don't think that C needs a defense. The last several decades have proven it to be an extremely flexible and productive language, suitable for building applications of nearly every kind. However, in the early days of C, there were many detractors who decried the ugliness of the language and promoted "pure" languages like Pascal. The current debate regarding C++ and other languages such as Eiffel, Obj-C and Smalltalk seems similar. Why did C succeed? Because it cut through all the crap. Instead of fighting for "purity", the authors of C created a language that could be *used*. They never contended that it was perfect or pure, certainly it is not. They wanted a simple, moderately low level language that they and other people could use. In that goal, they succeeded. Why has C++ succeeded? For the same reason. It cuts through all the nonsense. Instead of trying for some lofty goal of "purity", Stroustrup has created a language that can be *used*. None of the users or authors of C++ claim that the language is perfect, or pure. However the claims of its usability have been confirmed over and over again. The language *is being used* more than any other language in its class. And that usage is increasing at a geometric rate. This paper is not an attempt to answer the complaints made by C++ detractors. Rather it presents arguments for why C++ is a reasonable choice for the implementation of object oriented designs in a wide variety of application environments. Who am I that I should write such a paper? I am a user of C++, and the manager of a team of users. I have been using C++ since 1989, and have been involved with object oriented technology since 1986. I have produced, several large and successful systems in C++, and continue to enjoy such success. I am an international consultant who works with engineering teams, training them in object oriented design and C++, and helping them with their software designs. I am also the author of: "Designing Object Oriented C++ Applications using the Booch Method" by Robert Martin, Prentice Hall, 1995, ISBN 0-13-203837-4 What the Deuce is Purity? Almost everyone can agree that C++ is not a "pure" OO language. However, this definition is problematic in that it implies that "purity" is a valid concept. Yet, there is no accepted definition of the term "pure OO language". Despite years of discussion and argument on the net, and in other circles, I have never seen anyone present a definition of a "pure OOPL" that met with general agreement by others. The fact that C++ is "impure" is often taken to mean that users are free to leave the golden path to OO and "backslide" into the unrepentant state of (gasp) procedural design. However, *every* OOPL must allow such "backsliding", because object oriented design is a *superset* of procedural design. It is *always* possible for a procedural design to be implemented in an object oriented language. This assertion is easy to prove. A procedural design is a set of data structures and procedures. In an OOPL, one can create a single object which contains all the data structures and procedures of the procedural design. Thus, the procedural design is implemented within the confines of a single object. Don't laugh! I have talked to engineers who have done just this. So what good is purity? I can't tell you, because I can't define it. I can tell you this, however. Purity, if it exists, does not force users to write good programs. And impurity, if it exists, does not force programmers to write bad programs. The main (possibley sole) ingredient required for good programs is good programmers. The Benefits of C++ as a "Better C". Ignoring Object Oriented programming for the moment, probably the biggest benefit that C++ provides is type safety. C++ is a type safe language. What does this mean? Simply speaking it means this: void f(long l) {...} // function declared in one file. f(1); // in C, this can cause stack corruption since an integer // is passed instead of a long. However in C++, the // compiler knows that 'f' wants a "long" and so promotes // the '1' to the correct type. ANSI C makes type safety optional. C++ makes it mandatory. In C++ it is very difficult (not impossible) to violate the type system. Why is this important? Because type errors in C are often the causes of strange bugs that take weeks or months to find, and that exhibit transient and misleading behavior. They often foul the stack or heap and cause eventual failure several million instructions after the precipitating event. Such bugs are the hallmark of poor quality software. C++, in a single stroke, eliminates a huge percentage of them. This advantage alone makes C++ a better alternative than C. C programmers don't have to learn any of the other features of the language to take advantage of type safety. C++ is a Low Level Language with High Level Features. When all is said and done, C++ is a language for the manipulation of bits and bytes. Although "purists" might rant and bemoan this attribute of C++, *engineers* sigh with relief. All computer applications are, eventually, the manipulation of bits and bytes. We might not wish this were so, but it is. And C++ provides the features that allow low level manipulations to be effient and easy. If, in the end, I need to store the bit pattern '10110100' in the byte whose address is FCA9DE, C++ will allow me to do so, without complaint. But C++ also provides many high level features, so that the user can "pretend" that C++ is a high level language. This makes C++ useful in those places where a high level language is needed. As a user, and the representative of other users, I can attest to the fact that C++ succeeds in this dual role. I can implement high level abstractions in C++ using the high level structures of the language, and I can implement low level details using the low level structures of the language. It all works, and works quite well. Object Oriented Programming. Without a doubt, this feature of C++ is the most important. The reason is that well structured object oriented designs create applications that are robust, maintainable and comprised of elements that can be reused in other applications. It must be stressed that the use of C++ does not guarantee that applications will have these desirable attributes. In fact, C++ does not even "nudge" the user in the right direction. And neither does any other language! Bad designs are BAD DESIGNS, period. No language will correct them. No language, regardless of its "purity" will improve a bad design. An Object Oriented design is a difficult thing to create. Using an OO programming language does not guarantee that the design will be object oriented. In fact, the design should be expressible indepedently of the language. It is for this reason that Object Oriented design notations (e.g. Booch, or OMT) have been developed. There is a large contingent of developers who believe that object oriented design is simply the partitioning of the application into representative objects. Such designs can be represented in the design notations, and can be implemented in OO programming languages. However, most often these designs do not follow the principles of object oriented design. Object oriented designs should have certain attributes. Those attributes include the structuring of source code dependencies such that source code modules that implement the detailed parts of the application are isolated from the source code modules that implement the high level policies, or business rules, of the application. Moreover, the detailed modules should depend upon the high level modules, and the high level modules MUST NOT depend upon any of the detailed modules. This management of dependencies is the key design activity needed to produce robust, maintainable and reusable designs. And yet very many designers that are new to OO do not understand this. No language, regardless of its OO "purity" will help a designer manage the dependencies between high level details and low level policies. -- [ I have written a paper that describes ] -- [ dependency management, and it is also well ] -- [ covered in my book. If you would like a copy ] -- [ of the paper, send me some email and I'll ] -- [ send it to you. rmartin@oma.com ] Once an object oriented design has been created, C++ is an excellent language in which to implement it. Once implemented, all the advantages of the design are exhibited by the source code. The modules created are robust in that they are isolated from changes made in other modules, they are maintainable in that the engineers need not fear that changes in one module will ripple to other modules, and they are reusable in that the high level modules do not depend upon the low level details, and so can be reused in a different detailed context. Run Time Efficiency. There are two broad classifications of Object Oriented languages: Statically typed languages like C++ and Eiffel, and dynamically typed language like Smalltalk or Objective-C. Both of these language types employ "run time binding" which is the attribute that makes object oriented design possible. However, the mechanisms employed by the two different language types are very different. In dynamically typed languages, every run time binding is looked up in a table of some kind. Although table lookups can be very fast, they still involve a loop, and a token matching algorithm. Hash tables are common, and some calls can even be resolved at compile time. Generally, however, it is impossible to precisely describe the time required for such an operation. And generally the operation requires dozens, or even hundreds of microseconds. Since a well designed object oriented program will make the majority of its function calls via this mechanism, the runtime overhead of a dynamic type system can be significant. In statically typed languages, run time bindings are performed by indexing into a table of pointers. This operation always requires exactly the same amount of time, and can be theoretically reduced to a single index into an array followed by a single pointer dereference. On most machines of today's calibre, these operations require less than a microsecond total. Most implementations of C++ come very close to achieving the theoretical limit, adding only one or two other pointer dereferences or index operations. For each implementation, the time required can be exactly specified. Thus, run time efficiency of run time bindings in statically typed language is always better than that of dynamically typed languages. What requires one or two microseconds in C++ may require dozens or hundreds of microseconds in a dynamically typed language. This makes C++ an excellent choice for applications that have intense real time requirements. It also makes C++ a good choice for component libraries that *might* be used in intense real time applications. Memory Managment. C++ is one of the very few OO programming language that does not require dynamic memory management. Perfectly sound OO programs can be implemented without using the "heap" at all. This is extremely important to those industries that have regulations against "heap" usage. (e.g. Avionics.) Objects can be created on the stack just like auto variables, or they can be created statically. In such cases, there is no need for memory cleanup, and no risk of heap fragmentation or exhaustion. C++ is the one of the only languages that allows the programmer to have complete control over the way memory is managed. If the user wants to use a heap, he can. If he wants to implement his own heap, he can. If he wants some objects to be created on the heap, and other objects to be created on a separately managed heap, he can. If he wants his heap to be garbage collected, he can implement or buy the appropriate collector. I know of no other language that provides such flexibility. C++ is often "bashed" because it does not provide garbage collection. The argument proferred is often: "GC is intrinsic to OO. GC is needed to free the programmer from managing memory. The lack of GC imposes extra complexity on the design." Irrespective of the truth or falsity of these arguments, there is another argument to be made: "Programmers shou ld have complete control over how memory is managed." I know of no language that provides more control over this area than C++. The point is this. If you really think that you need garbage collection, then you can have it. It won't be neatly integrated into the language, and there will be a certain amount of difficulty involved, however you can gain the bulk of the advantages of a garbage collected environment if you absolutely need them. However, if you don't need them, (and very often you don't) you don't have to have them. In this, C++ is unique. But what about memory leaks? Yes, this is a problem. Any consciencious programmer should deal with this issue. There are several ways. First, you can get a garbage collector. Second, you can use a tool like Purify, or Bounds Checker. Third, you can use an environment like ObjectCenter for tracking heap problems. Fourth, you can write your own heap allocator and put your own tracing mechanisms in. Fifth, you don't need to use the heap at all. OK, then what about heap fragmentation? Yes, this too is a problem. However it is almost trivial to write an allocator that can't be fragmented. Stroustrup describes such an allocator in "The C++ Programming Language" 2d. ed. And Rogue Wave sells one in the Booch Component library. C++ allows you to use such an allocator instead of the standard (malloc based) allocator. Third Party Sources and Support. C++ is by far the most supported object oriented language. There are compilers for nearly every major platform out there. There are even cross compilers for embedded systems. Moreover there is a large and growing supply of third party tools and class libraries. No other object oriented language even comes close to the coverage and sourcing that C++ enjoys. C++ derives from C. Although this point is often counted as an argument against C++, I count it as an advantage of the language. It means that C++ programs can be easily integrated with legacy C code, and legacy code in other languages that are C callable. C++ programs can call C programs, and C programs can call C++ programs. Moreover, C++ inherits all of the attributes that make C such a successful and useful language. Although C++ is a bigger and more complex language than C, it still "feels" like C. This is a subjective point, but one that is not insignificant. Conclusion Wait a minute! Is that all? Aren't there more reasons to use C++ than that? Sure. There are lots of little details that I passed over. Why? Because they are details, and because they can be contentious. I could tell you how great templates are, or how wonderful operator overloading is, or how neat pure virtual functions are. But why? For every point I could make, someone else could refute it and say it is ugly or nasty. And who should you believe? Your best recourse is to find out about these features for yourself. I recommend that you do a lot of reading. Then examine the arguments, pro and con, and decide for yourself. Don't hesitate to drop me a line asking me what I think about this or that. (rmartin@oma.com). But isn't C++ ugly? Part of it, yes. So what? English is an ugly language too. Ask any Frenchman. Consider the word "garage". This is an ugly word. Listen to it. Yuck! But we don't often see the "ugliness" of the word because we *use* it to represent a concept that is not ugly at all. The same is true of C++. Yes, I can understand why some people would think that some of the features or syntax of C++ are ugly. But the concepts underneath are not. Once you begin using the language, the "ugliness" evaporates. I have not been trying to tell you that C++ is the only OOPL and all wisdom dies with it. I have not been trying to tell you that C++ is the language you should be using. I have simply been trying to tell you why I use it, and why I think it is a reasonable implementation language for object oriented designs. If you want to use some other language, do so. It's no skin off my apple. But don't fall prey to the religious arguments of C++ detractors. C++ is a great language. It will not corrupt you, nor drag you down into the hell reserved for mediocre programmers. Nor will it turn you into "Super-Programmer" able to leap tall specifications with a single switch/case statement. No language has such powers! Software is not a religion. C++ is a language. It is a good language. It is a usable language. And if you are interested in implementing object oriented designs, it will work for you. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ -- Frustrated with C, C++, Pascal, Fortran? Ada95 _might_ be for you! For all sorts of interesting Ada95 tidbits, run the command: "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as sub j.) if u cn rd ths, u r gd enuf to chg to Ada :-) -Spencer Allain spencer@era.com Engineering Research Associates Vienna, VA 22182 ======================================================================= 45 === Date: Wed, 12 Apr 1995 10:58:07 +0200 From: franz@inf.ethz.ch (Michael Franz) Subject: Announcement: Oberon Track at GISI'95 The First Joint Conference of GI and SI will have a major track dedicated to Oberon. There will be an Oberon tutorial, four talks, and a plenary discussion. The conference language will be German, but the proceedings (to be published by Springer-Verlag) will contain English versions of the papers. All this will happen on Monday, September 18th, 1995. Here are the abstracts of the talks: --- The Smart Document or How to Integrate Global Services Jurg Gutknecht Institut fur Computersysteme ETH Zurich, CH-8092 Zurich gutknecht@inf.ethz.ch Driven by a foreseeable significant increase of global services (cable and wireless) in the near future, client/server environments will progressively replace systems that operate a single computer or workstation in isolation. Modern operating systems will not merely be expected to access but to integrate global services as smoothly as possible, because it is unreasonable to require users to learn a different interface for every single service that they want to use. Services should be presented uniformly and called implicitly, i.e. service-specific technical details should be handled by the system unconspicuously and behind the scenes. We believe that the document-oriented approach is best suited to this purpose. We present and demonstrate a versatile document- oriented interface for Oberon that - currently - integrates local documents, visual objects, symbolic computation servers, Web and Teletext. --- Integrating Oberon Resources into the World-Wide Web Ralph Sommerer Institut fur Computersysteme ETH Zurich, CH-8092 Zurich sommerer@inf.ethz.ch The World-Wide Web (WWW) is currently one of the most popular network information systems on the Internet. The range of items that may be accessed within the WWW includes hypertext documents, images, sound patterns and video sequences. To identify these items, their location and the method to acquire them, a generic naming scheme is provided. Besides the identification of these items it allows to specify and parametrize activities that construct items "on-the-fly". Hence, aspects of interaction may be introduced to the information system. In our paper we discuss this interactive potential power of the WWW, especially how to obtain this power from the Oberon operating system. Our attention is directed to aspects of information provision, i.e. we explore the suitability of the Oberon system for a WWW information server. The objective is the integration of interactive Oberon applications and services in the global WWW document space. Hence, we allow remotely to invoke Oberon activities which produce textual or graphical data from any location in the world. The integration is based on a simple server framework that allows to attach Oberon services to the WWW with minimal implementation effort. --- A Comparison of C++, FORTRAN 90 and Oberon-2 for Scientific Programming Bernd Moesli ARITHMETICA CH-8307 Effretikon, Switzerland moesli@arithmetica.ch In the past decade, the programming languages C++, FORTRAN 90 and Oberon-2 all evolved from their ancestors. This invites to reflect upon the suitability of these modern programming languages for scientific and engineering computing. In the first part, we compare their primary language features, as needed by scientists and engineers. In the second part, we list some useful features missing in Oberon-2. The report concludes by a personal assessment of the three languages with respect to the numerical context. The reader's experience in scientific programming in C or FORTRAN would be advantageous. --- Oberon Dialogs: A User Interface for End Users Markus Knasmueller Institute for Computer Science (Systemsoftware) Johannes Kepler Universitaet, Altenbergerstrasse 69, A-4040 Linz knasmueller@ssw.uni-linz.ac.at This paper describes the Dialogs package which allows a user to create and use dialog viewers with buttons, check boxes, text fields and other user interface elements. Dialogs fit smoothly into the Oberon system. Existing tools can be equipped with a graphical user interface without modifications. The object-oriented nature of Dialogs allows adding new user interface items and new commands even by third party programmers and end users. --- Conference Program: Monday, September 18th, 1995. 08.30-11.30 Oberon-Tutorial (Gutknecht, Reiser) 13.45-14.30 Gutknecht: Smart Documents 14.30-15.00 Sommerer: World-Wide-Web 15.00-15.15 Coffee Break 15.15-15.45 Moesli: Scientific Programming 15.45-16.15 Knasmueller: Oberon Dialogs 16.15-16.55 Plenary Discussion (Niklaus Wirth and others) --- For general questions about GISI'95, please contact gisi95@inf.ethz.ch or look up http://www.inf.ethz.ch/GISI95/GISI95.html . Michael Franz ======================================================================= 46 === Date: Wed, 12 Apr 95 15:58:14 -0700 From: heydon@pa.dec.com Subject: SRC Modula-3 linker algorithm (was: enigmatic smuggling) My previous description of how the SRC Modula-3 linker decides which interfaces and modules to include when it builds a program had a small mistake. When the linker builds the reachability graph, it adds a *bi-directional* edge for each EXPORTed interface. A complete description of the algorithm is now available on the Web as part of the SRC Modula-3 documentation. See the URL: http://www.research.digital.com/SRC/- modula-3/html/linking/LinkingProgs.html The figures in the examples were drawn with Juno-2, a constraint-based drawing editor written in Modula-3. See the following URL for more information about Juno-2. http://gatekeeper.dec.com/pub/DEC/SRC/- research-reports/abstracts/src-rr-131a.html I also hope to create a Juno-2 "home page" in the near future. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 47 === Date: Thu, 13 Apr 1995 06:07:03 GMT From: cs_wcm@ug.cs.ust.hk (Woo Chat Ming) Subject: Trestle or Motif ? I want to learn programming in windows. I have two choice : I can use Trestle in Modula-3 or use Motif in C++. Which one is more powerful and which one is more easy to use ? Woo Chat Ming. ======================================================================= 48 === Date: Thu, 13 Apr 1995 14:52:23 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Trestle or Motif ? Woo Chat Ming writes: > I want to learn programming in windows. I have two choice : > I can use Trestle in Modula-3 or use Motif in C++. Which one > is more powerful and which one is more easy to use ? > > Woo Chat Ming. > Trestle, VBTKit, and FormsVBT (which is UIMS with a Motif'ish look to it built on Trestle) are far more powerful than Motif/C++. Trestle is a garbage-collected, concurrent UI toolkit, where as Motif/C++ is single threaded and requires manual storage management. For ease of learning about programming in window systems, Trestle and FormsVBT really can't be beat. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 49 === Date: Fri, 14 Apr 1995 00:41:32 GMT From: hgeorge@eskimo.com (Harry George) Subject: Re: Trestle or Motif ? In article <1995Apr13.060703.27267@uxmail.ust.hk>, cs_wcm@ug.cs.ust.hk says... > >I want to learn programming in windows. I have two choice : >I can use Trestle in Modula-3 or use Motif in C++. Which one >is more powerful and which one is more easy to use ? > >Woo Chat Ming. > Why not do Motif in Modula-3? What you need is a M3 binding for Motif (and for specific widgets). I still can't release my Xm.i3 bindings from work, but maybe we could jointly do the bindings in our spare(?) time from home. Motif is _the_ standard in much of the UNIX work world. Using it with Modula-3 can be fun. Not as powerful or clean as Trestle, but usable. Used with named parameters (courtesy of M3), X/Motif can be readable. Of course multithreading goes to hell, but you can lock the X-driver thread, mess with multithreads in normal M3, and then release the X thread. Just don't try to do multithreads while X is running. -- -------------------- Harry George email: hgeorge@eskimo.com smail: 22608 90th Ave W / Edmonds WA 98026 quote: ======================================================================= 50 === Date: 13 Apr 1995 18:34:24 GMT From: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Subject: Re: Trestle or Motif ? cs_wcm@ug.cs.ust.hk (Woo Chat Ming) writes: | I want to learn programming in windows. I have two choice : | I can use Trestle in Modula-3 or use Motif in C++. Which one | is more powerful and which one is more easy to use ? You might want to consider using Tk. It's smaller, faster, and easier than Trestle or Motif. You can use Tk from C or C++, probably from M3 also. ======================================================================= 51 === Date: 13 Apr 1995 23:38:20 GMT From: strand@nic.cerf.net (Parallel Performance Group) Subject: Software Announcement Parallel Performance Group (PPG) is a provider of high-tech Unix- and PC-based scientific, engineering, and graphics software. PPG publishes a free monthly electronic-mail Newsletter for each of the categories below. Each Newsletter covers material on the market/industry niches served by these categories and tutorial information on the technologies involved. By sending an e-mail letter to any mailbox shown below, you will obtain by return e-mail sample Newsletters for the particular area(s) of your interest. You will not be put on any mail- ing list unless you specifically ask to be. Category Software Products Auto-Response E-Mail Box ------------------------- ----------------------- ------------------------ Obj.-Oriented CASE Tools Oberon/F, case/4/0, obj@ppgsoft.com objectiF, Innovator, Wizdom-Pro, Loox RealTime DSP Rippen, Hypersignal dsp@ppgsoft.com Image Proc'g/Medicl Imgng IAP img@ppgsoft.com Fuzzy Logic/Fuzzy Control Fuzzy Control Manager fuz@ppgsoft.com Neural Networks NeuroCom, NeuroGraph neu@ppgsoft.com Project Management Accent, ACOS PLUS 1 prm@ppgsoft.com Volume Visualization Vox-L, IAP vis@ppgsoft.com Simulation SystemSpecs, GPSS sim@ppgsoft.com RealTime Multiprocessing/ Rippen, Express, mpr@ppgsoft.com Parallel Processing/ Strand88, HyperC, Distributed Processing Load Balancer, MUSIC, Pulsus Solid Modelling/CADD/ Prelude, Pytha, Unicad, sol@ppgsoft.com Mech. Design/Animation Point Line, 3DGO Graphical Application Loox GAI Design Tool gai@ppgsoft.com Interfaces To regularly receive any Newsletter, reply to subscribe@ppgsoft.com with the message "Subscribe ". For example, "Subscribe Multiprocessing". ======================================================================= 52 === Date: Fri, 14 Apr 1995 00:28:34 GMT From: hgeorge@eskimo.com (Harry George) Subject: Re: Why you should use C++ In article , spencer@ERA.COM says... > > >This was just posted in comp.lang.ada, and now I believe that it should >find it's way over to Modula-3 :) Hmm, I seem to recall someone asking >about why they might want to start programming in Modula-3. Wouldn't it >be great to just hand them a "Why Modula-3" paper, in addition to the >FAQ? > [long discussion skipped] "Why ?" papers abound, but they don't change anyone's mind. The other guy just keeps on saying, "Well, so what? My language can do the job, too." IMHO, the problem is this: a) A Turing Machine can do any computable task, and can be programmed by punching holes in a paper tape. b) Anything more abstract or sophisticated than that is for the convenience of humans. c) A great deal has been learned about how humans (both programmers and compiler writers) interact with programming languages. d) Language designers try to incorporate these insights into new languages. e) Some languages sacrifice functionality in the attempt to incorporate new insights -- I consider these to be interesting experiments, but not production ready. f) Some languages pile features on, accreting functionality but losing clarity. These are useable but costly to maintain. g) A few languages are both functional (in the sense of effective) and elegant. These are useable in a wide range of tasks, and are a joy to develop and to maintain. Also, they can readily be converted to the next silver bullet when it shows up. h) It is difficult to understand the differences among languages unless you see the same task done in several languages, set side-by-side. "h" is not just a matter of opinion. It is subject to verification. For example, a panel of multi-lingual programmers could review code written in several languages, all doing the same tasks. Use an Olympic scoring system: Artistic and technical scores given separately. Range 0-6. Throw out high and low, and average the remainder. I've been trying to set up that experiment. I prepared applications in M3 and locally asked people to replicate them in their favorite languages. I chose tasks which should highlight the positives of specific languages or language classes. The tasks include: - "Hello, world" in X/Motif with a few buttons and textfields - Bit twiddling - Matrix manipulation, built as a template so it is useable with various numeric types (IEEE 32bit, 64Bit, 80bit) - SQL database access and update, and printing a tabular formatted report. - System stuff (forks, execs, timers,...) - Lisp-like defun and eval (define a function, put it in a polymorphic list, then cdr down the list to find the function and eval it) - [I intend to add] "5 houses" problem from Prolog - [I do not have an example for embedded systems -- is anyone actually doing embedded systems in M3? How does one handle static addressing of objects or keep tight control of the heap?] I've had no luck getting samples from other languages. So maybe the net is the place to do this sort of thing. Anyone want to help? - Chose other/additional representative tasks - Build Modula-3 examples (or imporve on mine -- this was 2 weeks total effort) - Build examples (at least Ada, C, C++, Prolog, Lisp, ML, Sather, Eiffel, C+@, Dylan, Oberon-2,...) - Serve as a juror (you have to prove multi-lingual experience) - Spread the word that it is time to put-up-or-shut-up re languages Temporarily at least we could use comp.lang.modula3 for coordination. Later, maybe comp.lang.misc could host the code-offs. -------------------- Harry George email: hgeorge@eskimo.com smail: 22608 90th Ave W / Edmonds WA 98026 quote: ======================================================================= 53 === Date: Thu, 13 Apr 1995 13:06:58 -0400 From: Dick Orgass Subject: Re: Trestle or Motif ? I've used both Trestle and the Motif library to build applications and, as a result, my view is the following. If your application can be constructed from a few Motif widgets, then a C or C++ simplementation of the application is quite simple. However, it's stil easier to use Tk/Tck or Tk/Perl for applications of this sort. For an application of some substance, that is something that's more than just a rearrangement of some standard widgets with a bit of glue, Trestle and the accompanying libraries are, in my opinion, easier. This is in an area where reasonable people might disagree. The Trestle version will be multi-threaded producing a more lively application. For a complex application, there's no question in my mind that Trestle and friends are far better than the Motif library. To quickly make my point, consider writing the Trestle/FormsVBT mail program, Postcard. The Modula-3 code is simple and clean. Think about what it might be like to write this using Motif and X directly, even in Modula-3. I'm sure you'll conclude that the Trestle/FormsVBT version is much cleaner and simpler, not to mention more functional. All of the above are more or less technical arguments. The marketplace has a quite different idea. Skills in Motif and C or C++ are valued much more highly than skills in Trestle/FormsVBT and Modula-3. I don't endorse this state of affairs but it is reality. Dick ======================================================================= 54 === Date: Thu, 13 Apr 1995 22:39:59 GMT From: fmc@world.std.com (Fraser M Campbell) Subject: What's the best Tutorial for Modula-3? Thanks to all those who responded to my previous post in this group. What I was wanting (I probably didn't make this clear) was a recommendation on the best tutorial style book for Modula-3. I need something along the lines of the beginner C books you can buy, not something that already assumes you're an expert programmer. Please give me specific titles and ISBN numbers (which are not in the FAQ ;) ... if you can't give me an ISBN then please try to tell me the publisher at least. I am eagerly awaiting your numerous recommendations ... Thanks! ======================================================================= 55 === Date: 13 Apr 95 22:54:46 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: What's the best Tutorial for Modula-3? Fraser Campbell says: Thanks to all those who responded to my previous post in this group. What I was wanting (I probably didn't make this clear) was a recommendation on the best tutorial style book for Modula-3. I need something along the lines of the beginner C books you can buy, not something that already assumes you're an expert programmer. Your best bet is: Samuel P. Harbison, Modula-3, Prentice Hall, ISBN 0-13-596396-6, 1992. -- A complete Modula-3 textbook covering the full language, with examples and exercises. Includes a style manual and a user's guide for SRC Modula-3. I got this information from the Modula-3 bibliography page, http://www.research.digital.com/SRC/modula-3/html/bib.html) Also see the errata sheet for the same book: ftp://gatekeeper.dec.com/pub/DEC/Modula-3/errata/ -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 56 === Date: 14 Apr 95 07:37:11 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: TSrg, TImpl in NetObj In article wyrmok@plg.uwaterloo.ca (Ru ssell Mok) writes: I went through the NetObj reference manual(SRC report 115) but I am not sure whether I have to explictly to write codes for TSrg and TImpl which are subtypes of NetObj.T. The manual says that the stub generator will declare the surrogate type(TSrg), but exactly how? To be more specific, if I have the following declaration: TYPE T = NetObj.T OBJECT METHODS x(); END; do I have to declare a type TSrg and TImpl somewhere in the module? Should I give an implemention of T.x() or TImpl.x()? I don't know if I have made my question clear enough. I guess I do know the run-time relationships between T, TSrg and TImpl but I am confused in how they are generated. Russell, You don't need to code TSrg; stubgen will create it for you. As far as I know, unless you are doing something tricky, you should not be concerned with TSrg in your code. In fact, in simple cases you don't _need_ to declare TImpl either. For example, you could do: INTERFACE I; TYPE T = NetObj.T METHODS op() END; END M. MODULE M; IMPORT NetObj; IMPORT I; PROCEDURE Op(self: I.T) RAISES ... = BEGIN ... END Op; BEGIN NetObj.Export (NEW(I.T, op := Op)); END M. Here by calling NEW on I.T and overriding the implementation of op, I get away with exporting a netobj without having to declare a TImpl. (I guess TImpl = I.T in this case.) But this means you won't be able to associate any individual state to an exported I.T object, as I.T is a "pure" type. Many times you _do_ want to associate individual state to an exported object, so can make a subtype of I.T and declare some state for the subtype. This is why you may want to have a TImpl type in your module. Note that NetObj needs is that TImpl is a subtype of I.T. You can name TImpl anything you wish and pretty much declare it anywhere you'd like in your code. MODULE M; IMPORT NetObj, I; TYPE TImpl = I.T OBJECT state: ... := ...; METHODS op := Op; END; PROCEDURE op(self: TImpl) RAISES ... = BEGIN ... refer to self.state ... END op; BEGIN NetObj.Export (NEW(TImpl)); END M. Good luck! Hope this helps, -- Farshad For a longer explanation, see Geoff Wyant's Linux Journal article "Introducing Modula-3", ftp://ftp.gte.com/pub/m3/linux-journal.html: To turn an object type into a network object, that object must inherit (either directly or indirectly) from the type 'NetObj.T'. The object cannot contain any data fields. The interface containing the declaration is then run through a tool called a stub compiler. This generates all code necessary to handle network interactions. That's all that is required to allow an object to be passed around the network. Pretty simple. Below is an example of a network object. It defines an interface called "File" that defines the operations on a file, and an implementation of that interface. INTERFACE File; TYPE T = NetObj.T OBJECT METHODS getChar(): CHAR; putChar(c: CHAR); END; END File; INTERFACE FileServer; IMPORT File; TYPE T = NetObj.T OBJECT METHODS create(name: Text): File.T; open(name: Text): File.T; END; END FileServer; The above defines two types: "File.T", which is an object with two methods to get and put a single character resp; and "FileServer.T", an object which manages file objects. A server someplace defines a concrete implementation of these abstract types. MODULE FileServerImpl; IMPORT File, FileServer; TYPE FileImpl = File.T ...state for a file... OVERRIDES getChar := GetChar; putChar := PutChar; END; TYPE FileServerImpl = FileServer.T OBJECT ...state for a file server... OVERRIDES create := Create; open := Open; END; VAR fileServer := NEW(FileServerImpl); BEGIN NetObj.Export("FileServer", fileServer); END; MODULE FileServerClient; IMPORT File, FileServer; VAR fileServer := NetObj.Import("FileServer"); file := fileServer.Create("someFile"); BEGIN file.putChar('a'); END FileServerClient; In the above, 'FileServerImpl' creates an instance of a file server and puts it into a name server (this is what 'NetObj.Export' call does). The module 'FileServerClient' (which would be running in a different address space or machine) 'imports' the file server implementation. This gives a valid Modula-3 object back to the client. >From that point on, the client invokes methods on it as if it were local. It then creates a File object which it begins adding characters to. -- Farshad Nayeri nayeri@gte.com ======================================================================= 57 === Date: 14 Apr 95 06:55:00 From: nayeri@gte.com (Farshad Nayeri) Subject: unwritten style guidelines for designing Modula-3 interfaces I am writing down some of the "unwritten style guidelines". Evidently there are some at SRC, I have seen at least two posts regarding these unwritten "rules": Paul McJones says about exceptions vs. checked run-time errors: While designing Modula-3 libraries at SRC, our philosophy has been to treat conditions that could only be caused by client programming error as checked runtime errors rather than as declared exceptions. So in general, input/output errors are treated as exceptions. (The interface IO is itself an exception! It was designed to be as "Pascal-like" as possible, for teaching a first course in programming.) Mark Manasse says regarding locking levels: [Valuable information about locking levels in Trestle deleted.] A while ago, David Sternlicht asked about experience with locking levels, and with the locking strategies used in Trestle. [...] Over the years, we've even gained a few converts: when you write a large system, it just gets too hard to keep it all in your head [...]. Anyone care to elaborate on other such conventions? (Few of the simple ones are documented in an appendix of Sam Harbison's Modula-3, but the documentation is not extensive.) - procedures vs. methods on principal type - New() vs. NEW() vs. init() and their expected semantics - multiple inheritence workaround (via opaque types?) - dealing with import dependency cycles - naming conventions - interface commenting style - bit fields are bad - any others? I can come up with my own interpretation of these unwritten rules, but it is better to get a first-hand account, I think. Such a set of guidelines (with proper examples and explanation ultimately ) would be very useful for the intermediate Modula-3 programmer. I will be happy to collect the answers and repost a summary. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 58 === Date: Fri, 14 Apr 1995 05:03:46 GMT From: wyrmok@plg.uwaterloo.ca (Russell Mok) Subject: TSrg, TImpl in NetObj I went through the NetObj reference manual(SRC report 115) but I am not sure whether I have to explictly to write codes for TSrg and TImpl which are subtypes of NetObj.T. The manual says that the stub generator will declare the surrogate type(TSrg), but exactly how? To be more specific, if I have the following declaration: TYPE T = NetObj.T OBJECT METHODS x(); END; do I have to declare a type TSrg and TImpl somewhere in the module? Should I give an implemention of T.x() or TImpl.x()? I don't know if I have made my question clear enough. I guess I do know the run-time relationships between T, TSrg and TImpl but I am confused in how they are generated. Thanks in advance. Russell ======================================================================= 59 === Date: Fri, 14 Apr 95 13:03:09 -0700 From: heydon@pa.dec.com Subject: Re: unwritten style guidelines for designing Modula-3 interfaces Farshad, Another convention is the use of "Public" and "Private" types in relation to opaque types. Section A.1.4 of Harbison's book is a good start on this subject, but it could go further. Certainly, INTERFACE Foo; IMPORT Bar; TYPE T <: Public; Public = Bar.T OBJECT END; ... END Foo. is the most common idiom used with respect to opaque types, but often the introduction of the name "Public" is only for the convenience of the implementer of the interface. It allows the revelation to be expressed as: MODULE Foo; REVEAL T = Public OBJECT END; ... BEGIN ... END Foo. However, the introduction of the new type "Foo.Public" could have been avoided by writing: INTERFACE Foo; IMPORT Bar; TYPE T <: Bar.T OBJECT END; The disadvantage to this approach is that the declarations for the would then have to have been *repeated* in the concrete revelation, like this: MODULE Foo; IMPORT Bar; REVEAL T = Bar.T OBJECT END OBJECT END; As you can see, the former approach makes the implementer's job easier, but not the client's, since it introduces an extra (you might even say unnecessary) name. So implementers sometimes take the second approach. For example, the generic "Table" interface does not introduce the names "Table.Public" or "Table.DefaultPublic". If you look at "Table.mg", you will see that all the public methods in the definition of "Table.Default" (appearing in "Table.ig") are repeated in the concrete revelation. (You will also see that the name "Public" is also introduced in the module for convenience). In contrast to the "gratuitous" use of the "Public" type, the use of the "Private" type to define an object prefix is often necessary. This is well-described in chapter 6 of SPwM3, especially in the third paragraph from the bottom of page 143. The example discussed there is: INTERFACE Wr; TYPE T <: ROOT; ... END Wr. INTERFACE WrClass; IMPORT Wr; TYPE Private <: ROOT; REVEAL Wr.T = Private OBJECT END; ... END WrClass. UNSAFE MODULE WrRep EXPORTS Wr, WrClass, ...; REVEAL Private = MUTEX BRANDED OBJECT END; ... BEGIN ... END WrRep; This is a classic example of the partial revelation of an opaque type, and it also demonstrates nicely the use of a "Private" prefix type. Clients that import only "Wr" see none of its fields or methods. Clients that import "Wr" and "WrClass", see only the first group of fields and methods. The key is to notice that by declaring a "Private" type that is a *prefix* of the type "Wr.T", the implementation "WrRep" can reveal that a "Wr.T" is actually a "MUTEX" object. Hence, the code in the module "WrRep" can lock objects of type "Wr.T". If instead the traditional idiom involving "Public" had been used in "WrClass", like this: INTERFACE WrClass; IMPORT Wr; REVEAL Wr.T <: Public; TYPE Public = ROOT OBJECT END; ... END WrClass. then there would be no way to reveal that "Wr.T" was actually a subtype of a "MUTEX". Instead, the "MUTEX" object would have to have been imbedded as a field of the "Wr.T", like this: UNSAFE MODULE WrRep EXPORTS Wr, WrClass, ...; REVEAL Wr.T = Public BRANDED OBJECT mu: MUTEX; END; ... BEGIN ... END WrRep; This approach is much less convenient for the implementer of "WrRep", since the type "Wr.T" is not a mutex. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 60 === Date: 16 Apr 1995 13:37:09 GMT From: connolly@www18.cern.ch (Dan Connolly) Subject: Java-style interfaces (protocols) in M3, ILU? Has anybody looked at the way Java[1] gets around multiple inheritance? I don't think they invented the concept -- I think it's been in Objective C for a while... Anyway, a Java interface[2] is a sort of object type with no "home" in the object hierarchy. In contrast to M3, where method calls, at runtime, involve an dispatch via an array of methods, ala: obj.classtype.methods[i](params) Java method dispatch is by "name," where the name of a method is its identifier and the names of the types of the parameters. It looks a lot like smalltalk method dispatch. I'd like to see this sort of thing supported in an ILU binding for Java, at least. I have noodled on what M3 language changes would acomodate this sort of thing, but I haven't found anything I like. What do other folks think? [1] http://java.sun.com/ [2] http://java.sun.com/1.0alpha2/doc/javaspec/javaspec_6.html#HEADING46 -- Daniel W. Connolly "We believe in the interconnectedness of all things" Research Technical Staff, MIT/W3C http://www.w3.org/hypertext/WWW/People/Connolly ======================================================================= 61 === Date: 15 Apr 1995 13:32:41 -0700 From: rro@Tera.COM (Rod Oldehoeft) Subject: Re: What's the best Tutorial for Modula-3? Someone (why doesn't this Pnews include the article in followup?) asked about the best tutorial for M3. Of course that is Harbison's "Modula 3", published by Prentice-Hall, ISBN 0-13-596404-0 or 0-13-596396-6 (paper), 1992. Rumor has it that this will appear in a revised Second Edition sometime, with errata applied, updated SRC M3 info, and more additional goodies. In the meantime, this is it. ======================================================================= 62 === Date: Mon, 17 Apr 1995 01:41:34 GMT From: cwr@crash.cts.com (Will Rose) Subject: M3 for OS/2? Does anyone know the status of the M3 port mentioned in the FAQ? I tried email to the two addresses mentioned, but they both bounced. Will cwr@crash.cts.com ======================================================================= 63 === Date: Mon, 17 Apr 1995 04:11:01 -0400 From: "Daniel C. Wang" Subject: M3 runtime system. Just curious, but are there any modula3 systems that use a runtime system, particularly the GC, written almost entirely in modual3 itself. I'm curious, because a number of other higher level languages (Lisp,Scheme,ML...) seem to resort to C hackery when it comes to the runtime system. I'm wondering if modula3 is an exception to the rule. ======================================================================= 64 === Date: 17 Apr 95 08:16:08 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: M3 runtime system. In article "Daniel C. Wang" writes: Just curious, but are there any modula3 systems that use a runtime system, particularly the GC, written almost entirely in modual3 itself. I'm curious, because a number of other higher level languages (Lisp,Scheme,ML...) seem to resort to C hackery when it comes to the runtime system. I'm wondering if modula3 is an exception to the rule. Daniel, Modula-3's run time can be written entirely in Modula-3, including the garbage collector. SRC Modula-3 is almost entirely written in Modula-3 [1]. As you note, this sets Modula-3 apart from many other "high-level" languages: Modula-3 defines an unsafe subset, so it is more convenient for machine-level programming tasks such as writing the garbage collector. This is unlike most other comparable "safe" languages. (Some people have informally call a "systems prorgramming language" one which you can use to write its own run-time subsystem.) The boundaries of what makes a language a "systems programming language" are not too clear, however. A "higher-level" language *without* an unsafe subset but *with* a native compiler subsystem may have the same "machine-level" programming power as Modula-3. This langauge & native subsystem pair allow you to write your garbage collector "in the same language". There are at least three advantages for having an unsafe portion _as a part of the language_: - for the most extent, you can treat your unsafe code the same as your safe code -- they all have interfaces; they have .i3 and .m3 files; the language tools and editors will work on both, etc. And you don't need a C compiler. In other languages, the unsafe portions -- which are normally the most intricate -- fall through the cracks, are badly documented, and are hard to deal with. - your unsafe code will work the same in different compilers; its semantics are language-defined, unless otherwise noted in the language spec. This is a blessing since you would probably have to deal with platform portability problems in your unsafe portions already. - the language can make adequate measures to get its safety practices out of your way in the unsafe portions of your code. It is difficult to do unsafe programming if you have to worry about the garbage collector and concurrency on every statement. Modula-3 is one of the few languages that carefully (and elegantly) walks the lines of safe and unsafe programming. (As evidence, see IMPORT rules for safe and unsafe interfaces.) Most other "high-level" languages punt on unsafe portions where _implementations_ of those language will have to provide access to unsafe operations. "Lower-level" languages' normal assumption is that you are programming in unsafe mode. Modula-3, _the language_, allows you to program in safe mode conveniently, but provides adequate support for you in case you want to program in unsafe mode (to write a garbage collector, for example!). [1] SRC Modula-3 implements certain parts of the thread switching code in C. I don't know why this is, and I would be surprised if it can't be done otherwise. Also, SRC compiler currently generates a m3main.c file in C. Other than these two -- and for the ability to link in C code, you don't need a C compiler for either compiling or even bootstrapping the SRC Modula-3 compiler. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 65 === Date: 18 Apr 95 00:01:47 GMT From: eaiu378@taurus.oac.uci.edu (Audrey Toy) Subject: Question I have a question about modula3. Who was the key designer and when was the year of initial ful design? What is the significance and origin of it's name? Could I have a brief histiry of modula3? please send reply to atoy@clyde.ics.uci.edu Thanks!!! ======================================================================= 66 === Date: Tue, 18 Apr 1995 03:25:47 GMT From: beatty@beatty.slip.netcom.com (Derek Beatty) Subject: building SRC 3.5.2 on a NEXTstation Has anyone successfully built 3.5.2 including Trestle on a NEXTstation under NEXTSTEP 3.2? What's the secret? I succeeded in getting some of the basics up by ripping out the "-posix" flag and writing my own macros for S_IFDIR and WEXITSTATUS (NEXT's posix support is in 3.2 is rumored to be buggy), but when I try to compile a long list of files, m3 hangs with a runtime error (Segmentation violation - possible attempt to dereference NIL). I don't think I'm out of virtual memory: when it hangs, the virtual size is only 7.14M, and I have 20M physical memory and about 15M free on the partition containing the swapfile. If I run gdb on m3 and attach to the hanging process, the stack trace looks like this: #0 0xcf960 in RTHooks__AllocateOpenArray () #1 0xc86ea in IntIntTbl__NewBuckets () #2 0xc7f94 in IntIntTbl__Init () #3 0x9f016 in MxOut__WriteUnits () #4 0xa724 in Main__DumpLinkInfo () #5 0x6d6e in Main__CleanUp () #6 0xd3a2c in RTProcess__InvokeExitors () #7 0xd3aca in RTProcess__Crash () #8 0xe4148 in RTMisc__EndError () #9 0xe40a2 in RTMisc__FatalErrorPC () #10 0xce77c in RTSignal__SegV () #11 0x50083ac in _sigtramp () #12 0xd67f6 in RTCollector__Move () #13 0xd5916 in RTHeapMap__Walk () #14 0xd521a in RTHeapMap__DoWalkRef () #15 0xd517a in RTHeapMap__WalkRef () #16 0xd8c44 in RTCollector__CleanBetween () #17 0xd89fa in RTCollector__CopySome () #18 0xd8064 in RTCollector__CollectSomeInStateOne () #19 0xd7638 in RTCollector__CollectSome () #20 0xd7094 in RTCollector__CollectEnough () #21 0xd9e9a in RTCollector__LongAlloc () #22 0xd9afe in RTHeapRep__AllocForNew () #23 0xcf05a in RTHooks__Allocate () #24 0x5c624 in Constant__Create () #25 0x5c530 in Constant__ParseDecl () #26 0x7105e in Decl__Parse () #27 0x296de in Module__Parse () #28 0x91536 in M3Compiler__DoCompile () #29 0x912f0 in M3Compiler__Compile () #30 0xd254 in Main__Pass0 () #31 0xc15a in Main__PushOneM3 () #32 0xbde0 in Main__CompileM3 () #33 0xb03c in Main__CompileOne () #34 0xae2c in Main__CompileEverything () #35 0x6cf4 in Main__DoIt () #36 0x12c54 in _INITM_Main () #37 0xcea9c in RTLinker__RunMainBodies () #38 0xceba6 in _INITM_RTLinker () #39 0x2962 in main (argc=31, argv=0x3fffadc, envp=0x3fffb5c) at _m3main.c:1430 -- Derek Lee Beatty beatty@netcom.com ,(((|)))-K ,(((|)))-K ,(((|)))-K Austin, Texas ^ ^ ^ ^ ^ ^ ======================================================================= 67 === Date: 18 Apr 1995 12:30:58 GMT From: Quentin Stafford-Fraser Subject: Re: unwritten style guidelines for designing Modula-3 interfaces nayeri@gte.com (Farshad Nayeri) wrote: >I am writing down some of the "unwritten style guidelines". Evidently >there are some at SRC ... >- procedures vs. methods on principal type Yes, this has puzzled me in the past. Why do we have PutText as a procedure in Wr, rather than as a method of a Wr.T? The latter seems much more aesthetically pleasing, as well as saving typing :-) There are plenty of similar examples. Is it just to avoid the small performance and memory overhead? Or is this a legacy of Modula-2? Quentin -- --------------------------------------------------------------------- Quentin Stafford-Fraser http://pelican.cl.cam.ac.uk/people/qs101/me.html --------------------------------------------------------------------- ======================================================================= 68 === Date: 18 Apr 1995 10:42:22 -0400 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: building SRC 3.5.2 on a NEXTstation >>>>> On Tue, 18 Apr 1995 03:25:47 GMT, beatty@beatty.slip.netcom.com >>>>> (Derek Beatty) said: Derek> Has anyone successfully built 3.5.2 including Trestle on a NEXTstation Derek> under NEXTSTEP 3.2? What's the secret? Never tried, but your error (dereferencing NIL) is the same thing that happened to me under HP-UX when I tried to use the newer version of the m3gcc backend. Try using the older 2.5.7-based backend. ======================================================================= 69 === Date: 18 Apr 95 21:10:48 GMT From: elessar@helios.acm.rpi.edu (Kenneth Lareau) Subject: Binaries for Solaris 2.4? Hello folks, I was wondering if perchance there are already some compiled binaries for the latest (or nearly latest) version of Modula 3 for Solaris 2.4 available somewhere on the net? I would gladly attempt to compile it myself, were it not for the fact that I simply don't have the disk space for the compile, though I do for the final executables (assuming I've been told correctly about that as well, can anyone give me a good estimate of the size of a complete distribution?). Any information on this matter would be greatly appreicated. Thank you. Ken Lareau elessar@helios.acm.rpi.edu ======================================================================= 70 === Date: 19 Apr 95 01:41:09 GMT From: ffung@clyde.ICS.UCI.EDU ("Frederick C. Fung") Subject: MODULA3 history Hi Professionals: Can anyone help me find out the following information: year of initial full design, key designer, significance, and (optionally) origin of its name about "MODULA3"? e.g. for PROLOG: . Here is a sample answer. prolog was first implemented in 1972 by Alain Colmerauer's research group in Marseille, France. Prolog was the first language based on a procedural interpretation of first order predicate calculus. prolog stands for programming logic. thanks in advance. ======================================================================= 71 === Date: 19 Apr 95 07:01:18 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: MODULA3 history ffung@clyde.ICS.UCI.EDU ("Frederick C. Fung") writes: Can anyone help me find out the following information: year of initial full design, key designer, significance, and (optionally) origin of its name about "MODULA3"? eaiu378@taurus.oac.uci.edu ("Audrey Toy") writes: I have a question about modula3. Who was the key designer and when was the year of initial ful design? What is the significance and origin of it's name? Could I have a brief histiry of modula3? Hmm. Sounds like extra credit for a comparative languages course. Why this is relevant to study of languages is beyond me. Hint: How about checking out books on M3 or at least the Modula-3 home page? I bet you can find something there. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 72 === Date: Wed, 19 Apr 1995 10:50:48 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: M3 runtime system. Cc: m3@src.dec.com In-Reply-To: Distribution: world X-Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) X-Received: by src-mail.pa.dec.com; id AA29949; Wed, 19 Apr 95 08:04:00 -0700 X-Newsgroups: comp.lang.modula3 X-Content-Length: 1017 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-1.pa.dec.com (5.65/24Feb95) X-Received: by cloyd.East.Sun.COM (5.x/SMI-SVR4) X-Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) X-Received: by src-news.pa.dec.com; id AA03513; Wed, 19 Apr 95 08:04:03 -0700 Farshad Nayeri writes: > > [1] SRC Modula-3 implements certain parts of the thread switching code > in C. I don't know why this is, and I would be surprised if it > can't be done otherwise. Also, SRC compiler currently generates a > m3main.c file in C. Other than these two -- and for the ability to > link in C code, you don't need a C compiler for either compiling > or even bootstrapping the SRC Modula-3 compiler. > > -- Farshad Actually, the thread switching code is all in Modula-3. On POSIX systems it does some rather sophisticated magic involving setjmp and stack analysis to do this in a portable fashion (most C implementations of threads that I've encountered have are a hairball of #ifdefs to get around various processor dependencies). That POSIX thread's implementation is about 1500 lines of M3 code, including the code to do thread switching. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 73 === Date: 19 Apr 1995 06:52:45 GMT From: laszlo@bornholm.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Re: Modula3 and Oberon2. You might read my paper: A Comparison of Modula-3 and Oberon-2 (Structured Programming 1993 14:15-22. Best regards Laszlo Boszormenyi ======================================================================= 74 === Date: 18 Apr 1995 21:13:51 GMT From: drake@PROBLEM_WITH_INEWS_DOMAIN_FILE (Joshua Drake) Subject: Does anyone know where.. COMPLETE src for Linux? m3 I am looking for the complete src tree for modula-3, for linux. The one on sunsite seems to be missing some very important things.. (like the makefile). If anyone can direct me please let me know via e-mail. Joshua drake@transport.com -- ############################################################################# ============================================================================= = drake@transport.com The Admin with an attitude = ============================================================================= As long is there are tests... There WILL be PRAYER in SCHOOLS. ############################################################################# ======================================================================= 75 === Date: Thu, 20 Apr 1995 18:50:00 +0100 From: vgr@gaia.psdn.org (vgr) Subject: (none) SUBSCRIBE comp.lang.modula3 Vic Reyes ======================================================================= 76 === Date: Thu, 20 Apr 95 12:06:21 -0400 From: nayeri@gte.com (Farshad Nayeri) Subject: Siphon documentation I looked around, but couldn't find any reports or documents on Siphon. Is there such a document? Thanks, -- Farshad ======================================================================= 77 === Date: Thu, 20 Apr 1995 14:53:45 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Siphon documentation Farshad Nayeri writes: > > I looked around, but couldn't find any reports or documents on Siphon. > Is there such a document? > > Thanks, -- Farshad > There is a report from DEC-PRL describing an ealier incarnation of Siphon (I believe it was written in M2+ and thus didn't use Network Objects). Thue functionality was essentially the same as the current Siphon implementation. If you look under gatekeeper.dec.com:/pub/DEC/PRL/reports I think you will find the report. Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 78 === Date: 19 Apr 1995 21:11:05 -0400 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: pickling part of an object Let's say I have an object T for which I want to write a custom pickle routine. There is a large amount of data in T that I don't want to pickle, since I can regenerate it from a few small data value. So, I can write a pickling routine for it. However, what happens to subclasses? I don't want to lose all their data when they get pickled using my pickler. Is there a way to use the RTHeap interface, as Pickle does, to only pickle out the data fields of the subclasses, not of the object itself? ======================================================================= 79 === Date: 21 Apr 1995 06:51:15 GMT From: laszlo@bornholm.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Re: What's the best Tutorial for Modula-3? > I need something along the lines of > the beginner C books you can buy, not something that already assumes you're > an expert programmer. Such a book is just in preparation at Springer Verlag in German and in English. L. Boszormenyi, C. Weich: Programming in Style -- An introduction into Programming with Modula-3 The book is written for beginners. It starts with the basic concepts of structured programming and the corresponding Modula-3 constructs. The second part of the book addresses more advanced topics, such as object-oriented and parallel programming as well. It contains a great number of examples and appendices, such as a full and short description of the language, a somewhat bigger, non-trivial example, a guide how to get M3 and the examples of the book etc. We will put the table of content into this newsgroup soon. The German version should appear before the end of June 95, the English version in autumn, maybe October 95. Best regards L. Boszormenyi ======================================================================= 80 === Date: 22 Apr 1995 02:18:52 GMT From: egustafs@ecepc44.uccs.edu (Eric Gustafson) Subject: modula3.el maintainer? I found a bug in the modula3.el code, but can't figure out who to report it to. (Actually I have the fix for it too :). I remember getting the code from somewhere in the U.K., and the beginning of the file is included below. The problem is that it parses '\\', and "\\" as an unterminated character/string. ---- Snip, Snip ---- ;;; Last modified on Fri Feb 11 16:08:05 PST 1994 by detlefs ;;; modified on Fri May 15 17:13:12 PDT 1992 by heydon ;;; modified on Thu Apr 23 17:45:03 PDT 1992 by muller ;;; modified on Fri Feb 2 13:04:24 1990 by discolo ;;; modified on Tue May 2 21:59:35 1989 by ellis ;;; modified by Trevor Morris ;;; modified by Tom Perrine ;;; modified by Michael Schmidt ;;; modified by Peter Robinson ;;; modified by mjordan ;; LCD Archive Entry: ;; modula3|Eric Muller|muller@src.dec.com| ;; Modula-3 mode.| ;; 92-04-17||~/modes/modula3.el.Z| ---- Snip, Snip ---- Thanks, -- Eric Gustafson egustafs@ecepc44.uccs.edu Electrical & Computer Engineering egustafs@cpe.valpo.edu University of Colorado -- UCCS Phone: (719) 637-8022 ** Warning ** Planet is 97% full please remove unneeded inhabitants !! ======================================================================= 81 === Date: 23 Apr 1995 03:22:09 GMT From: mlw2374@omega (Tai West) Subject: Re: MODULA3 history Frederick C. Fung (ffung@clyde.ICS.UCI.EDU) wrote: : Hi Professionals: : Can anyone help me find out the following information: year of : initial full design, key designer, significance, and (optionally) : origin of its name about "MODULA3"? Modula-3 corrects many of the deficiencies of Pascal and Modula-2 for practical software engineering. In particular, Modula-3 keeps the simplicity and type saftey of these earlier languages while providing new facilities for exception handling, concurrency, object-oriented program- ming, run-time typing, generics, support for multithreaded applications, and automatic garbage collection. Modula-3 was designed by Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, and Greg Nelson as a joint project by DEC's Digital Systems Research Center (SRC) and the Olivetti Research Center. Modula-3 was implemented at SRC by Bill Kalsow and Eric Muller. I got this information from the book "Modula-3" by Samuel P. Harbison, and "Introducing Modula-3" in the December 1994 Linux Journal. -- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ When one has good wine, @ @ Tai West @ A graceful schooner, @ @ mlw2374@omega.uta.edu @ And a maiden's love, @ @ @ Why envy the immortal gods? @ @ @ -LI T'SI PO (A.D. 705-762) @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ======================================================================= 82 === Date: Sun, 23 Apr 1995 00:28:15 GMT From: groener@vt.edu (Markus K. Groener) Subject: Where is Klaus Preschern? Hi, we are searching for Klaus Preschern. In his documentation of EX32.DOC he gives an address for the University of Klagenfurt but e-mail to this address bounced back (user unknown). Klaus, in the documentation you write that you subscribe to this group, please send us your new e-mail address if possible. Thanks, Markus (email: groener@vt.edu) & Utku (email: utku@csgrad.cs.vt.edu) ======================================================================= 83 === Date: Sun, 23 Apr 1995 00:22:45 GMT From: groener@vt.edu (Markus K. Groener) Subject: Problem with starting Modula-3 on PC Urgent! Today we installed your DOS implementation of Modula-3 on a PC. This is a Gateway 2000 486DX2/50MHz with 8MB RAM running MS-DOS 6.20. Since we initially ran into lots of different problems we changed the CONFIG.SY S and AUTOEXEC.BAT files to reflect only the necessary commands as shown in the EX32.DOC documentation. Still whenever running EX after having the SETLIBPC. BAT program run we would receive an error message. We have tried to work around this and load the VSSH shell manually but still received the same error message. Here is the output of trying to start EX32 -v vssh: ex32 1.01, (C)opyright 1994 Klaus Preschern, All rights reserved. Coprocessor detected. XMS driver detected XMS query: total: 5035 K = 5155840 bytes, free: 5035 K = 5155840 bytes XMS linear base: 3232768 first page: 790 last page: 2047 XMS allocated: total: 0 K, free: 0 K Physical system memory 65517568 bytes Virtual system memory 125829120 bytes panic: memory size is not a multiple of the page size (4096). Running just EX we would receive the last error line without all the other output. We hope this will help in pointing us into the right direction. Please let us know if further information is need. Thanks a lot in advance for any help. A quick response will be greatly appreciated. Markus (email: groener@vt.edu) & Utku (email: utku@csgrad.cs.vt.edu) ======================================================================= 84 === Date: 23 Apr 1995 07:35:10 GMT From: mlw2374@omega (Tai West) Subject: Re: MODULA3 history Tai West (mlw2374@omega) wrote: : Frederick C. Fung (ffung@clyde.ICS.UCI.EDU) wrote: : Hi Professionals: : Can anyone help me find out the following information: year of : initial full design, key designer, significance, and (optionally) : origin of its name about "MODULA3"? Modula-3 corrects many of the deficiencies of Pascal and Modula-2 for practical software engineering. In particular, Modula-3 keeps the simplicity and type saftey of these earlier languages while providing new facilities for exception handling, concurrency, object-oriented program- ming, run-time typing, generics, support for multithreaded applications, and automatic garbage collection. Modula-3 was designed by Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, and Greg Nelson as a joint project by DEC's Digital Systems Research Center (SRC) and the Olivetti Research Center. Modula-3 was implemented at SRC by Bill Kalsow and Eric Muller. The first description of the language was published by Digital and Olivetti in August of 1988. A revision based on implementation experience was pub- lished in 1989, and a few final adjustments were made in 1990. Modula-3's immediate ancestor is the language Modula-2+, designed at SRC in the early 1980s as an in-house development language. Modula-2+ is an upward- compatible extension of Niklaus Wirth's Modula-2 language, which in turn is a succesor to Wirth's Pascal. I got this information from the book "Modula-3" by Samuel P. Harbison, and "Introducing Modula-3" in the December 1994 Linux Journal. -- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ When one has good wine, @ @ Tai West @ A graceful schooner, @ @ mlw2374@omega.uta.edu @ And a maiden's love, @ @ @ Why envy the immortal gods? @ @ @ -LI T'SI PO (A.D. 705-762) @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ======================================================================= 85 === Date: Sun, 23 Apr 1995 00:25:43 GMT From: groener@vt.edu (Markus K. Groener) Subject: M3 Documentation on Concurreny???? Hello, is there any documentation and/or examples available on the internet that gives information on writing concurrent programs using threads and mutual exclusion in Modula-3? Any pointers to information will be appreciated. Markus (email: groener@vt.edu) & Utku (email: utku@csgrad.cs.vt.edu) ======================================================================= 86 === Date: 23 Apr 1995 11:43:07 GMT From: mrg17@cus.cam.ac.uk (M.R. Gray) Subject: Re: Problem with starting Modula-3 on PC Markus K. Groener (groener@vt.edu) wrote: : Urgent! : message. Here is the output of trying to start EX32 -v vssh: : ex32 1.01, (C)opyright 1994 Klaus Preschern, All rights reserved. : Coprocessor detected. : XMS driver detected : XMS query: total: 5035 K = 5155840 bytes, free: 5035 K = 5155840 bytes : XMS linear base: 3232768 first page: 790 last page: 2047 : XMS allocated: total: 0 K, free: 0 K : Physical system memory 65517568 bytes : Virtual system memory 125829120 bytes : panic: memory size is not a multiple of the page size (4096). As I use the EX32 for the PC, I have just pulled the patch from src.doc.ic.ac.uk, I enclose the readme README file for ex32.exe version 1.03 This file should come together with "ex32.exz" - the new gzipped ex32.exe 1.03. It should solve the following problems: "panic: memory size is not a multiple of the page size (4096)." "panic: not enough RAM." "panic: pager: attempt to free a not allocated block." For installation do: gzip -d ex32.exz copy ex32.exe \ex32\bin\ex32.exe If you use the system with XMS, the memory size reported by XMS is used to determine the size of available RAM. If you run it *without* XMS, use the "-v" option to check wether the reported physical memory size is correct. If NOT, you can specify the memory size instart ex32 with: initdrvs files ex32 -v -m8192 /ex32/bin/vssh Enjoy! Klaus Preschern End of README file for ex32.exe version 1.03 -- ----------------------------------------------- Malcolm Gray Trinity Hall, Diploma in Computer Science ----------------------------------------------- ======================================================================= 87 === Date: Sun, 23 Apr 1995 20:47:28 GMT From: groener@vt.edu (Markus K. Groener) Subject: Re: Problem with starting Modula-3 on PC - Thanks In article <3ndegb$t3g@lyra.csx.cam.ac.uk> mrg17@cus.cam.ac.uk (M.R. Gray) writ es: >As I use the EX32 for the PC, I have just pulled the patch from >src.doc.ic.ac.uk, I enclose the readme >README file for ex32.exe version 1.03 Thanks, we got the patch and the problem was solved. Markus & Utku ======================================================================= 88 === Date: Mon, 24 Apr 95 00:24:04 -0700 From: heydon@pa.dec.com Subject: Re: M3 Documentation on Concurreny???? Markus K. Groener asks: > is there any documentation and/or examples available on the internet that > gives information on writing concurrent programs using threads and mutual > exclusion in Modula-3? Yes, Chapter 4 of the book "Systems Programming with Modula-3", edited by Greg Nelson, is an excellent introduction to this subject. The chapter is called "An Introduction to Programming with Threads", and was written by Andrew Birrell. If you don't have a copy of SPwM3, an earlier version of this paper was published as SRC Research Report 35. The abstract and PostScript for the report is available at the following URL: http://gatekeeper.dec.com/pub/DEC/SRC/ research-reports/abstracts/src-rr-035.html You can also order hardcopy reports and videotapes from us for free. The URL for ordering SRC Research Reports and videotapes is: http://www.research.digital.com/SRC/publications/src-rr.html I hope this helps. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 89 === Date: Mon, 24 Apr 1995 15:38:39 GMT From: chan@alfrothul.uchicago.edu (C. Chan) Subject: Modula-3 for AIX 3.2 I have been learning Modula-3 on my home Linux box with the SRC 3.3 distribution and I think it would be useful for my projects at work where we use IBM RS/6000s running AIX 3.2. I looked at the distributions of 3.5.2 on gatekeeper.dec.com and saw only a port to AIX 3.1. I contacted the maintainer of the AIX 3.2 port and he informed me that work on that has been set aside temporarily. Are there any older distributions of Modula-3 available in binary or source form for AIX 3.2? -- C. Chan | "ASCII Magic Eye .Sig" . ======================================================================= 90 === Date: 25 Apr 1995 23:02:54 GMT From: Ted Wobber Subject: Re: Siphon documentation nayeri@gte.com (Farshad Nayeri) wrote: > > > I looked around, but couldn't find any reports or documents on Siphon. > Is there such a document? > > Thanks, -- Farshad > The PRL report Geoff mentions is still pretty relevant, even though it refers to anartifact written in Modula 2+. The man pages for the siphon and packagetools contain a fair amount of information as well: pkgsrv/src/packageserver.8 pkgtool/src/packagetool.1 pkgq/src/pkgq.1 pkgfprint/src/pkgfp.1 If all else fails, I can answer questions directly. /Ted ======================================================================= 91 === Date: 27 Apr 1995 02:28:49 GMT From: olm@Eng.Sun.COM (Ole Lehrmann Madsen) Subject: ECOOP'95 Preliminary programme This article was originally posted by Jorgen Lindskov Knudsen, but due to a currently heavy delay in the news stream to/from Denmark I have reposted this article. ---olm ------------------------------------------------------------------------------- Department of Computer Science, University of Aarhus, Denmark, and AITO (Association Internationale pour les Technologies Objets) are happy to invite you to: ECOOP'95 European Conference on Object-Oriented Programming Aarhus, Denmark, August 7-11, 1995 The ninth European Conference on Object-Oriented Programming is held in Aarhus, Denmark. The conference aims at bringing together researchers and practitioners from academia and industry to discuss and exchange new developments in object-oriented languages, systems and methods Printed program, including registration form for ECOOP'95 can be obtained from: ECOOP'95 Computer Science Department Aarhus University Ny Munkegade 116, Bld. 540 DK-8000 Aarhus C, Denmark Phone: +45 89 42 31 88 Fax: +45 89 42 32 55 E-mail: ecoop95@daimi.aau.dk WWW: http://www.daimi.aau.dk/ecoop95 You are also welcome to contact us on the above address and we will help you by answering questions about the conference or its organization, or other issues related to ECOOP'95. Please note, that the entire contents of the ECOOP'95 program is available on World Wide Web (WWW) at the URL: http://www.daimi.aau.dk/ecoop95 You will here find many more details, including GIF, PostScript (European A4 and US letter format) and RTF versions of the registration forms, ready for printing, filling-in and sending to make your registration for ECOOP'95 as easy as possible. Please remember these important dates: Early registration deadline: 5. June 1995 Conference period: 7.-11. August 1995 We are looking forward to seing you in Aarhus at the exciting ECOOP'95 event. Jxrgen Lindskov Knudsen Organizing Chair ------------------------------------------------------------------------------- Technical Program ----------------- The ECOOP'95 technical program highlights state-of-the-art object-oriented research results, based on the intense developments during the last decade, resulting in object-oriented technology being spread into nearly all areas of computer science research and development. Ole Lehrmann Madsen Conference Chair Walter Olthoff Program Chair Boris Magnusson Panel Chair Wednesday, 9 August, 1995: .......................... 09.00-10.00 Keynote Address Experiences on the Road to Object Utopia, Dave Thomas (Object Technology International) 10.30-12.00 Technical Session: Types Chair: Remo Pareschi (Xerox, France) The Cartesian Product Algorithm, Ole Agesen (Stanford University) PolyTOIL: A Type-Safe Polymorphic Object-Oriented Language, Kim B. Bruce, Angela Schuett, Robert van Gent (Williams College, Williamstown) Object Imaging, Satish R. Thatte (Clarkson University, Potsdam) 12.00-13.30 Lunch 13.30-15.00 Panel Object Technology and the World-Wide Information Infrastructure Panel chair: Andreas Paepcke (Xerox PARC) 15.30-17.00 Technical Session: Programming Languages Chair: Markku Sakkinen (University of Jyvdskyld) Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis, Jeffrey Dean, David Grove, Craig Chambers (University of Washington) Objects with Multiple Most Specific Classes, Elisa Bertino (Universita di Milano), Giovanna Guerrini (Universita di Genova) A Marriage of Class- and Object-Based Inheritance Without Unwanted Children, Patrick Steyaert, Wolfgang De Meuter (Free University of Brussels) 17.15-18.15 Demonstration Sessions Thursday, 10 August, 1995: .......................... 09.00-10.00 Invited Talk On Subtyping and Matching, Luca Cardelli (Digital Systems Research Center) 10.30-12.00 Technical Session: Reflective Programming/Verification Chair: Boris Magnusson (Lund University) Using Meta-Object Protocols to Implement Atomic Data Types, R.J. Stroud, Z. Wu (University of Newcastle upon Tyne) Meta-Level Programming with CodA, Jeff McAffer (University of Tokyo and Object Technology International) An Object-Oriented Framework for the Formal Verification of Processors, Laurent Arditi, Hilhne Collavizza (Universiti de Nice) 12.00-13.30 Lunch 13.30-15.00 Panel Open Problems in Object-Oriented Programming Panel chair: Ole Lehrmann Madsen (University of Aarhus) 15.30-17.00 Technical Session: Implementation Chair: Bjxrn Freeman-Benson (Carleton University) Incremental Mature Garbage Collection Using the Train Algorithm, Jacob Seligmann, Steffen Grarup (University of Aarhus) Message Dispatch on Pipelined Processors, Karel Driesen, Urs Hvlzle (University of California, Santa Barbara), Jan Vitek (Universiti de Geneve) Do Object-Oriented Languages Need Special Hardware Support?, Urs Hvlzle (University of California, Santa Barbara), David Ungar (Sun Microsystems Laboratories) 17.15-18.15 Demonstration Sessions Friday, 11 August, 1995: ........................ 09.00-10.00 Invited Talk Programming as an Experience: The Inspiration for Self, Randall B. Smith and Dave Ungar (Sun Microsystems Laboratories) 10.30-12.00 Technical Session: Concurrency/Specification Chair: Oscar Nierstrasz (Universitdt Bern) Time and Asynchrony in Interactions Among Distributed Real Time Objects, Ichiro Satoh (Keio University), Mario Tokoro (Keio University and Sony Computer Science Laboratory) Object Protocols as Functional Parsers, Gert Florijn (Utrecht University) Interface-Based Protocol Specification of Open Systems Using PSL, Doug Lea (SUNY at Oswego), Jos Marlowe (Sun Microsystems Laboratories) 12.00-13.30 Lunch 13.30-15.00 Technical Session: Distribution/Interfaces Chair: Gerti Kappel (University of Linz) Experience Using Design Patterns to Evolve System Software Across Diverse OS Platforms, Douglas C. Schmidt (Washington University), Paul Stephenson (Ericsson, Inc.) Sharing Properties in a Uniform Object Space, Heiko Kiessling, Uwe Kr|ger (University of Karlsruhe) ChyPro: A Hypermedia Programming Environment for Smalltalk, Maurice Amsellem (Universiti de Paris) ------------------------------------------------------------------------------- Tutorial Overview ----------------- ECOOP'95 offers an exciting tutorial program, featuring a selection of introductory, intermediate and advanced presentations of interest to both researchers and practitioners. The tutorial program addresses a broad spectrum of object technology, including methods, languages, environments and theoretical topics. The tutorial program welcomes both conference participants and other interrested parties. Birger Mxller-Pedersen Tutorial Chair Tutorials T01: MOSES: Methodology for Object-Oriented Software Engineering of Systems T02: Adoption and Management of OO by an Organization T03: Prototype-Based Application Construction Using Self T04: Using Design Patterns - Elements of Reusable Architectures T05: Concurrent Object-Oriented Network Programming with C++ T06: Enterprise Object Modeling T07: Object-Oriented Technology for Real-Time Systems T08: From OOA/OOD to Eiffel T09: Efficient Implementation of Object-Oriented Programming Languages T10: Oberon and Extensible Programming T11: Integrating Formal Methods With Object-Oriented Software Engineering Methodologies T12: OTI Constraint Solver T13: Object Cobol T14: Models and Paradigms of Interaction T15: Programming in BETA T16: Object-Oriented Domain Analysis: Reuse, Obstacles and Possible Solutions ------------------------------------------------------------------------------- Workshop Overview ----------------- The ECOOP'95 workshop program provides an excellent framework for people to meet and focus on current advanced research topics as well as discuss issues of general interest. Workshops can also help by bridging gaps between related fields. The workshop program is free of charge for conference participants. Others must pay a workshop fee, which gives access to any number of workshops. Prospective workshop attendees must submit a position paper to the respective workshop organizer, who will grant admission hereupon. Any additional information about a particular workshop should be obtained directly from the workshop organizer. Please consult the workshop organizer for specific deadlines for position paper submissions and notification of acceptance. Please note that further details on the individual workshops are available on the ECOOP'95 Workshop World Wide Web pages. Eric Jul Workshop Chair Workshops W1: 5th ECOOP Workshop for Doctoral Students in Object-Oriented Systems W2: Quantitative Methods for Object-Oriented Systems Development W3: Object Technology: Learning, Teaching and Training W4: Advances in Metaobject Protocols and Reflection W5: Experiences with Object-Oriented Design Methods W6: Use of Object-Oriented Technology for Network Design and Management W7: Pattern Languages of Object-Oriented Programs W8: Mobility and Replication ------------------------------------------------------------------------------- Exhibition ---------- The main conference will be accompanied by a three-day commercial exhibition on August 9, 10 and 11. Vendors of object-oriented products and services should contact the Exhibition Chair at the earliest convenience to ensure their inclusion. For further information please contact: Elmer Sandvad Computer Science Department University of Aarhus Ny Munkegade 116, Bldg 540 DK-8000 Aarhus C, Denmark Telephone: +45 8942 3188 Fax: +45 8942 3255 E-mail: ess@daimi.aau.dk Demonstrations -------------- ECOOP'95 provides a venue for live demonstrations of object-oriented systems. Proposals for demonstrations of object-oriented software are invited to illustrate innovative concepts or recent work in applying object-oriented technology. Demonstrations will be selected on the basis of technical merit, novelty and relevance. Demonstrations include in-house applications, as well as academic and corporate research efforts. If you are planning to present a system at ECOOP'95, please send a description of the demonstration, your name and address together with hardware requirements to: Kurt Nxrmark Department of Mathematics and Computer Science Institute for Electronic Systems Aalborg University Fredrik Bajers Vej 7E DK-9220 Aalborg, Denmark Telephone: +45 9815 8522 Fax: +45 9815 8129 E-mail: normark@iesd.auc.dk ------------------------------------------------------------------------------- Pricing Information (all prices are in DKK) ------------------- CONFERENCE FEE Paid before Paid before Paid after June 5, 1995 July 24, 1995 July 24, 1995 Regular 2550 3000 3450 Reduced 2100 2550 3000 Student 900 1350 1800 WORKSHOP-only* FEE Regular 1105 1300 1495 Reduced 910 1105 1300 Student 360 585 780 TUTORIAL (full day) FEE Regular 1870 2200 2530 Reduced 1540 1870 2200 Student 660 990 1320 TUTORIAL (half day) FEE Regular 1020 1200 1380 Reduced 840 1020 1200 Student 360 540 720 * Please note that workshop participation is free of charge for conference participants. Cancellation ............ Notification of cancellation must be made in writing to Aarhus Convention Bureau. For cancellation before 5 June 1995, fees will be fully refunded, except for an administration charge of DKK 300. For cancellation between 5 June and 24 July, a refund of 50% will be made. In the event of cancellation after 24 July, fees will not be refunded. All refunds will be dealt with only after the conference. Accommodation Booking ..................... Category DKK per night (approx.) A. with single room 895 bath/shower/toilet double room 995 B. with single room 420-480 bath/shower/toilet double room 505-680 C. primarily without single room 315-340 bath/shower/toilet double room 465 All room prices include breakfast, VAT and service charges. Payment directly to hotel upon departure. NB! Should the preferred category be fully booked, we reserve the right to book you a room in the alternative category. Confirmation will be forwarded. Tickets will be handed over on arrival. Payment ....... The payment has to be none in one of the following ways: cheque in Danish Crowns, drawn on a Danish bank and made payable to: ECOOP'95, c/o Aarhus Convention Bureau, Raadhuset, DK-8000 Aarhus C, Denmark bank transfer order to: ECOOP'95, c/o Aarhus Convention Bureau. Account No. 3627-3258011031, Den Danske Bank, 2-12 Holmens Kanal, DK-1092 Copenhagen K, Denmark credit card: Visa, Diners, Eurocard, MasterCard, JCB or Dankort NB! Fees, if any, are at the sender's expense. ------------------------------------------------------------------------------- General Information ------------------- ECOOP'95, the Ninth European Conference on Object-Oriented Programming, will be held at the University of Aarhus, Denmark. The ECOOP'95 conference lasts from 7 August to 11 August 1995. The Final Program and other information including the registration form can be obtained from: ECOOP'95 Dept. of Computer Science University of Aarhus Ny Munkegade, Bldg 540 DK-8000 Aarhus C, Denmark E-mail: ecoop95@daimi.aau.dk Telephone: +45 8942 3188 Fax: +45 8942 3255 WWW: http://www.daimi.aau.dk/ecoop95 The contact numbers for urgent messages to the ECOOP'95 organization and conference delegates during the five days of ECOOP'95 will be: Telephone: +45 8942 3417 Fax: +45 8613 1769 All fax messages should be clearly marked: ECOOP'95. Registration ............ Please fill in the registration and hotel reservation form and return it along with relevant payment as soon as possible to: ECOOP'95 Aarhus Convention Bureau Raadhuset DK-8000 Aarhus C, Denmark Telephone: +45 8612 1177 Fax: +45 8612 0807 This is the address for all correspondence concerning registration and accommodation (payment, cancellation, etc). Registration Fees ................. Please consult the registration form for details of the fees. The deadline for receipt of early registrations 5 June 1995. The ECOOP'95 registration fee covers: Access to scientific sessions Access to any number of workshops (provided attendance has been granted by the workshop organizer) ECOOP'95 Proceedings and other conference materials Welcome Reception and Buffet at Kongreshuset, 9 August Access to Exhibitions Lunches (9-11 August) Refreshments during breaks Local transportation The Tutorial registration fee covers: Access to the registered tutorials Tutorial materials Refreshments during breaks Local transportation The Workshops-only registration fee covers: Access to any number of workshops (provided attendance has been granted by the workshop organizer) Workshop materials Refreshments during breaks Local transportation The Workshops-only registration fee is available to persons who will participate in one or more workshops, but who will not register for the conference. Note that no workshop fee applies to persons registered for the conference. Reduced rates are available for ACM members only, and only if the correct ACM membership number is specified on the registration form. Student rates are available for all full-time students. A student registration must be accompanied by proof of full-time student status, otherwise it will be returned. Accompanying persons are entitled to: attend the Welcome Reception and Buffet. Please note, that tickets are required. Remember to indicate the number of tickets on the registration form. visit the Exhibition Lunch tickets for lunches on 7-8 August should be ordered on the registration form. Payment ....... All payments should be forwarded in Danish currency (DKK) and can be made by bank transfer, Eurocheque (each cheque not exceeding DKK 1,500), cheque (drawn on a Danish bank), postal cheque, or credit card (Dankort, Eurocard, Master Card, Visa, JCB, Diners). All fees are on the account of the participant. When paying by credit card, it is necessary to state the card number and date of expiry, and the card-holder's name exactly as shown on the card. Please note that it will not be possible to pay fees by credit card during the conference. Upon receipt of the registration fee, each participant will receive confirmation of the accommodation booked and a receipt for the amount paid. Please bring this confirmation with you and present it at the registration desk when collecting your tickets and materials. Cancellation ............ Notification of cancellation must be made in writing to Erhus Convention Bureau. For cancellation before 5 June 1995, fees will be fully refunded, except for an administration charge of DKK 300. For cancellation between 5 June and 24 July, a refund of 50% will be made. In the event of cancellation after 24 July, fees will not be refunded. Insurance ......... You are requested to arrange for your own health and travel insurance. The ECOOP'95 Organizing Committee will not accept responsibility for compensation as regard of accidents or damage suffered by participants and accompanying persons, occurring during or arising from the conference. Social Program .............. + Welcome Reception and Buffet A reception and buffet will be hosted by the Mayor of Erhus on 9 August, at Kongreshuset. The reception and buffet is open to all registered conference delegates and accompanying persons. Please do not forget to register for the reception on the registration form. + Banquet The conference banquet will be held on 10 August, at the Varna Mansion in the outskirts of Erhus. Participation is not included in the conference fee, so bear in mind to register for the banquet on the registration form. Accommodation ............. Hotels Erhus Convention Bureau has made preliminary hotel reservations for the ECOOP'95 participants. Please use the enclosed registration form to book rooms. The hotels have been divided into two categories according to standard of comfort. The organisers cannot guarantee accommodation to participants who do not book in advance. Payment has to be made directly to the hotel upon departure. Camp sites and summer cottages If you wish to stay at a camp site or summer cottage during the conference, please contact: Camping Blommehaven Xrneredevej 35, DK-8270 Hxjbjerg Telephone: +45 8627 0207 Fax: +45 8627 4522 Beautifully located by the sea in the Marselisborg Woods close to the city centre. Cabins available. Approx. 20 min. by bus from conference venue. Ajstrup Camping Ajstrup Strandvej, DK-8340 Malling Telephone: +45 8693 3535 Fax: +45 8693 1584 Situated south of Erhus in recreational surroundings by the beach and close to the woods. Cabins available. Approx. 50 min. by bus, 30 min. by car from conference venue. Dansommer Voldbjergvej 12, DK-8240 Risskov Telephone: +45 8617 6122 Fax: +45 8617 6855 For booking of summer cottages. Climate ....... The weather in Denmark in August is usually sunny with temperatures around twenty degrees celsius, and with occasional showers. Travel ...... Erhus Airport/Tirstrup offers direct flights to and from Copenhagen, Oslo, Stockholm, London, Gothenburg, and Brussels. The airport bus, with service to and from the central train station, departs from the airport directly after each arriving flight; it leaves for the airport from the train station 70 minutes before all departing domestic flights (i.e., to Copenhagen) and 80 minutes before all departing direct international flights. Erhus is served by a train station with an hourly comfortable service to and from Copenhagen (4 1/2 hours) and several connections daily with Sweden, Germany, and the rest of Europe. There is also a harbour conveniently located in the centre of the city, with ferry and hydrofoil connections with Copenhagen via Kalundborg. A motorway links Erhus directly with Germany and thereby most major European cities. Erhus is a 4 to 5 hour drive from Hamburg. Within the city, the municipal bus system is a convenient and reliable means of transportation. Each ECOOP'95 participant will be issued with a bus card covering local bus transportation. ------------------------------------------------------------------------------- Organization ------------ ECOOP'95 is organized by the Department of Computer Science, University of Aarhus and AITO (Association Internationale pour les Technologies Objets) in cooperation with ACM/SIGPLAN. Executive Committee ................... Conference Chair: Ole Lehrmann Madsen (University of Aarhus) Program Chair: Walter Olthoff (DFKI GmbH) Organizing Chair: Jxrgen Lindskov Knudsen (University of Aarhus) Tutorial Chair: Birger Mxller-Pedersen (Norwegian Computing Center) Workshop Chair: Eric Jul (University of Copenhagen) Panel Chair: Boris Magnusson (Lund University) Demonstrations Chair: Kurt Nxrmark (Aalborg University) Exhibition Chair: Elmer Sandvad (University of Aarhus) Conference Secretariat ...................... Susanne Brxndberg (University of Aarhus) Janne Damgaard (University of Aarhus) Marianne D. Iversen (University of Aarhus) Program Committee ................. Mehmet Aksit (University of Twente) Pierre America (Philips) Jean Bezivin (University de Nantes) Pierre Cointe (Ecoles des Mines de Nantes) Bjxrn Freeman-Benson (Carleton University) Yutaka Ishikawa (RWCP) Gerti Kappel (University of Linz) Eric Jul (University of Copenhagen) Mary Loomis (Hewlett-Packard) Boris Magnusson (Lund University) Jose Meseguer (SRI) Paola Mello (University of Bologna) Bertrand Meyer (ISE) Oscar Nierstrasz (University of Bern) Walter Olthoff (DFKI GmbH) Andreas Paepcke (Xerox PARC) Jens Palsberg (University of Aarhus) Remo Pareschi (Xerox, France) Markku Sakkinen (University of Jyvdskyld) Alan Snyder (SunSoft, Inc.) Dave Thomas (Object Technology International) Mario Tokoro (Keio University/Sony CSL) Peter Wegner (Brown University) Roberto Zicari (Goethe-University) Sponsoring Organizations ........................ ACM/SIGPLAN: Association of Computing Machinery : Special Interest Group in Programming Languages AITO: Association Internationale pour les Technologies Objets CINCOM Systems, Denmark DAIMI: Department of Computer Science, University of Aarhus, Denmark Den Danske Bank, Denmark DEVISE: Centre for Experimental System Development, University of Aarhus, Denmark Faculty of Science, University of Aarhus, Denmark Sun Division, ICL Data A/S, Denmark ======================================================================= 92 === Date: 26 Apr 1995 19:03:51 GMT From: ryan@ponder.csci.unt.edu (Ryan Stansifer) Subject: a checkbox in VBTKit/Trestle How do you correctly implement a checkbox in VBTKit/Trestle? I am working along the following lines: VAR (* the interior of the button *) text := TextVBT.New(" Check "); v := RigidVBT.FromHV (text, 20.0, 10.0); (* 3-d shadow around the interior *) sfb := NEW(ShadowedFeedbackVBT.T).init(ch:=v, shadow:=sh); (* put a check box off to the side *) mfb := MarginFeedbackVBT.NewBox(ch:=sfb); (* Without something like BiFeedbackVBT the shadow around "v" is not altered when the button is pushed. But I don't understand BiFeedbackVBT and the arguments to BiFeedbackVBT.T init *) (* the button *) switch := NEW(SwitchVBT.T).init(mfb?????); (* add the boolean state, and we are done *) main := NEW(BooleanVBT.T, callback:=Check).init(switch); Ryan Stansifer ryan@cs.unt.edu ======================================================================= 93 === Date: 26 Apr 1995 19:13:18 -0400 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: modula3 tutorial ... I have an online modula3 tutorial in html another student in the lab ftp'd from .... ??? .... he can't remember! He had gotten the pointer from the newsgroup, which I remember seeing as well. Will the author please tell us who you are, and were we got it? We'd like a tex or postscript version to give to people new to the language, but we only have the html version! Besides, we'd like to put a link in to your home page and give you credit for it. :-) Thanks! ======================================================================= 94 === Date: Thu, 27 Apr 1995 02:55:11 GMT From: fmc@world.std.com (Fraser M Campbell) Subject: Re: Does anyone know where.. COMPLETE src for Linux? m3 drake@PROBLEM_WITH_INEWS_DOMAIN_FILE (Joshua Drake) writes: >I am looking for the complete src tree for modula-3, for linux. The one on >sunsite seems to be missing some very important things.. (like the makefile). >If anyone can direct me please let me know via e-mail. > drake@transport.com The pre-built Linux binaries are available from ftp.vlsi.polymtl.ca in /pub/m3/linux. Source code is available at gatekeeper.dec.com in /pub/DEC/Modula-3/release-3.3 Hope that helps ... ======================================================================= 95 === Date: Thu, 27 Apr 95 23:42:29 GMT From: pjt2@ukc.ac.uk (Paul Teasdel) Subject: Help with Linux modula3 compiler I've just installed the SRC modula3 compiler for Linux. When I try to run a program ie tetris it comes up with the following error: tetris: can't find library 'libm3X11R4.so.3' I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so I know it's there. How do I solve the problem. Do I need to do some recompiling os somehow tell my machine to look in the right place. Cheers Paul ======================================================================= 96 === Date: Fri, 28 Apr 1995 08:31:40 -0400 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Help with Linux modula3 compiler Paul Teasdel writes: > I've just installed the SRC modula3 compiler for Linux. When I try > to run a program ie tetris it comes up with the following error: > > tetris: can't find library 'libm3X11R4.so.3' > > I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so > I know it's there. How do I solve the problem. Do I need to do > some recompiling os somehow tell my machine to look in the right > place. > > Cheers > > Paul > Easily solved: setenv LD_LIBRARY_PATH /usr/local/soft/modula3-3.4/lib/m3/LINUX (assuming csh) Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 97 === Date: 28 Apr 1995 08:14:41 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Help with Linux modula3 compiler In article <9705@merlin.ukc.ac.uk>, Paul Teasdel wrote: >I've just installed the SRC modula3 compiler for Linux. When I try >to run a program ie tetris it comes up with the following error: > >tetris: can't find library 'libm3X11R4.so.3' > >I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so >I know it's there. How do I solve the problem. Do I need to do >some recompiling os somehow tell my machine to look in the right >place. ld.so has to be able to find the library in one of : (i) /etc/ld.so.conf (ii) LD_LIBRARY_PATH I generally symlink all the shared libs to a `lib' directory somewhere, and then add that to /etc/ld.so.conf. In fact, I believe the current distribution generates symlinks for you ? (remember to re-run `ldconfig' if you change /etc/ld.so.conf). 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. ======================================================================= 98 === Date: Fri, 28 Apr 1995 01:41:51 GMT From: beatty@beatty.slip.netcom.com (Derek Beatty) Subject: Modula-3 partial solution Recently I posted a query re: building SRC Modula-3 release 3.5.2 on a NeXTstation running NEXTSTEP 3.2. The symptom was that on large compilations the compiler would die. The problem, it turns out, was that it was running out of memory: the Modula-3 runtime calls sbrk to allocate large chunks of memory, and NeXT's undocumented sbrk emulation is only good to 6MB. Fortunately, Modula-3 does not care if its memory chunks are contiguous, so writing my own sbrk as a simple wrapper around vm_allocate sufficed. I've succeeded in building Trestle. However, I haven't succeeded in building Trestle applications---there's no shared memory in the Mouse-X libraries on the NeXT archives. It looks like a dummy version of XSharedMem is called for. This much I think I've figured out: PROCEDURE UsesExtension (st: VBT.ScreenType): BOOLEAN = BEGIN RETURN FALSE; END UsesExtension; -- Derek Lee Beatty beatty@netcom.com ,(((|)))-K ,(((|)))-K ,(((|)))-K Austin, Texas ^ ^ ^ ^ ^ ^ ======================================================================= 99 === Date: Fri, 28 Apr 95 14:24:45 -0700 From: mhb@pa.dec.com ("Marc H. Brown") Subject: Re: a checkbox in VBTKit/Trestle I suggest that you use FormsVBT. But if you want to do it yourself, the following code should work; child := TextVBT.New("check"); feedback := MarginFeedbackVBT.NewBox(child, state.shadow) switch := NEW(SwitchVBT.T).init(feedback) main := NEW(BooleanVBT.T, callback:=Check).init(switch); BooleanVBT.Put(main, TRUE); ======================================================================= 100 === Date: 28 Apr 1995 23:39:33 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Obtaining return address of procedure Is there any standard way of obtaining the return address of the executing procedure ( or any other address within the calling procedure) , to enable a procedure ( in this case an execution tracing package ) obtain the name of the calling procedure with a call to RTProcedureSRC.FromPC() ? I can do it by counting down the stack from the address of a local variable by a fixed amount, but the fixed amount can only be obtained by trial and error, and has a habit of changing when the code in the procedure changes. Also, this method strikes me as a little non-portable... Thanks, Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 101 === Date: Fri, 28 Apr 1995 13:26:00 -0700 From: bruce@newton.apple.com (Bruce Thompson) Subject: Re: Help with Linux modula3 compiler In article <9705@merlin.ukc.ac.uk>, pjt2@ukc.ac.uk (Paul Teasdel) wrote: > I've just installed the SRC modula3 compiler for Linux. When I try > to run a program ie tetris it comes up with the following error: > > tetris: can't find library 'libm3X11R4.so.3' > > I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so > I know it's there. How do I solve the problem. Do I need to do > some recompiling os somehow tell my machine to look in the right > place. > > Cheers > > Paul Is your LD_LIBRARY_PATH variable set correctly? Assuming you use bash, try this: $ LD_LIBRARY_PATH=/usr/local/soft/modula3-3.4/lib/m3/LINUX $ export LD_LIBRARY_PATH Or using tcsh: % setenv LD_LIBRARY_PATH /usr/local/soft/modula3-3.4/lib/m3/LINUX Either that or setup your ld.config to include the modula 3 libraries. Cheers, Bruce -- -------------------------------------------------------------------- Bruce Thompson | "Never put off till tomorrow what PIE Developer Information Group | you can comfortably put off till Apple Computer Inc. | next week." | -- Unknown Usual Disclaimers Apply | ======================================================================= 102 === Date: Fri, 28 Apr 95 21:22:23 GMT From: pjt2@ukc.ac.uk (Paul Teasdel) Subject: Re: Help with Linux modula3 compiler Thanks to the many people who offered help to the last problem. This seems to be the general solution: put the library directories in /etc/ld.so.config and then run /sbin/ldconfig -v That solves the problems with finding the libraries I have installed. Now when I run tetris I get this: tetris: can't find library 'libXaw.so.6' The only relevant library I have is /usr/X11/lib/libXaw.so.3.1.0 so it seems like I need to get some newer libraries. Where do I find them and is it an easy process to install them? Cheers Paul ======================================================================= 103 === Date: 29 Apr 1995 20:21:19 GMT From: rbrewer@rwb114.rh.psu.edu (Robert W. Brewer) Subject: Re: Help with Linux modula3 compiler Yes, you need XFree86 3.1.1. It looks like you have 2.x installed right now. -Rob -- Robert W. Brewer KB3BEH A thorough knowledge of the Bible is worth more rbrewer@psu.edu than a college education. --Theodore Roosevelt ======================================================================= 104 === Date: 29 Apr 1995 23:15:22 GMT From: tlh20@thor.cam.ac.uk (T.L. Harris) Subject: accessing a variable before initialising it Looking at the Modula-3 language definition, I was wondering if there is a reason why it is legal to access a variable before initiallising it. To me this seems somewhat at odds with other features of the language which generally seem to reduce opportunities for 'careless' errors along the lines of not freeing memory that is no longer pointed to, or forcing non-sensible typecasts. I can see circumstances where an problem of this type could not be identified at compile time - e.g. with INTEGERs a and x: IF a=1 THEN x=1; END; x=x+1; may fail if x is initially undefined and a#1, but succeed whatever x's initial state if a=1. This would, admittedly, produce some overhead at run-time - but there have been numerous times when some combination of circumstances has left a variable undefined and led to unpredictable consequences. Any thoughts? tim -- +---------------------------------------------------------------------------+ | You remind me of Shallot, only made of shadows even though you're not - | | Indigo Girls, Left me a Fool | +----------------------------+----------------------------------------------+ | tlh20@cam.ac.uk | WWW home page: | | | http://www.chu.cam.ac.uk/home/tlh20/home.html| +----------------------------+----------------------------------------------+ ======================================================================= 105 === Date: Sun, 30 Apr 1995 12:42:39 -0700 From: bruce@newton.apple.com (Bruce Thompson) Subject: Re: Help with Linux modula3 compiler In article <9718@merlin.ukc.ac.uk>, pjt2@ukc.ac.uk (Paul Teasdel) wrote: > Thanks to the many people who offered help to the last problem. > This seems to be the general solution: > > put the library directories in /etc/ld.so.config and then run > /sbin/ldconfig -v > > That solves the problems with finding the libraries I have > installed. Now when I run tetris I get this: > > tetris: can't find library 'libXaw.so.6' > > The only relevant library I have is /usr/X11/lib/libXaw.so.3.1.0 so > it seems like I need to get some newer libraries. Where do I find > them and is it an easy process to install them? > > Cheers > > Paul Hi. It just doesn't want to cooperate does it! :-) Ok, I'd suggest you grab the latest X11R6 from sunsite.unc.edu:/pub/Linux/X11/XFree86-3.1.1 and install tha t. There's a large amount of stuff there, but as I recall there's an INSTALL fi le that will walk you through the installation. It's not difficult at all. Cheers, Bruce. -- ----------------------------------------------------------------------- Bruce Thompson | "Never put off till tomorrow what Newton Developer Information Group | you can comfortably put off till Apple Computer Inc. | next week." | -- Unknown Usual Disclaimers Apply | ======================================================================= 106 === Date: 28 Apr 1995 17:49:00 GMT From: buzz@marvin.isdn.cs.tu-berlin.de (Bastian Schlueter) Subject: Re: Modula-3 partial solution beatty@beatty.slip.netcom.com (Derek Beatty) wrote: Hello Derek, [...] >The problem, it turns out, was that it was running out of memory: the >Modula-3 runtime calls sbrk to allocate large chunks of memory, and NeXT's >undocumented sbrk emulation is only good to 6MB. Fortunately, Modula-3 are you shure about that? The following output makes me wonder: marvin buzz 102 (Documentation/RFC):limit cputime unlimited filesize unlimited datasize 6144 kbytes <--- Looks like this made sbrk fail ?! stacksize 512 kbytes coredumpsize unlimited memoryuse unlimited No i don't have any limit set by myself, nor by my sysop (that's me of course : -) Greetings Bastian -- Bastian Schlueter TEL.: +49 030 / 314 25 973 (uni) Fehrbellinerstr. 39 44 34 01 35 (priv) __o D-10119 Berlin e-mail: buzz@cs.TU-Berlin.DE _`\<,_ Germany buzz@marvin.isdn.cs.TU-Berlin.DE (_)/ (_) -- Radfahrer haben nichts zu verlieren als ihre Ketten -- ~~~~~~~~~~~ ======================================================================= 107 === Date: Sun, 30 Apr 1995 13:20:22 GMT From: beatty@beatty.slip.netcom.com (Derek Beatty) Subject: Re: Modula-3 partial solution In article <3nr9qd$7dr@marvin.isdn.cs.tu-berlin.de> buzz@marvin.isdn.cs.tu-berlin.de (Bastian Schlueter) writes: > beatty@beatty.slip.netcom.com (Derek Beatty) wrote: > >The problem, it turns out, was that it was running out of memory: the > >Modula-3 runtime calls sbrk to allocate large chunks of memory, and NeXT's > >undocumented sbrk emulation is only good to 6MB. Fortunately, Modula-3 > > are you shure about that? The following output makes me wonder: > . . . No, I'm absolutely sure. I raised all the limits before I ran the compiler, and it still failed. I attached the debugger to the compiler process, set a breakpoint at sbrk, and watched the parameters and the return values. It's only a coincidence that the default process data size limit is also the point of failure. Here are the notes I kept during the debugging process: Tried ulimit -d 20000; still failed at same spot Tried ulimit -s 2000 as well; still failed at same spot Ran m3build, paused, attached debugger to m3 process. Found that it dies on attempt to access memory at 0x5bc000 (inaccessible). Previous longword is accessible. Somehow, Mach didn't give M3 the memory it wanted: Breakpoint 1, 0x5055714 in sbrk () (gdb) p/x $d0 $17 = 0xcc000 (gdb) fin Run till exit from #0 0x5055714 in sbrk () 0xdec4c in RTOS__GetMemory () (gdb) p/x $d0 $18 = 0x5aa000 (gdb) cont Continuing. Program generated(1): Memory access exception on address 0x5bc000 (invalid address). 0x5008622 in memcpy () (gdb) Trying m3build from a csh with limit data unl;limit stack 32768...same error. My best guess is now that the sbrk() function doesn't really work. I should try writing my own, a wrapper on vm_allocate. -- Derek Lee Beatty beatty@netcom.com ,(((|)))-K ,(((|)))-K ,(((|)))-K Austin, Texas ^ ^ ^ ^ ^ ^ ======================================================================= 108 === Date: 30 Apr 1995 03:12:42 GMT From: davidf@cais3.cais.com (David R Fruehwald) Subject: Re: Modula3 and Oberon2 I would be interested how do I get it.