======================================================================= 1 === Date: Mon, 02 May 94 15:11:53 -0700 From: mhb@src.dec.com ("Marc H. Brown") Subject: Re: formsedit and "Visual" windowing > It appears that Browse requires the items be listed or from a file > (not from an array of Text.T). I suggest you use the "realize" method to subclass the ListVBT that Browser uses, and then call ListVBT methods directly using your array of Text.T. Look at the section in FormsVBT.i3 file entitled "Sublcass of components"; the example there is pretty explicit. > On another point, while formsedit is much better than building windows by > writing code, it seems what would make life much better would be to have > a graphical tool which one could pick various forms, place them on the wi ndow > expand them, change characteristics of them. The result of this tool wou ld > be the FormsVBT language which describes the window just built. Anyone > working on this kind of thing? Nobody that I know of. However, last summer, an intern Krishna Bharat from Georgia Tech, wrote an system "Visual Obliq" that includes a direct-manipulation GUI-builder. That can be used for generating .fv files, but it's very preliminary at present. ======================================================================= 2 === Date: Tue, 3 May 1994 13:54:14 GMT From: mmeola@cahill (Vulcan) Subject: Using the Xt interface... Has anyone had success using the X interfaces? In this code, PROCEDURE uiInit(argc:INTEGER; argv:M3toC.Argv) = BEGIN Top := Xt.AppInitialize(AppC, "Xtimeclock", NIL, 0, (* options *) argc, argv); (* user-supplied args *) Xt.GetApplicationResources(Top, ADR(global_data), rezs, 2); END uiInit; I get this error: m3make /work/m3/bin/m3 -w3 -make -why -g -o timeclock -F.PGM_SOURCES new source -> compiling ./Ui.m3 "./Ui.m3", line 26: incompatible types (application_class) 1 error encountered application_class is "Xtimeclock" -- what do I need to do to get this to compile? -- Matt Meola mmeola@lookout.ecte.uswc.uswest.com ======================================================================= 3 === Date: 3 May 1994 14:55:07 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Local procedure-constant as parameter In article <2q5lcgINN3dp@fstgds15.tu-graz.ac.at>, laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) writes: > Modula-3 explicitly forbids to assign a local (nested) procedure > to a procedure variable (this is o.k., otherwise > a procedure could be called without context). > The compiler allows, however, to pass a local procedure as parameter. > I wonder, whether this is a feature or a bug?! It's a feature. See SPwM3. Section 2.3.1, Assignment: Since there is no way to determine statically whether the value of a procedure parameter is local or global, assigning a local procedure is a runtime rather than static error. Section 2.3.2, Procedure call: For a READONLY or VALUE parameter, the actual can be any expression assignable to the type of the formal (except that the prohibition against assigning local procedures is relaxed). - Bill Kalsow ======================================================================= 4 === Date: 3 May 1994 17:06:45 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Using the Xt interface... In article , mmeola@cahill (Vulcan) wri tes: > Top := Xt.AppInitialize(AppC, "Xtimeclock", ... > "./Ui.m3", line 26: incompatible types (application_class) > application_class is "Xtimeclock" -- what do I need to do to get this > to compile? Try IMPORT M3toC; Top := Xt.AppInitialize(AppC, M3toC.TtoS ("Xtimeclock"), ... - Bill Kalsow ======================================================================= 5 === Date: 3 May 1994 16:08:33 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Local procedure-constant as parameter >Modula-3 explicitly forbids to assign a local (nested) procedure >to a procedure variable (this is o.k., otherwise >a procedure could be called without context). >The compiler allows, however, to pass a local procedure as parameter. >I wonder, whether this is a feature or a bug?! > It's a feature. The language report says (section 2.2.8): "A local procedure can be passed as a parameter but not assigned, since in a stack implementation a local procedure becomes invalid when the frame for the procedure containing it is popped." Or, in other words, it is generally no problem to pass a procedure as a parameter because - during the execution of the called procedure - the context of the caller is "alive" and may be used by the nested procedure. Peter --- Peter Klein E-Mail: pk@i3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21311 Ahornstrasse 55 Fax.: +49/241/8888-218 RWTH Aachen 52074 Aachen Germany ======================================================================= 6 === Date: 3 May 1994 13:59:44 GMT From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Local procedure-constant as parameter Modula-3 explicitly forbids to assign a local (nested) procedure to a procedure variable (this is o.k., otherwise a procedure could be called without context). The compiler allows, however, to pass a local procedure as parameter. I wonder, whether this is a feature or a bug?! Please find the following example with comments. Best regards Laszlo Boszormenyi MODULE x EXPORTS Main; IMPORT SIO; TYPE Action = PROCEDURE (i: INTEGER); VAR aa: Action; PROCEDURE P(a: Action) = BEGIN a(1); (*This is compiled and runs properly*) aa:= a; (*This is compiled and crahses at runtime (feature or bug?)*) END P; PROCEDURE Q() = PROCEDURE A(i: INTEGER) = BEGIN SIO.PutInt(i); SIO.Nl(); END A; BEGIN (*aa:= A; This is not compiled: in accordance with the definition*) P(A); (*This is compiled and runs properly. Is this allowed?*) END Q; BEGIN Q(); END x. ********************************* * Prof. Laszlo Boeszoermenyi * * Institut fuer Informatik * * * * Universitaet Klagenfurt * * Universitaetsstr. 65-67 * * A-9022 Klagenfurt / Austria * * * * e-mail: * * laszlo@ifi.uni-klu.ac.at * * Tel.: * * 00-43-463-2700-509 * * 00-43-463-2700-506 (secr.) * * Fax.: * * 00-43-463-2700-505 * ********************************* ======================================================================= 7 === Date: 3 May 1994 11:40:27 GMT From: a.vermeulen@ecn.nl (Alex T. Vermeulen) Subject: Re: OS/2 2.x port of SRC Modula-3 attempt In , bcrwhims@undergrad.math.uwaterloo. ca (Carsten Whimster) writes: >Hi all, > >I am going to attempt a port of SRC modula-3 3.1 starting with the >SRC package available for Linux. I am not an experienced "porter", >so I would appreciate it if anyone more familiar with OS/2 and >porting could assist me. I am willing to do most of the work, but >probably not knowledgeable enough to do all of it. > >I am starting tonight, with what little help the documentation gives, >and see where that lands me. I will probably try using emx 0.8h, as >I have heard that this is the best package for porting UNIX software >to OS/2. Any comments/suggestions? > >Thanks to anyone who replies. (e-mail or news is fine). > I wish you good luck and would like to hear when you make any progress. I started on the alpha 3.0 release with emx 0.8g and the Linux sources and compilation of the core went reasonably well. However compiling m3lib was not possible with my limited amount of time. I started on porting 3.1 but after trying for two hours I realized I would not have the time to continue. I used a PD-cshell port to execute the scripts, but have forgotten which. I also used gnumake as the make-program, but the newest OS/2-version (forgot the number) is very picky with spaces or tabs inside makefiles and chokes on spaces so I wined and got to more urgent other jobs. You will need ports of awk, sed, ar and other gnu/unix utilities to complete the job, but I think it will be possible to come up with a multi-threaded 32-bits compiler with a estimated working time of 2-3 weeks. ====================================================================== A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194) Energy Research Foundation, PO Box 1, 1755 ZG Petten, The Netherlands ======================================================================= 8 === Date: Tue, 3 May 1994 19:07:38 GMT From: mmeola@cahill (Vulcan) Subject: Re: Using the Xt interface... Bill Kalsow (kalsow@src.dec.com) wrote in comp.lang.modula3 on 3 May 1994 17:06 :45 GMT: >Try > IMPORT M3toC; > > Top := Xt.AppInitialize(AppC, M3toC.TtoS ("Xtimeclock"), ... > - Bill Kalsow Thank you Bill, that worked! However, now I get complaints during linking, something like "missing compiled interface Xt.io..." Any ideas? -- Matt Meola ======================================================================= 9 === Date: 4 May 1994 20:56:59 GMT From: stellanl@vaxkab.e.kth.se (Stellan Lagerstroem) Subject: Problem building M3-3.1 on ALPHA_OSF While building 3.1 on a DEC 3000-800 with OSF-1, during the building of libm3, the C compiler complains about the following piece of 'RTExceptionC.c': /* PROCEDURE CurrentFrame (VAR(*OUT*) f: Frame) * returns the frame that corresponds to its caller. */ void RTException__CurFrame (Frame *f) { f->lock = FrameLock; setjmp (& f->cxt); __exc_virtual_unwind (0, &(f->cxt)); f->pc = f->cxt.sc_pc; f->sp = f->cxt.sc_sp; /* <------- sc_sp UNDEFINED!!! */ if (f->lock != FrameLock) abort (); } because 'ctx' is a 'sigcontext' which is declared by /usr/include/signal.h as: struct sigcontext { #ifdef __alpha /* * Backward compatibility -- correlates with user space * notion of layout. */ long sc_onstack; /* sigstack state to restore */ long sc_mask; /* signal mask to restore */ #else int sc_onstack; /* sigstack state to restore */ int sc_mask; /* signal mask to restore */ #endif /* __alpha */ /* other architectures here */ #ifdef __alpha long sc_pc; /* pc at time of signal */ long sc_ps; /* psl to retore */ long sc_regs[32]; /* processor regs 0 to 31 */ long sc_ownedfp; /* fp has been used */ long sc_fpregs[32]; /* fp regs 0 to 31 */ unsigned long sc_fpcr; /* floating point control register */ unsigned long sc_fp_control; /* software fpcr */ /* * END OF REGION THAT MUST AGREE WITH jmp_buf REGION IN setjmp.h */ long sc_reserved1; /* reserved for user */ long sc_reserved2; /* reserved for user */ long sc_reserved3; /* reserved for user */ long sc_reserved4; /* reserved for user */ unsigned long sc_traparg_a0; /* a0 argument to trap on exception */ unsigned long sc_traparg_a1; /* a1 argument to trap on exception */ unsigned long sc_traparg_a2; /* a2 argument to trap on exception */ unsigned long sc_fp_trap_pc; /* imprecise pc */ unsigned long sc_fp_trigger_sum; /* Exception summary at trigger pc */ unsigned long sc_fp_trigger_inst; /* Instruction at trigger pc */ #endif /* __alpha */ }; which seems to lack any 'sc_sp'... I would be very grateful if anyone could tell me what to believe. Stellan --- Stellan Lagerstrom, VMS system manager, School of E.E. --- Royal Institute of Technology, Stockholm, Sweden ======================================================================= 10 === Date: 4 May 1994 22:09:19 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Problem building M3-3.1 on ALPHA_OSF In article <2q926r$m97@news.kth.se>, stellanl@vaxkab.e.kth.se (Stellan Lagerstr oem) writes: > > While building 3.1 on a DEC 3000-800 with OSF-1, > during the building of libm3, > the C compiler complains about the following piece of 'RTExceptionC.c': > f->sp = f->cxt.sc_sp; /* <------- sc_sp UNDEFINED!!! */ The fix is to include #define sc_sp sc_regs[30] near the top of RTExceptionC.c. We built and tested the Alpha code on an internal version of OSF. Apparently the version shipping to customers doesn't define sc_sp. - Bill Kalsow ======================================================================= 11 === Date: 7 May 1994 07:01:50 GMT From: jont@ocs.mq.edu.au (Jonathon Earnshaw TIDSWELL) Subject: Modula 3 and Windows NT ? I read the monthly posting in comp.compilers, only the entry for modula-3 seems not to have been updated since '92. [ Version 2.11 ] I believe the latest version is 3.1, and that there is a NT port (in progress?) for version 3.x. Can somebody provide more [authorative] detail ? thanks - JonT --- Jonathon Earnshaw Tidswell Postgraduate Student, Department of Computing School of Mathematics, Physics, Computing and Engineering Macquarie University, NSW Australia 2039 Phone: +61 2 850 9507 Fax: +61 2 850 9551 Internet: jont@mpce.mq.edu.au --- Research Fellow Microsoft Institute of Advanced Software Technology 65 Epping Road North Ryde NSW Australia 2062 Phone: +61 2 870 2776 Fax: +61 2 870 2255 Internet: t-jont@microsoft.com --- Disclaimer: I think my thoughts are my own, and I believe my writings are too. "These are my opinions, others may have similar ones, but these are MINE." ======================================================================= 12 === Date: 09 May 1994 23:27:35 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: Non-deterministic Error Conditions? I was distrurbed to discover that the SRC implementation of Modula-3 doesn't convert checked runtime errors to exceptions, but programs that generate runtime errors aren't correct anyway... But what happens when the heap is exhausted? In ANSI C, malloc() may return NULL, indicating that there's no more memory to be malloc'd (at least temporarily). I didn't see any corresponding error/exception in SPwM3 -- NEW() seems to draw from a limitless source of virtual memory. But we all know that eventually, memory runs out. I gather that SRC Modula-3 programs crash at that point. Hmmm... Suppose I wanted to write a mission-critical application: how can I prevent NEW() from crashing? That is, how can I determine, before calling NEW(), whether it will succeed? If the answer is "you can't," then how does one write a correct Modula-3 program that uses NEW()? (i.e. one that can be proved to terminate with correct results) I wonder if any of the other checked runtime errors are similarly non-deterministic. Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html ======================================================================= 13 === Date: 9 May 1994 18:07:10 GMT From: stellanl@vaxkab.e.kth.se (Stellan Lagerstroem) Subject: Re: Problem building M3-3.1 on ALPHA_OSF 1.3B (part 2) Ok, now I have got the compiler running, compiling small programs etc. Great. However, programs in games/ and trestle/tutorial/ compile nicely, BUT when run crash immediately with "segmentation fault" in malloc... We have seen this before on programs that linked statically with X, so I tried redoing the link step and removing the -L/usr/lib before the X librarie s which made it work. Is there a good place to make m3build do the link this way? Emptying "import_X11R4()" in boot-ALPHA_OSF/m3build/templates/ALPHA_OSF does not work... Stellan -- --- Stellan Lagerstrom, VMS system manager, School of E.E. --- Royal Institute of Technology, Stockholm, Sweden ======================================================================= 14 === Date: Mon, 9 May 1994 19:22:11 PDT From: janssen@parc.xerox.com (Bill Janssen) Subject: Re: Non-deterministic Error Conditions? I'd suggest that you look at src/libm3/src/runtime/common/RTMisc.m3, and decide if what that code does with `fatal' errors (including CRE's), is really what you need. You might more specifically also look at src/libm3/src/runtime/common/RTAllocator.m3. Bill ======================================================================= 15 === Date: 10 May 1994 00:41:01 GMT From: larryr@slapshot.pa.dec.com (Larry Rau (Migration Software)) Subject: Re: Problem building M3-3.1 on ALPHA_OSF in DEC OSF/1 v2.0 the header file signal.h now includes defines for sc_sp ............larry ======================================================================= 16 === Date: 10 May 1994 23:23:56 +1000 From: richard@cs.anu.edu.au (Richard Walker) Subject: Shared libs on SPARC again Hi again. Well, after a break of two years, I'm working with Modula-3 again. Would someone please let me know what I need to do to get shared libraries working under SunOS 4.1.3 in Modula-3 release 3.1? (I'm presuming that it's a change to the SPARC m3build template.) Richard. -- Richard Walker richard@cs.anu.edu.au Department of Computer Science Aust: (06) 249 5689 The Australian National University Intl: +61 6 249 5689 Canberra, ACT 0200, Australia Fax: +61 6 249 0010 ======================================================================= 17 === Date: 10 May 94 23:17:29 From: fn00@gte.com (Farshad Nayeri) Subject: Re: Shared libs on SPARC again In article <2qo1tcINNfh6@barnard.anu.edu.au> richard@cs.anu.edu.au (Richard Wal ker) writes: Would someone please let me know what I need to do to get shared libraries working under SunOS 4.1.3 in Modula-3 release 3.1? See "file://ftp.gte.com/pub/m3/m3-sparc.html", the SPARC release note for Modula-3 3.1 as a good start. Send corrections or suggestions to m3-sparc@gte.com. Thanks, --farshad -- /// | {@,@} | (...) Farshad Nayeri | I ran out of neat quotes. " " nayeri@gte.com | ======================================================================= 18 === Date: Wed, 11 May 1994 15:03:42 GMT From: kramer@inf.fu-berlin.de (Markus) Subject: [request] writing a m3makefile-generator I started with Modula-3 to find out if it could be an interesting language to introduce in university. So I wrote my first m3makefile. Now I wonder if someone has written a parser who is capable to get all what is neccessary from the m3-source files. Having to repeat to the linker what is written down makes a bad impression. Markus ======================================================================= 19 === Date: 11 May 1994 18:52:35 GMT From: qs101@pelican.cl.cam.ac.uk (Quentin Stafford-Fraser) Subject: Any useful obliq add-ons? Obliq is great fun, and as I started writing some extensions for it, I asked myself whether anybody else already had useful Obliq add-ons they could make available. I didn't get much of an answwer, so I thought I would ask you... :-) Quentin ---------------------------------------------------------------------- Quentin Stafford-Fraser Cambridge University Computer Lab Rank Xerox Cambridge EuroPARC qs101@cl.cam.ac.uk fraser@europarc.xerox.com Tel: +44 223 334411 Tel: +44 223 341521 Fax: +44 223 334679 Fax: +44 223 341510 http://pelican.cl.cam.ac.uk/people/qs101/me.html ---------------------------------------------------------------------- -- ---------------------------------------------------------------------- Quentin Stafford-Fraser Cambridge University Computer Lab Rank Xerox Cambridge EuroPARC ======================================================================= 20 === Date: Wed, 11 May 1994 20:54:32 GMT From: bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster) Subject: Modula-3 port Hi all, I posted a short while ago regarding attempting an OS/2 2.x port of SRC Modula-3, and got a number of replies. I have come to several conclusions: 1) the hendrik... address in the porting list is not reachable from where I live. I presume his involvement is dead. 2) SRC is just about to come out with version 3.2 of Modula-3, so starting a 3.1 port now would be a waste. Therefore, I am going to wait for that to happen first. 3) The port is non-trivial, and is going to take a lot more time and effort than I had first imagined. I am going to get the Linux version first, and then when I am familiar with that, try the OS/2 port. 4) I can give no firm dates on this project, due to other commitments. If anyone is willing to help, that would be wonderful. If anyone is unsatisfied at the pace of the port, they are welcome to take it over. I don't particularly want to do the port, I just want it done :) 5) For lack of a better name to put on the list, please put mine on. I can't find anyone else who is willing to take it on. 6) I can't promise I'll be able to do it, but I get good marks in school, so I can't be completely hopeless. I will give it my best shot. If anyone has any comments, helpful hints, or anything else, please feel free to mail me. I won't be lifting a finger until 3.2, though. -- ------------------------------------------------------------------- Carsten Whimster --- EDM/2 Associate Editor bcrwhims@uwaterloo.ca --- EDM/2 Book Review columnist --- TEAM-OS/2 ======================================================================= 21 === Date: 12 May 1994 18:02:36 GMT From: siva@csgrad.cs.vt.edu (Siva Challa) Subject: ** CFP: OOPSLA'94 Workshop on Multi-Language Object Models ** OOPSLA94 Workshop Announcement and Call for Position Papers: --------------------------------------------------------------------- Workshop Name: Multi-Language Object Models Workshop Overview: The purpose of this workshop is to bring together experts from industry and academia who are using object-oriented techniques to achieve interoperability among application components that may be implemented in different programming languages, perhaps distributed across heterogeneous architectures. This workshop is motivated by the need for an open, but integrated, distributed computing environment and the desire for more effective reuse of software components implemented in different programming languages. Some key problems are the level of object abstraction and the granularity of run-time integration. Goals and Focus: This workshop focuses on object models that incorporate more features than the current "least common denominator" models and remain interoperable among different object-oriented languages. Of interest are both the techniques (e.g., meta-object protocols, reflection, common run-time environment) for achieving these models as well as specific models that embody a richer set of features (e.g., SOM, DOM). Some of the important questions to be addressed are: How can an extensible object model be realized? What are the performance costs of extensibility? What degree of interoperability is sacrificied by inconsistent extensions? Can a single framework integrate languages from different paradigms? Is an approach that is limited to only a few languages too narrow for the needs of real applications? Participants should be prepared to discuss: (1) how a diverse set of features can be supported in the model, and (2) how the aspects of scalability, debugging, fault-tolerance, performance, etc. are realized. Requirements for Attendance: Interested individuals are invited to submit a position paper limited to five (5) pages indicating their experience with the workshop theme with particular reference to above list of issues. It is particularly encouraged that the position paper include the statement of specific topics or questions that should be addressed at the workshop. Each position paper should be sent via email in Postscript form or mailed hardcopy to the addess listed below. Each position paper should provide complete contact information, including email address, phone number, and fax number for the primary author. Submission must be received no later than August 15, 1994. Interested individuals are encouraged to send at the earliest possible time a brief email message to the organizers indicating their interest and giving a short description (keywords, title) of their position paper. Authors of selected papers may be asked to extend their papers for inclusion in a workshop proceedings to be published in a special-issue journal. Organizers: Dennis Kafura, Virginia Tech Greg Lavender, MCC Submissions: Dr. Dennis Kafura Department of Computer Science Virginia Tech Blacksburg, VA 24061-0106 Phone: +1.703.231.5568 Email: kafura@cs.vt.edu Fax: +1.703.231.6075 A World Wide Web page for the workshop can be found at 'http://actor.cs.vt.edu/whats-new.html' ======================================================================= 22 === Date: Fri, 13 May 1994 14:21:54 GMT From: bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster) Subject: Re: Modula-3 port In article , Simon Johnston wrote: >In article you wrote: >: Hi all, > >: I posted a short while ago regarding attempting an OS/2 2.x port of >: SRC Modula-3, and got a number of replies. I have come to several >: conclusions: >: 1) the hendrik... address in the porting list is not reachable from >: where I live. I presume his involvement is dead. >Probably - I never heard from him. > >: 2) SRC is just about to come out with version 3.2 of Modula-3, so >: starting a 3.1 port now would be a waste. Therefore, I am going to >: wait for that to happen first. >Good plan. > >: 3) The port is non-trivial, and is going to take a lot more time and >: effort than I had first imagined. I am going to get the Linux version >: first, and then when I am familiar with that, try the OS/2 port. >If you need ANY OS2 help, mail me we have 100+ developers here, all OS2 >development, the source to MS OS2 1.3, and so we can always try. We are >also a good (ready and willing) test site for anything you can offer us. Will do. >: 4) I can give no firm dates on this project, due to other commitments. >: If anyone is willing to help, that would be wonderful. If anyone is >: unsatisfied at the pace of the port, they are welcome to take it over. >: I don't particularly want to do the port, I just want it done :) >Fine, we do however need someone to lead the project and coordinate the >effort even if they don't do it. Looks like your hand is in the air !! I am more than willing to coordinate the effort. I just don't know if I have the technical know-how to do it alone. >: 5) For lack of a better name to put on the list, please put mine on. I >: can't find anyone else who is willing to take it on. >Ok. > >: 6) I can't promise I'll be able to do it, but I get good marks in >: school, so I can't be completely hopeless. I will give it my best >: shot. >Thats all anyone can ask, good luck, and remember theres lots of us out >here who want an OS2 version and have even less time. Were all looking to >you to save our souls from C ;-> :) :) :) I regularly get into discussions with people who like the freedom of C, and say that "if you know what you are doing, you don't need strong typing etc". I usually respond that if you know what you are doing, you don't need C, you can just use assembly code or machine code :) I have been looking for an alternative language for so long I don't care to try to remember. I had a brief fling with Ada, but Modula-3 looks like it. >: If anyone has any comments, helpful hints, or anything else, please >: feel free to mail me. I won't be lifting a finger until 3.2, though. >Good, lets me know when you start though. Will do. I'll post to the groups, and send mail directly to all those who have sent me notes. >: Carsten Whimster --- EDM/2 Associate Editor >whats EDM/2 ? Electronic Developer's Magazine for OS/2. You can find it at ftp.cdrom.com in /pub/os2/2_x/program/newsltr or something like that. >MODULE Sig; >FROM ICL IMPORT StdDisclaimer; >FROM Interests IMPORT Modula2, Modula3, Linux, OS2; > >BEGIN >(* ------------------------------------------------------------------------. >|Simon K. Johnston - Development Engineer |ICL Retail Systems | >|------------------------------------------------------|3/4 Willoughby Road| >|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | >|Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | >|Internal : 7261 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | >`------------------------------------------------------------------------ *) >END Sig. -- ------------------------------------------------------------------- Carsten Whimster --- EDM/2 Associate Editor bcrwhims@uwaterloo.ca --- EDM/2 Book Review columnist --- TEAM-OS/2 ======================================================================= 23 === Date: Fri, 13 May 1994 15:20:41 GMT From: mmeola@cahill.ecte.uswc.uswest.com (Matt Meola) Subject: Text.FromChars Has anyone had any difficulties with Text.FromChars? When I feed it a Ctypes.char_star, I get the message, "types are not assignable". Is there a way to convert a Ctypes.char_star into a TEXT? -- (********************************************************) (* Matt Meola, NRA Life Member, Militiaman, Libertarian *) (* "Gun control means using two hands." *) (********************************************************) ======================================================================= 24 === Date: 13 May 94 14:18:12 From: fn00@gte.com (Farshad Nayeri) Subject: Re: Text.FromChars In article mmeola@cahill.ect e.uswc.uswest.com (Matt Meola) writes: When I feed it a Ctypes.char_star, I get the message, "types are not assignable". That's because Text.FromChars requires an ARRAY OF CHAR argument. You are passing in Ctypes.char_star which (I believe) is a REF CHAR. References to characters and arrays of characters in Modula-3 are distinct types, unlike the way C treats them. Is there a way to convert a Ctypes.char_star into a TEXT? Try M3toC.StoT or CopyStoT. The M3toC would be useful if you are messing with C strings from Modula-3. Unless you are trying to connect up with some C code, it is probably a good idea not to use C strings from Modula-3. Good luck, --farshad -- /// | {@,@} | (...) Farshad Nayeri | I ran out of neat quotes. " " nayeri@gte.com | ======================================================================= 25 === Date: 13 May 1994 18:37:48 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Text.FromChars In article , Matt Meola wrote: > >Has anyone had any difficulties with Text.FromChars? When I feed it a >Ctypes.char_star, I get the message, "types are not assignable". That's because a Ctypes.char_star is not an ARRAY OF CHAR. It's an UNTRACED REF char (char being the subrange [-16_80 .. 16_7F] on my Linux machine). > >Is there a way to convert a Ctypes.char_star into a TEXT? Yes. M3toC.StoT(a: char_star): TEXT - which may not copy the original string (a). M3ToC.CopyStoT(a : char_star): TEXT - which is guaranteed to copy a. From a brief example (Uuio.read()ing a C string, then converting and outputting it), M3toC.StoT works fine. > > [blank lines deleted] >(********************************************************) >(* Matt Meola, NRA Life Member, Militiaman, Libertarian *) >(* "Gun control means using two hands." *) >(********************************************************) ======================================================================= 26 === Date: 14 May 1994 07:47:12 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: Re: Non-deterministic Error Conditions? In article janssen@parc.xerox.com (B ill Janssen) writes: Newsgroups: comp.lang.modula3 From: janssen@parc.xerox.com (Bill Janssen) Date: Mon, 9 May 1994 19:22:11 PDT I'd suggest that you look at src/libm3/src/runtime/common/RTMisc.m3, and decide if what that code does with `fatal' errors (including CRE's), is really what you need. You might more specifically also look at src/libm3/src/runtime/common/RTAllocator.m3. 1) I'm not familiar with these filenames... they are from some M3 implementation distribution? I don't have M3 installed or anything like that. I just read the book... 2) This seems to be a probem with the language definition, not the runtime interfaces. The whole attraction to the language, to me, is the assistance it gives in writing correct programs. But as far as I can tell, no program that uses NEW() is guaranteed to complete. Or perhaps it's the other way around ... perhaps the language definition says that such programs are guaranteed to complete, but it's impossible to correctly implement the language definition! Anyway... I'd hate to think that a program has to "peek under the covers" and twiddle with the runtime system... but perhaps in pracitce it's not so bad. And perhaps evenutally the interface to do this will become a standard interface. Dan -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html ======================================================================= 27 === Date: 12 May 1994 20:34:13 GMT From: siva@vtaix.cc.vt.edu (Siva Challa) Subject: ** CFP: OOPSLA'94 Workshop on Multi-Language Object Models ** OOPSLA'94 Workshop Announcement and Call for Position Papers: --------------------------------------------------------------------- Workshop Name: Multi-Language Object Models Workshop Overview: The purpose of this workshop is to bring together experts from industry and academia who are using object-oriented techniques to achieve interoperability among application components that may be implemented in different programming languages, perhaps distributed across heterogeneous architectures. This workshop is motivated by the need for an open, but integrated, distributed computing environment and the desire for more effective reuse of software components implemented in different programming languages. Some key problems are the level of object abstraction and the granularity of run-time integration. Goals and Focus: This workshop focuses on object models that incorporate more features than the current "least common denominator" models and remain interoperable among different object-oriented languages. Of interest are both the techniques (e.g., meta-object protocols, reflection, common run-time environment) for achieving these models as well as specific models that embody a richer set of features (e.g., SOM, DOM). Some of the important questions to be addressed are: How can an extensible object model be realized? What are the performance costs of extensibility? What degree of interoperability is sacrificied by inconsistent extensions? Can a single framework integrate languages from different paradigms? Is an approach that is limited to only a few languages too narrow for the needs of real applications? Participants should be prepared to discuss: (1) how a diverse set of features can be supported in the model, and (2) how the aspects of scalability, debugging, fault-tolerance, performance, etc. are realized. Requirements for Attendance: Interested individuals are invited to submit a position paper limited to five (5) pages indicating their experience with the workshop theme with particular reference to above list of issues. It is particularly encouraged that the position paper include the statement of specific topics or questions that should be addressed at the workshop. Each position paper should be sent via email in Postscript form or mailed hardcopy to the addess listed below. Each position paper should provide complete contact information, including email address, phone number, and fax number for the primary author. Submission must be received no later than August 15, 1994. Interested individuals are encouraged to send at the earliest possible time a brief email message to the organizers indicating their interest and giving a short description (keywords, title) of their position paper. Authors of selected papers may be asked to extend their papers for inclusion in a workshop proceedings to be published in a special-issue journal. Organizers: Dennis Kafura, Virginia Tech Greg Lavender, MCC Submissions: Dr. Dennis Kafura Department of Computer Science Virginia Tech Blacksburg, VA 24061-0106 Phone: +1.703.231.5568 Email: kafura@cs.vt.edu Fax: +1.703.231.6075 A World Wide Web page for the workshop can be found at 'http://actor.cs.vt.edu/whats-new.html' ======================================================================= 28 === Date: Mon, 16 May 1994 22:00:00 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: [request] writing a m3makefile-generator Now I wonder if someone has written a parser who is capable to get all what is neccessary from the m3-source files. Having to repeat to the linker what is written down makes a bad impression. There is a bit more information. You may not want to include all the files in the directory to build the program, you can specify if the interfaces should be exported or not (Interface vs interface...), say if you are building a library or a program... Mick Jordan i think had something to generate the old m3makefiles. Of course the most difficult part is to find automatically the needed libraries. Otherwise you could get most of the work done with: ls *.i3 | sed -e 's/^/interface("/' -e 's/$/")/' >>m3makefile ls *.m3 | sed -e 's/^/implementation("/' -e 's/$/")/' >>m3makefile But i agree that an automatic tool would be cute even though in practice very very little time is spent building m3makefiles. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 29 === Date: 17 May 94 15:58:32 From: rbnix@damabus.zer.z-netz.rechner.amiga.software (Reiner B. Nix) Subject: no close construct in Modula-3 I'm wondering about a large lack in Modula-3. Using several independent modules to construct a whole program you can initialize every module in its statement sequence of the module body. When executing a program the statement sequence of all other modules is done before the statement sequence of the main module. But on other side there is no general way to specify a common termination of these modules. Termination statements of modules should preserve the posibility to finish the work and close needed ressources. For example: (using SCR Modula-3, version 3.1) it is explicit neccessary to use Wr.Flush (Stdio.stdout) to see the last line of output of a program. Thinking on more complicated data structures it is not very usefull to call termination procedures from used modules because imported modules should act stand alone. As a result of this it should be possible to specify both: an initialization and a termination statement sequence for modules. May be like this: (* Module A *) BEGIN Init (); CLOSE Exit (); END A. While statements between BEGIN and CLOSE are init statements and are executed before the statement sequence of the main module the statements between CLOSE and END are termination statements and are executed after normal or abnormal execution of the main statement sequence. Now a module can finish its work and free all ressources independent from every unknown importer of this module. -- Reiner B. Nix rbnix@pool.informatik.rwth-aachen.de ---------------------------------------------------------------------- Nominiert fuer den Umweltpreis: das Fensehen, der groesste Recyclingunternehmen der Welt ======================================================================= 30 === Date: Tue, 17 May 1994 04:45:40 GMT From: m4359@abc.se (Morgan Lantz) Subject: modula3 for pc I Wounder if there are any modula3 that i can use on my pc,under windows och dos. All regars Morgan Lantz. ======================================================================= 31 === Date: Wed, 18 May 1994 19:46:29 +0200 (MET DST) From: thomas.tensi@fi.sdm.de (Dr. Thomas Tensi) Subject: Re: no close construct in Modula-3 Hallo Reiner, you ask about the lack of termination actions in Modula-3. > > > I'm wondering about a large lack in Modula-3. > > Using several independent modules to construct a whole program you can > initialize every module in its statement sequence of the module body. > When executing a program the statement sequence of all other modules > is done before the statement sequence of the main module. > > But on other side there is no general way to specify a common > termination of these modules. Termination statements of modules should > preserve the posibility to finish the work and close needed > ressources. > > [...] > > (* Module A *) > BEGIN > Init (); > CLOSE > Exit (); > END A. > If I remember correctly that kind of idea was initially in the first concepts for Oberon. Wirth and Gutknecht dropped it for a simple reason: With a little runtime system support you can do it within the language itself. Just assume that the runtime system offers a procedure 'RegisterTermination' with signature (READONLY proc : PROCEDURE() ). A module can register its own termination procedure there. Hence your example looks like this: MODULE A; IMPORT RuntimeSystem; ... BEGIN Init(); RuntimeSystem.RegisterTermination(Exit); END A. The runtime system module maintains a stack of procedures to call and pop whenever something goes completely wrong. No big deal. Note that this idea does not work for initialisation: A module cannot gain control unless some part of it is called from outside. Hence you do not have to add anything to the language to handle completion apart from a library module encapsulating the runtime system. Thomas ------------------------------------------------------------------------- Dr. Thomas Tensi |s |d &|m | software design & management GmbH | | | | Thomas-Dehler-Str. 18 thomas.tensi@sdm.de | | | | 81737 M"unchen, Germany. ======================================================================= 32 === Date: Thu, 19 May 94 11:52:30 -0700 From: mhb@src.dec.com ("Marc H. Brown") Subject: Two FormsVBT Q+A's FormsVBT Question: Setting the fount for the TextEdit with a line: (Font (Family "lucida") (PointSize 180)) doesn't work. It seems to be ignored. However: (Font "-*-lucida-medium-r-*-*-18-*-*-*-*-*-*") works fine. This contrasts with LabelFont, which works with both styles. Answer: The problem here is probably that there is no match for Family=lucida and all other field equal to their defaults for Font. I don't recall offhand what the defaults are, but they probably are not 'medium', 'r', '18', and a slew of asterisks. The defaults for LabelFont are different. If you have some good ideas about the issue of specifying fonts, let me know. FormsVBT Question: I tried to make two separate views onto the TextEdit by using a Viewport: (Viewport (TextEdit NoScrollbar %buffer)) but this leaves the TextEdit inaccessible. Putting a NoScroll in the Viewport instead of a NoScrollbar in the TextEdit makes things worse. Putting a Shape round the TextEdit helps a bit, but it doesn't scroll properly. Is this a bug or am I just missing the point about how Viewport and TextEdit should be used together? Answer: There are many bugs in Viewport and in TextEdit (I fear), but I think you are missing the point here. A Viewport will make its child think it has its minimum requested shape. If the domain of the Viewport is smaller, then the Viewport puts scrollbars to scroll the child. The min shape of a TextEdit is very small. Thus, to get a Viewport to put on scrollbars, you should do something like (Viewport (Shape (Height 2000)(Width 500) (TextEdit NoScrollbar))) If you want the Viewport's scrollbar to be tightly coupled with the TextEdit, you'll need to write some M3 code that will tell reset the Shape of the TextEdit each time it grows. Keep those letters and cards comin'! ======================================================================= 33 === Date: 20 May 94 01:13:52 From: rundle@degas.jrc.flinders.edu.au (Richard Rundle) Subject: Files and Pipes I am writing a modula 3 program which needs to read information from one named pipe and write to another named pipe. If no information is in the pipe to read from then the program should block. My problem is that when I try to open the pipe(s) my program hangs. Relevant code is as follows: IMPORT Params; (* For getting command line arguments *) IMPORT FileStream, Rd, Wr; (* For operations on files *) IMPORT Spew; (* outputs stuff to screen *) VAR inputfile : Rd.T; (* File to read from *) outputfile : Wr.T; (* File to write to *) TimeLimit : TEXT; (* Holds move time limit *) spew : BOOLEAN := TRUE; (* Controls logging to screen *) PROCEDURE Initialise() = VAR input, output : TEXT; BEGIN Spew.spew("Gomoku Started.\n",spew); TimeLimit := Params.Get(1); input := Params.Get(2); output := Params.Get(3); Spew.spew("Time Limit = " & TimeLimit & "\nReading From " & input & " Writing To " & output & "\n",spew); inputfile := FileStream.OpenRead(input); (******* program seems to hang here, ie following line is not displayed *) Spew.spew("Opened pipe for writing: " & output & "\n",spew); outputfile := FileStream.OpenWrite(output); Spew.spew("Opened pipe for reading: " & input & "\n",spew); ... Any words of advice / answers would be much appreciated. Thanks - Richard ======================================================================= 34 === Date: 20 May 1994 22:13:41 GMT From: barton@jhm2.eche.ualberta.ca (Bob Barton) Subject: library reference manual? Has anyone generated a reference manual for the modula3 library interfaces? I know that m3totex is available but if there is someplace that has produced the reference manual in postscript format it would be useful to have access to it. I have tried using m3totex but seem to have some incompatibilities with the version of tex I have here. --,,,, | D | R.L. Barton Department of Chemical Engineering | A | Tel (403) 492-5160 University of Alberta | C | Fax (403) 492-2881 Edmonton, Alberta, Canada T6G 2G6 | S | Internet barton@chopin.eche.ualberta.ca --'''' ======================================================================= 35 === Date: 21 May 1994 01:45:28 GMT From: janssen@holmes.PARC.Xerox.Com (Bill Janssen) Subject: ILU 1.6.4 available Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU) system is now available for general use. WHAT'S ILU? ILU (pronounced eye'-loo) is a system that promotes software interoperability via interfaces. Interfaces between what? Whatever units of program structure are desired; we call them by the generic term "modules". They could be parts of one process, all written in the same language; they could be parts written in different languages, sharing runtime support in one memory image; they could be parts running in different memory images on different machines (on different sides of the planet). A module could even be a distributed system implemented by many programs on many machines. Calls across ILU interfaces involve only as much mechanism as necessary for the calling and called modules to interact. In particular, when the two modules are in the same memory image and use the same data representations, the calls are direct local procedure calls -- no stubs or other RPC mechanisms are involved. ILU modules are known by their interfaces. A module interface is specified once in ILU's object-oriented Interface Specification Language (called, simply, ISL). For each of the particular programming languages supported by ILU (currently Common Lisp, ANSI C, C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works), a version of the interface in that particular programming language can be generated. The ILU kernel library provides services which may be used by the language-specific interface to overcome intermodule language or address space differences. Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF DCE RPC, have strong notions of interfaces. ILU allows binding to such services provided by such systems if their interfaces can be described in ISL. ISL has been designed to facilitate such description (currently, only for ONC RPC; Courier and DCE RPC are in progress). The binding to such RPC services is done in such a way as to be indistinguishable from binding to other ILU modules. In fact, properly constructed ILU modules can appear as native RPC services, and can be manipulated by non-ILU tools designed to work with those RPC services. Similarly, the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) defines modules with explicit interfaces. ILU allows modules that can be described with a safe subset of OMG CORBA IDL to be used as ILU modules, as well, though the ILU object model is not quite the same as the OMG CORBA object model. In fact, people wishing to experiment with CORBA may find ILU a useful experimental platform, as it does allow module specification with OMG IDL, and does generate ANSI C support as specified in Draft 1.2 of the OMG CORBA specification. As the OMG specification for a C++ mapping is agreed upon, we intend to provide that mapping for our C++ support, as well. Release 1.6.4 is intended as a beta release. Major efficiency improvements and some usability improvements are planned for the next release. It has been tested lightly on SunOS 4.1.3, Sun's Solaris 2.3, and SGI's IRIX 5.2. It is designed to be highly portable, and a port to the Macintosh has been done (but is not included in this release). GETTING THE RELEASE The release is only available via FTP from the PARC ftp server. Perhaps the simplest way is to go through our World Wide Web home page, ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html. It has links to everything else, and may help answer any questions you might have. The release notes are available as an HTML document, ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/announce.html. The full source code, including documentation, is available as a 3 MB compressed tar file as ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-1.6.4.tar.Z The 1.6.4 ILU manual is also available separately, either in Postscript (231 KB) as ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-manual-1.6.4.ps.Z or via World Wide Web at ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_toc.html. CONTRIBUTORS Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson, Mike Spreitzer, Mark Stefik, Farrell Wymore COPYRIGHT RESTRICTIONS ILU is Copyright (c) 1991, 1992, 1993, 1994 Xerox Corporation. All Rights Reserved. Unlimited use, reproduction, and distribution of this software is permitted. Any copy of this software must include both the above copyright notice of Xerox Corporation and this paragraph. Any distribution of this software must comply with all applicable United States export control laws. This software is made available AS IS, and XEROX CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF XEROX CORPORATION IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. -- Bill Janssen (415) 812-4763 FAX: (415) 812-4777 Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304 URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html ======================================================================= 36 === Date: 22 May 1994 01:39:07 GMT From: najork@src.dec.com (Marc Najork) Subject: Re: library reference manual? Bob Barton writes: Has anyone generated a reference manual for the modula3 library interfaces? I know that m3totex is available but if there is someplace that has produce d the reference manual in postscript format it would be useful to have access to it. I have tried using m3totex but seem to have some incompatibilities w ith the version of tex I have here. SRC Research Report 113 ("Some Useful Modula-3 Interfaces") contains a description of the base libraries shipped with Modula-3 version 3.1. This report can be obtained - via anonymous ftp: gatekeeper.dec.com:pub/DEC/SRC/research-reports/SRC-113.ps.Z - via Mosaic: http://www.research.digital.com/SRC/publications/src-rr.html Here is the abstract: December 25, 1993 AVAILABLE ELECTRONICALLY "Some Useful Modula-3 Interfaces" Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson 103 pages This manual describes a collection of interfaces defining abstractions that SRC's programmers have found useful over a number of years of experience with Modula-3 and its precursors. We hope the interfaces will be useful as a "starter kit" of abstractions, and as a model for designing and specifying abstractions in Modula-3. ======================================================================= 37 === Date: 23 May 94 01:20:12 From: vixie@vix.com (Paul A Vixie) Subject: Re: Files and Pipes > I am writing a modula 3 program which needs to read information from one > named pipe and write to another named pipe. If no information is in the > pipe to read from then the program should block. > > My problem is that when I try to open the pipe(s) my program hangs. Do both pipes have other processes on them? That is, does the one you are going to read from have someone else writing on it at the time of your open? Does the one you want to write on have someone else blocked on read when you open it for writing? Named pipes block the first opening process until a second one gets it open. -- Paul Vixie Redwood City, CA decwrl!vixie!paul ======================================================================= 38 === Date: Mon, 23 May 1994 13:51:36 GMT From: mmeola@cahill.ecte.uswc.uswest.com (Matt Meola) Subject: Is version 3.[12] out yet? I was wondering, what's the status of version 3.1? Last I heard, 3.1 was "stable" on Linux and DEC platforms, others were being worked on. How's this going? Inquiring minds want to know! :) -- (********************************************************) (* Matt Meola mmeola@cahill.ecte.uswc.uswest.com *) (* NRA Life Member, Militiaman, Libertarian *) (* Gun control means using two hands. *) (********************************************************) ======================================================================= 39 === Date: 24 May 1994 02:19:47 -0400 From: keogh@anshar.shadow.net (Matt Keogh) Subject: Skinny Dip \[[[[[\ [[ \[[ ^[[] \[[[[[\ \[[[[[\ [[ [[ [[[[[[\ ^[[] [[[[[[\ [[\\\\ [[\[[_ [[ [[ [[ [[ [[ [[\ \[[ [[ [[ [[ [[\\\[[ ____[[ [[_[[\ [[ [[ [[ [[ [[ _[[[_ [[ [[ [[ [[____ _[[[[[_ [[ _[[ ^[[] [[ [[ [[ [[ ^[] [[[[[[_ ^[[] [[ *** THIGH CREAM *** The ORIGINAL thigh cream, as seen on national TV This is the NEW, SUPER STRENGTH formula Accept none of the immitation creams YOU'RE WORTH THE BEST!!! Now only $29.95 per bottle which INCLUDES shipping, handling and tax U.S. orders only, please. Rush check or money order to: U.S. Health Inc. 18524 NW 67th Ave. #311 Miami, Florida 33015 ======================================================================= 40 === Date: 25 May 1994 15:59:35 GMT From: ahrens@informatik.hu-berlin.de (Klaus Ahrens) Subject: m3 (3.1) on SunOS 4.1.3 After building m3 (rel. 3.1) by m3boot without serious problems on a SPARC10 with SunOS 4.1.3 I get executables m3 and m3c which seem to loop forever doing nothing but wasting 80% cpu time ! Any ideas or suggestions ? Please reply by email directly. Thanks, Klaus Ahrens --- ____________________________________________________________________ /| | | || Dr. K. Ahrens | Phone +49-030-20181 238 | || FB Informatik | Fax +49-030-20181 234 | || Humboldt-Universitaet | email ahrens@informatik.hu-berlin.de | || +----------------------------------------+ || P.O.Box 1297 | | || 10099 Berlin | | || Germany | | ||__________________________|________________________________________| |/__________________________/________________________________________/ ======================================================================= 41 === Date: Wed, 25 May 1994 19:31:43 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Revised Modula-3 FAQ The revised FAQ appears below. I have received quite a bit of material lately; if something you sent me is missing or not quoted adequately, let me know. The FAQ will be submitted to the moderated comp.answers and news.answers newsgroups shortly. If you have a rather long entry in the FAQ that could be trimmed down, it would be appreciated; sometimes rewording someone else's text is difficult. Postscript and HTML (World Wide Web) versions of the FAQ will be made available shortly as well. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 42 === Date: Wed, 25 May 1994 19:33:46 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Modula-3 FAQ Modula-3 FAQ Michel Dagenais, dagenais@vlsi.polymtl.ca v2.0, 25 May 1994 This document contains references to most of the material available on the Modula-3 language, compiler, tools and libraries. It should answer all the most frequently asked questions about Modula-3. The FAQ was originally written by Eric Muller. Send corrections, suggestions, additions to the current maintainer, Michel Dagenais dage- nais@vlsi.polymtl.ca. 1. What is new? A single source file is now used to generate the ASCII, Postscript and World Wide Web versions of the FAQ. The How to obtain pre-compiled binaries, Modula-3 for teaching, Modula-3 in industry, Work in progress, wish list, and the Who's who sections are new. The language definition and documentation for most of the libraries is now available on the World Wide Web (thus accessible through Mosaic) Modula-3 Home 2. The language 2.1. What is Modula-3? Modula-3 is a systems programming language that descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, they studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. They found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. 2.2. Is Modula-3 a superset of Modula-2? No; valid Modula-2 programs are not valid Modula-3 programs. However, there is a tool to help convert Modula-2 programs to Modula-3. 3. The documentation 3.1. Where can I get a description of Modula-3? The language definition and most electronically available Modula-3 information can be accessed on: Modula-3 Home The definition of Modula-3 is contained in: o System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 also known as SPwM3. Here is the table of contents: 1. Introduction 2. Language Definition 3. Standard Interfaces 4. An Introduction to Programming with Threads 5. Thread Synchronization: A Formal Specification 6. I/O Streams: Abstract Types, Real Programs 7. Trestle Window System Tutorial 8. How the Language Got its Spots Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27, Number 8, August 1992, pp 15-42. Sam Harbison has written a more tutorial book about Modula3: o Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 The table of contents is as follows: 1. Introduction 2. Declarations 3. Statements 4. Basic Types 5. Structured Types 6. Procedures 7. Exceptions 8. Interfaces and Modules 9. Generics 10. Dynamic Programming 11. Objects 12. Threads 13. Low-Level Programming 14. Programming Conventions 15. SRC Modula-3 16. Modula-3 Syntax 17. Answers to Selected Exercises The errata sheet is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/errata. Errata If you cannot find these books at your favorite bookstore, here are bookstores connected to the net known to carry them: UCI carries both books: UCI Bookstore While Roswell is known to at least carry the language definition (SPwM3): Roswell Electronic Computer Bookstore Roswell Bookstore 3.2. Where can I get other information on Modula-3? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. If you do not have access to Usenet, there is a relay mailing list; send a message to m3-request@src.dec.com to be added to it. Comp.lan g.modula3 archive There are a couple high-level overview articles available: o "Modula-3", Sam Harbison, Byte, Vol. 15, No. 12, November 1990, pp 385+. o "Safe Programming with Modula-3", Sam Harbison, Dr. Dobb's Journal, Vol. 17, No. 10, October 1992, pp 88+. A description of the Modula-3 type system is in o "The Modula-3 Type System", Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages (POPL), Austin Texas, January 11-13 1989, pp 202-212. The Modula-3 treatment of floating-point values is described in o "The Design of Floating-Point Data Types", David Goldberg, ACM Letters on Programming Languages and Systems (LOPLAS), June 1992, Vol 1, no.2, pp 138-151 The core library interfaces are described and indexed in o "Some Useful Modula-3 Interfaces", Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson, SRC Research Report 113. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research- reports/SRC-113.ps.Z Libm3 o "Pickles: a system for automatic serialization of typed values", Andrew Birrell, Greg Nelson, Susan Owicki, Edward Wobber, Systems Research Center, Digital Equipment Corp., in preparation. The Trestle window system toolkit, higher-level FormsVBT toolkit, and Zeus animation system available with Modula-3, are documented in the following reports: o "Trestle Reference Manual", Mark S. Manasse and Greg Nelson, SRC Research Report 68, December 1991. o "Trestle Tutorial", Mark S. Manasse and Greg Nelson, SRC Research Report 69, May 1, 1992. o "VBTkit Reference Manual: A toolkit for Trestle", edited by Marc H. Brown and James R. Meehan. (soon to be a SRC Research Report) A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z. VBTKit o "The FormsVBT Reference Manual", Marc H. Brown and James R. Meehan, (soon to be a SRC Research Report). A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z. VBTKit library VBTKit applications o "Zeus: A System for Algorithm Animation and Multi-View Editing", Marc H. Brown, SRC Research Report 75, February 28, 1992. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-075*.ps.Z. Zeus o "Color and Sound in Algorithm Animation", Marc H. Brown and John Hershberger, SRC Research Report 76a, August 30, 1991. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research- reports/SRC-076a*.ps.Z. Color and Sound o "The 1992 SRC Algorithm Animation Festival", Marc H. Brown, SRC Research Report 98, March 27, 1993. Available via anonymous ftp from gatekeeper.dec.com in pub/DEC/SRC/research- reports/SRC-098*.ps.Z. Animation Festival Network objects are described in the following reports: o "Network Objects", Andrew Birrell, Greg Nelson, Susan Owicki, and Edward Wobber, SRC Research Report 115, February 28, 1994. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-115*.ps.Z. Network Objects o "Distributed garbage collection for Network Objects", Andrew Birrell, David Evers, Greg Nelson, Susan Owicki, and Edward Wobber, SRC Research Report 116, December 1993. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research- reports/SRC-116*.ps.Z. Distributed GC While the Obliq embeddable interpreter is documented in: o "Obliq: A lightweight language for network objects", Luca Cardelli, User's Manual, Systems Research Center, Digital Equipment Corp., 1994. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/Obliq.ps. Obliq Hardcopy versions of these reports can be ordered by e-mail; send your request including a postal mail address to src-reports@src.dec.com. Sedgewick's classic text on computer algorithms is presented in Modula-3 in: o Alogorithms in Modula-3 Robert Sedgewick Addison-Wesley, 1993 ISBN 0-201-53351-0 4. The implementations 4.1. Where can I get an implementation? Two implementations are available, SRC Modula-3 and a PC version of it (m3pc). As far as we know, implementations are not available for VMS, Macintosh. 4.2. What is SRC Modula-3? SRC Modula-3 was built by the DEC Systems Research Center and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3. The most recent version, release 3.1, is a major release and introduces a native compiler, Modula-3 aware debugger, revised libraries (libm3), Network Objects and the Obliq embeddable language. It runs fine on the DS3100 architecture and with a few patches on the LINUX and SPARC architectures. The previous version is release 2.11. SRC-Modula-3 < /A> The compiler implements the language defined in SPwM3. There are versions for the following machines: o AIX386 IBM PC running AIX/PS2, o AOSF DEC Alpha AXP running OSF/1 o AP3000 Apollo DN4500 running Domain/OS o ARM Acorn R260 running RISC iX 1.21 o DS3100 DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 o HP300 HP 9000/300 running HP-UX 8.0 o HPPA HP 700/800 running HP-UX 8.0 o IBMR2 IBM R6000 running AIX 3.1, o IBMRT IBM RT running IBM/4.3, o LINUX Intel 386 running LINUX o NEXT NeXT running ?? o NT386 Intel 386 running Windows NT o OKI Okidata 7300 (i860) running UNIX SVR4.0 o SEQUENT Sequent computers running ?? o SOL2 Sparc running Solaris 2.x o SPARC SPARCstation running SunOS 4.1.x o SUN3 SUN3 running SunOS o SUN386 Sun 386i running SunOS 4.0.1 o UMAX Encore Multimax running UMAX 4.3 (R4.1.1) o VAX VAX running Ultrix 3.1 The new native compiler is based on GCC and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. 4.3. What is m3pc? m3pc is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/m3pc. PC Modula-3 < /A> From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI) Subject: M3 pn PC The Modula-3 system ported by us on the PC and available on the gatekeeper, runs with MSDOS, gnu c compiler and djgpp memory manager (detailed description in the read me file). The first version was ported by Klaus Preschern. Carsten Weich rewrote the handling of long filenames for the second version. You may compile, link and run Modula-3 programs, without threads. From the library modules only those are tested which are used by the compiler. We are using the actual version for our beginners-course and we are working on "student-friendly" programming environments and a simple windowing graphic-library. From: carsten@post.ifi.uni-klu.ac.at (Carsten WEICH) Subject: New version of Modula-3/PC Date: 28 Jan 1994 13:25:28 GMT We have built a new version of Modula-3 running on a PC. You will need a PC: o 80486 or 80386 with floatingpoint-coprocessor, o at least 4 but preferable 8 MByte of RAM, o 20 MByte discspace free at least. You can run a modified Modula-3 version 2.09 without thread- support. Our version features: o support for Unix-like long filenames o automatic compilation (to substitute the lack of m3make) o library to access DOS-files and directories. We have built a little shell which translates the long filenames you type in into DOS-filenames. It has a unix-lookalike "ls"-command. There are commands to teach the system new long filenames. You can safely move such files around through DOS-directories (which was not possible with the first version). This version accesses DOS-files significantly faster than the first version. Especially linking large Modula-3 programs is much faster now. On a 50 MHz 80486 with 16 MByte of RAM we measured a turn-around time of 2 minutes for a 5 module, 500 lines program. If you want to compile only one module you will have to wait about one minute. The necessary files are available at "gatekeeper.dec.com" in /pub/DEC/Modula-3/contrib/m3pc: Install.txt please read this first! djgpp.tar the DJGPP-gnu-C-compiler m3.tar compiler binaries m3src.tar sources of the compiler (optional) tar.exe program to unpack these files 5. Some specific questions 5.1. Why is "Hello World" so large? Modula-3 programs are larger than C programs for the following reasons: 1. The fixed runtime is substantially larger. It contains a garbage collector, a thread runtime, and exception support. Note that "Hello World" is virtually all runtime. For larger programs the runtime is not an issue. 2. The generated code includes runtime checks for out-of-bound array references and NIL pointer. Many of these checks could be removed by a better compiler. 5.2. Why objects and interfaces? Allan Heydon on comp.lang.modula3, May 4th 1993: Modula-3 provides two separate mechanisms for data-hiding: one for hiding details about how interfaces are implemented, and the other for hiding details about how objects are implemented. The first data-hiding mechanism is realized by the distinction between interfaces and modules. Clients can only import interfaces, so the names declared in the modules implementing those interfaces are hidden from clients. Note that this mechanism has only two levels; a name is either declared in an interface, or it isn't. If a name is only declared in a module, it can't be used by a client. The second data-hiding mechanism is realized by opaque types and revelations. A Modula-3 interface may declare an object type to be opaque, in which case only a subset of the fields and methods of that object are revealed to clients importing the interface. Furthermore, the Modula-3 revelation mechanism allows a designer to reveal successively more fields and methods of an object in a series of interfaces. The fields and methods visible to a client then depends on which interfaces the client imports. The latter mechanism is quite flexible. As opposed to the interface/module data-hiding mechanism, opaque types allow you to define an arbitrary number of levels at which more and more information about the implementation of your object is revealed. See Sections 2.2.10, 2.4.6, and 2.4.7 of "Systems Programming with Modula-3" for more information about opaque types and about partial and complete revelations. 5.3. What is the story with Trestle and OpenWindows? Mark Manasse says: I think that the OpenWindows release should be enough (no need to get the MIT X release), although there are a few things in Trestle that trigger devastating bugs in OpenWindows. But the only library we depend on is Xlib, R4 or later. The main thing I know that crashes OW 2.0 is the code where we call GrabKey specifying AnyKey. You can either loop over all of the keys, or you can just comment out the call; programs won't run exactly the same, but you probably won't notice the difference. 5.4. What is new in the 3.1 release o the compiler has a new internal interface between the front-end and the back-end, M3CG. This interface is supposed to be easy to implement. o the front-end can compute in the target arithmetic system; in particular it is possible to cross-compile to machines with larger integers than the host. o one back-end has been implemented on top of gcc. The implementation of M3CG interface generates the tree representation used internally in gcc. From the gcc point of view, this back-end looks like a new front-end. Using this back-end, they have cross- compiled solitaire for mips, alpha and 386 processors; there is no reason to believe that there would be a problem for the other architectures supported by gcc. o gdb has been modified to understand Modula-3 debugging information produced by the back-ends. gdb can now parse Modula-3 expressions, print Modula-3 values and evaluate some of the Modula-3 built-in operations. There is also a little bit of support for multi- threaded programs (you can look at the stacks of other threads). o there is a replacement for m3make, m3build, that does not rely on cpp/awk/sed/make and what not, and removes some of the limitations of m3make. m3makefiles are very similar. o libm3 has been significantly changed by the Interface Police, mostly in the area of OS interfaces and data structures. o for the OS interfaces, the U* interfaces are still there, but applications are not supposed to use those. Instead they should use a new set of interfaces that are os-independent; for example, there is a Pathname interface that manipulates file names; there is a Process interface that manipulate child processes. These interfaces enabled a prototype port of the C based version to Windows NT machines. o for the data structures, generics have been introduced and the various data structures are more consistent. o the runtime has been improved quite a bit. o new platforms: Alpha running OSF/1, 386 running Linux. More attention was paid to the porting instructions and support. 5.5. When is the next release of SRC Modula-3 ? The next release will be 3.2 and should be available soon. It should run well for at least the DS3100, SPARC and LINUX architectures. Given the amount of changes introduced by 3.1, a high rate of release can be expected for a while. While SRC can test on DS3100, ALPHA/OSF and LINUX, it can only rely on what users on other platforms tell them to integrate all the platform specific code. Because of the improved portability of the 3.1 release, ports to non Unix platforms are easier. A port to Windows NT and/or Windows 3.1 may be available in the future. The Windows NT port uses native threads. This should be a good model for other implementations of Thread using native threads. 6. FTP 6.1. How To Obtain Pre-Compiled Binaries The following binaries are available for FTP. If you are willing to provide binaries for other architectures, please contact dagenais@vlsi.polymtl.ca; they may be put on his FTP server or links to your server can be included in the FAQ. Starting with release 3.2, more detailed instructions will be included for those who need to install these binaries in different locations, for instance in their home directory. o Release 2.11 SPARC binaries. Contains everything with shared (with debugging info) and static (optimized) libraries. It can be retrieved from ftp.vlsi.polymtl.ca:lude/modula3-2.11/run.tar.Z and should be placed in /usr/local/modula3-2.11/run... Then, /usr/local/modula3-2.11/run/poly/sun4.1_sparc/bin must be added to your path. Compiled by Michel Dagenais. SPARC Modul a3-2.11 o Release 3.1 SPARC binaries. Only contains some of the libraries (libm3 and the Trestle related libraries) and only for static linking. It can be retrieved from ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/poly.tar.Z and should be placed in /usr/local/soft/modula3-3.1/run/poly... Then, /usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc/bin must be added to your path. Compiled by Michel Dagenais. SPARC M odula3-3.1 o Release 3.1 LINUX binaries. Only contains some of the libraries (libm3 and the Trestle related libraries), static and shared. It can be retrieved from ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/linuxm3.tar.gz and should be placed in /usr/local/soft/modula3-3.1... Then, /usr/local/soft/modula3-3.1/run/bin must be added to your path. Compiled by Michel Dagenais. LIN UX Modula3-3.1 6.2. What if I don't have ftp access? Unfortunately, DEC SRC cannot deliver Modula-3 other than by anonymous ftp. Fortunately, Prime Time Freeware (PTF) includes Modula-3. PTF is a set of two ISO-9660 CDroms filled with 3GB of freeware, issued semi- annually. The latest issue, Volume 1, Number 2, July 1992, contains SRC Modula-3 2.07. PTF is distributed via bookstores and mail. You can reach PTF using: Email: ptf@cfcl.com Fax: [1] (408) 738 2050 Voice: [1] (408) 738 4832 Mail: Prime Time Freeware 415-112 N. Mary Ave., Suite 50 Sunnyvale, CA 94086 USA 7. Contributing 7.1. Can I contribute Modula-3 software? Certainly. Send to m3-request@src.dec.com what you are willing to share, be it programs, libraries or other things. They will be put in the distribution. Right now, the pub/DEC/Modula-3/contrib directory contains: Contrib o m3rpc an rpc system from Xerox Parc o M2toM3 a translator from Modula-2 to Modula-3 o m3pc an implementation of Modula-3 for PCs. 7.2. ILU, an object-oriented multi-lingual RPC-capable module system The following was recently announced by Xerox PARC: Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU) system is now available for general use. WHAT'S ILU? ILU (pronounced eye'-loo) is a system that promotes software interoperability via interfaces. Interfaces between what? Whatever units of program structure are desired; we call them by the generic term "modules". They could be parts of one process, all written in the same language; they could be parts written in different languages, sharing runtime support in one memory image; they could be parts running in different memory images on different machines (on different sides of the planet). A module could even be a distributed system implemented by many programs on many machines. Calls across ILU interfaces involve only as much mechanism as necessary for the calling and called modules to interact. In particular, when the two modules are in the same memory image and use the same data representations, the calls are direct local procedure calls -- no stubs or other RPC mechanisms are involved. ILU modules are known by their interfaces. A module interface is specified once in ILU's object-oriented Interface Specification Language (called, simply, ISL). For each of the particular programming languages supported by ILU (currently Common Lisp, ANSI C, C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works), a version of the interface in that particular programming language can be generated. The ILU kernel library provides services which may be used by the language-specific interface to overcome intermodule language or address space differences. Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF DCE RPC, have strong notions of interfaces. ILU allows binding to such services provided by such systems if their interfaces can be described in ISL. ISL has been designed to facilitate such description (currently, only for ONC RPC; Courier and DCE RPC are in progress). The binding to such RPC services is done in such a way as to be indistinguishable from binding to other ILU modules. In fact, properly constructed ILU modules can appear as native RPC services, and can be manipulated by non-ILU tools designed to work with those RPC services. Similarly, the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) defines modules with explicit interfaces. ILU allows modules that can be described with a safe subset of OMG CORBA IDL to be used as ILU modules, as well, though the ILU object model is not quite the same as the OMG CORBA object model. In fact, people wishing to experiment with CORBA may find ILU a useful experimental platform, as it does allow module specification with OMG IDL, and does generate ANSI C support as specified in Draft 1.2 of the OMG CORBA specification. As the OMG specification for a C++ mapping is agreed upon, we intend to provide that mapping for our C++ support, as well. Release 1.6.4 is intended as a beta release. Major efficiency improvements and some usability improvements are planned for the next release. It has been tested lightly on SunOS 4.1.3, Sun's Solaris 2.3, and SGI's IRIX 5.2. It is designed to be highly portable, and a port to the Macintosh has been done (but is not included in this release). GETTING THE RELEASE The release is only available via FTP from the PARC ftp server. Perhaps the simplest way is to go through our World Wide Web home page, ILU It has links to everything else, and may help answer any questions you might have. The release notes are available as an HTML document. Announce The full source code, including documentation, is available as a 3 MB compressed tar file as Source The 1.6.4 ILU manual is also available separately, either in Postscript (231 KB) as Doc umentation or via World Wide Web at Documentation CONTRIBUTORS Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson, Mike Spreitzer, Mark Stefik, Farrell Wymore 8. Modula-3 for teaching Modula-3 is very well suited for teaching: simple yet powerful, and safe. It avoids the complexity of legacy languages. It can be used to demonstrate modules and interfaces, object oriented programming, multi-threading (concurrency issues), graphical user interfaces (Trestle, VBTKit, FormsVBT) and even distributed programming (Network Objects, Obliq). Since less time is spent by students and teaching assistants chasing dangling pointers and corrupted data, more time is available for learning the important concepts. It is used for teaching in a number of universities. This list is far from complete, send corrections and additions to dagenais@vlsi.polymtl.ca. From: Michael Coffin (mhcoffin@tolstoy.uwaterloo.ca) Modula-3 is being used at the University of Waterloo for both second- year CS courses and some third and fourth year courses. From: John Kominek (jmkomine@neumann.uwaterloo.ca) Modula-3 is the primary teaching language for second year core computer science courses at the University of Waterloo. From: Carsten Whimster (bcrwhims@undergrad.math.uwaterloo.ca) University of Waterloo: CS246 - Third introductory course in computer science. Software engineering and software systems. Medium size projects. Uses Modula-3 to demonstrate proper OO programming, as well as general programming practices. CS241 - Fourth and final intro course to CS. Focuses mainly on compilers and languages. Various assignments has students create most of the different parts of a compiler. Also introduces Scheme (lisp). From: Peter.Robinson@cl.cam.ac.uk University of Cambridge, England. The Computer Science course at the University of Cambridge teaches ML as an introductory language at the beginning of the freshman year, and then uses Modula-3 to develop imperative programming at the end of that year. Further lectures on advanced features of the language are given early in the second year, together with separate lectures on other, specialised languages. The course has been given to about 70 students each year since 1990, and has developed with the language. It ties in with other lectures on data structures & algorithms, software engineering and concurrency. Modula-3 is used for student group projects in the second year and for about a quarter of individual projects in the final year (where, interestingly, students using Modula-3 tend to earn higher grades than those using C/C++). Modula-3 is also used in the Computer Laboratory at Cambridge for a number of research projects on distributed computing, human-computer interaction and electronic CAD. From: Matthew.Huntbach@dcs.qmw.ac.uk We have used it for three years here at Queen Mary and Westfield College, London. The main problem I find with the language is the slow compilation speed on our teaching machines (Macs running A/UX), otherwise it's a nice language to teach with. From: laszlo@ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) University Klagenfurt Modula-3 is used at the following courses: Undergraduate: Softwaretechnology-1 (actually an introduction into programming) (on PCs) Softwaretechnology-2 (data structures and algorithms) (on PCs) Graduate: Computer Networks (on a network of DECs and SUNs) Parallel Programming (on an DEC-Alpha Farm) Modula-3 has been in use since ca. one year, with very good experiences. From: pk@i3.informatik.rwth-aachen.de (Peter Klein) Lehrstuhl fuer Informatik III, RWTH Aachen, Germany: Software Development Projects, now held for the second time using Modula-3. Aim of these projects is to introduce different aspects of software development to graduate students. This includes project planning, supervision, design, and cooperative implementation of small but usable software systems. Central ideas of software design and object- oriented implementation are presented and discussed with the concepts of Modula-3, which is also the implementation language. Future plans: Maybe Modula-3 will replace Modula-2 in some undergraduate programming lectures in the future. From: rro@cs.colostate.edu (Rod Oldehoeft) In the Computer Science Department at Colorado State University, M3 is envisioned as a vehicle for several courses. M3 is introduced in the second course (data structures) to implement the ADT concept, including generics. In the sophomore languages course, it is an example of an O-O language. In the junior software engineering course, additional relevant features are brought in, and threads are added in the junior operating systems course. From: viggo@nada.kth.se Royal Institute of Technology. Several courses at the computer science department use Modula-3. The courses contain programming projects, and many students choose to use Trestle. (Dr. Viggo Kann, viggo@nada.kth.se) From: Arnulf Mester (mester@tamfana.informatik.uni-dortmund.de) University of Dortmund, Department of Computer Science, Germany. An undergraduate course (scheduled for September) for students within their second year of studies this time takes Modula-3 as third language. Maybe later network programming courses will also use M3/NO/Obliq. The Modula-3 class has it's own WWW home page which is planned to be filled during the class in Oktober/September this year. Modul a-3 Class From: "Dave Snelling" (snelling@cs.man.ac.uk) Department of Computer Science, University of Manchester, Manchester U.K. We have a small, interdisciplinary collection of people using Modula-3 for a variety of activities. Our major production code is a hardware architecture simulator (about 120 modules). Smaller projects include a Lattice Gass model and a Shallow Water model. At: University of Massachusetts at Amherst Modula-3 is used as an input language for the Computer Science course on Compilation techniques. The professor is Eliot Moss. From: Michel Dagenais (dagenais@vlsi.polymtl.ca) Modula-3 is used as the main example in a graduate course on "Algorithmic Aspects of CAD", which includes a large portion on OO programming and databases. 9. Modula-3 In Industry A number of programming teams in industry selected Modula-3 for their project. It encourages good programming practices and comes with excellent libraries for distributed programming and graphical user interfaces. From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Sun Microsystems Laboratories, Inc. (East) is using Modula-3 (Network Objects, FormsVBT) as the basis for its research in large scale distributed object systems. From: Farshad Nayeri (nayeri@gte.com) Distributed Object Computing, GTE Labs, Waltham, Massachusetts USA Modula-3 (FormsVBT, Sx, Netobj libraries) is used to prototype distributed object management. (Farshad Nayeri nayeri@gte.com). Report From: Mike Elliott (elliottm@csulb.edu) I'm currently using M3 at Interstate Electronics Corporation 602 E. Vermont Ave. Anaheim, CA 92803 USA. The project is a trajectory simulator; that is, given an initial position, velocity, and attitude, determine data concerning a simulated aircraft at pre-determined points in time. The simulated aircraft is given a list of maneuvers to perform at specified times in the flight. The overall objective is to be able to test flight software involved in inertial and satellite navigation, by providing any desired flight path, and to be able to easily modify the simulated inertial navigation instruments and satellite readings (i.e., for different atmospheric models and different inertial gyro characteristics). Modula-3 was chosen as a fall back position. My first choice was Smalltalk, since it has a good reputation for modeling applications, but that was seen as too exotic, or too expensive, or something. The eventual implementation is to be done in Ada, and the managers wished the project to be done completely in Ada, without determining whether a suitable Ada compiler was at hand. Since one was not, and the GNAT compiler is much less mature than the SRC Modula-3 compiler, and M3 does look vaguely like Ada, I was allowed to use M3. 10. Work In Progress The purpose of this section is to let everyone know what is being worked on. This is not a commitment to a quick release or even to completion. However it may enable parties interested in the same topics to pool their efforts, avoid duplication or better integrate their packages. To find more information about the names mentioned, see the Who's Who section. 10.1. The SRC Compiler The compiler already implements the full language and runs on several platforms. Speed enhancements and support for some popular non-Unix platforms may be expected. 10.2. Modula-2 To Modula-3 Converter A better Modula-2 to Modula-3 converter (99% conversion...) is in the works under the supervision of Peter Klein. 10.3. On-Line Documentation Most library modules already contain their documentation, which may be extracted with m3totex. Bill Kalsow has been working on organizing and indexing the documentation for browsing through the World Wide Web. 10.4. Integrated Development Environment A number of groups have made experiments in this area. Tools such as VBTkit for the user interface, m3tk for syntax and dependency analysis, dynamic linking... could be used to produce such an environment. It is worth noting that precompiled interfaces are much easier to achieve in M3 than in several other popular languages. Peter Klein is working on a Modula-3 development environment and associated user interface. Klaus Preschern, Carsten Weich, Laszlo Boszormenyi have made the port of Modula-3 to the PC. The M3-PC environment will be enhanced, especially with threads and graphics, including a student-friendly environment. David N. Gray of Lucid Inc. has been experimenting with connecting the Modula-3 compiler with the Lucid Energize Programming System (currently sold as a development environment for C and C++ on Sun SPARCstations). He expects to be able to make the modified compiler available as an unsupported as-is hack in a couple of months, to accompany the new Energize release that it works with. Geoff Wyant is experimenting with FormsVBT/VBTKit to build a simple friendly development environment. 10.5. Useful Data Structures Michel Dagenais has insertable sequences. This is like the existing Sequences in libm3 except that the complexity is O(log n) instead of O(1) but elements can be inserted anywhere, not only at the top and bottom of the sequences. This is useful to keep childs in a tree automatically numbered or to efficiently keep words or paragraphs numbered while insertions are being made. This will be made available eventually but could be packaged in a relatively short time if there is a need. 10.6. Windowing And User Interfaces 10.6.1. Rotated Text Currently, there is no VBT to show non horizontal text, because of X windows limitations. This would be desirable and can be implemented in one of the following ways: a) open a pipe to the ghostscript Postscript interpreter and use it as a font renderer, cache and display the character bitmaps produced; b) have Bezier curves for the most popular Postscript fonts, Trestle handles Bezier curves; c) use the new text facilities in X11R6 that remove previous limitations. A prototype implementation of a) has been implemented by Alain Dube (contact Michel Dagenais); the performance with the cache is good but this remains a relatively complex solution. The b) solution would be relatively easy to implement but the resulting quality may not be as good as a real font renderer. The c) solution may not be available for some time since many workstation vendors take a long time before integrating the new X windows facilities. 10.6.2. Postscript VBTs It is often useful to display Postscript files in a VBT, for example for an included diagram in a document editor. This can be achieved by using the ghostscript Postscript interpreter as a rasterizer. A prototype has been programmed by Alain Dube (contact Michel Dagenais) but the performance is not too good when large color bitmaps are handled. An alternative implementation is to convert Postscript files into display lists (Bezier curves and text) as a preprocessing step. Further displaying and even editing becomes very simple. A prototype implementation of this has been done by Benoit Poirier (contact Michel Dagenais). 10.7. Persistent Objects With Pickles to store objects in files, the implementation of persistent objects is simplified. Furthermore, with the m3tk library it is not too difficult to read a type description and to write the needed methods to handle that type. Combined with FormsVBT, network objects and Obliq, all the ingredients are there to have a nice environment for developing graphical distributed applications with persistent state and querying facilities. Peter Klein has a specialized database for annotated graphs, GRAS, that is being re-implemented in Modula-3. Eliot Moss is working on persistent Modula-3 objects. The main features are persistence through reachability, load on demand and a very low overhead for using persistent objects. The high performance is obtained by modifying the compiler and run-time. Initially a modified version of GCC, GNU M3, was being worked on. However, with the release of the SRC native compiler, the modifications are being moved to the SRC compiler instead. Persistency 10.8. Abstract Syntax Tree Tools (M3 Parser) The m3tk library can be used to analyze Modula-3 source code in order to find specific constructions (use of OBSOLETE facilities, un-handled exceptions), build source code browser and analysis tools, stubs generators for network or persistent objects... Mick Jordan is preparing the 3.2 release of m3tk and finishing the documentation, in his spare time. From: hudson@yough.ucs.umass.edu (Rick Hudson) If anyone is interested we have developed a Bison grammar that parses the Modula-3 language input. If interested please feel free to contact me hudson@cs.umass.edu. 10.9. Computer Assisted Learning Tools (Algorithm Animation) The Zeus Algorithm Animation package may be used to quickly develop graphical and animated teaching aids. Most of the algorithms described in Robert Sedgewick's Algorithms book have been animated at DEC SRC through the work of Marc H. Brown. Animation of compilation techniques have been produced by students at University of Illinois with the help of Marc Najork. Animation of Memory Hierarchy (Disk, RAM, Cache) has been produced by Michel Dagenais and should be released soon, after some tuning and packaging. From: "Arnulf Mester" (mester@ls4.informatik.uni-dortmund.de) As part of a studental project advised by a college of mine and me a Mentor-like collection of Zeus-based animations of typical distributed algorithms and communication protocols (termed ZADA) has been compiled. Hopefully I'll get to include more information and access during the next weeks into our ZADA WWW home page ZADA 10.10. Presentations, Tutorials And Teaching Material Modula 3 is used for teaching in a number of Universities. Some Modula-3 related teaching material may be shared between interested parties. Michel Dagenais has a French presentation about the Modula 3 language that could be distributed. An English presentation about the Modula-3 environment and libraries should be available later this summer. Geoff Wyant is preparing a tutorial on Modula-3 for the upcoming OOPSLA conference. 10.11. Reports And Books Sam Harbison is preparing a revised version of his existing book on Modula-3. He may include more material on the new libraries. Laszlo Boszormenyi, Roland Mittermeir and Carsten Weich are working on a book (it will be published in German and in English) with the work- title: "Programming in Style - An Introduction into Programming with Modula-3" The book will be published at Springer (in German in October 1994, in English maybe or December, or January 1995). For the book, the M3-PC environment will be enhanced, especially with threads and graphics, including a student-friendly environment. A book about writing distributed object oriented applications, using Modula-3, m3build, m3gdb, analyze_coverage, FormsVBT, Obliq and Network Objects is being planned by Geoff Wyant, Farshad Nayeri and Michel Dagenais. 10.12. Matrix Algebra From: Mike Elliott (elliottm@csulb.edu) Interstate Electronics Corporation My project involves a lot of matrix algebra -- I'm loaded down with vectors and direction cosine matrices and stuff -- and I really wish I had a good matrix algebra library to use. I'm developing routines, but I'm currently unconvinced that my design and implementation are optimal. 10.13. Floating Point Geometry Library Currently, an Integer geometry package is available in libm3. Portions of an equivalent floating point counterpart is available in other applications such as Zeus/Mentor. Michel Dagenais has packaged these and completed some. It has been contributed to m3-request@src.dec.com but may be distributed to those that simply cannot wait. 10.14. Parallel Programming Ernst A. Heinz writes the following: I would like to inform you about our ongoing Modula-3* project here at the University of Karlsruhe. At the moment, we are actively involved in adding sophisticated dependence and data flow analysis to DEC's Modula-3 compiler (release 3.x!). The Modula-3* compiler will be able to generate code for real parallel machines, for networks of workstations, and for standard sequential execution. (Our new IPD Modula-2* system available by anonymous ftp from ftp.ira.uka.de in "pub/programming/modula2star" may give you an initial feeling about it!) Beside my JSPP'93 paper I have already written an extended abstract about a unifying semantics specification for sequential and parallel exception handling in Modula-3*. This will soon be extended to a complete unifying semantics specification for Modula-3* as a whole! For all interested folks I have made my JSPP'93 paper publicly available by anonymous ftp. The title of the paper reads as follows: "Modula-3*: An Efficiently Compilable Extension of Modula-3 for Problem-Oriented Explicitly Parallel Programming". To retrieve DVI, PostScript, or compressed Postscript versions of the paper please connect to i41s10.ira.uka.de by anonymous ftp. There, the directory pub/m3s contains the corresponding files named jspp93.dvi, jspp93.ps, and jspp93.ps.Z. Paper -rw-r----- 1 ftp ftp 41604 Jul 14 11:33 jspp93.dvi -rw-r----- 1 ftp ftp 147100 Jul 14 11:33 jspp93.ps -rw-r----- 1 ftp ftp 59443 Jul 14 11:34 jspp93.ps.Z Don't forget to use binary mode when retrieving the DVI or compressed PostScript versions! Please send me a short email containing your full name and address plus affiliation if you retrieve any of the above. For your information I see the abstract of my JSPP'93 paper below. 10.14.1. PROBLEM-ORIENTED EXPLICITLY PARALLEL PROGRAMMING MODULA-3*: AN EFFICIENTLY COMPILABLE EXTENSION OF MODULA-3 FOR Ernst A. Heinz, University of Karlsruhe, F.R. Germany (email: heinze@ira.uka.de) In this paper we present the programming language Modula-3* and machine-independent optimization techniques for its compilation. We consider Modula-3* to be a promising new framework for problem- oriented explicitly parallel programming that aims at high performance on a variety of architectures and machines. By proposing a large collection of effective optimizations we illustrate the feasibility of efficient Modula-3* compilation. We ensure portability of the compiler by formulating most optimizations as source-to-source transformations in the intermediate high-level language Modula-3pi, an extension of Modula-3* especially designed for this task. 11. Wish List The Modula-3 development environment now contains a large number of very good tools and libraries that work nicely together. The purpose of this section is to help contributors determine what additions would be helpful to others. It may get you in contact with people that would like to use your contribution or with people that may provide some items on your wanted list or team with you for their development. 11.1. M3Build The descriptions of programs and libraries stored in m3makefiles are simple and efficient. It would be interesting to be able to specify different m3-options for some files (debugging, performance analysis...), and to have the dependency analysis take into account previously used options when determining modules to recompile (Michel Dagenais). Although makefiles cannot perform the same consistency checks as m3build and are more cumbersome to use, it may be useful to be able to drive the compiler through makefiles for training purposes (i.e. learn Modula-3 and Makefiles at the same time) (bwbecker@watdragon.uwaterloo.ca). 11.2. Coverage And Performance Analysis Tools already exist for coverage analysis, pretty printing, performance analysis, viewing the threads and the garbage collected heap. It would be nice to have these easily accessible through an integrated development environment (Michel Dagenais). 11.3. More VBTs An editor widget with multiple fonts (fixed and proportional character spacing) perhaps even with direct support for HTML (item lists, centered headings...) (Geoff Wyant). A split VBT that positions NxM childs in aligned rows and columns (Geoff Wyant). A Graph VBT that displays arbitrary graphs (such as call trees, cross references...). This could be implemented adding a placement module (to determine the vertex positions) to work on the existing GraphVBT module (Geoff Wyant). Some of the VBTs implemented in miscellaneous libraries (such as GraphVBT in Mentor/Zeus) could be placed in a more visible location such as VBTKit (Michel Dagenais). 11.4. Distributed Computing (Network Objects) Network objects are an exciting recent addition. The underlying model is very simple and effective. Authentication and access control will be required in many applications. A network object daemon that starts specific programs upon need, like inetd does using inetd.conf for most network services, would be very useful (Michel Dagenais). 11.5. Interfaces To Other Libraries And Programs (Tcl, Dps...) C functions are easily called from Modula 3. Thus, stubs have been produced to access John Ousterhout's Tcl and also Display Postscript from Modula 3. An automatic tool to produce such stubs from .h C files would be very useful (Geoff Wyant). A similar tool available for ADA may be modified for that purpose (Michel Dagenais). Stubs to access the Motif X Windows library would be useful (Geoff Wyant). Similar stubs would be desirable to access databases such as Postgres or Exodus and access/provide World Wide Web information using the hypertext transfer protocol libraries (HTTP) (Geoff Wyant). 12. Who's Who Modula-3 enthusiasts, users or contributors. Please notify me for additions, corrections or removals. o Robert Ayers, Adobe, (ayers@Mv.Us.Adobe.Com), the Display Postscript to Modula-3 interface o Andrew Birrell, DEC SRC, Network objects. o Laszlo Boeszoermenyi, Universitaet Klagenfurt, Austria, (laszlo@ifi.uni-klu.ac.at), PC port (m3pc), Programming in style book. o Marc H. Brown, DEC SRC, VBTKit, FormsVBT, Zeus. o Luca Cardelli, DEC SRC, Modula-3 definition, Obliq. o Michel Dagenais, Ecole Polytechnique de Montreal, (dagenais@vlsi.polymtl.ca), LINUX and SPARC M3 binaries, M3 FAQ. o John D. DeTreville, DEC SRC, Incremental garbage collector. o David N. Gray, Lucid Inc., Menlo Park, (gray@Lucid.Com), interface between the Lucid environment and the M3 compiler. o Sam Harbison, Tartan, harbison@tartan.com, Modula-3 book. o Ernst A. Heinz, University of Karlsruhe, F.R. Germany (heinze@ira.uka.de) o Jim Horning, DEC SRC, Useful Modula-3 interfaces. o Rick Hudson, University of Massachusetts at Amherst, (hudson@cs.umass.edu), GNU Modula-3. o Mick Jordan, Sunlabs near Palo Alto, Modula-3 definition, M3TK and related tools. o Bill Kalsow, DEC SRC, Modula-3 definition, M3 compiler and run- time. o Peter Klein, Lehrstuhl fuer Informatik III, (pk@i3.informatik.rwth- aachen.de). Modula-2 to Modula-3 converter. o Mark S. Manasse, DEC SRC, Trestle. o Paul McJones, DEC SRC, Useful Modula-3 interfaces. o James R. Meehan, DEC SRC, VBTKit, FormsVBT. o Roland Mittermeir, Universitaet Klagenfurt, Austria, (mittermeir@ifi.uni-klu.ac.at), Programming in style book. o Eliot Moss, University Of Massachusetts At Amherst, (moss@Cs.Umass.Edu), GNU Modula-3. o Eric Muller, DEC SRC, M3 compiler and run-time. o Marc Najork, DEC SRC, 3D animation. o Greg Nelson, DEC SRC, Modula-3 definition, Systems Programming with Modula-3 book editor, Trestle, Network objects. o Farshad Nayeri, GTE Near Boston, (fn00@Gte.Com), m3-sparc mailing list. o Frode Odegard, (frode@Odegard.Com), commercial Modula-3 support. o Susan Owicki, DEC SRC, Network objects. o Klaus Preschern, Universitaet Klagenfurt, Austria, (preschern@ifi.uni-klu.ac.at), PC port (m3pc). o Robert Sedgewick, Princeton University, Algorithms in Modula-3 book. o Jorge Stolfi, Brazil, Computational geometry procedures. o Carsten Weich, Universitaet Klagenfurt, Austria, (weich@ifi.uni- klu.ac.at), PC port (m3pc), Programming in style book. o Edward Wobber, DEC SRC, Network objects. o Geoff Wyant, Sunlabs Near Boston, (gwyant@East.Sun.COM), SPARC port. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 43 === Date: Fri, 27 May 1994 09:57:56 -0700 (PDT) From: David L Miller Subject: Re: Macros in Modula-3 You could use the C-style macros and run your code through the C pre-processor before compiling, but that is very ugly... |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing, JE-20 4545 15th Ave NE, Seattle WA 98105, USA On Fri, 27 May 1994, Salman Ahmed wrote: > Is there any way to define Macros in Modula-3 the way C allows (sth like this : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex). > > Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA > > Thanks in advance. > > > -- > > _Salman Ahmed_ > > > ----------------------------------------------------------------------------- - > > "Remember when you were young, you shone like the sun, > Shine on you Crazy Diamond ..... > > Come on you raver, you seer of visions, come on you painter, you piper, > you prisoner, and shine!" > - Pink Floyd > > ======================================================================= 44 === Date: Fri, 27 May 1994 13:46:44 GMT From: ssahmed@napier.uwaterloo.ca (Salman Ahmed) Subject: Macros in Modula-3 Is there any way to define Macros in Modula-3 the way C allows (sth like this : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex). Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA Thanks in advance. -- _Salman Ahmed_ ------------------------------------------------------------------------------ "Remember when you were young, you shone like the sun, Shine on you Crazy Diamond ..... Come on you raver, you seer of visions, come on you painter, you piper, you prisoner, and shine!" - Pink Floyd ======================================================================= 45 === Date: 27 May 1994 18:47:23 GMT From: najork@src.dec.com (Marc Najork) Subject: Re: Macros in Modula-3 One use of macros is to inline non-recursive function definitions. The m3 <* INLINE *> pragma is intended to provide a safer way to do this. Here is what SPwM3 has to say about INLINE: We recommend supporting the two pragmas <* INLINE *> and <* EXTERNAL *>. The pragma <* INLINE *> precedes a procedure declaration to indicate that the procedure should be expanded at the point of call. And here is what Harbison has to say: The pragma <* INLINE *> can precede a procedure declaration to indicate that calls to the procedure should be expanded in-line, eliminating the overhead of an actual call. Inlined procedures can be local to a module or can be exported from an interface (in which case the INLINE pragma should appear in the interface). Some Modula-3 implementations may ignore the INLINE pragma completely. Others may be unable to in-line procedures imported from interfaces, because that is difficult to implement. Methods probably cannot be inlined, since inlining is not compatible with dynamic binding. Unfortunately, as far as SRC m3 goes, INLINE hasn't been implemented (yet). -- Marc ======================================================================= 46 === Date: 28 May 1994 10:15:11 GMT From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Re: Macros in Modula-3 Karl-Heinz Eder is working (with a group of students) on a macro-preprocessor for M3. His mail-adress is charly@ifi.uni-klu.ac.at ********************************* * Prof. Laszlo Boeszoermenyi * * Institut fuer Informatik * * * * Universitaet Klagenfurt * * Universitaetsstr. 65-67 * * A-9022 Klagenfurt / Austria * * * * e-mail: * * laszlo@ifi.uni-klu.ac.at * * Tel.: * * 00-43-463-2700-509 * * 00-43-463-2700-506 (secr.) * * Fax.: * * 00-43-463-2700-505 * ********************************* ======================================================================= 47 === Date: Mon, 30 May 1994 06:06:33 GMT From: brister@netcom.com (james brister) Subject: BSDI port? Has anyone ported M3 to BSDI (1.1)? I'll probably attempt to port the LINUX version myself if no-one else has done it. Thanks James -- James Brister brister@vix.com decwrl!vixie!brister ======================================================================= 48 === Date: 30 May 1994 02:54:04 GMT From: hendrik@CAM.ORG (Hendrik Boom) Subject: Re: Macros in Modula-3 David L Miller (dlm@cac.washington.edu) wrote: : You could use the C-style macros and run your code through the C : pre-processor before compiling, but that is very ugly... If you're going to use an off-the-shelf macro processor, you are probably better off with ML/1, a portable macro processor written in the 60's by P.J. Brown, and distributed through DECUS. I'm not sure what the appropriate source for ML/1 is now, but I hear runours that someone in England, possibly at the University of Canterbury in Kent, maintains it and does ports. If anyone has better information, please let me know. I have a not-up-to-date copy, but it would take quite some effort to dearchive it, and I have mislaid the documentation. ML/1 macros are specified using a sequence of delimiters, not just a name. I have used them to add statements like the following to Algol W: for i in list x do uuu where i, x, and uuu are macro parameters, and 'uuu' evennests properly, allowing begin-end blocks or just a statement ending in a semicolon. I have always thought is a shame that the C macro processor ignores all that was known about macro processing at the time, but has become the de-facto canonical macro processor today, even though it is woefully inadequate even for C. : |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 : |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) : University of Washington, Networks & Distributed Computing, JE-20 : 4545 15th Ave NE, Seattle WA 98105, USA : On Fri, 27 May 1994, Salman Ahmed wrote: : > Is there any way to define Macros in Modula-3 the way C allows (sth like th is : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex). : > : > Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA : > : > Thanks in advance. : > : > : > -- : > : > _Salman Ahmed_ : > : > : > --------------------------------------------------------------------------- --- : > : > "Remember when you were young, you shone like the sun, : > Shine on you Crazy Diamond ..... : > : > Come on you raver, you seer of visions, come on you painter, you piper, : > you prisoner, and shine!" : > - Pink Floyd : > : > ======================================================================= 49 === Date: Mon, 30 May 1994 01:06:01 From: j_mcarthur@BIX.com (Jeffrey McArthur) Subject: Re: Macros in Modula-3 A slightly more radical approach would be convert one of the Literate programming tools to Modula-3. Since Modula-3 is based on Modula-2 it would not be much work to convert Mangle and Meave to process Modula-3 instead of Modula-2 syntax. This would give the added bonus of full literate programming techniques. ---- Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur a.k.a. Jeffrey McArthur ATLIS Publishing phone: (301) 210-6655 12001 Indian Creek Court fax: (301) 210-4999 Beltsville, MD 20705 home: (410) 290-6935 email: j_mcarthur@bix.com The opinions express are mine and mine alone. They do not reflect the opinions of ATLIS Publishing or any part of ATLIS Systems. ATLIS does NOT pay for my access to the Internet. ======================================================================= 50 === Date: 30 May 1994 12:55:40 GMT From: stolfi@cmos.dcc.unicamp.br (Jorge Stolfi) Subject: Re: Fixed Point vs. Floating Point To: dewar@cs.nyu.edu (Robert Dewar) In-reply-to: dewar@cs.nyu.edu's message of 30 May 1994 02:29:57 -0400 Mime-Version: 1.0 Content-Type: text/plain, charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Fixed Point vs. Floating Point Reply-to: stolfi@dcc.unicamp.br --text follows this line-- > If it is really true that Modula 3 requires all intermediate > results to be in the "correct" floating-point type, then the > code must be truly horrible on a Pentium. That's the trouble, > this most obvious semantics isn't viable as the only possible > semantics on machines like the Pentium which do all arithmetic > in extended mode. Well, The philosophy (if not the letter) of the Modula-3 spec requires that the same expression evaluates to the same value on any IEEE-conforming machine. (This, if you recall, was also the primary motivation behind the IEEE standard.) Since the extended mode is not part of the IEEE standard, and may not be available on all machines, it follows that any arithmetic expression involving double-precision quantities must be evaluated using double-precision operations and temporaries. If you DO want Modula-3 to evaluate an expression with extended-precision, just convert the operands to EXTENDED, or declare them that way. --stolfi PS. Pardon my ignorance, but I thought that the IEEE standard required that the result of A := B * C be correctly rounded in all cases. Does that work correctly on the Pentium? (i.e. will the Pentium round B*C to the nearest extended, and then round the result to the nearest double? Is that equivalent to rounding B*C to the nearest double?) -------------------------------------------------------------------- Jorge Stolfi | Tel: +55 (192) 39-8442 Computer Science Dept. (DCC-IMECC) | +55 (192) 39-3115 Universidade Estadual de Campinas (UNICAMP) | Internet: stolfi@dcc.unicamp.br | Fax: +55 (192) 39-7470 -------------------------------------------------------------------- ======================================================================= 51 === Date: 30 May 1994 17:48:56 GMT From: krste@ICSI.Berkeley.EDU (Krste Asanovic) Subject: Re: Fixed Point vs. Floating Point In article , stolfi@cmos.dcc.unicamp. br (Jorge Stolfi) writes: |> |> Since the extended mode is not part of the IEEE standard, and may not |> be available on all machines, it follows that any arithmetic |> expression involving double-precision quantities must be evaluated |> using double-precision operations and temporaries. I thought double-precision was not a required part of the standard either :-) (see Sec 3.4) -- Krste Asanovic International Computer Science Institute Email: krste@icsi.berkeley.edu 1947 Center Street, Phone: +1 (510) 642-4274 x143 Berkeley, CA 94704, USA Fax: +1 (510) 643-7684 ======================================================================= 52 === Date: Mon, 30 May 94 22:53:54 GMT From: Scott Martin Subject: Re: Macros in Modula-3 > Is there any way to define Macros in Modula-3 the way C allows (sth like this : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex). > > Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA > > Thanks in advance. > > > -- > > _Salman Ahmed_ > Oh please no, let's not stuff M3 up with dangerous shortcuts! Scott ======================================================================= 53 === Date: 31 May 1994 15:36:36 +0800 From: lingo@perth.DIALix.oz.au (Bill Rayer) Subject: Re: Fixed Point vs. Floating Point Hello everyone I've been following this thread with interest for a week or so. What is anyone's view on the "currency" format used in Microsoft Quick basic? This stores an integer in 8 bytes with implicit decimal scaling of 10,000. Thus it represents fractional values exactly (to 4 decimal places) Bill Rayer lingo@dialix.oz.au ======================================================================= 54 === Date: 31 May 1994 06:25:12 GMT From: stolfi@cmos.dcc.unicamp.br (Jorge Stolfi) Subject: Re: Fixed Point vs. Floating Point > [Me:] Pardon my ignorance, but I thought that the IEEE standard > required that the result of A := B * C be correctly rounded in > all cases. Does that work correctly on the Pentium? Well, I have just been told (by e-mail) that the Pentium will indeed round B*C to the nearest extended; and then, if requested, round the result to the nearest single or double. Which is not in general equivalent to directly rounding B*C to the nearest single double. If this is true, does it mean that the Pentium does NOT conform to the IEEE FP standard? Will my next PC come with a sticker saying "Intel inside, IEEE out there somewhere"? 8-) Is this the beginning of the end of the IEEE standard? --stolfi -------------------------------------------------------------------- Jorge Stolfi | Tel: +55 (192) 39-8442 Computer Science Dept. (DCC-IMECC) | +55 (192) 39-3115 Universidade Estadual de Campinas (UNICAMP) | Internet: stolfi@dcc.unicamp.br | Fax: +55 (192) 39-7470 -------------------------------------------------------------------- ======================================================================= 55 === Date: Tue, 31 May 1994 14:12:46 GMT From: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Macros in Modula-3 A slightly more radical approach would be convert one of the Literate programming tools to Modula-3. Since Modula-3 is based on Modula-2 it would not be much work to convert Mangle and Meave to process Modula-3 instead of Modula-2 syntax. This would give the added bonus of full literate programming techniques. You already get a form of literate programming with m3totex. As a matter of fact, several libraries (libm3, Trestle, VBTKit, FormsVBT...) are already documented in this way. This may not be a direct consequence, but the M3 libraries are much better documented than most publically available libraries on the net. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 56 === Date: Tue, 31 May 94 15:36:46 EDT From: BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin) Subject: m3build problem Help. I just built m3.3.1. When trying to use m3build I get an error on reading the first line of the first interface file in my src directory to the effect that a) RT0.i3 can't be found and b) RT0.i3 isn't an interface. Well, RT0.i3 is in my usr/local/m3/include as I expect, but it seems m3build expects otherwise. What did I do wrong? Oh yes, after issuing m3boot and m3ship on my DecStation, I did delete the build directory boot-RS3100. Thanks. ======================================================================= 57 === Date: 1 Jun 1994 01:02:54 GMT From: stolfi@cmos.dcc.unicamp.br (Jorge Stolfi) Subject: Re: Fixed Point vs. Floating Point > [Me:] I have been told that the Pentium will round B*C to the > nearest extended; and then, if requested, round the result to > the nearest single or double. Which is not in general > equivalent to directly rounding B*C to the nearest single > double. Oops! It seems I have, hum, extrapolated a bit from what people told me. Douglas Priest and Norbert Juffa kindly explained to me that, by setting two "precision" bits in the Pentium's FP control register, one *can* get "A op B" correctly rounded to single or double, in just one step. So the Pentium IS IEEE compliant --- almost. Why "almost"? Well, there are two little snags. (1) Setting the control bits correctly may be quite a hassle. At the very least, they have to be set between any two consecutive operations with different precisions; and perhaps at other times too, e.g. on procedure boundaries. I don't know how easy that operation is on the Pentium. I would guess it requires 1. storing the FP control register into memory; 2. loading that word into an ordinary register; 3. masking off the two precision bits; 4. setting them to the desired value; 5. storing the modified word into memory; 6. loading that word into the FP control register; 7. performing the operation. Yuck. (2) It seems that, in register-to-register operations, the control bits only determine the precision of the *mantissa*, but not the range of the exponent. So, single- or double-precision intermediate results which would be denormalized or infinite in a strict IEEE machine may retain full precision when computed on the Pentium; and this extra precision may affect the final result. Some of these effects may be avoidable by forcing a store+load of every intermediate result to memory, thus forcing low-exponent values to be denormalized. However, besides being expensive, this solution will cause those denormals to be rounded twice, which is incorrect. Thus, as my informant put it, "the goal of getting the same result on any IEEE machine is not likely to be achieved." Would some Pentium expert please check these comments? --stolfi -------------------------------------------------------------------- Jorge Stolfi | Tel: +55 (192) 39-8442 Computer Science Dept. (DCC-IMECC) | +55 (192) 39-3115 Universidade Estadual de Campinas (UNICAMP) | Internet: stolfi@dcc.unicamp.br | Fax: +55 (192) 39-7470 -------------------------------------------------------------------- ======================================================================= 58 === Date: 31 May 94 22:54:41 From: fn00@gte.com (Farshad Nayeri) Subject: Re: m3build problem In article <9405311943.AA06958@inet-gw-1.pa.dec.com> BERGINF@PACEVM.DAC.PACE.ED U (Joseph Bergin) writes: Help. I just built m3.3.1. When trying to use m3build I get an error on reading the first line of the first interface file in my src directory to the effect that a) RT0.i3 can't be found and b) RT0.i3 isn't an interface. Well, RT0.i3 is in my usr/local/m3/include as I expect, but it seems m3build expects otherwise. What did I do wrong? Oh yes, after issuing m3boot and m3ship on my DecStation, I did delete the build directory boot-RS3100. Thanks. Starting with version 3.?, SRC Modula-3 requires that you include a line "import (libm3)" in your m3makefile; this statement was left out of the example "m3makefile" in the 3.1 documentation. To fix, just add "import (libm3)" in your favorite m3makefile. I believe the documentation error has been fixed for release 3.2, so this may not be an FAQ for much longer. --farshad -- /// | {@,@} | (...) Farshad Nayeri | ...neat quote coming soon... " " nayeri@gte.com |